| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3079
|
High |
|
N/A
|
Type confusion in V8 in Google Chrome prior to 114.0.5735.110 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) |
["http://packetstormsecurity.com/files/176211/Chrome-V8-Type-Confusion.html","http://packetstormsecurity.com/files/176212/Chrome-V8-Type-Confusion-New-Sandbox-Escape.html","https://chromereleases.googleblog.com/2023/06/stable-channel-update-for-desktop.html","https://crbug.com/1450481","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DYTXO5E3FI3I2ETDP3HF4SHYYTFMKMIC/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/U4OXTNIZY4JYHJT7CVLPAJQILI6BISVM/","https://security.gentoo.org/glsa/202311-11","https://security.gentoo.org/glsa/202401-34","https://www.couchbase.com/alerts/","https://www.debian.org/security/2023/dsa-5420","http://packetstormsecurity.com/files/176211/Chrome-V8-Type-Confusion.html","http://packetstormsecurity.com/files/176212/Chrome-V8-Type-Confusion-New-Sandbox-Escape.html","https://chromereleases.googleblog.com/2023/06/stable-channel-update-for-desktop.html","https://crbug.com/1450481","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DYTXO5E3FI3I2ETDP3HF4SHYYTFMKMIC/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/U4OXTNIZY4JYHJT7CVLPAJQILI6BISVM/","https://security.gentoo.org/glsa/202311-11","https://security.gentoo.org/glsa/202401-34","https://www.couchbase.com/alerts/","https://www.debian.org/security/2023/dsa-5420"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-0266
|
High |
fixed |
- 4.14.303
- 4.19.270
- 5.4.229
- 5.10.163
- 5.15.88
- 6.1.6
|
A use after free vulnerability exists in the ALSA PCM package in the Linux Kernel. SNDRV_CTL_IOCTL_ELEM_{READ|WRITE}32 is missing locks that can be used in a use-after-free that can result in a priviledge escalation to gain ring0 access from the system user. We recommend upgrading past commit 56b88b50565cd8b946a2d00b0c83927b7ebb055e |
["https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.10/alsa-pcm-move-rwsem-lock-inside-snd_ctl_elem_read-to-prevent-uaf.patch?id=72783cf35e6c55bca84c4bb7b776c58152856fd4","https://github.com/torvalds/linux/commit/56b88b50565cd8b946a2d00b0c83927b7ebb055e","https://github.com/torvalds/linux/commit/becf9e5d553c2389d857a3c178ce80fdb34a02e1","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.10/alsa-pcm-move-rwsem-lock-inside-snd_ctl_elem_read-to-prevent-uaf.patch?id=72783cf35e6c55bca84c4bb7b776c58152856fd4","https://github.com/torvalds/linux/commit/56b88b50565cd8b946a2d00b0c83927b7ebb055e","https://github.com/torvalds/linux/commit/becf9e5d553c2389d857a3c178ce80fdb34a02e1","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-1086
|
High |
fixed |
- 5.15.149
- 6.1.76
- 6.6.15
- 6.7.3
|
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.
The nft_verdict_init() function allows positive values as drop error within the hook verdict, and hence the nf_hook_slow() function can cause a double free vulnerability when NF_DROP is issued with a drop error which resembles NF_ACCEPT.
We recommend upgrading past commit f342de4e2f33e0e39165d8639387aa6c19dff660. |
["http://www.openwall.com/lists/oss-security/2024/04/10/22","http://www.openwall.com/lists/oss-security/2024/04/10/23","http://www.openwall.com/lists/oss-security/2024/04/14/1","http://www.openwall.com/lists/oss-security/2024/04/15/2","http://www.openwall.com/lists/oss-security/2024/04/17/5","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f342de4e2f33e0e39165d8639387aa6c19dff660","https://github.com/Notselwyn/CVE-2024-1086","https://kernel.dance/f342de4e2f33e0e39165d8639387aa6c19dff660","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7LSPIOMIJYTLZB6QKPQVVAYSUETUWKPF/","https://news.ycombinator.com/item?id=39828424","https://pwning.tech/nftables/","https://security.netapp.com/advisory/ntap-20240614-0009/","http://www.openwall.com/lists/oss-security/2024/04/10/22","http://www.openwall.com/lists/oss-security/2024/04/10/23","http://www.openwall.com/lists/oss-security/2024/04/14/1","http://www.openwall.com/lists/oss-security/2024/04/15/2","http://www.openwall.com/lists/oss-security/2024/04/17/5","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f342de4e2f33e0e39165d8639387aa6c19dff660","https://github.com/Notselwyn/CVE-2024-1086","https://kernel.dance/f342de4e2f33e0e39165d8639387aa6c19dff660","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7LSPIOMIJYTLZB6QKPQVVAYSUETUWKPF/","https://news.ycombinator.com/item?id=39828424","https://pwning.tech/nftables/","https://security.netapp.com/advisory/ntap-20240614-0009/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53104
|
High |
fixed |
- 4.19.324
- 5.4.286
- 5.10.230
- 5.15.172
- 6.1.117
- 6.6.61
- 6.11.8
- 6.12.1
|
In the Linux kernel, the following vulnerability has been resolved:
media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format
This can lead to out of bounds writes since frames of this type were not
taken into account when calculating the size of the frames buffer in
uvc_parse_streaming. |
["https://git.kernel.org/stable/c/1ee9d9122801eb688783acd07791f2906b87cb4f","https://git.kernel.org/stable/c/467d84dc78c9abf6b217ada22b3fdba336262e29","https://git.kernel.org/stable/c/575a562f7a3ec2d54ff77ab6810e3fbceef2a91d","https://git.kernel.org/stable/c/622ad10aae5f5e03b7927ea95f7f32812f692bb5","https://git.kernel.org/stable/c/684022f81f128338fe3587ec967459669a1204ae","https://git.kernel.org/stable/c/95edf13a48e75dc2cc5b0bc57bf90d6948a22fe8","https://git.kernel.org/stable/c/beced2cb09b58c1243733f374c560a55382003d6","https://git.kernel.org/stable/c/ecf2b43018da9579842c774b7f35dbe11b5c38dd","https://git.kernel.org/stable/c/faff5bbb2762c44ec7426037b3000e77a11d6773"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53197
|
High |
fixed |
- 4.19.325
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices
A bogus device can provide a bNumConfigurations value that exceeds the
initial value used in usb_get_configuration for allocating dev->config.
This can lead to out-of-bounds accesses later, e.g. in
usb_destroy_configuration. |
["https://git.kernel.org/stable/c/0b4ea4bfe16566b84645ded1403756a2dc4e0f19","https://git.kernel.org/stable/c/379d3b9799d9da953391e973b934764f01e03960","https://git.kernel.org/stable/c/62dc01c83fa71e10446ee4c31e0e3d5d1291e865","https://git.kernel.org/stable/c/920a369a9f014f10ec282fd298d0666129379f1b","https://git.kernel.org/stable/c/9887d859cd60727432a01564e8f91302d361b72b","https://git.kernel.org/stable/c/9b8460a2a7ce478e0b625af7c56d444dc24190f7","https://git.kernel.org/stable/c/b521b53ac6eb04e41c03f46f7fe452e4d8e9bcca","https://git.kernel.org/stable/c/b8f8b81dabe52b413fe9e062e8a852c48dd0680d","https://git.kernel.org/stable/c/b909df18ce2a998afef81d58bbd1a05dc0788c40"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36971
|
High |
fixed |
- 4.19.316
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.94
- 6.6.34
- 6.9.4
|
In the Linux kernel, the following vulnerability has been resolved:
net: fix __dst_negative_advice() race
__dst_negative_advice() does not enforce proper RCU rules when
sk->dst_cache must be cleared, leading to possible UAF.
RCU rules are that we must first clear sk->sk_dst_cache,
then call dst_release(old_dst).
Note that sk_dst_reset(sk) is implementing this protocol correctly,
while __dst_negative_advice() uses the wrong order.
Given that ip6_negative_advice() has special logic
against RTF_CACHE, this means each of the three ->negative_advice()
existing methods must perform the sk_dst_reset() themselves.
Note the check against NULL dst is centralized in
__dst_negative_advice(), there is no need to duplicate
it in various callbacks.
Many thanks to Clement Lecigne for tracking this issue.
This old bug became visible after the blamed commit, using UDP sockets. |
["https://git.kernel.org/stable/c/051c0bde9f0450a2ec3d62a86d2a0d2fad117f13","https://git.kernel.org/stable/c/2295a7ef5c8c49241bff769e7826ef2582e532a6","https://git.kernel.org/stable/c/5af198c387128a9d2ddd620b0f0803564a4d4508","https://git.kernel.org/stable/c/81dd3c82a456b0015461754be7cb2693991421b4","https://git.kernel.org/stable/c/92f1655aa2b2294d0b49925f3b875a634bd3b59e","https://git.kernel.org/stable/c/b8af8e6118a6605f0e495a58d591ca94a85a50fc","https://git.kernel.org/stable/c/db0082825037794c5dba9959c9de13ca34cc5e72","https://git.kernel.org/stable/c/eacb8b195579c174a6d3e12a9690b206eb7f28cf","https://git.kernel.org/stable/c/051c0bde9f0450a2ec3d62a86d2a0d2fad117f13","https://git.kernel.org/stable/c/2295a7ef5c8c49241bff769e7826ef2582e532a6","https://git.kernel.org/stable/c/5af198c387128a9d2ddd620b0f0803564a4d4508","https://git.kernel.org/stable/c/81dd3c82a456b0015461754be7cb2693991421b4","https://git.kernel.org/stable/c/92f1655aa2b2294d0b49925f3b875a634bd3b59e","https://git.kernel.org/stable/c/b8af8e6118a6605f0e495a58d591ca94a85a50fc","https://git.kernel.org/stable/c/db0082825037794c5dba9959c9de13ca34cc5e72","https://git.kernel.org/stable/c/eacb8b195579c174a6d3e12a9690b206eb7f28cf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53150
|
High |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Fix out of bounds reads when finding clock sources
The current USB-audio driver code doesn't check bLength of each
descriptor at traversing for clock descriptors. That is, when a
device provides a bogus descriptor with a shorter bLength, the driver
might hit out-of-bounds reads.
For addressing it, this patch adds sanity checks to the validator
functions for the clock descriptor traversal. When the descriptor
length is shorter than expected, it's skipped in the loop.
For the clock source and clock multiplier descriptors, we can just
check bLength against the sizeof() of each descriptor type.
OTOH, the clock selector descriptor of UAC2 and UAC3 has an array
of bNrInPins elements and two more fields at its tail, hence those
have to be checked in addition to the sizeof() check. |
["https://git.kernel.org/stable/c/096bb5b43edf755bc4477e64004fa3a20539ec2f","https://git.kernel.org/stable/c/45a92cbc88e4013bfed7fd2ccab3ade45f8e896b","https://git.kernel.org/stable/c/74cb86e1006c5437b1d90084d22018da30fddc77","https://git.kernel.org/stable/c/a3dd4d63eeb452cfb064a13862fb376ab108f6a6","https://git.kernel.org/stable/c/a632bdcb359fd8145e86486ff8612da98e239acd","https://git.kernel.org/stable/c/ab011f7439d9bbfd34fd3b9cef4b2d6d952c9bb9","https://git.kernel.org/stable/c/da13ade87a12dd58829278bc816a61bea06a56a9","https://git.kernel.org/stable/c/ea0fa76f61cf8e932d1d26e6193513230816e11d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-2586
|
High |
|
N/A
|
It was discovered that a nft object or expression could reference a nft set on a different nft table, leading to a use-after-free once that table was deleted. |
["https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2586","https://lore.kernel.org/netfilter-devel/20220809170148.164591-1-cascardo@canonical.com/T/#t","https://ubuntu.com/security/notices/USN-5557-1","https://ubuntu.com/security/notices/USN-5560-1","https://ubuntu.com/security/notices/USN-5560-2","https://ubuntu.com/security/notices/USN-5562-1","https://ubuntu.com/security/notices/USN-5564-1","https://ubuntu.com/security/notices/USN-5565-1","https://ubuntu.com/security/notices/USN-5566-1","https://ubuntu.com/security/notices/USN-5567-1","https://ubuntu.com/security/notices/USN-5582-1","https://www.openwall.com/lists/oss-security/2022/08/09/5","https://www.zerodayinitiative.com/advisories/ZDI-22-1118/","https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2586","https://lore.kernel.org/netfilter-devel/20220809170148.164591-1-cascardo@canonical.com/T/#t","https://ubuntu.com/security/notices/USN-5557-1","https://ubuntu.com/security/notices/USN-5560-1","https://ubuntu.com/security/notices/USN-5560-2","https://ubuntu.com/security/notices/USN-5562-1","https://ubuntu.com/security/notices/USN-5564-1","https://ubuntu.com/security/notices/USN-5565-1","https://ubuntu.com/security/notices/USN-5566-1","https://ubuntu.com/security/notices/USN-5567-1","https://ubuntu.com/security/notices/USN-5582-1","https://www.openwall.com/lists/oss-security/2022/08/09/5","https://www.vicarius.io/vsociety/posts/use-after-free-vulnerability-linked-chain-between-nft-tables-cve-2022-2586","https://www.zerodayinitiative.com/advisories/ZDI-22-1118/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50302
|
Medium |
fixed |
- 4.19.324
- 5.4.286
- 5.10.230
- 5.15.172
- 6.1.117
- 6.6.61
- 6.11.8
|
In the Linux kernel, the following vulnerability has been resolved:
HID: core: zero-initialize the report buffer
Since the report buffer is used by all kinds of drivers in various ways, let's
zero-initialize it during allocation to make sure that it can't be ever used
to leak kernel memory via specially-crafted report. |
["https://git.kernel.org/stable/c/05ade5d4337867929e7ef664e7ac8e0c734f1aaf","https://git.kernel.org/stable/c/177f25d1292c7e16e1199b39c85480f7f8815552","https://git.kernel.org/stable/c/1884ab3d22536a5c14b17c78c2ce76d1734e8b0b","https://git.kernel.org/stable/c/3f9e88f2672c4635960570ee9741778d4135ecf5","https://git.kernel.org/stable/c/492015e6249fbcd42138b49de3c588d826dd9648","https://git.kernel.org/stable/c/9d9f5c75c0c7f31766ec27d90f7a6ac673193191","https://git.kernel.org/stable/c/d7dc68d82ab3fcfc3f65322465da3d7031d4ab46","https://git.kernel.org/stable/c/e7ea60184e1e88a3c9e437b3265cbb6439aa7e26"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-2588
|
High |
fixed |
- 4.9.326
- 4.14.291
- 4.19.256
- 5.4.211
- 5.10.137
- 5.15.61
- 5.18.18
- 5.19.2
|
It was discovered that the cls_route filter implementation in the Linux kernel would not remove an old filter from the hashtable before freeing it if its handle had the value 0. |
["https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2588","https://github.com/Markakd/CVE-2022-2588","https://lore.kernel.org/netdev/20220809170518.164662-1-cascardo@canonical.com/T/#u","https://ubuntu.com/security/notices/USN-5557-1","https://ubuntu.com/security/notices/USN-5560-1","https://ubuntu.com/security/notices/USN-5560-2","https://ubuntu.com/security/notices/USN-5562-1","https://ubuntu.com/security/notices/USN-5564-1","https://ubuntu.com/security/notices/USN-5565-1","https://ubuntu.com/security/notices/USN-5566-1","https://ubuntu.com/security/notices/USN-5567-1","https://ubuntu.com/security/notices/USN-5582-1","https://ubuntu.com/security/notices/USN-5588-1","https://www.openwall.com/lists/oss-security/2022/08/09/6","https://www.zerodayinitiative.com/advisories/ZDI-22-1117/","https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2588","https://github.com/Markakd/CVE-2022-2588","https://lore.kernel.org/netdev/20220809170518.164662-1-cascardo@canonical.com/T/#u","https://ubuntu.com/security/notices/USN-5557-1","https://ubuntu.com/security/notices/USN-5560-1","https://ubuntu.com/security/notices/USN-5560-2","https://ubuntu.com/security/notices/USN-5562-1","https://ubuntu.com/security/notices/USN-5564-1","https://ubuntu.com/security/notices/USN-5565-1","https://ubuntu.com/security/notices/USN-5566-1","https://ubuntu.com/security/notices/USN-5567-1","https://ubuntu.com/security/notices/USN-5582-1","https://ubuntu.com/security/notices/USN-5588-1","https://www.openwall.com/lists/oss-security/2022/08/09/6","https://www.zerodayinitiative.com/advisories/ZDI-22-1117/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-34918
|
High |
fixed |
- 4.14.316
- 4.19.284
- 5.4.244
- 5.10.130
- 5.15.54
- 5.18.11
|
An issue was discovered in the Linux kernel through 5.18.9. A type confusion bug in nft_set_elem_init (leading to a buffer overflow) could be used by a local attacker to escalate privileges, a different vulnerability than CVE-2022-32250. (The attacker can obtain root access, but must start with an unprivileged user namespace to obtain CAP_NET_ADMIN access.) This can be fixed in nft_setelem_parse_data in net/netfilter/nf_tables_api.c. |
["http://packetstormsecurity.com/files/168191/Kernel-Live-Patch-Security-Notice-LSN-0089-1.html","http://packetstormsecurity.com/files/168543/Netfilter-nft_set_elem_init-Heap-Overflow-Privilege-Escalation.html","http://www.openwall.com/lists/oss-security/2022/07/05/1","http://www.openwall.com/lists/oss-security/2022/08/06/5","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=7e6bc1f6cabcd30aba0b11219d8e01b952eacbb6","https://lore.kernel.org/netfilter-devel/cd9428b6-7ffb-dd22-d949-d86f4869f452%40randorisec.fr/T/#u","https://security.netapp.com/advisory/ntap-20220826-0004/","https://www.debian.org/security/2022/dsa-5191","https://www.openwall.com/lists/oss-security/2022/07/02/3","https://www.randorisec.fr/crack-linux-firewall/","http://packetstormsecurity.com/files/168191/Kernel-Live-Patch-Security-Notice-LSN-0089-1.html","http://packetstormsecurity.com/files/168543/Netfilter-nft_set_elem_init-Heap-Overflow-Privilege-Escalation.html","http://www.openwall.com/lists/oss-security/2022/07/05/1","http://www.openwall.com/lists/oss-security/2022/08/06/5","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=7e6bc1f6cabcd30aba0b11219d8e01b952eacbb6","https://lore.kernel.org/netfilter-devel/cd9428b6-7ffb-dd22-d949-d86f4869f452%40randorisec.fr/T/#u","https://security.netapp.com/advisory/ntap-20220826-0004/","https://www.debian.org/security/2022/dsa-5191","https://www.openwall.com/lists/oss-security/2022/07/02/3","https://www.randorisec.fr/crack-linux-firewall/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-0995
|
High |
fixed |
|
An out-of-bounds (OOB) memory write flaw was found in the Linux kernel’s watch_queue event notification subsystem. This flaw can overwrite parts of the kernel state, potentially allowing a local user to gain privileged access or cause a denial of service on the system. |
["http://packetstormsecurity.com/files/166770/Linux-watch_queue-Filter-Out-Of-Bounds-Write.html","http://packetstormsecurity.com/files/166815/Watch-Queue-Out-Of-Bounds-Write.html","https://bugzilla.redhat.com/show_bug.cgi?id=2063786","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=93ce93587d36493f2f86921fa79921b3cba63fbb","https://security.netapp.com/advisory/ntap-20220429-0001/","http://packetstormsecurity.com/files/166770/Linux-watch_queue-Filter-Out-Of-Bounds-Write.html","http://packetstormsecurity.com/files/166815/Watch-Queue-Out-Of-Bounds-Write.html","https://bugzilla.redhat.com/show_bug.cgi?id=2063786","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=93ce93587d36493f2f86921fa79921b3cba63fbb","https://security.netapp.com/advisory/ntap-20220429-0001/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-0386
|
High |
fixed |
|
A flaw was found in the Linux kernel, where unauthorized access to the execution of the setuid file with capabilities was found in the Linux kernel’s OverlayFS subsystem in how a user copies a capable file from a nosuid mount into another mount. This uid mapping bug allows a local user to escalate their privileges on the system. |
["http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f11ada10d0a","https://lists.debian.org/debian-lts-announce/2023/06/msg00008.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://security.netapp.com/advisory/ntap-20230420-0004/","https://www.debian.org/security/2023/dsa-5402","http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f11ada10d0a","https://lists.debian.org/debian-lts-announce/2023/06/msg00008.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://security.netapp.com/advisory/ntap-20230420-0004/","https://www.debian.org/security/2023/dsa-5402"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-44466
|
High |
fixed |
|
An issue was discovered in net/ceph/messenger_v2.c in the Linux kernel before 6.4.5. There is an integer signedness error, leading to a buffer overflow and remote code execution via HELLO or one of the AUTH frames. This occurs because of an untrusted length taken from a TCP packet in ceph_decode_32. |
["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a282a2f10539dce2aa619e71e1817570d557fc97","https://github.com/google/security-research/security/advisories/GHSA-jg27-jx6w-xwph","https://github.com/torvalds/linux/commit/a282a2f10539dce2aa619e71e1817570d557fc97","https://security.netapp.com/advisory/ntap-20231116-0003/","https://www.spinics.net/lists/ceph-devel/msg57909.html","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a282a2f10539dce2aa619e71e1817570d557fc97","https://github.com/google/security-research/security/advisories/GHSA-jg27-jx6w-xwph","https://github.com/torvalds/linux/commit/a282a2f10539dce2aa619e71e1817570d557fc97","https://security.netapp.com/advisory/ntap-20231116-0003/","https://www.spinics.net/lists/ceph-devel/msg57909.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3338
|
Medium |
fixed |
|
A null pointer dereference flaw was found in the Linux kernel's DECnet networking protocol. This issue could allow a remote user to crash the system. |
["https://access.redhat.com/security/cve/CVE-2023-3338","https://bugzilla.redhat.com/show_bug.cgi?id=2218618","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://seclists.org/oss-sec/2023/q2/276","https://security.netapp.com/advisory/ntap-20230824-0005/","https://www.debian.org/security/2023/dsa-5480","https://access.redhat.com/security/cve/CVE-2023-3338","https://bugzilla.redhat.com/show_bug.cgi?id=2218618","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://seclists.org/oss-sec/2023/q2/276","https://security.netapp.com/advisory/ntap-20230824-0005/","https://www.debian.org/security/2023/dsa-5480"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-36946
|
High |
fixed |
- 4.9.326
- 4.14.291
- 4.19.255
- 5.4.209
- 5.10.135
- 5.15.59
- 5.18.16
|
nfqnl_mangle in net/netfilter/nfnetlink_queue.c in the Linux kernel through 5.18.14 allows remote attackers to cause a denial of service (panic) because, in the case of an nf_queue verdict with a one-byte nfta_payload attribute, an skb_pull can encounter a negative skb->len. |
["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=99a63d36cb3ed5ca3aa6fcb64cffbeaf3b0fb164","https://lists.debian.org/debian-lts-announce/2022/09/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://marc.info/?l=netfilter-devel\u0026m=165883202007292\u0026w=2","https://security.netapp.com/advisory/ntap-20220901-0007/","https://www.debian.org/security/2022/dsa-5207","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=99a63d36cb3ed5ca3aa6fcb64cffbeaf3b0fb164","https://lists.debian.org/debian-lts-announce/2022/09/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://marc.info/?l=netfilter-devel\u0026m=165883202007292\u0026w=2","https://security.netapp.com/advisory/ntap-20220901-0007/","https://www.debian.org/security/2022/dsa-5207"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35960
|
Critical |
fixed |
- 4.19.313
- 5.4.275
- 5.10.216
- 5.15.156
- 6.1.87
- 6.6.28
- 6.8.7
|
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Properly link new fs rules into the tree
Previously, add_rule_fg would only add newly created rules from the
handle into the tree when they had a refcount of 1. On the other hand,
create_flow_handle tries hard to find and reference already existing
identical rules instead of creating new ones.
These two behaviors can result in a situation where create_flow_handle
1) creates a new rule and references it, then
2) in a subsequent step during the same handle creation references it
again,
resulting in a rule with a refcount of 2 that is not linked into the
tree, will have a NULL parent and root and will result in a crash when
the flow group is deleted because del_sw_hw_rule, invoked on rule
deletion, assumes node->parent is != NULL.
This happened in the wild, due to another bug related to incorrect
handling of duplicate pkt_reformat ids, which lead to the code in
create_flow_handle incorrectly referencing a just-added rule in the same
flow handle, resulting in the problem described above. Full details are
at [1].
This patch changes add_rule_fg to add new rules without parents into
the tree, properly initializing them and avoiding the crash. This makes
it more consistent with how rules are added to an FTE in
create_flow_handle. |
["https://git.kernel.org/stable/c/1263b0b26077b1183c3c45a0a2479573a351d423","https://git.kernel.org/stable/c/2e8dc5cffc844dacfa79f056dea88002312f253f","https://git.kernel.org/stable/c/3d90ca9145f6b97b38d0c2b6b30f6ca6af9c1801","https://git.kernel.org/stable/c/5cf5337ef701830f173b4eec00a4f984adeb57a0","https://git.kernel.org/stable/c/7aaee12b804c5e0374e7b132b6ec2158ff33dd64","https://git.kernel.org/stable/c/7c6782ad4911cbee874e85630226ed389ff2e453","https://git.kernel.org/stable/c/adf67a03af39095f05d82050f15813d6f700159d","https://git.kernel.org/stable/c/de0139719cdda82806a47580ca0df06fc85e0bd2","https://git.kernel.org/stable/c/1263b0b26077b1183c3c45a0a2479573a351d423","https://git.kernel.org/stable/c/2e8dc5cffc844dacfa79f056dea88002312f253f","https://git.kernel.org/stable/c/3d90ca9145f6b97b38d0c2b6b30f6ca6af9c1801","https://git.kernel.org/stable/c/5cf5337ef701830f173b4eec00a4f984adeb57a0","https://git.kernel.org/stable/c/7aaee12b804c5e0374e7b132b6ec2158ff33dd64","https://git.kernel.org/stable/c/7c6782ad4911cbee874e85630226ed389ff2e453","https://git.kernel.org/stable/c/adf67a03af39095f05d82050f15813d6f700159d","https://git.kernel.org/stable/c/de0139719cdda82806a47580ca0df06fc85e0bd2","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-5178
|
High |
fixed |
- 5.4.260
- 5.10.199
- 5.15.137
- 6.1.60
- 6.5.9
|
A use-after-free vulnerability was found in drivers/nvme/target/tcp.c` in `nvmet_tcp_free_crypto` due to a logical bug in the NVMe/TCP subsystem in the Linux kernel. This issue may allow a malicious user to cause a use-after-free and double-free problem, which may permit remote code execution or lead to local privilege escalation. |
["https://access.redhat.com/errata/RHSA-2023:7370","https://access.redhat.com/errata/RHSA-2023:7379","https://access.redhat.com/errata/RHSA-2023:7418","https://access.redhat.com/errata/RHSA-2023:7548","https://access.redhat.com/errata/RHSA-2023:7549","https://access.redhat.com/errata/RHSA-2023:7551","https://access.redhat.com/errata/RHSA-2023:7554","https://access.redhat.com/errata/RHSA-2023:7557","https://access.redhat.com/errata/RHSA-2023:7559","https://access.redhat.com/errata/RHSA-2024:0340","https://access.redhat.com/errata/RHSA-2024:0378","https://access.redhat.com/errata/RHSA-2024:0386","https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:0431","https://access.redhat.com/errata/RHSA-2024:0432","https://access.redhat.com/errata/RHSA-2024:0461","https://access.redhat.com/errata/RHSA-2024:0554","https://access.redhat.com/errata/RHSA-2024:0575","https://access.redhat.com/errata/RHSA-2024:1268","https://access.redhat.com/errata/RHSA-2024:1269","https://access.redhat.com/errata/RHSA-2024:1278","https://access.redhat.com/security/cve/CVE-2023-5178","https://bugzilla.redhat.com/show_bug.cgi?id=2241924","https://lore.kernel.org/linux-nvme/20231002105428.226515-1-sagi@grimberg.me/","https://access.redhat.com/errata/RHSA-2023:7370","https://access.redhat.com/errata/RHSA-2023:7379","https://access.redhat.com/errata/RHSA-2023:7418","https://access.redhat.com/errata/RHSA-2023:7548","https://access.redhat.com/errata/RHSA-2023:7549","https://access.redhat.com/errata/RHSA-2023:7551","https://access.redhat.com/errata/RHSA-2023:7554","https://access.redhat.com/errata/RHSA-2023:7557","https://access.redhat.com/errata/RHSA-2023:7559","https://access.redhat.com/errata/RHSA-2024:0340","https://access.redhat.com/errata/RHSA-2024:0378","https://access.redhat.com/errata/RHSA-2024:0386","https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:0431","https://access.redhat.com/errata/RHSA-2024:0432","https://access.redhat.com/errata/RHSA-2024:0461","https://access.redhat.com/errata/RHSA-2024:0554","https://access.redhat.com/errata/RHSA-2024:0575","https://access.redhat.com/errata/RHSA-2024:1268","https://access.redhat.com/errata/RHSA-2024:1269","https://access.redhat.com/errata/RHSA-2024:1278","https://access.redhat.com/security/cve/CVE-2023-5178","https://bugzilla.redhat.com/show_bug.cgi?id=2241924","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://lore.kernel.org/linux-nvme/20231002105428.226515-1-sagi@grimberg.me/","https://security.netapp.com/advisory/ntap-20231208-0004/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-2156
|
High |
fixed |
- 5.10.184
- 5.15.117
- 6.1.34
- 6.2.13
- 6.3.8
|
A flaw was found in the networking subsystem of the Linux kernel within the handling of the RPL protocol. This issue results from the lack of proper handling of user-supplied data, which can lead to an assertion failure. This may allow an unauthenticated remote attacker to create a denial of service condition on the system. |
["http://www.openwall.com/lists/oss-security/2023/05/17/8","http://www.openwall.com/lists/oss-security/2023/05/17/9","http://www.openwall.com/lists/oss-security/2023/05/18/1","http://www.openwall.com/lists/oss-security/2023/05/19/1","https://bugzilla.redhat.com/show_bug.cgi?id=2196292","https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html","https://security.netapp.com/advisory/ntap-20230622-0001/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5453","https://www.zerodayinitiative.com/advisories/ZDI-23-547/","http://www.openwall.com/lists/oss-security/2023/05/17/8","http://www.openwall.com/lists/oss-security/2023/05/17/9","http://www.openwall.com/lists/oss-security/2023/05/18/1","http://www.openwall.com/lists/oss-security/2023/05/19/1","https://bugzilla.redhat.com/show_bug.cgi?id=2196292","https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html","https://security.netapp.com/advisory/ntap-20230622-0001/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5453","https://www.zerodayinitiative.com/advisories/ZDI-23-547/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27405
|
High |
fixed |
- 4.19.308
- 5.4.270
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs
It is observed sometimes when tethering is used over NCM with Windows 11
as host, at some instances, the gadget_giveback has one byte appended at
the end of a proper NTB. When the NTB is parsed, unwrap call looks for
any leftover bytes in SKB provided by u_ether and if there are any pending
bytes, it treats them as a separate NTB and parses it. But in case the
second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that
were parsed properly in the first NTB and saved in rx_list are dropped.
Adding a few custom traces showed the following:
[002] d..1 7828.532866: dwc3_gadget_giveback: ep1out:
req 000000003868811a length 1025/16384 zsI ==> 0
[002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025
[002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342
[002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67
[002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400
[002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10
[002] d..1 7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames
In this case, the giveback is of 1025 bytes and block length is 1024.
The rest 1 byte (which is 0x00) won't be parsed resulting in drop of
all datagrams in rx_list.
Same is case with packets of size 2048:
[002] d..1 7828.557948: dwc3_gadget_giveback: ep1out:
req 0000000011dfd96e length 2049/16384 zsI ==> 0
[002] d..1 7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342
[002] d..1 7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800
Lecroy shows one byte coming in extra confirming that the byte is coming
in from PC:
Transfer 2959 - Bytes Transferred(1025) Timestamp((18.524 843 590)
- Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590)
--- Packet 4063861
Data(1024 bytes)
Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590)
--- Packet 4063863
Data(1 byte)
Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722)
According to Windows driver, no ZLP is needed if wBlockLength is non-zero,
because the non-zero wBlockLength has already told the function side the
size of transfer to be expected. However, there are in-market NCM devices
that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize.
To deal with such devices, it pads an extra 0 at end so the transfer is no
longer multiple of wMaxPacketSize. |
["https://git.kernel.org/stable/c/059285e04ebb273d32323fbad5431c5b94f77e48","https://git.kernel.org/stable/c/2b7ec68869d50ea998908af43b643bca7e54577e","https://git.kernel.org/stable/c/2cb66b62a5d64ccf09b0591ab86fb085fa491fc5","https://git.kernel.org/stable/c/35b604a37ec70d68b19dafd10bbacf1db505c9ca","https://git.kernel.org/stable/c/57ca0e16f393bb21d69734e536e383a3a4c665fd","https://git.kernel.org/stable/c/76c51146820c5dac629f21deafab0a7039bc3ccd","https://git.kernel.org/stable/c/a31cf46d108dabce3df80b3e5c07661e24912151","https://git.kernel.org/stable/c/c7f43900bc723203d7554d299a2ce844054fab8e","https://git.kernel.org/stable/c/059285e04ebb273d32323fbad5431c5b94f77e48","https://git.kernel.org/stable/c/2b7ec68869d50ea998908af43b643bca7e54577e","https://git.kernel.org/stable/c/2cb66b62a5d64ccf09b0591ab86fb085fa491fc5","https://git.kernel.org/stable/c/35b604a37ec70d68b19dafd10bbacf1db505c9ca","https://git.kernel.org/stable/c/57ca0e16f393bb21d69734e536e383a3a4c665fd","https://git.kernel.org/stable/c/76c51146820c5dac629f21deafab0a7039bc3ccd","https://git.kernel.org/stable/c/a31cf46d108dabce3df80b3e5c07661e24912151","https://git.kernel.org/stable/c/c7f43900bc723203d7554d299a2ce844054fab8e","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-32250
|
High |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.120
- 5.15.45
- 5.17.13
- 5.18.2
|
net/netfilter/nf_tables_api.c in the Linux kernel through 5.18.1 allows a local user (able to create user/net namespaces) to escalate privileges to root because an incorrect NFT_STATEFUL_EXPR check leads to a use-after-free. |
["http://www.openwall.com/lists/oss-security/2022/06/03/1","http://www.openwall.com/lists/oss-security/2022/06/04/1","http://www.openwall.com/lists/oss-security/2022/06/20/1","http://www.openwall.com/lists/oss-security/2022/07/03/5","http://www.openwall.com/lists/oss-security/2022/07/03/6","http://www.openwall.com/lists/oss-security/2022/08/25/1","http://www.openwall.com/lists/oss-security/2022/09/02/9","https://blog.theori.io/research/CVE-2022-32250-linux-kernel-lpe-2022/","https://bugzilla.redhat.com/show_bug.cgi?id=2092427","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/net/netfilter?id=520778042ccca019f3ffa136dd0ca565c486cedd","https://github.com/theori-io/CVE-2022-32250-exploit","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/MO6Y3TC4WUUNKRP7OQA26OVTZTPCS6F2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UIZTJOJCVVEJVOQSCHE6IJQKMPISHQ5L/","https://security.netapp.com/advisory/ntap-20220715-0005/","https://www.debian.org/security/2022/dsa-5161","https://www.debian.org/security/2022/dsa-5173","https://www.openwall.com/lists/oss-security/2022/05/31/1","http://www.openwall.com/lists/oss-security/2022/06/03/1","http://www.openwall.com/lists/oss-security/2022/06/04/1","http://www.openwall.com/lists/oss-security/2022/06/20/1","http://www.openwall.com/lists/oss-security/2022/07/03/5","http://www.openwall.com/lists/oss-security/2022/07/03/6","http://www.openwall.com/lists/oss-security/2022/08/25/1","http://www.openwall.com/lists/oss-security/2022/09/02/9","https://blog.theori.io/research/CVE-2022-32250-linux-kernel-lpe-2022/","https://bugzilla.redhat.com/show_bug.cgi?id=2092427","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/net/netfilter?id=520778042ccca019f3ffa136dd0ca565c486cedd","https://github.com/theori-io/CVE-2022-32250-exploit","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/MO6Y3TC4WUUNKRP7OQA26OVTZTPCS6F2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UIZTJOJCVVEJVOQSCHE6IJQKMPISHQ5L/","https://security.netapp.com/advisory/ntap-20220715-0005/","https://www.debian.org/security/2022/dsa-5161","https://www.debian.org/security/2022/dsa-5173","https://www.openwall.com/lists/oss-security/2022/05/31/1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-0742
|
High |
fixed |
|
Memory leak in icmp6 implementation in Linux Kernel 5.13+ allows a remote attacker to DoS a host by making it go out-of-memory via icmp6 packets of type 130 or 131. We recommend upgrading past commit 2d3916f3189172d5c69d33065c3c21119fe539fc. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2d3916f3189172d5c69d33065c3c21119fe539fc","https://security.netapp.com/advisory/ntap-20220425-0001/","https://www.openwall.com/lists/oss-security/2022/03/15/3","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2d3916f3189172d5c69d33065c3c21119fe539fc","https://security.netapp.com/advisory/ntap-20220425-0001/","https://www.openwall.com/lists/oss-security/2022/03/15/3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27053
|
Critical |
fixed |
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: wilc1000: fix RCU usage in connect path
With lockdep enabled, calls to the connect function from cfg802.11 layer
lead to the following warning:
=============================
WARNING: suspicious RCU usage
6.7.0-rc1-wt+ #333 Not tainted
-----------------------------
drivers/net/wireless/microchip/wilc1000/hif.c:386
suspicious rcu_dereference_check() usage!
[...]
stack backtrace:
CPU: 0 PID: 100 Comm: wpa_supplicant Not tainted 6.7.0-rc1-wt+ #333
Hardware name: Atmel SAMA5
unwind_backtrace from show_stack+0x18/0x1c
show_stack from dump_stack_lvl+0x34/0x48
dump_stack_lvl from wilc_parse_join_bss_param+0x7dc/0x7f4
wilc_parse_join_bss_param from connect+0x2c4/0x648
connect from cfg80211_connect+0x30c/0xb74
cfg80211_connect from nl80211_connect+0x860/0xa94
nl80211_connect from genl_rcv_msg+0x3fc/0x59c
genl_rcv_msg from netlink_rcv_skb+0xd0/0x1f8
netlink_rcv_skb from genl_rcv+0x2c/0x3c
genl_rcv from netlink_unicast+0x3b0/0x550
netlink_unicast from netlink_sendmsg+0x368/0x688
netlink_sendmsg from ____sys_sendmsg+0x190/0x430
____sys_sendmsg from ___sys_sendmsg+0x110/0x158
___sys_sendmsg from sys_sendmsg+0xe8/0x150
sys_sendmsg from ret_fast_syscall+0x0/0x1c
This warning is emitted because in the connect path, when trying to parse
target BSS parameters, we dereference a RCU pointer whithout being in RCU
critical section.
Fix RCU dereference usage by moving it to a RCU read critical section. To
avoid wrapping the whole wilc_parse_join_bss_param under the critical
section, just use the critical section to copy ies data |
["https://git.kernel.org/stable/c/205c50306acf58a335eb19fa84e40140f4fe814f","https://git.kernel.org/stable/c/4bfd20d5f5c62b5495d6c0016ee6933bd3add7ce","https://git.kernel.org/stable/c/5800ec78775c0cd646f71eb9bf8402fb794807de","https://git.kernel.org/stable/c/745003b5917b610352f52fe0d11ef658d6471ec2","https://git.kernel.org/stable/c/b4bbf38c350acb6500cbe667b1e2e68f896e4b38","https://git.kernel.org/stable/c/d80fc436751cfa6b02a8eda74eb6cce7dadfe5a2","https://git.kernel.org/stable/c/dd50d3ead6e3707bb0a5df7cc832730c93ace3a7","https://git.kernel.org/stable/c/e556006de4ea93abe2b46cba202a2556c544b8b2","https://git.kernel.org/stable/c/205c50306acf58a335eb19fa84e40140f4fe814f","https://git.kernel.org/stable/c/4bfd20d5f5c62b5495d6c0016ee6933bd3add7ce","https://git.kernel.org/stable/c/5800ec78775c0cd646f71eb9bf8402fb794807de","https://git.kernel.org/stable/c/745003b5917b610352f52fe0d11ef658d6471ec2","https://git.kernel.org/stable/c/b4bbf38c350acb6500cbe667b1e2e68f896e4b38","https://git.kernel.org/stable/c/d80fc436751cfa6b02a8eda74eb6cce7dadfe5a2","https://git.kernel.org/stable/c/dd50d3ead6e3707bb0a5df7cc832730c93ace3a7","https://git.kernel.org/stable/c/e556006de4ea93abe2b46cba202a2556c544b8b2","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1015
|
Medium |
fixed |
|
A flaw was found in the Linux kernel in linux/net/netfilter/nf_tables_api.c of the netfilter subsystem. This flaw allows a local user to cause an out-of-bounds write issue. |
["http://blog.dbouman.nl/2022/04/02/How-The-Tables-Have-Turned-CVE-2022-1015-1016/","http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html","http://www.openwall.com/lists/oss-security/2022/08/25/2","http://www.openwall.com/lists/oss-security/2023/01/13/2","http://www.openwall.com/lists/oss-security/2023/02/23/1","https://bugzilla.redhat.com/show_bug.cgi?id=2065323","https://seclists.org/oss-sec/2022/q1/205","http://blog.dbouman.nl/2022/04/02/How-The-Tables-Have-Turned-CVE-2022-1015-1016/","http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html","http://www.openwall.com/lists/oss-security/2022/08/25/2","http://www.openwall.com/lists/oss-security/2023/01/13/2","http://www.openwall.com/lists/oss-security/2023/02/23/1","https://bugzilla.redhat.com/show_bug.cgi?id=2065323","https://seclists.org/oss-sec/2022/q1/205"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52696
|
High |
fixed |
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
powerpc/powernv: Add a null pointer check in opal_powercap_init()
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. |
["https://git.kernel.org/stable/c/69f95c5e9220f77ce7c540686b056c2b49e9a664","https://git.kernel.org/stable/c/6b58d16037217d0c64a2a09b655f370403ec7219","https://git.kernel.org/stable/c/9da4a56dd3772570512ca58aa8832b052ae910dc","https://git.kernel.org/stable/c/a67a04ad05acb56640798625e73fa54d6d41cce1","https://git.kernel.org/stable/c/b02ecc35d01a76b4235e008d2dd292895b28ecab","https://git.kernel.org/stable/c/e123015c0ba859cf48aa7f89c5016cc6e98e018d","https://git.kernel.org/stable/c/f152a6bfd187f67afeffc9fd68cbe46f51439be0","https://git.kernel.org/stable/c/69f95c5e9220f77ce7c540686b056c2b49e9a664","https://git.kernel.org/stable/c/6b58d16037217d0c64a2a09b655f370403ec7219","https://git.kernel.org/stable/c/9da4a56dd3772570512ca58aa8832b052ae910dc","https://git.kernel.org/stable/c/a67a04ad05acb56640798625e73fa54d6d41cce1","https://git.kernel.org/stable/c/b02ecc35d01a76b4235e008d2dd292895b28ecab","https://git.kernel.org/stable/c/e123015c0ba859cf48aa7f89c5016cc6e98e018d","https://git.kernel.org/stable/c/f152a6bfd187f67afeffc9fd68cbe46f51439be0","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-47939
|
Critical |
fixed |
|
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. fs/ksmbd/smb2pdu.c has a use-after-free and OOPS for SMB2_TREE_DISCONNECT. |
["http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cf6531d98190fa2cf92a6d8bbc8af0a4740a223c","https://github.com/torvalds/linux/commit/cf6531d98190fa2cf92a6d8bbc8af0a4740a223c","https://www.secpod.com/blog/zero-day-server-message-block-smb-server-in-linux-kernel-5-15-has-a-critical-vulnerability-patch-ksmbd-immediately/","https://www.zerodayinitiative.com/advisories/ZDI-22-1690/","http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cf6531d98190fa2cf92a6d8bbc8af0a4740a223c","https://github.com/torvalds/linux/commit/cf6531d98190fa2cf92a6d8bbc8af0a4740a223c","https://www.secpod.com/blog/zero-day-server-message-block-smb-server-in-linux-kernel-5-15-has-a-critical-vulnerability-patch-ksmbd-immediately/","https://www.zerodayinitiative.com/advisories/ZDI-22-1690/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35823
|
Medium |
fixed |
- 4.19.312
- 5.4.274
- 5.10.215
- 5.15.154
- 6.1.84
- 6.6.24
- 6.7.12
|
In the Linux kernel, the following vulnerability has been resolved:
vt: fix unicode buffer corruption when deleting characters
This is the same issue that was fixed for the VGA text buffer in commit
39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the
buffer"). The cure is also the same i.e. replace memcpy() with memmove()
due to the overlaping buffers. |
["https://git.kernel.org/stable/c/0190d19d7651c08abc187dac3819c61b726e7e3f","https://git.kernel.org/stable/c/1581dafaf0d34bc9c428a794a22110d7046d186d","https://git.kernel.org/stable/c/1ce408f75ccf1e25b3fddef75cca878b55f2ac90","https://git.kernel.org/stable/c/2933b1e4757a0a5c689cf48d80b1a2a85f237ff1","https://git.kernel.org/stable/c/7529cbd8b5f6697b369803fe1533612c039cabda","https://git.kernel.org/stable/c/994a1e583c0c206c8ca7d03334a65b79f4d8bc51","https://git.kernel.org/stable/c/fc7dfe3d123f00e720be80b920da287810a1f37d","https://git.kernel.org/stable/c/ff7342090c1e8c5a37015c89822a68b275b46f8a","https://git.kernel.org/stable/c/0190d19d7651c08abc187dac3819c61b726e7e3f","https://git.kernel.org/stable/c/1581dafaf0d34bc9c428a794a22110d7046d186d","https://git.kernel.org/stable/c/1ce408f75ccf1e25b3fddef75cca878b55f2ac90","https://git.kernel.org/stable/c/2933b1e4757a0a5c689cf48d80b1a2a85f237ff1","https://git.kernel.org/stable/c/7529cbd8b5f6697b369803fe1533612c039cabda","https://git.kernel.org/stable/c/994a1e583c0c206c8ca7d03334a65b79f4d8bc51","https://git.kernel.org/stable/c/fc7dfe3d123f00e720be80b920da287810a1f37d","https://git.kernel.org/stable/c/ff7342090c1e8c5a37015c89822a68b275b46f8a","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35845
|
Critical |
fixed |
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: dbg-tlv: ensure NUL termination
The iwl_fw_ini_debug_info_tlv is used as a string, so we must
ensure the string is terminated correctly before using it. |
["https://git.kernel.org/stable/c/71d4186d470e9cda7cd1a0921b4afda737c6f641","https://git.kernel.org/stable/c/783d413f332a3ebec916664b366c28f58147f82c","https://git.kernel.org/stable/c/96aa40761673da045a7774f874487cdb50c6a2f7","https://git.kernel.org/stable/c/c855a1a5b7e3de57e6b1b29563113d5e3bfdb89a","https://git.kernel.org/stable/c/ea1d166fae14e05d49ffb0ea9fcd4658f8d3dcea","https://git.kernel.org/stable/c/fabe2db7de32a881e437ee69db32e0de785a6209","https://git.kernel.org/stable/c/fec14d1cdd92f340b9ba2bd220abf96f9609f2a9","https://git.kernel.org/stable/c/71d4186d470e9cda7cd1a0921b4afda737c6f641","https://git.kernel.org/stable/c/783d413f332a3ebec916664b366c28f58147f82c","https://git.kernel.org/stable/c/96aa40761673da045a7774f874487cdb50c6a2f7","https://git.kernel.org/stable/c/c855a1a5b7e3de57e6b1b29563113d5e3bfdb89a","https://git.kernel.org/stable/c/ea1d166fae14e05d49ffb0ea9fcd4658f8d3dcea","https://git.kernel.org/stable/c/fabe2db7de32a881e437ee69db32e0de785a6209","https://git.kernel.org/stable/c/fec14d1cdd92f340b9ba2bd220abf96f9609f2a9","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2007-2764
|
High |
|
N/A
|
The embedded Linux kernel in certain Sun-Brocade SilkWorm switches before 20070516 does not properly handle a situation in which a non-root user creates a kernel process, which allows attackers to cause a denial of service (oops and device reboot) via unspecified vectors. |
["http://osvdb.org/39117","http://sunsolve.sun.com/search/document.do?assetkey=1-26-102752-1","http://www.securityfocus.com/bid/24036","https://exchange.xforce.ibmcloud.com/vulnerabilities/34495","http://osvdb.org/39117","http://sunsolve.sun.com/search/document.do?assetkey=1-26-102752-1","http://www.securityfocus.com/bid/24036","https://exchange.xforce.ibmcloud.com/vulnerabilities/34495"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52832
|
Critical |
fixed |
- 4.14.331
- 4.19.300
- 5.4.262
- 5.10.202
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: don't return unset power in ieee80211_get_tx_power()
We can get a UBSAN warning if ieee80211_get_tx_power() returns the
INT_MIN value mac80211 internally uses for "unset power level".
UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5
-2147483648 * 100 cannot be represented in type 'int'
CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE
Call Trace:
dump_stack+0x74/0x92
ubsan_epilogue+0x9/0x50
handle_overflow+0x8d/0xd0
__ubsan_handle_mul_overflow+0xe/0x10
nl80211_send_iface+0x688/0x6b0 [cfg80211]
[...]
cfg80211_register_wdev+0x78/0xb0 [cfg80211]
cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211]
[...]
ieee80211_if_add+0x60e/0x8f0 [mac80211]
ieee80211_register_hw+0xda5/0x1170 [mac80211]
In this case, simply return an error instead, to indicate
that no data is available. |
["https://git.kernel.org/stable/c/1571120c44dbe5757aee1612c5b6097cdc42710f","https://git.kernel.org/stable/c/21a0f310a9f3bfd2b4cf4f382430e638607db846","https://git.kernel.org/stable/c/298e767362cade639b7121ecb3cc5345b6529f62","https://git.kernel.org/stable/c/2be24c47ac19bf639c48c082486c08888bd603c6","https://git.kernel.org/stable/c/5a94cffe90e20e8fade0b9abd4370bd671fe87c7","https://git.kernel.org/stable/c/717de20abdcd1d4993fa450e28b8086a352620ea","https://git.kernel.org/stable/c/adc2474d823fe81d8da759207f4f1d3691aa775a","https://git.kernel.org/stable/c/e160ab85166e77347d0cbe5149045cb25e83937f","https://git.kernel.org/stable/c/efeae5f4972f75d50002bc50eb112ab9e7069b18","https://git.kernel.org/stable/c/1571120c44dbe5757aee1612c5b6097cdc42710f","https://git.kernel.org/stable/c/21a0f310a9f3bfd2b4cf4f382430e638607db846","https://git.kernel.org/stable/c/298e767362cade639b7121ecb3cc5345b6529f62","https://git.kernel.org/stable/c/2be24c47ac19bf639c48c082486c08888bd603c6","https://git.kernel.org/stable/c/5a94cffe90e20e8fade0b9abd4370bd671fe87c7","https://git.kernel.org/stable/c/717de20abdcd1d4993fa450e28b8086a352620ea","https://git.kernel.org/stable/c/adc2474d823fe81d8da759207f4f1d3691aa775a","https://git.kernel.org/stable/c/e160ab85166e77347d0cbe5149045cb25e83937f","https://git.kernel.org/stable/c/efeae5f4972f75d50002bc50eb112ab9e7069b18"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-47943
|
High |
fixed |
|
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. There is an out-of-bounds read and OOPS for SMB2_WRITE, when there is a large length in the zero DataOffset case. |
["http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ac60778b87e45576d7bfdbd6f53df902654e6f09","https://github.com/torvalds/linux/commit/ac60778b87e45576d7bfdbd6f53df902654e6f09","https://security.netapp.com/advisory/ntap-20230216-0006/","https://www.zerodayinitiative.com/advisories/ZDI-22-1691/","http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ac60778b87e45576d7bfdbd6f53df902654e6f09","https://github.com/torvalds/linux/commit/ac60778b87e45576d7bfdbd6f53df902654e6f09","https://security.netapp.com/advisory/ntap-20230216-0006/","https://www.zerodayinitiative.com/advisories/ZDI-22-1691/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35854
|
High |
fixed |
- 5.4.275
- 5.10.216
- 5.15.158
- 6.1.90
- 6.6.30
- 6.8.9
|
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash
The rehash delayed work migrates filters from one region to another
according to the number of available credits.
The migrated from region is destroyed at the end of the work if the
number of credits is non-negative as the assumption is that this is
indicative of migration being complete. This assumption is incorrect as
a non-negative number of credits can also be the result of a failed
migration.
The destruction of a region that still has filters referencing it can
result in a use-after-free [1].
Fix by not destroying the region if migration failed.
[1]
BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230
Read of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858
CPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G W 6.9.0-rc2-custom-00782-gf2275c2157d8 #5
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
Call Trace:
<TASK>
dump_stack_lvl+0xc6/0x120
print_report+0xce/0x670
kasan_report+0xd7/0x110
mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230
mlxsw_sp_acl_ctcam_entry_del+0x2e/0x70
mlxsw_sp_acl_atcam_entry_del+0x81/0x210
mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3cd/0xb50
mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300
process_one_work+0x8eb/0x19b0
worker_thread+0x6c9/0xf70
kthread+0x2c9/0x3b0
ret_from_fork+0x4d/0x80
ret_from_fork_asm+0x1a/0x30
</TASK>
Allocated by task 174:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
__kasan_kmalloc+0x8f/0xa0
__kmalloc+0x19c/0x360
mlxsw_sp_acl_tcam_region_create+0xdf/0x9c0
mlxsw_sp_acl_tcam_vregion_rehash_work+0x954/0x1300
process_one_work+0x8eb/0x19b0
worker_thread+0x6c9/0xf70
kthread+0x2c9/0x3b0
ret_from_fork+0x4d/0x80
ret_from_fork_asm+0x1a/0x30
Freed by task 7:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x60
poison_slab_object+0x102/0x170
__kasan_slab_free+0x14/0x30
kfree+0xc1/0x290
mlxsw_sp_acl_tcam_region_destroy+0x272/0x310
mlxsw_sp_acl_tcam_vregion_rehash_work+0x731/0x1300
process_one_work+0x8eb/0x19b0
worker_thread+0x6c9/0xf70
kthread+0x2c9/0x3b0
ret_from_fork+0x4d/0x80
ret_from_fork_asm+0x1a/0x30 |
["https://git.kernel.org/stable/c/311eeaa7b9e26aba5b3d57b09859f07d8e9fc049","https://git.kernel.org/stable/c/4c89642ca47fb620914780c7c51d8d1248201121","https://git.kernel.org/stable/c/54225988889931467a9b55fdbef534079b665519","https://git.kernel.org/stable/c/813e2ab753a8f8c243a39ede20c2e0adc15f3887","https://git.kernel.org/stable/c/a02687044e124f8ccb427cd3632124a4e1a7d7c1","https://git.kernel.org/stable/c/a429a912d6c779807f4d72a6cc0a1efaaa3613e1","https://git.kernel.org/stable/c/e118e7ea24d1392878ef85926627c6bc640c4388","https://git.kernel.org/stable/c/311eeaa7b9e26aba5b3d57b09859f07d8e9fc049","https://git.kernel.org/stable/c/4c89642ca47fb620914780c7c51d8d1248201121","https://git.kernel.org/stable/c/54225988889931467a9b55fdbef534079b665519","https://git.kernel.org/stable/c/813e2ab753a8f8c243a39ede20c2e0adc15f3887","https://git.kernel.org/stable/c/a02687044e124f8ccb427cd3632124a4e1a7d7c1","https://git.kernel.org/stable/c/a429a912d6c779807f4d72a6cc0a1efaaa3613e1","https://git.kernel.org/stable/c/e118e7ea24d1392878ef85926627c6bc640c4388","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3113
|
Medium |
fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. mtk_vcodec_fw_vpu_init in drivers/media/platform/mtk-vcodec/mtk_vcodec_fw_vpu.c lacks check of the return value of devm_kzalloc() and will cause the null pointer dereference. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2153053","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=e25a89f743b18c029bfbe5e1663ae0c7190912b0","https://bugzilla.redhat.com/show_bug.cgi?id=2153053","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=e25a89f743b18c029bfbe5e1663ae0c7190912b0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38612
|
Critical |
fixed |
- 4.19.316
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: fix invalid unregister error path
The error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNEL
is not defined. In that case if seg6_hmac_init() fails, the
genl_unregister_family() isn't called.
This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control
lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible
use-after-free and null-ptr-deref") replaced unregister_pernet_subsys()
with genl_unregister_family() in this error path. |
["https://git.kernel.org/stable/c/00e6335329f23ac6cf3105931691674e28bc598c","https://git.kernel.org/stable/c/10610575a3ac2a702bf5c57aa931beaf847949c7","https://git.kernel.org/stable/c/160e9d2752181fcf18c662e74022d77d3164cd45","https://git.kernel.org/stable/c/1a63730fb315bb1bab97edd69ff58ad45e04bb01","https://git.kernel.org/stable/c/3398a40dccb88d3a7eef378247a023a78472db66","https://git.kernel.org/stable/c/646cd236c55e2cb5f146fc41bbe4034c4af5b2a4","https://git.kernel.org/stable/c/85a70ff1e572160f1eeb096ed48d09a1c9d4d89a","https://git.kernel.org/stable/c/c04d6a914e890ccea4a9d11233009a2ee7978bf4","https://git.kernel.org/stable/c/e77a3ec7ada84543e75722a1283785a6544de925","https://git.kernel.org/stable/c/00e6335329f23ac6cf3105931691674e28bc598c","https://git.kernel.org/stable/c/10610575a3ac2a702bf5c57aa931beaf847949c7","https://git.kernel.org/stable/c/160e9d2752181fcf18c662e74022d77d3164cd45","https://git.kernel.org/stable/c/1a63730fb315bb1bab97edd69ff58ad45e04bb01","https://git.kernel.org/stable/c/3398a40dccb88d3a7eef378247a023a78472db66","https://git.kernel.org/stable/c/646cd236c55e2cb5f146fc41bbe4034c4af5b2a4","https://git.kernel.org/stable/c/85a70ff1e572160f1eeb096ed48d09a1c9d4d89a","https://git.kernel.org/stable/c/c04d6a914e890ccea4a9d11233009a2ee7978bf4","https://git.kernel.org/stable/c/e77a3ec7ada84543e75722a1283785a6544de925"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-2639
|
High |
fixed |
- 3.19
- 4.5
- 4.9.312
- 4.14.277
- 4.19.240
- 5.4.191
- 5.10.113
- 5.15.36
- 5.17.5
|
An integer coercion error was found in the openvswitch kernel module. Given a sufficiently large number of actions, while copying and reserving memory for a new action of a new flow, the reserve_sfa_size() function does not return -EMSGSIZE as expected, potentially leading to an out-of-bounds write access. This flaw allows a local user to crash or potentially escalate their privileges on the system. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2084479","https://github.com/torvalds/linux/commit/cefa91b2332d7009bc0be5d951d6cbbf349f90f8","https://bugzilla.redhat.com/show_bug.cgi?id=2084479","https://github.com/torvalds/linux/commit/cefa91b2332d7009bc0be5d951d6cbbf349f90f8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38623
|
Critical |
fixed |
- 5.15.161
- 6.1.93
- 6.6.33
- 6.9.4
|
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Use variable length array instead of fixed size
Should fix smatch warning:
ntfs_set_label() error: __builtin_memcpy() 'uni->name' too small (20 vs 256) |
["https://git.kernel.org/stable/c/1997cdc3e727526aa5d84b32f7cbb3f56459b7ef","https://git.kernel.org/stable/c/1fe1c9dc21ee52920629d2d9b9bd84358931a8d1","https://git.kernel.org/stable/c/3839a9b19a4b70eff6b6ad70446f639f7fd5a3d7","https://git.kernel.org/stable/c/a2de301d90b782ac5d7a5fe32995caaee9ab3a0f","https://git.kernel.org/stable/c/cceef44b34819c24bb6ed70dce5b524bd3e368d1","https://git.kernel.org/stable/c/1997cdc3e727526aa5d84b32f7cbb3f56459b7ef","https://git.kernel.org/stable/c/1fe1c9dc21ee52920629d2d9b9bd84358931a8d1","https://git.kernel.org/stable/c/3839a9b19a4b70eff6b6ad70446f639f7fd5a3d7","https://git.kernel.org/stable/c/a2de301d90b782ac5d7a5fe32995caaee9ab3a0f","https://git.kernel.org/stable/c/cceef44b34819c24bb6ed70dce5b524bd3e368d1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-6200
|
High |
fixed |
|
A race condition was found in the Linux Kernel. Under certain conditions, an unauthenticated attacker from an adjacent network could send an ICMPv6 router advertisement packet, causing arbitrary code execution. |
["https://access.redhat.com/security/cve/CVE-2023-6200","https://bugzilla.redhat.com/show_bug.cgi?id=2250377","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dade3f6a1e4e","https://access.redhat.com/security/cve/CVE-2023-6200","https://bugzilla.redhat.com/show_bug.cgi?id=2250377","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dade3f6a1e4e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-43945
|
High |
fixed |
|
The Linux kernel NFSD implementation prior to versions 5.19.17 and 6.0.2 are vulnerable to buffer overflow. NFSD tracks the number of pages held by each NFSD thread by combining the receive and send buffers of a remote procedure call (RPC) into a single array of pages. A client can force the send buffer to shrink by sending an RPC message over TCP with garbage data added at the end of the message. The RPC message with garbage data is still correctly formed according to the specification and is passed forward to handlers. Vulnerable code in NFSD is not expecting the oversized request and writes beyond the allocated buffer space. CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H |
["http://packetstormsecurity.com/files/171289/Kernel-Live-Patch-Security-Notice-LNS-0092-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f90497a16e434c2211c66e3de8e77b17868382b8","https://security.netapp.com/advisory/ntap-20221215-0006/","http://packetstormsecurity.com/files/171289/Kernel-Live-Patch-Security-Notice-LNS-0092-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f90497a16e434c2211c66e3de8e77b17868382b8","https://security.netapp.com/advisory/ntap-20221215-0006/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26924
|
Medium |
fixed |
- 5.10.216
- 5.15.157
- 6.1.88
- 6.6.29
- 6.8.8
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: do not free live element
Pablo reports a crash with large batches of elements with a
back-to-back add/remove pattern. Quoting Pablo:
add_elem("00000000") timeout 100 ms
...
add_elem("0000000X") timeout 100 ms
del_elem("0000000X") <---------------- delete one that was just added
...
add_elem("00005000") timeout 100 ms
1) nft_pipapo_remove() removes element 0000000X
Then, KASAN shows a splat.
Looking at the remove function there is a chance that we will drop a
rule that maps to a non-deactivated element.
Removal happens in two steps, first we do a lookup for key k and return the
to-be-removed element and mark it as inactive in the next generation.
Then, in a second step, the element gets removed from the set/map.
The _remove function does not work correctly if we have more than one
element that share the same key.
This can happen if we insert an element into a set when the set already
holds an element with same key, but the element mapping to the existing
key has timed out or is not active in the next generation.
In such case its possible that removal will unmap the wrong element.
If this happens, we will leak the non-deactivated element, it becomes
unreachable.
The element that got deactivated (and will be freed later) will
remain reachable in the set data structure, this can result in
a crash when such an element is retrieved during lookup (stale
pointer).
Add a check that the fully matching key does in fact map to the element
that we have marked as inactive in the deactivation step.
If not, we need to continue searching.
Add a bug/warn trap at the end of the function as well, the remove
function must not ever be called with an invisible/unreachable/non-existent
element.
v2: avoid uneeded temporary variable (Stefano) |
["https://git.kernel.org/stable/c/14b001ba221136c15f894577253e8db535b99487","https://git.kernel.org/stable/c/3cfc9ec039af60dbd8965ae085b2c2ccdcfbe1cc","https://git.kernel.org/stable/c/41d8fdf3afaff312e17466e4ab732937738d5644","https://git.kernel.org/stable/c/7a1679e2d9bfa3b5f8755c2c7113e54b7d42bd46","https://git.kernel.org/stable/c/e3b887a9c11caf8357a821260e095f2a694a34f2","https://git.kernel.org/stable/c/ebf7c9746f073035ee26209e38c3a1170f7b349a","https://git.kernel.org/stable/c/14b001ba221136c15f894577253e8db535b99487","https://git.kernel.org/stable/c/3cfc9ec039af60dbd8965ae085b2c2ccdcfbe1cc","https://git.kernel.org/stable/c/41d8fdf3afaff312e17466e4ab732937738d5644","https://git.kernel.org/stable/c/7a1679e2d9bfa3b5f8755c2c7113e54b7d42bd46","https://git.kernel.org/stable/c/e3b887a9c11caf8357a821260e095f2a694a34f2","https://git.kernel.org/stable/c/ebf7c9746f073035ee26209e38c3a1170f7b349a","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38605
|
High |
fixed |
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: core: Fix NULL module pointer assignment at card init
The commit 81033c6b584b ("ALSA: core: Warn on empty module")
introduced a WARN_ON() for a NULL module pointer passed at snd_card
object creation, and it also wraps the code around it with '#ifdef
MODULE'. This works in most cases, but the devils are always in
details. "MODULE" is defined when the target code (i.e. the sound
core) is built as a module; but this doesn't mean that the caller is
also built-in or not. Namely, when only the sound core is built-in
(CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m),
the passed module pointer is ignored even if it's non-NULL, and
card->module remains as NULL. This would result in the missing module
reference up/down at the device open/close, leading to a race with the
code execution after the module removal.
For addressing the bug, move the assignment of card->module again out
of ifdef. The WARN_ON() is still wrapped with ifdef because the
module can be really NULL when all sound drivers are built-in.
Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would
lead to a false-positive NULL module check. Admittedly it won't catch
perfectly, i.e. no check is performed when CONFIG_SND=y. But, it's no
real problem as it's only for debugging, and the condition is pretty
rare. |
["https://git.kernel.org/stable/c/39381fe7394e5eafac76e7e9367e7351138a29c1","https://git.kernel.org/stable/c/6b8374ee2cabcf034faa34e69a855dc496a9ec12","https://git.kernel.org/stable/c/c935e72139e6d523defd60fe875c01eb1f9ea5c5","https://git.kernel.org/stable/c/d7ff29a429b56f04783152ad7bbd7233b740e434","https://git.kernel.org/stable/c/e007476725730c1a68387b54b7629486d8a8301e","https://git.kernel.org/stable/c/e644036a3e2b2c9b3eee3c61b5d31c2ca8b5ba92","https://git.kernel.org/stable/c/e7e0ca200772bdb2fdc6d43d32d341e87a36f811","https://git.kernel.org/stable/c/39381fe7394e5eafac76e7e9367e7351138a29c1","https://git.kernel.org/stable/c/6b8374ee2cabcf034faa34e69a855dc496a9ec12","https://git.kernel.org/stable/c/c935e72139e6d523defd60fe875c01eb1f9ea5c5","https://git.kernel.org/stable/c/d7ff29a429b56f04783152ad7bbd7233b740e434","https://git.kernel.org/stable/c/e007476725730c1a68387b54b7629486d8a8301e","https://git.kernel.org/stable/c/e644036a3e2b2c9b3eee3c61b5d31c2ca8b5ba92","https://git.kernel.org/stable/c/e7e0ca200772bdb2fdc6d43d32d341e87a36f811"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38582
|
Medium |
fixed |
- 4.19.316
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential hang in nilfs_detach_log_writer()
Syzbot has reported a potential hang in nilfs_detach_log_writer() called
during nilfs2 unmount.
Analysis revealed that this is because nilfs_segctor_sync(), which
synchronizes with the log writer thread, can be called after
nilfs_segctor_destroy() terminates that thread, as shown in the call trace
below:
nilfs_detach_log_writer
nilfs_segctor_destroy
nilfs_segctor_kill_thread --> Shut down log writer thread
flush_work
nilfs_iput_work_func
nilfs_dispose_list
iput
nilfs_evict_inode
nilfs_transaction_commit
nilfs_construct_segment (if inode needs sync)
nilfs_segctor_sync --> Attempt to synchronize with
log writer thread
*** DEADLOCK ***
Fix this issue by changing nilfs_segctor_sync() so that the log writer
thread returns normally without synchronizing after it terminates, and by
forcing tasks that are already waiting to complete once after the thread
terminates.
The skipped inode metadata flushout will then be processed together in the
subsequent cleanup work in nilfs_segctor_destroy(). |
["https://git.kernel.org/stable/c/06afce714d87c7cd1dcfccbcd800c5c5d2cf1cfd","https://git.kernel.org/stable/c/1c3844c5f4eac043954ebf6403fa9fd1f0e9c1c0","https://git.kernel.org/stable/c/6e5c8e8e024e147b834f56f2115aad241433679b","https://git.kernel.org/stable/c/911d38be151921a5d152bb55e81fd752384c6830","https://git.kernel.org/stable/c/a8799662fed1f8747edae87a1937549288baca6a","https://git.kernel.org/stable/c/bc9cee50a4a4ca23bdc49f75ea8242d8a2193b3b","https://git.kernel.org/stable/c/c516db6ab9eabbedbc430b4f93b0d8728e9b427f","https://git.kernel.org/stable/c/eb85dace897c5986bc2f36b3c783c6abb8a4292e","https://git.kernel.org/stable/c/eff7cdf890b02596b8d73e910bdbdd489175dbdb","https://git.kernel.org/stable/c/06afce714d87c7cd1dcfccbcd800c5c5d2cf1cfd","https://git.kernel.org/stable/c/1c3844c5f4eac043954ebf6403fa9fd1f0e9c1c0","https://git.kernel.org/stable/c/6e5c8e8e024e147b834f56f2115aad241433679b","https://git.kernel.org/stable/c/911d38be151921a5d152bb55e81fd752384c6830","https://git.kernel.org/stable/c/a8799662fed1f8747edae87a1937549288baca6a","https://git.kernel.org/stable/c/bc9cee50a4a4ca23bdc49f75ea8242d8a2193b3b","https://git.kernel.org/stable/c/c516db6ab9eabbedbc430b4f93b0d8728e9b427f","https://git.kernel.org/stable/c/eb85dace897c5986bc2f36b3c783c6abb8a4292e","https://git.kernel.org/stable/c/eff7cdf890b02596b8d73e910bdbdd489175dbdb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26594
|
High |
fixed |
- 5.15.149
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate mech token in session setup
If client send invalid mech token in session setup request, ksmbd
validate and make the error if it is invalid. |
["https://git.kernel.org/stable/c/5e6dfec95833edc54c48605a98365a7325e5541e","https://git.kernel.org/stable/c/6eb8015492bcc84e40646390e50a862b2c0529c9","https://git.kernel.org/stable/c/92e470163d96df8db6c4fa0f484e4a229edb903d","https://git.kernel.org/stable/c/a2b21ef1ea4cf632d19b3a7cc4d4245b8e63202a","https://git.kernel.org/stable/c/dd1de9268745f0eac83a430db7afc32cbd62e84b","https://git.kernel.org/stable/c/5e6dfec95833edc54c48605a98365a7325e5541e","https://git.kernel.org/stable/c/6eb8015492bcc84e40646390e50a862b2c0529c9","https://git.kernel.org/stable/c/92e470163d96df8db6c4fa0f484e4a229edb903d","https://git.kernel.org/stable/c/a2b21ef1ea4cf632d19b3a7cc4d4245b8e63202a","https://git.kernel.org/stable/c/dd1de9268745f0eac83a430db7afc32cbd62e84b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38541
|
Critical |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
of: module: add buffer overflow check in of_modalias()
In of_modalias(), if the buffer happens to be too small even for the 1st
snprintf() call, the len parameter will become negative and str parameter
(if not NULL initially) will point beyond the buffer's end. Add the buffer
overflow check after the 1st snprintf() call and fix such check after the
strlen() call (accounting for the terminating NUL char). |
["https://git.kernel.org/stable/c/0b0d5701a8bf02f8fee037e81aacf6746558bfd6","https://git.kernel.org/stable/c/5d59fd637a8af42b211a92b2edb2474325b4d488","https://git.kernel.org/stable/c/c7f24b7d94549ff4623e8f41ea4d9f5319bd8ac8","https://git.kernel.org/stable/c/cf7385cb26ac4f0ee6c7385960525ad534323252","https://git.kernel.org/stable/c/e45b69360a63165377b30db4a1dfddd89ca18e9a","https://git.kernel.org/stable/c/ee332023adfd5882808f2dabf037b32d6ce36f9e","https://git.kernel.org/stable/c/0b0d5701a8bf02f8fee037e81aacf6746558bfd6","https://git.kernel.org/stable/c/cf7385cb26ac4f0ee6c7385960525ad534323252","https://git.kernel.org/stable/c/e45b69360a63165377b30db4a1dfddd89ca18e9a","https://git.kernel.org/stable/c/ee332023adfd5882808f2dabf037b32d6ce36f9e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-2602
|
High |
|
N/A
|
io_uring UAF, Unix SCM garbage collection |
["http://packetstormsecurity.com/files/176533/Linux-Broken-Unix-GC-Interaction-Use-After-Free.html","https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2602","https://ubuntu.com/security/notices/USN-5691-1","https://ubuntu.com/security/notices/USN-5692-1","https://ubuntu.com/security/notices/USN-5693-1","https://ubuntu.com/security/notices/USN-5700-1","https://ubuntu.com/security/notices/USN-5752-1","http://packetstormsecurity.com/files/176533/Linux-Broken-Unix-GC-Interaction-Use-After-Free.html","https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2602","https://ubuntu.com/security/notices/USN-5691-1","https://ubuntu.com/security/notices/USN-5692-1","https://ubuntu.com/security/notices/USN-5693-1","https://ubuntu.com/security/notices/USN-5700-1","https://ubuntu.com/security/notices/USN-5752-1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-23222
|
High |
fixed |
|
kernel/bpf/verifier.c in the Linux kernel through 5.15.14 allows local users to gain privileges because of the availability of pointer arithmetic via certain *_OR_NULL pointer types. |
["http://www.openwall.com/lists/oss-security/2022/01/14/1","http://www.openwall.com/lists/oss-security/2022/01/18/2","http://www.openwall.com/lists/oss-security/2022/06/01/1","http://www.openwall.com/lists/oss-security/2022/06/04/3","http://www.openwall.com/lists/oss-security/2022/06/07/3","https://bugzilla.suse.com/show_bug.cgi?id=1194765","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=64620e0a1e712a778095bd35cbb277dc2259281f","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/FCR3LIRUEXR7CA63W5M2HT3K63MZGKBR/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/Z5VTIZZUPC73IEJNZX66BY2YCBRZAELB/","https://security.netapp.com/advisory/ntap-20220217-0002/","https://www.debian.org/security/2022/dsa-5050","https://www.openwall.com/lists/oss-security/2022/01/13/1","http://www.openwall.com/lists/oss-security/2022/01/14/1","http://www.openwall.com/lists/oss-security/2022/01/18/2","http://www.openwall.com/lists/oss-security/2022/06/01/1","http://www.openwall.com/lists/oss-security/2022/06/04/3","http://www.openwall.com/lists/oss-security/2022/06/07/3","https://bugzilla.suse.com/show_bug.cgi?id=1194765","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=64620e0a1e712a778095bd35cbb277dc2259281f","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/FCR3LIRUEXR7CA63W5M2HT3K63MZGKBR/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/Z5VTIZZUPC73IEJNZX66BY2YCBRZAELB/","https://security.netapp.com/advisory/ntap-20220217-0002/","https://www.debian.org/security/2022/dsa-5050","https://www.openwall.com/lists/oss-security/2022/01/13/1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44947
|
Medium |
fixed |
- 4.19.321
- 5.4.283
- 5.10.225
- 5.15.166
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
fuse: Initialize beyond-EOF page contents before setting uptodate
fuse_notify_store(), unlike fuse_do_readpage(), does not enable page
zeroing (because it can be used to change partial page contents).
So fuse_notify_store() must be more careful to fully initialize page
contents (including parts of the page that are beyond end-of-file)
before marking the page uptodate.
The current code can leave beyond-EOF page contents uninitialized, which
makes these uninitialized page contents visible to userspace via mmap().
This is an information leak, but only affects systems which do not
enable init-on-alloc (via CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y or the
corresponding kernel command line parameter). |
["https://git.kernel.org/stable/c/18a067240817bee8a9360539af5d79a4bf5398a5","https://git.kernel.org/stable/c/33168db352c7b56ae18aa55c2cae1a1c5905d30e","https://git.kernel.org/stable/c/3c0da3d163eb32f1f91891efaade027fa9b245b9","https://git.kernel.org/stable/c/4690e2171f651e2b415e3941ce17f2f7b813aff6","https://git.kernel.org/stable/c/49934861514d36d0995be8e81bb3312a499d8d9a","https://git.kernel.org/stable/c/831433527773e665bdb635ab5783d0b95d1246f4","https://git.kernel.org/stable/c/8c78303eafbf85a728dd84d1750e89240c677dd9","https://git.kernel.org/stable/c/ac42e0f0eb66af966015ee33fd355bc6f5d80cd6","https://project-zero.issues.chromium.org/issues/42451729"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-2008
|
High |
fixed |
- 5.4.202
- 5.10.127
- 5.15.51
- 5.18.8
- 5.19
|
A flaw was found in the Linux kernel's udmabuf device driver. The specific flaw exists within a fault handler. The issue results from the lack of proper validation of user-supplied data, which can result in a memory access past the end of an array. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the kernel. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2186862","https://github.com/torvalds/linux/commit/05b252cccb2e5c3f56119d25de684b4f810ba4","https://security.netapp.com/advisory/ntap-20230517-0007/","https://www.zerodayinitiative.com/advisories/ZDI-23-441/","https://bugzilla.redhat.com/show_bug.cgi?id=2186862","https://github.com/torvalds/linux/commit/05b252cccb2e5c3f56119d25de684b4f810ba4","https://security.netapp.com/advisory/ntap-20230517-0007/","https://www.zerodayinitiative.com/advisories/ZDI-23-441/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27028
|
Medium |
fixed |
- 4.19.311
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
spi: spi-mt65xx: Fix NULL pointer access in interrupt handler
The TX buffer in spi_transfer can be a NULL pointer, so the interrupt
handler may end up writing to the invalid memory and cause crashes.
Add a check to trans->tx_buf before using it. |
["https://git.kernel.org/stable/c/1784053cf10a14c4ebd8a890bad5cfe1bee51713","https://git.kernel.org/stable/c/2342b05ec5342a519e00524a507f7a6ea6791a38","https://git.kernel.org/stable/c/55f8ea6731aa64871ee6aef7dba53ee9f9f3b2f6","https://git.kernel.org/stable/c/62b1f837b15cf3ec2835724bdf8577e47d14c753","https://git.kernel.org/stable/c/766ec94cc57492eab97cbbf1595bd516ab0cb0e4","https://git.kernel.org/stable/c/a20ad45008a7c82f1184dc6dee280096009ece55","https://git.kernel.org/stable/c/bcfcdf19698024565eff427706ebbd8df65abd11","https://git.kernel.org/stable/c/bea82355df9e1c299625405b1947fc9b26b4c6d4","https://git.kernel.org/stable/c/c10fed329c1c104f375a75ed97ea3abef0786d62","https://git.kernel.org/stable/c/1784053cf10a14c4ebd8a890bad5cfe1bee51713","https://git.kernel.org/stable/c/2342b05ec5342a519e00524a507f7a6ea6791a38","https://git.kernel.org/stable/c/55f8ea6731aa64871ee6aef7dba53ee9f9f3b2f6","https://git.kernel.org/stable/c/62b1f837b15cf3ec2835724bdf8577e47d14c753","https://git.kernel.org/stable/c/766ec94cc57492eab97cbbf1595bd516ab0cb0e4","https://git.kernel.org/stable/c/a20ad45008a7c82f1184dc6dee280096009ece55","https://git.kernel.org/stable/c/bcfcdf19698024565eff427706ebbd8df65abd11","https://git.kernel.org/stable/c/bea82355df9e1c299625405b1947fc9b26b4c6d4","https://git.kernel.org/stable/c/c10fed329c1c104f375a75ed97ea3abef0786d62","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-4379
|
High |
fixed |
|
A use-after-free vulnerability was found in __nfs42_ssc_open() in fs/nfs/nfs4file.c in the Linux kernel. This flaw allows an attacker to conduct a remote denial |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=75333d48f92256a0dec91dbf07835e804fc411c0","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aeba12b26c79fc35e07e511f692a8907037d95da","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LECFVUHKIRBV5JJBE3KQCLGKNYJPBRCN/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RAVD6JIILAVSRHZ4VXSV3RAAGUXKVXZA/","https://seclists.org/oss-sec/2022/q4/185","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=75333d48f92256a0dec91dbf07835e804fc411c0","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aeba12b26c79fc35e07e511f692a8907037d95da","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LECFVUHKIRBV5JJBE3KQCLGKNYJPBRCN/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RAVD6JIILAVSRHZ4VXSV3RAAGUXKVXZA/","https://seclists.org/oss-sec/2022/q4/185","https://security.netapp.com/advisory/ntap-20230223-0004/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-32233
|
High |
fixed |
- 4.14.315
- 4.19.283
- 5.4.243
- 5.10.180
- 5.15.111
- 6.1.28
- 6.2.15
- 6.3.2
|
In the Linux kernel through 6.3.1, a use-after-free in Netfilter nf_tables when processing batch requests can be abused to perform arbitrary read and write operations on kernel memory. Unprivileged local users can obtain root privileges. This occurs because anonymous sets are mishandled. |
["http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html","http://www.openwall.com/lists/oss-security/2023/05/15/5","https://bugzilla.redhat.com/show_bug.cgi?id=2196105","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c1592a89942e9678f7d9c8030efa777c0d57edab","https://github.com/torvalds/linux/commit/c1592a89942e9678f7d9c8030efa777c0d57edab","https://lists.debian.org/debian-lts-announce/2023/06/msg00008.html","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://news.ycombinator.com/item?id=35879660","https://security.netapp.com/advisory/ntap-20230616-0002/","https://www.debian.org/security/2023/dsa-5402","https://www.openwall.com/lists/oss-security/2023/05/08/4","http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html","http://www.openwall.com/lists/oss-security/2023/05/15/5","https://bugzilla.redhat.com/show_bug.cgi?id=2196105","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c1592a89942e9678f7d9c8030efa777c0d57edab","https://github.com/torvalds/linux/commit/c1592a89942e9678f7d9c8030efa777c0d57edab","https://lists.debian.org/debian-lts-announce/2023/06/msg00008.html","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://news.ycombinator.com/item?id=35879660","https://security.netapp.com/advisory/ntap-20230616-0002/","https://www.debian.org/security/2023/dsa-5402","https://www.openwall.com/lists/oss-security/2023/05/08/4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-27666
|
High |
fixed |
|
A heap buffer overflow flaw was found in IPsec ESP transformation code in net/ipv4/esp4.c and net/ipv6/esp6.c. This flaw allows a local attacker with a normal user privilege to overwrite kernel heap objects and may cause a local privilege escalation threat. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2061633","https://github.com/torvalds/linux/commit/ebe48d368e97d007bfeb76fcb065d6cfc4c96645","https://security.netapp.com/advisory/ntap-20220429-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173","https://bugzilla.redhat.com/show_bug.cgi?id=2061633","https://github.com/torvalds/linux/commit/ebe48d368e97d007bfeb76fcb065d6cfc4c96645","https://security.netapp.com/advisory/ntap-20220429-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2008-4609
|
High |
|
N/A
|
The TCP implementation in (1) Linux, (2) platforms based on BSD Unix, (3) Microsoft Windows, (4) Cisco products, and probably other operating systems allows remote attackers to cause a denial of service (connection queue exhaustion) via multiple vectors that manipulate information in the TCP state table, as demonstrated by sockstress. |
["http://blog.robertlee.name/2008/10/conjecture-speculation.html","http://insecure.org/stf/tcp-dos-attack-explained.html","http://lists.immunitysec.com/pipermail/dailydave/2008-October/005360.html","http://marc.info/?l=bugtraq\u0026m=125856010926699\u0026w=2","http://marc.info/?l=bugtraq\u0026m=125856010926699\u0026w=2","http://searchsecurity.techtarget.com.au/articles/27154-TCP-is-fundamentally-borked","http://www.cisco.com/en/US/products/products_security_advisory09186a0080af511d.shtml","http://www.cisco.com/en/US/products/products_security_response09186a0080a15120.html","http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf","http://www.mandriva.com/security/advisories?name=MDVSA-2013:150","http://www.oracle.com/technetwork/topics/security/cpujul2012-392727.html","http://www.outpost24.com/news/news-2008-10-02.html","http://www.us-cert.gov/cas/techalerts/TA09-251A.html","https://docs.microsoft.com/en-us/security-updates/securitybulletins/2009/ms09-048","https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A6340","https://www.cert.fi/haavoittuvuudet/2008/tcp-vulnerabilities.html","http://blog.robertlee.name/2008/10/conjecture-speculation.html","http://insecure.org/stf/tcp-dos-attack-explained.html","http://lists.immunitysec.com/pipermail/dailydave/2008-October/005360.html","http://marc.info/?l=bugtraq\u0026m=125856010926699\u0026w=2","http://marc.info/?l=bugtraq\u0026m=125856010926699\u0026w=2","http://searchsecurity.techtarget.com.au/articles/27154-TCP-is-fundamentally-borked","http://www.cisco.com/en/US/products/products_security_advisory09186a0080af511d.shtml","http://www.cisco.com/en/US/products/products_security_response09186a0080a15120.html","http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf","http://www.mandriva.com/security/advisories?name=MDVSA-2013:150","http://www.oracle.com/technetwork/topics/security/cpujul2012-392727.html","http://www.outpost24.com/news/news-2008-10-02.html","http://www.us-cert.gov/cas/techalerts/TA09-251A.html","https://docs.microsoft.com/en-us/security-updates/securitybulletins/2009/ms09-048","https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A6340","https://www.cert.fi/haavoittuvuudet/2008/tcp-vulnerabilities.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52798
|
High |
fixed |
- 5.10.202
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix dfs radar event locking
The ath11k active pdevs are protected by RCU but the DFS radar event
handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a
read-side critical section.
Mark the code in question as an RCU read-side critical section to avoid
any potential use-after-free issues.
Compile tested only. |
["https://git.kernel.org/stable/c/1fd878e1750190a612b5de2af357cca422ec0822","https://git.kernel.org/stable/c/21ebb0aba580d347e12f01ce5f6e75044427b3d5","https://git.kernel.org/stable/c/3b6c14833165f689cc5928574ebafe52bbce5f1e","https://git.kernel.org/stable/c/426e718ce9ba60013364a54233feee309356cb82","https://git.kernel.org/stable/c/ca420ac4f9451f22347bae44b18ab47ba2c267ec","https://git.kernel.org/stable/c/f882f51905517575c9f793a3dff567af90ef9a10","https://git.kernel.org/stable/c/1fd878e1750190a612b5de2af357cca422ec0822","https://git.kernel.org/stable/c/21ebb0aba580d347e12f01ce5f6e75044427b3d5","https://git.kernel.org/stable/c/3b6c14833165f689cc5928574ebafe52bbce5f1e","https://git.kernel.org/stable/c/426e718ce9ba60013364a54233feee309356cb82","https://git.kernel.org/stable/c/ca420ac4f9451f22347bae44b18ab47ba2c267ec","https://git.kernel.org/stable/c/f882f51905517575c9f793a3dff567af90ef9a10"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47659
|
High |
fixed |
- 4.19.322
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.109
- 6.6.50
- 6.10.9
|
In the Linux kernel, the following vulnerability has been resolved:
smack: tcp: ipv4, fix incorrect labeling
Currently, Smack mirrors the label of incoming tcp/ipv4 connections:
when a label 'foo' connects to a label 'bar' with tcp/ipv4,
'foo' always gets 'foo' in returned ipv4 packets. So,
1) returned packets are incorrectly labeled ('foo' instead of 'bar')
2) 'bar' can write to 'foo' without being authorized to write.
Here is a scenario how to see this:
* Take two machines, let's call them C and S,
with active Smack in the default state
(no settings, no rules, no labeled hosts, only builtin labels)
* At S, add Smack rule 'foo bar w'
(labels 'foo' and 'bar' are instantiated at S at this moment)
* At S, at label 'bar', launch a program
that listens for incoming tcp/ipv4 connections
* From C, at label 'foo', connect to the listener at S.
(label 'foo' is instantiated at C at this moment)
Connection succeedes and works.
* Send some data in both directions.
* Collect network traffic of this connection.
All packets in both directions are labeled with the CIPSO
of the label 'foo'. Hence, label 'bar' writes to 'foo' without
being authorized, and even without ever being known at C.
If anybody cares: exactly the same happens with DCCP.
This behavior 1st manifested in release 2.6.29.4 (see Fixes below)
and it looks unintentional. At least, no explanation was provided.
I changed returned packes label into the 'bar',
to bring it into line with the Smack documentation claims. |
["https://git.kernel.org/stable/c/0776bcf9cb6de46fdd94d10118de1cf9b05f83b9","https://git.kernel.org/stable/c/0aea09e82eafa50a373fc8a4b84c1d4734751e2c","https://git.kernel.org/stable/c/2fe209d0ad2e2729f7e22b9b31a86cc3ff0db550","https://git.kernel.org/stable/c/4be9fd15c3c88775bdf6fa37acabe6de85beebff","https://git.kernel.org/stable/c/5b4b304f196c070342e32a4752e1fa2e22fc0671","https://git.kernel.org/stable/c/a948ec993541db4ef392b555c37a1186f4d61670","https://git.kernel.org/stable/c/d3703fa94116fed91f64c7d1c7d284fb4369070f","https://git.kernel.org/stable/c/d3f56c653c65f170b172d3c23120bc64ada645d8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50251
|
Medium |
fixed |
- 4.19.323
- 5.4.285
- 5.10.229
- 5.15.171
- 6.1.116
- 6.6.60
- 6.11.7
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_payload: sanitize offset and length before calling skb_checksum()
If access to offset + length is larger than the skbuff length, then
skb_checksum() triggers BUG_ON().
skb_checksum() internally subtracts the length parameter while iterating
over skbuff, BUG_ON(len) at the end of it checks that the expected
length to be included in the checksum calculation is fully consumed. |
["https://git.kernel.org/stable/c/0ab3be58b45b996764aba0187b46de19b3e58a72","https://git.kernel.org/stable/c/a661ed364ae6ae88c2fafa9ddc27df1af2a73701","https://git.kernel.org/stable/c/ac7df3fc80fc82bcc3b1e8f6ebc0d2c435d0c534","https://git.kernel.org/stable/c/b1d2de8a669fa14c499a385e056944d5352b3b40","https://git.kernel.org/stable/c/c43e0ea848e7b9bef7a682cbc5608022d6d29d7b","https://git.kernel.org/stable/c/d3217323525f7596427124359e76ea0d8fcc9874","https://git.kernel.org/stable/c/d5953d680f7e96208c29ce4139a0e38de87a57fe","https://git.kernel.org/stable/c/e3e608cbad376674d19a71ccd0d41804d9393f02","https://github.com/slavin-ayu/CVE-2024-50251-PoC"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38573
|
High |
fixed |
- 5.15.161
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
cppc_cpufreq: Fix possible null pointer dereference
cppc_cpufreq_get_rate() and hisi_cppc_cpufreq_get_rate() can be called from
different places with various parameters. So cpufreq_cpu_get() can return
null as 'policy' in some circumstances.
Fix this bug by adding null return check.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/769c4f355b7962895205b86ad35617873feef9a5","https://git.kernel.org/stable/c/9a185cc5a79ba408e1c73375706630662304f618","https://git.kernel.org/stable/c/b18daa4ec727c0266de5bfc78e818d168cc4aedf","https://git.kernel.org/stable/c/cf7de25878a1f4508c69dc9f6819c21ba177dbfe","https://git.kernel.org/stable/c/dfec15222529d22b15e5b0d63572a9e39570cab4","https://git.kernel.org/stable/c/f84b9b25d045e67a7eee5e73f21278c8ab06713c","https://git.kernel.org/stable/c/769c4f355b7962895205b86ad35617873feef9a5","https://git.kernel.org/stable/c/9a185cc5a79ba408e1c73375706630662304f618","https://git.kernel.org/stable/c/b18daa4ec727c0266de5bfc78e818d168cc4aedf","https://git.kernel.org/stable/c/cf7de25878a1f4508c69dc9f6819c21ba177dbfe","https://git.kernel.org/stable/c/dfec15222529d22b15e5b0d63572a9e39570cab4","https://git.kernel.org/stable/c/f84b9b25d045e67a7eee5e73f21278c8ab06713c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2017-6264
|
High |
|
N/A
|
An elevation of privilege vulnerability exists in the NVIDIA GPU driver (gm20b_clk_throt_set_cdev_state), where an out of bound memory read is used as a function pointer could lead to code execution in the kernel.This issue is rated as high because it could allow a local malicious application to execute arbitrary code within the context of a privileged process. Product: Android. Version: N/A. Android ID: A-34705430. References: N-CVE-2017-6264. |
["http://www.securityfocus.com/bid/101744","https://source.android.com/security/bulletin/2017-11-01","http://www.securityfocus.com/bid/101744","https://source.android.com/security/bulletin/2017-11-01"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35853
|
Medium |
fixed |
- 5.4.275
- 5.10.216
- 5.15.158
- 6.1.90
- 6.6.30
- 6.8.9
|
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix memory leak during rehash
The rehash delayed work migrates filters from one region to another.
This is done by iterating over all chunks (all the filters with the same
priority) in the region and in each chunk iterating over all the
filters.
If the migration fails, the code tries to migrate the filters back to
the old region. However, the rollback itself can also fail in which case
another migration will be erroneously performed. Besides the fact that
this ping pong is not a very good idea, it also creates a problem.
Each virtual chunk references two chunks: The currently used one
('vchunk->chunk') and a backup ('vchunk->chunk2'). During migration the
first holds the chunk we want to migrate filters to and the second holds
the chunk we are migrating filters from.
The code currently assumes - but does not verify - that the backup chunk
does not exist (NULL) if the currently used chunk does not reference the
target region. This assumption breaks when we are trying to rollback a
rollback, resulting in the backup chunk being overwritten and leaked
[1].
Fix by not rolling back a failed rollback and add a warning to avoid
future cases.
[1]
WARNING: CPU: 5 PID: 1063 at lib/parman.c:291 parman_destroy+0x17/0x20
Modules linked in:
CPU: 5 PID: 1063 Comm: kworker/5:11 Tainted: G W 6.9.0-rc2-custom-00784-gc6a05c468a0b #14
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
RIP: 0010:parman_destroy+0x17/0x20
[...]
Call Trace:
<TASK>
mlxsw_sp_acl_atcam_region_fini+0x19/0x60
mlxsw_sp_acl_tcam_region_destroy+0x49/0xf0
mlxsw_sp_acl_tcam_vregion_rehash_work+0x1f1/0x470
process_one_work+0x151/0x370
worker_thread+0x2cb/0x3e0
kthread+0xd0/0x100
ret_from_fork+0x34/0x50
ret_from_fork_asm+0x1a/0x30
</TASK> |
["https://git.kernel.org/stable/c/0ae8ff7b6d42e33943af462910bdcfa2ec0cb8cf","https://git.kernel.org/stable/c/413a01886c3958d4b8aac23a3bff3d430b92093e","https://git.kernel.org/stable/c/617e98ba4c50f4547c9eb0946b1cfc26937d70d1","https://git.kernel.org/stable/c/8ca3f7a7b61393804c46f170743c3b839df13977","https://git.kernel.org/stable/c/b3fd51f684a0711504f82de510da109ae639722d","https://git.kernel.org/stable/c/b822644fd90992ee362c5e0c8d2556efc8856c76","https://git.kernel.org/stable/c/c6f3fa7f5a748bf6e5c4eb742686d6952f854e76","https://git.kernel.org/stable/c/0ae8ff7b6d42e33943af462910bdcfa2ec0cb8cf","https://git.kernel.org/stable/c/413a01886c3958d4b8aac23a3bff3d430b92093e","https://git.kernel.org/stable/c/617e98ba4c50f4547c9eb0946b1cfc26937d70d1","https://git.kernel.org/stable/c/8ca3f7a7b61393804c46f170743c3b839df13977","https://git.kernel.org/stable/c/b3fd51f684a0711504f82de510da109ae639722d","https://git.kernel.org/stable/c/b822644fd90992ee362c5e0c8d2556efc8856c76","https://git.kernel.org/stable/c/c6f3fa7f5a748bf6e5c4eb742686d6952f854e76","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1012
|
High |
fixed |
|
A memory leak problem was found in the TCP source port generation algorithm in net/ipv4/tcp.c due to the small table perturb size. This flaw may allow an attacker to information leak and may cause a denial of service problem. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2064604","https://lore.kernel.org/lkml/20220427065233.2075-1-w%401wt.eu/T/","https://security.netapp.com/advisory/ntap-20221020-0006/","https://bugzilla.redhat.com/show_bug.cgi?id=2064604","https://lore.kernel.org/lkml/20220427065233.2075-1-w%401wt.eu/T/","https://security.netapp.com/advisory/ntap-20221020-0006/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-0179
|
High |
fixed |
|
A buffer overflow vulnerability was found in the Netfilter subsystem in the Linux Kernel. This issue could allow the leakage of both stack and heap addresses, and potentially allow Local Privilege Escalation to the root user via arbitrary code execution. |
["http://packetstormsecurity.com/files/171601/Kernel-Live-Patch-Security-Notice-LNS-0093-1.html","https://bugzilla.redhat.com/show_bug.cgi?id=2161713","https://seclists.org/oss-sec/2023/q1/20","https://security.netapp.com/advisory/ntap-20230511-0003/","http://packetstormsecurity.com/files/171601/Kernel-Live-Patch-Security-Notice-LNS-0093-1.html","https://bugzilla.redhat.com/show_bug.cgi?id=2161713","https://seclists.org/oss-sec/2023/q1/20","https://security.netapp.com/advisory/ntap-20230511-0003/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-3864
|
High |
|
N/A
|
A flaw was found in the way the dumpable flag setting was handled when certain SUID binaries executed its descendants. The prerequisite is a SUID binary that sets real UID equal to effective UID, and real GID equal to effective GID. The descendant will then have a dumpable value set to 1. As a result, if the descendant process crashes and core_pattern is set to a relative value, its core dump is stored in the current directory with uid:gid permissions. An unprivileged local user with eligible root SUID binary could use this flaw to place core dumps into root-owned directories, potentially resulting in escalation of privileges. |
["https://access.redhat.com/security/cve/CVE-2021-3864","https://bugzilla.redhat.com/show_bug.cgi?id=2015046","https://lore.kernel.org/all/20211221021744.864115-1-longman%40redhat.com/","https://lore.kernel.org/all/20211226150310.GA992%401wt.eu/","https://lore.kernel.org/lkml/20211228170910.623156-1-wander%40redhat.com/","https://security-tracker.debian.org/tracker/CVE-2021-3864","https://www.openwall.com/lists/oss-security/2021/10/20/2","https://access.redhat.com/security/cve/CVE-2021-3864","https://bugzilla.redhat.com/show_bug.cgi?id=2015046","https://lore.kernel.org/all/20211221021744.864115-1-longman%40redhat.com/","https://lore.kernel.org/all/20211226150310.GA992%401wt.eu/","https://lore.kernel.org/lkml/20211228170910.623156-1-wander%40redhat.com/","https://security-tracker.debian.org/tracker/CVE-2021-3864","https://www.openwall.com/lists/oss-security/2021/10/20/2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35835
|
Medium |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.76
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: fix a double-free in arfs_create_groups
When `in` allocated by kvzalloc fails, arfs_create_groups will free
ft->g and return an error. However, arfs_create_table, the only caller of
arfs_create_groups, will hold this error and call to
mlx5e_destroy_flow_table, in which the ft->g will be freed again. |
["https://git.kernel.org/stable/c/2501afe6c4c9829d03abe9a368b83d9ea1b611b7","https://git.kernel.org/stable/c/3c6d5189246f590e4e1f167991558bdb72a4738b","https://git.kernel.org/stable/c/42876db001bbea7558e8676d1019f08f9390addb","https://git.kernel.org/stable/c/66cc521a739ccd5da057a1cb3d6346c6d0e7619b","https://git.kernel.org/stable/c/b21db3f1ab7967a81d6bbd328d28fe5a4c07a8a7","https://git.kernel.org/stable/c/c57ca114eb00e03274dd38108d07a3750fa3c056","https://git.kernel.org/stable/c/cf116d9c3c2aebd653c2dfab5b10c278e9ec3ee5","https://git.kernel.org/stable/c/e3d3ed8c152971dbe64c92c9ecb98fdb52abb629","https://git.kernel.org/stable/c/2501afe6c4c9829d03abe9a368b83d9ea1b611b7","https://git.kernel.org/stable/c/3c6d5189246f590e4e1f167991558bdb72a4738b","https://git.kernel.org/stable/c/42876db001bbea7558e8676d1019f08f9390addb","https://git.kernel.org/stable/c/66cc521a739ccd5da057a1cb3d6346c6d0e7619b","https://git.kernel.org/stable/c/b21db3f1ab7967a81d6bbd328d28fe5a4c07a8a7","https://git.kernel.org/stable/c/c57ca114eb00e03274dd38108d07a3750fa3c056","https://git.kernel.org/stable/c/cf116d9c3c2aebd653c2dfab5b10c278e9ec3ee5","https://git.kernel.org/stable/c/e3d3ed8c152971dbe64c92c9ecb98fdb52abb629","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47685
|
Critical |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()
syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending
garbage on the four reserved tcp bits (th->res1)
Use skb_put_zero() to clear the whole TCP header,
as done in nf_reject_ip_tcphdr_put()
BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255
nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255
nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344
nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48
expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288
nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161
nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626
nf_hook include/linux/netfilter.h:269 [inline]
NF_HOOK include/linux/netfilter.h:312 [inline]
ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310
__netif_receive_skb_one_core net/core/dev.c:5661 [inline]
__netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775
process_backlog+0x4ad/0xa50 net/core/dev.c:6108
__napi_poll+0xe7/0x980 net/core/dev.c:6772
napi_poll net/core/dev.c:6841 [inline]
net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963
handle_softirqs+0x1ce/0x800 kernel/softirq.c:554
__do_softirq+0x14/0x1a kernel/softirq.c:588
do_softirq+0x9a/0x100 kernel/softirq.c:455
__local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382
local_bh_enable include/linux/bottom_half.h:33 [inline]
rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline]
__dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450
dev_queue_xmit include/linux/netdevice.h:3105 [inline]
neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565
neigh_output include/net/neighbour.h:542 [inline]
ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141
__ip6_finish_output net/ipv6/ip6_output.c:215 [inline]
ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247
dst_output include/net/dst.h:450 [inline]
NF_HOOK include/linux/netfilter.h:314 [inline]
ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366
inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135
__tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466
tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]
tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143
tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333
__inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679
inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750
__sys_connect_file net/socket.c:2061 [inline]
__sys_connect+0x606/0x690 net/socket.c:2078
__do_sys_connect net/socket.c:2088 [inline]
__se_sys_connect net/socket.c:2085 [inline]
__x64_sys_connect+0x91/0xe0 net/socket.c:2085
x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was stored to memory at:
nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249
nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344
nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48
expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288
nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161
nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626
nf_hook include/linux/netfilter.h:269 [inline]
NF_HOOK include/linux/netfilter.h:312 [inline]
ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310
__netif_receive_skb_one_core
---truncated--- |
["https://git.kernel.org/stable/c/10210658f827ad45061581cbfc05924b723e8922","https://git.kernel.org/stable/c/7a7b5a27c53b55e91eecf646d1b204e73fa4af93","https://git.kernel.org/stable/c/7bcbc4cda777d26c88500d973fad0d497fc8a82e","https://git.kernel.org/stable/c/7ea2bcfd9bf4c3dbbf22546162226fd1c14d8ad2","https://git.kernel.org/stable/c/872eca64c3267dbc5836b715716fc6c03a18eda7","https://git.kernel.org/stable/c/9c778fe48d20ef362047e3376dee56d77f8500d4","https://git.kernel.org/stable/c/af4b8a704f26f38310655bad67fd8096293275a2","https://git.kernel.org/stable/c/dcf48ab3ca2c55b09c8f9c8de0df01c1943bc4e5","https://git.kernel.org/stable/c/fbff87d682e57ddbbe82abf6d0a1a4a36a98afcd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-45934
|
High |
fixed |
- 4.9.337
- 4.14.303
- 4.19.270
- 5.4.229
- 5.10.161
- 5.15.85
- 6.0.15
|
An issue was discovered in the Linux kernel through 6.0.10. l2cap_config_req in net/bluetooth/l2cap_core.c has an integer wraparound via L2CAP_CONF_REQ packets. |
["https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=ae4569813a6e931258db627cdfe50dfb4f917d5d","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NDAKCGDW6CQ6G3RZWYZJO454R3L5CTQB/","https://security.netapp.com/advisory/ntap-20230113-0008/","https://www.debian.org/security/2023/dsa-5324","https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=ae4569813a6e931258db627cdfe50dfb4f917d5d","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NDAKCGDW6CQ6G3RZWYZJO454R3L5CTQB/","https://security.netapp.com/advisory/ntap-20230113-0008/","https://www.debian.org/security/2023/dsa-5324"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36912
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
Drivers: hv: vmbus: Track decrypted status in vmbus_gpadl
In CoCo VMs it is possible for the untrusted host to cause
set_memory_encrypted() or set_memory_decrypted() to fail such that an
error is returned and the resulting memory is shared. Callers need to
take care to handle these errors to avoid returning decrypted (shared)
memory to the page allocator, which could lead to functional or security
issues.
In order to make sure callers of vmbus_establish_gpadl() and
vmbus_teardown_gpadl() don't return decrypted/shared pages to
allocators, add a field in struct vmbus_gpadl to keep track of the
decryption status of the buffers. This will allow the callers to
know if they should free or leak the pages. |
["https://git.kernel.org/stable/c/1999644d95194d4a58d3e80ad04ce19220a01a81","https://git.kernel.org/stable/c/211f514ebf1ef5de37b1cf6df9d28a56cfd242ca","https://git.kernel.org/stable/c/8e62341f5c45b27519b7d193bcc32ada416ad9d8","https://git.kernel.org/stable/c/bfae56be077ba14311509e70706a13458f87ea99","https://git.kernel.org/stable/c/1999644d95194d4a58d3e80ad04ce19220a01a81","https://git.kernel.org/stable/c/211f514ebf1ef5de37b1cf6df9d28a56cfd242ca","https://git.kernel.org/stable/c/8e62341f5c45b27519b7d193bcc32ada416ad9d8","https://git.kernel.org/stable/c/bfae56be077ba14311509e70706a13458f87ea99"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-32981
|
High |
|
N/A
|
An issue was discovered in the Linux kernel through 5.18.3 on powerpc 32-bit platforms. There is a buffer overflow in ptrace PEEKUSER and POKEUSER (aka PEEKUSR and POKEUSR) when accessing floating point registers. |
["http://www.openwall.com/lists/oss-security/2022/06/14/3","https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=8e1278444446fc97778a5e5c99bca1ce0bbc5ec9","http://www.openwall.com/lists/oss-security/2022/06/14/3","https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=8e1278444446fc97778a5e5c99bca1ce0bbc5ec9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-2002
|
Medium |
fixed |
|
A vulnerability was found in the HCI sockets implementation due to a missing capability check in net/bluetooth/hci_sock.c in the Linux Kernel. This flaw allows an attacker to unauthorized execution of management commands, compromising the confidentiality, integrity, and availability of Bluetooth communication. |
["https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20240202-0004/","https://www.debian.org/security/2023/dsa-5480","https://www.openwall.com/lists/oss-security/2023/04/16/3","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20240202-0004/","https://www.debian.org/security/2023/dsa-5480","https://www.openwall.com/lists/oss-security/2023/04/16/3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52735
|
Critical |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itself
sock_map proto callbacks should never call themselves by design. Protect
against bugs like [1] and break out of the recursive loop to avoid a stack
overflow in favor of a resource leak.
[1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/ |
["https://git.kernel.org/stable/c/5b4a79ba65a1ab479903fff2e604865d229b70a9","https://git.kernel.org/stable/c/7499859881488da97589f3c79cc66fa75748ad49","https://git.kernel.org/stable/c/f312367f5246e04df564d341044286e9e37a97ba","https://git.kernel.org/stable/c/5b4a79ba65a1ab479903fff2e604865d229b70a9","https://git.kernel.org/stable/c/7499859881488da97589f3c79cc66fa75748ad49","https://git.kernel.org/stable/c/f312367f5246e04df564d341044286e9e37a97ba"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-0210
|
High |
fixed |
|
A bug affects the Linux kernel’s ksmbd NTLMv2 authentication and is known to crash the OS immediately in Linux-based systems. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=797805d81baa814f76cf7bdab35f86408a79d707","https://github.com/cifsd-team/ksmbd/commit/8824b7af409f51f1316e92e9887c2fd48c0b26d6","https://security.netapp.com/advisory/ntap-20230517-0002/","https://securityonline.info/cve-2023-0210-flaw-in-linux-kernel-allows-unauthenticated-remote-dos-attacks/","https://www.openwall.com/lists/oss-security/2023/01/04/1","https://www.openwall.com/lists/oss-security/2023/01/11/1","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=797805d81baa814f76cf7bdab35f86408a79d707","https://github.com/cifsd-team/ksmbd/commit/8824b7af409f51f1316e92e9887c2fd48c0b26d6","https://security.netapp.com/advisory/ntap-20230517-0002/","https://securityonline.info/cve-2023-0210-flaw-in-linux-kernel-allows-unauthenticated-remote-dos-attacks/","https://www.openwall.com/lists/oss-security/2023/01/04/1","https://www.openwall.com/lists/oss-security/2023/01/11/1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48655
|
High |
fixed |
- 5.4.277
- 5.10.218
- 5.15.71
- 5.19.12
|
In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Harden accesses to the reset domains
Accessing reset domains descriptors by the index upon the SCMI drivers
requests through the SCMI reset operations interface can potentially
lead to out-of-bound violations if the SCMI driver misbehave.
Add an internal consistency check before any such domains descriptors
accesses. |
["https://git.kernel.org/stable/c/1f08a1b26cfc53b7715abc46857c6023bb1b87de","https://git.kernel.org/stable/c/7184491fc515f391afba23d0e9b690caaea72daf","https://git.kernel.org/stable/c/8e65edf0d37698f7a6cb174608d3ec7976baf49e","https://git.kernel.org/stable/c/e9076ffbcaed5da6c182b144ef9f6e24554af268","https://git.kernel.org/stable/c/f2277d9e2a0d092c13bae7ee82d75432bb8b5108","https://git.kernel.org/stable/c/1f08a1b26cfc53b7715abc46857c6023bb1b87de","https://git.kernel.org/stable/c/7184491fc515f391afba23d0e9b690caaea72daf","https://git.kernel.org/stable/c/8e65edf0d37698f7a6cb174608d3ec7976baf49e","https://git.kernel.org/stable/c/e9076ffbcaed5da6c182b144ef9f6e24554af268","https://git.kernel.org/stable/c/f2277d9e2a0d092c13bae7ee82d75432bb8b5108","https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html","https://security.netapp.com/advisory/ntap-20240912-0008/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-42896
|
High |
fixed |
- 4.9.335
- 4.14.301
- 4.19.268
- 5.4.226
- 5.10.154
- 5.15.78
- 6.0.8
|
There are use-after-free vulnerabilities in the Linux kernel's net/bluetooth/l2cap_core.c's l2cap_connect and l2cap_le_connect_req functions which may allow code execution and leaking kernel memory (respectively) remotely via Bluetooth. A remote attacker could execute code leaking kernel memory via Bluetooth if within proximity of the victim.
We recommend upgrading past commit https://www.google.com/url https://github.com/torvalds/linux/commit/711f8c3fb3db61897080468586b970c87c61d9e4 https://www.google.com/url |
["https://github.com/torvalds/linux/commit/711f8c3fb3db61897080468586b970c87c61d9e4","https://kernel.dance/#711f8c3fb3db61897080468586b970c87c61d9e4","https://github.com/torvalds/linux/commit/711f8c3fb3db61897080468586b970c87c61d9e4","https://kernel.dance/#711f8c3fb3db61897080468586b970c87c61d9e4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3594
|
Medium |
fixed |
|
A vulnerability was found in Linux Kernel. It has been declared as problematic. Affected by this vulnerability is the function intr_callback of the file drivers/net/usb/r8152.c of the component BPF. The manipulation leads to logging of excessive data. The attack can be launched remotely. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211363. |
["https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=93e2be344a7db169b7119de21ac1bf253b8c6907","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://vuldb.com/?id.211363","https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=93e2be344a7db169b7119de21ac1bf253b8c6907","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://vuldb.com/?id.211363"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-47941
|
High |
fixed |
|
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. fs/ksmbd/smb2pdu.c omits a kfree call in certain smb2_handle_negotiate error conditions, aka a memory leak. |
["http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=aa7253c2393f6dcd6a1468b0792f6da76edad917","https://github.com/torvalds/linux/commit/aa7253c2393f6dcd6a1468b0792f6da76edad917","https://www.zerodayinitiative.com/advisories/ZDI-22-1687/","http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=aa7253c2393f6dcd6a1468b0792f6da76edad917","https://github.com/torvalds/linux/commit/aa7253c2393f6dcd6a1468b0792f6da76edad917","https://www.zerodayinitiative.com/advisories/ZDI-22-1687/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-2585
|
High |
fixed |
- 5.10.137
- 5.15.61
- 5.18.18
- 5.19.2
|
It was discovered that when exec'ing from a non-leader thread, armed POSIX CPU timers would be left on a list but freed, leading to a use-after-free. |
["https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2585","https://lore.kernel.org/lkml/20220809170751.164716-1-cascardo@canonical.com/T/#u","https://ubuntu.com/security/notices/USN-5564-1","https://ubuntu.com/security/notices/USN-5565-1","https://ubuntu.com/security/notices/USN-5566-1","https://ubuntu.com/security/notices/USN-5567-1","https://www.openwall.com/lists/oss-security/2022/08/09/7","https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2585","https://lore.kernel.org/lkml/20220809170751.164716-1-cascardo@canonical.com/T/#u","https://ubuntu.com/security/notices/USN-5564-1","https://ubuntu.com/security/notices/USN-5565-1","https://ubuntu.com/security/notices/USN-5566-1","https://ubuntu.com/security/notices/USN-5567-1","https://www.openwall.com/lists/oss-security/2022/08/09/7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47726
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to wait dio completion
It should wait all existing dio write IOs before block removal,
otherwise, previous direct write IO may overwrite data in the
block which may be reused by other inode. |
["https://git.kernel.org/stable/c/3aa5254d80969cb576601fb9fec7a188cc8dc169","https://git.kernel.org/stable/c/7be13b73409b553d9d9a6cbb042b4d19e2631cc7","https://git.kernel.org/stable/c/96cfeb0389530ae32ade8a48ae3ae1ac3b6c009d","https://git.kernel.org/stable/c/c2a7fc514637f640ff55c3f3e3ed879970814a3f","https://git.kernel.org/stable/c/e3db757ff9b7101ae68650ac5f6dd5743b68164e","https://git.kernel.org/stable/c/f81302decd64245bb1bd154ecae0f65a9ee21f04"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26804
|
Medium |
fixed |
- 5.4.271
- 5.10.212
- 5.15.151
- 6.1.81
- 6.6.21
- 6.7.9
|
In the Linux kernel, the following vulnerability has been resolved:
net: ip_tunnel: prevent perpetual headroom growth
syzkaller triggered following kasan splat:
BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170
Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191
[..]
kasan_report+0xda/0x110 mm/kasan/report.c:588
__skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170
skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline]
___skb_get_hash net/core/flow_dissector.c:1791 [inline]
__skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856
skb_get_hash include/linux/skbuff.h:1556 [inline]
ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748
ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
xmit_one net/core/dev.c:3548 [inline]
dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564
__dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592
...
ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235
ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323
..
iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82
ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831
ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
xmit_one net/core/dev.c:3548 [inline]
dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564
...
The splat occurs because skb->data points past skb->head allocated area.
This is because neigh layer does:
__skb_pull(skb, skb_network_offset(skb));
... but skb_network_offset() returns a negative offset and __skb_pull()
arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value.
The negative value is returned because skb->head and skb->data distance is
more than 64k and skb->network_header (u16) has wrapped around.
The bug is in the ip_tunnel infrastructure, which can cause
dev->needed_headroom to increment ad infinitum.
The syzkaller reproducer consists of packets getting routed via a gre
tunnel, and route of gre encapsulated packets pointing at another (ipip)
tunnel. The ipip encapsulation finds gre0 as next output device.
This results in the following pattern:
1). First packet is to be sent out via gre0.
Route lookup found an output device, ipip0.
2).
ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future
output device, rt.dev->needed_headroom (ipip0).
3).
ip output / start_xmit moves skb on to ipip0. which runs the same
code path again (xmit recursion).
4).
Routing step for the post-gre0-encap packet finds gre0 as output device
to use for ipip0 encapsulated packet.
tunl0->needed_headroom is then incremented based on the (already bumped)
gre0 device headroom.
This repeats for every future packet:
gre0->needed_headroom gets inflated because previous packets' ipip0 step
incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0
needed_headroom was increased.
For each subsequent packet, gre/ipip0->needed_headroom grows until
post-expand-head reallocations result in a skb->head/data distance of
more than 64k.
Once that happens, skb->network_header (u16) wraps around when
pskb_expand_head tries to make sure that skb_network_offset() is unchanged
after the headroom expansion/reallocation.
After this skb_network_offset(skb) returns a different (and negative)
result post headroom expansion.
The next trip to neigh layer (or anything else that would __skb_pull the
network header) makes skb->data point to a memory location outside
skb->head area.
v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to
prevent perpetual increase instead of dropping the headroom increment
completely. |
["https://git.kernel.org/stable/c/049d7989c67e8dd50f07a2096dbafdb41331fb9b","https://git.kernel.org/stable/c/2e95350fe9db9d53c701075060ac8ac883b68aee","https://git.kernel.org/stable/c/5ae1e9922bbdbaeb9cfbe91085ab75927488ac0f","https://git.kernel.org/stable/c/a0a1db40b23e8ff86dea2786c5ea1470bb23ecb9","https://git.kernel.org/stable/c/ab63de24ebea36fe73ac7121738595d704b66d96","https://git.kernel.org/stable/c/afec0c5cd2ed71ca95a8b36a5e6d03333bf34282","https://git.kernel.org/stable/c/f81e94d2dcd2397137edcb8b85f4c5bed5d22383","https://git.kernel.org/stable/c/049d7989c67e8dd50f07a2096dbafdb41331fb9b","https://git.kernel.org/stable/c/2e95350fe9db9d53c701075060ac8ac883b68aee","https://git.kernel.org/stable/c/5ae1e9922bbdbaeb9cfbe91085ab75927488ac0f","https://git.kernel.org/stable/c/a0a1db40b23e8ff86dea2786c5ea1470bb23ecb9","https://git.kernel.org/stable/c/ab63de24ebea36fe73ac7121738595d704b66d96","https://git.kernel.org/stable/c/afec0c5cd2ed71ca95a8b36a5e6d03333bf34282","https://git.kernel.org/stable/c/f81e94d2dcd2397137edcb8b85f4c5bed5d22383","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36913
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
Drivers: hv: vmbus: Leak pages if set_memory_encrypted() fails
In CoCo VMs it is possible for the untrusted host to cause
set_memory_encrypted() or set_memory_decrypted() to fail such that an
error is returned and the resulting memory is shared. Callers need to
take care to handle these errors to avoid returning decrypted (shared)
memory to the page allocator, which could lead to functional or security
issues.
VMBus code could free decrypted pages if set_memory_encrypted()/decrypted()
fails. Leak the pages if this happens. |
["https://git.kernel.org/stable/c/03f5a999adba062456c8c818a683beb1b498983a","https://git.kernel.org/stable/c/6123a4e8e25bd40cf44db14694abac00e6b664e6","https://git.kernel.org/stable/c/e813a0fc2e597146e9cebea61ced9c796d4e308f","https://git.kernel.org/stable/c/03f5a999adba062456c8c818a683beb1b498983a","https://git.kernel.org/stable/c/6123a4e8e25bd40cf44db14694abac00e6b664e6","https://git.kernel.org/stable/c/e813a0fc2e597146e9cebea61ced9c796d4e308f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-29968
|
High |
|
N/A
|
An issue was discovered in the Linux kernel through 5.17.5. io_rw_init_file in fs/io_uring.c lacks initialization of kiocb->private. |
["https://github.com/torvalds/linux/commit/32452a3eb8b64e01e2be717f518c0be046975b9d","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LU7MT7BPTA2NG24BTLZF5ZWYTLSO7BU3/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/TLWTG3TWIMLNQEVTA3ZQYVLLU2AJM3DY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XA7UZ3HS73KXVYCIKN5ZDH7LLLGPUMOZ/","https://security.netapp.com/advisory/ntap-20220715-0009/","https://github.com/torvalds/linux/commit/32452a3eb8b64e01e2be717f518c0be046975b9d","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LU7MT7BPTA2NG24BTLZF5ZWYTLSO7BU3/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/TLWTG3TWIMLNQEVTA3ZQYVLLU2AJM3DY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XA7UZ3HS73KXVYCIKN5ZDH7LLLGPUMOZ/","https://security.netapp.com/advisory/ntap-20220715-0009/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44946
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
kcm: Serialise kcm_sendmsg() for the same socket.
syzkaller reported UAF in kcm_release(). [0]
The scenario is
1. Thread A builds a skb with MSG_MORE and sets kcm->seq_skb.
2. Thread A resumes building skb from kcm->seq_skb but is blocked
by sk_stream_wait_memory()
3. Thread B calls sendmsg() concurrently, finishes building kcm->seq_skb
and puts the skb to the write queue
4. Thread A faces an error and finally frees skb that is already in the
write queue
5. kcm_release() does double-free the skb in the write queue
When a thread is building a MSG_MORE skb, another thread must not touch it.
Let's add a per-sk mutex and serialise kcm_sendmsg().
[0]:
BUG: KASAN: slab-use-after-free in __skb_unlink include/linux/skbuff.h:2366 [inline]
BUG: KASAN: slab-use-after-free in __skb_dequeue include/linux/skbuff.h:2385 [inline]
BUG: KASAN: slab-use-after-free in __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline]
BUG: KASAN: slab-use-after-free in __skb_queue_purge include/linux/skbuff.h:3181 [inline]
BUG: KASAN: slab-use-after-free in kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691
Read of size 8 at addr ffff0000ced0fc80 by task syz-executor329/6167
CPU: 1 PID: 6167 Comm: syz-executor329 Tainted: G B 6.8.0-rc5-syzkaller-g9abbc24128bc #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Call trace:
dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:291
show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:298
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x178/0x518 mm/kasan/report.c:488
kasan_report+0xd8/0x138 mm/kasan/report.c:601
__asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381
__skb_unlink include/linux/skbuff.h:2366 [inline]
__skb_dequeue include/linux/skbuff.h:2385 [inline]
__skb_queue_purge_reason include/linux/skbuff.h:3175 [inline]
__skb_queue_purge include/linux/skbuff.h:3181 [inline]
kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691
__sock_release net/socket.c:659 [inline]
sock_close+0xa4/0x1e8 net/socket.c:1421
__fput+0x30c/0x738 fs/file_table.c:376
____fput+0x20/0x30 fs/file_table.c:404
task_work_run+0x230/0x2e0 kernel/task_work.c:180
exit_task_work include/linux/task_work.h:38 [inline]
do_exit+0x618/0x1f64 kernel/exit.c:871
do_group_exit+0x194/0x22c kernel/exit.c:1020
get_signal+0x1500/0x15ec kernel/signal.c:2893
do_signal+0x23c/0x3b44 arch/arm64/kernel/signal.c:1249
do_notify_resume+0x74/0x1f4 arch/arm64/kernel/entry-common.c:148
exit_to_user_mode_prepare arch/arm64/kernel/entry-common.c:169 [inline]
exit_to_user_mode arch/arm64/kernel/entry-common.c:178 [inline]
el0_svc+0xac/0x168 arch/arm64/kernel/entry-common.c:713
el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598
Allocated by task 6166:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x40/0x78 mm/kasan/common.c:68
kasan_save_alloc_info+0x70/0x84 mm/kasan/generic.c:626
unpoison_slab_object mm/kasan/common.c:314 [inline]
__kasan_slab_alloc+0x74/0x8c mm/kasan/common.c:340
kasan_slab_alloc include/linux/kasan.h:201 [inline]
slab_post_alloc_hook mm/slub.c:3813 [inline]
slab_alloc_node mm/slub.c:3860 [inline]
kmem_cache_alloc_node+0x204/0x4c0 mm/slub.c:3903
__alloc_skb+0x19c/0x3d8 net/core/skbuff.c:641
alloc_skb include/linux/skbuff.h:1296 [inline]
kcm_sendmsg+0x1d3c/0x2124 net/kcm/kcmsock.c:783
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
sock_sendmsg+0x220/0x2c0 net/socket.c:768
splice_to_socket+0x7cc/0xd58 fs/splice.c:889
do_splice_from fs/splice.c:941 [inline]
direct_splice_actor+0xec/0x1d8 fs/splice.c:1164
splice_direct_to_actor+0x438/0xa0c fs/splice.c:1108
do_splice_direct_actor
---truncated--- |
["https://git.kernel.org/stable/c/00425508f30baa5ab6449a1f478480ca7cffa6da","https://git.kernel.org/stable/c/6633b17840bf828921254d788ccd15602843fe9b","https://git.kernel.org/stable/c/72da240aafb142630cf16adc803ccdacb3780849","https://git.kernel.org/stable/c/807067bf014d4a3ae2cc55bd3de16f22a01eb580","https://git.kernel.org/stable/c/8c9cdbf600143bd6835c8b8351e5ac956da79aec","https://git.kernel.org/stable/c/9c8d544ed619f704e2b70e63e08ab75630c2ea23","https://git.kernel.org/stable/c/eb06c8d3022ce6738711191c89f9b3e9cfb91914","https://git.kernel.org/stable/c/fa6c23fe6dcac8c8bd63920ee8681292a2bd544e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-35001
|
High |
fixed |
- 4.14.322
- 5.4.251
- 5.10.188
- 5.15.121
- 6.1.39
- 6.4.4
|
Linux Kernel nftables Out-Of-Bounds Read/Write Vulnerability; nft_byteorder poorly handled vm register contents when CAP_NET_ADMIN is in any user or network namespace |
["http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html","http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","http://www.openwall.com/lists/oss-security/2023/07/05/3","https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RGZC5XOANA75OJ4XARBBXYSLDKUIJI5E/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UPHI46ROSSLVAV4R5LJWJYU747JGOS6D/","https://lore.kernel.org/netfilter-devel/20230705121515.747251-1-cascardo@canonical.com/T/","https://security.netapp.com/advisory/ntap-20230824-0007/","https://www.debian.org/security/2023/dsa-5453","https://www.openwall.com/lists/oss-security/2023/07/05/3","http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html","http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","http://www.openwall.com/lists/oss-security/2023/07/05/3","https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RGZC5XOANA75OJ4XARBBXYSLDKUIJI5E/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UPHI46ROSSLVAV4R5LJWJYU747JGOS6D/","https://lore.kernel.org/netfilter-devel/20230705121515.747251-1-cascardo@canonical.com/T/","https://security.netapp.com/advisory/ntap-20230824-0007/","https://www.debian.org/security/2023/dsa-5453","https://www.openwall.com/lists/oss-security/2023/07/05/3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-6546
|
High |
fixed |
|
A race condition was found in the GSM 0710 tty multiplexor in the Linux kernel. This issue occurs when two threads execute the GSMIOC_SETCONF ioctl on the same tty file descriptor with the gsm line discipline enabled, and can lead to a use-after-free problem on a struct gsm_dlci while restarting the gsm mux. This could allow a local unprivileged user to escalate their privileges on the system. |
["https://access.redhat.com/errata/RHSA-2024:0930","https://access.redhat.com/errata/RHSA-2024:0937","https://access.redhat.com/errata/RHSA-2024:1018","https://access.redhat.com/errata/RHSA-2024:1019","https://access.redhat.com/errata/RHSA-2024:1055","https://access.redhat.com/errata/RHSA-2024:1250","https://access.redhat.com/errata/RHSA-2024:1253","https://access.redhat.com/errata/RHSA-2024:1306","https://access.redhat.com/errata/RHSA-2024:1607","https://access.redhat.com/errata/RHSA-2024:1612","https://access.redhat.com/errata/RHSA-2024:1614","https://access.redhat.com/errata/RHSA-2024:2093","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2621","https://access.redhat.com/errata/RHSA-2024:2697","https://access.redhat.com/errata/RHSA-2024:4577","https://access.redhat.com/errata/RHSA-2024:4729","https://access.redhat.com/errata/RHSA-2024:4731","https://access.redhat.com/errata/RHSA-2024:4970","https://access.redhat.com/security/cve/CVE-2023-6546","https://bugzilla.redhat.com/show_bug.cgi?id=2255498","https://github.com/torvalds/linux/commit/3c4f8333b582487a2d1e02171f1465531cde53e3","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20527","http://www.openwall.com/lists/oss-security/2024/04/10/18","http://www.openwall.com/lists/oss-security/2024/04/10/21","http://www.openwall.com/lists/oss-security/2024/04/11/7","http://www.openwall.com/lists/oss-security/2024/04/11/9","http://www.openwall.com/lists/oss-security/2024/04/12/1","http://www.openwall.com/lists/oss-security/2024/04/12/2","http://www.openwall.com/lists/oss-security/2024/04/16/2","http://www.openwall.com/lists/oss-security/2024/04/17/1","https://access.redhat.com/errata/RHSA-2024:0930","https://access.redhat.com/errata/RHSA-2024:0937","https://access.redhat.com/errata/RHSA-2024:1018","https://access.redhat.com/errata/RHSA-2024:1019","https://access.redhat.com/errata/RHSA-2024:1055","https://access.redhat.com/errata/RHSA-2024:1250","https://access.redhat.com/errata/RHSA-2024:1253","https://access.redhat.com/errata/RHSA-2024:1306","https://access.redhat.com/errata/RHSA-2024:1607","https://access.redhat.com/errata/RHSA-2024:1612","https://access.redhat.com/errata/RHSA-2024:1614","https://access.redhat.com/errata/RHSA-2024:2093","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2621","https://access.redhat.com/errata/RHSA-2024:2697","https://access.redhat.com/errata/RHSA-2024:4577","https://access.redhat.com/errata/RHSA-2024:4729","https://access.redhat.com/errata/RHSA-2024:4731","https://access.redhat.com/security/cve/CVE-2023-6546","https://bugzilla.redhat.com/show_bug.cgi?id=2255498","https://github.com/torvalds/linux/commit/3c4f8333b582487a2d1e02171f1465531cde53e3","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20527"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-47938
|
Medium |
fixed |
|
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. fs/ksmbd/smb2misc.c has an out-of-bounds read and OOPS for SMB2_TREE_CONNECT. |
["http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=824d4f64c20093275f72fc8101394d75ff6a249e","https://github.com/torvalds/linux/commit/824d4f64c20093275f72fc8101394d75ff6a249e","https://www.zerodayinitiative.com/advisories/ZDI-22-1689/","http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=824d4f64c20093275f72fc8101394d75ff6a249e","https://github.com/torvalds/linux/commit/824d4f64c20093275f72fc8101394d75ff6a249e","https://www.zerodayinitiative.com/advisories/ZDI-22-1689/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26952
|
High |
fixed |
- 5.15.181
- 6.1.119
- 6.6.32
- 6.7.12
- 6.8.3
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix potencial out-of-bounds when buffer offset is invalid
I found potencial out-of-bounds when buffer offset fields of a few requests
is invalid. This patch set the minimum value of buffer offset field to
->Buffer offset to validate buffer length. |
["https://git.kernel.org/stable/c/0c5541b4c980626fa3cab16ba1a451757778bbb5","https://git.kernel.org/stable/c/2dcda336b6e80b72d58d30d40f2fad9724e5fe63","https://git.kernel.org/stable/c/39bdc4197acf2ed13269167ccf093ee28cfa2a4e","https://git.kernel.org/stable/c/480469f145e5abf83361e608734e421b7d99693d","https://git.kernel.org/stable/c/ad6480c9a5d884e2704adc51d69895d93339176c","https://git.kernel.org/stable/c/c6cd2e8d2d9aa7ee35b1fa6a668e32a22a9753da","https://git.kernel.org/stable/c/0c5541b4c980626fa3cab16ba1a451757778bbb5","https://git.kernel.org/stable/c/2dcda336b6e80b72d58d30d40f2fad9724e5fe63","https://git.kernel.org/stable/c/39bdc4197acf2ed13269167ccf093ee28cfa2a4e","https://git.kernel.org/stable/c/c6cd2e8d2d9aa7ee35b1fa6a668e32a22a9753da"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-0045
|
High |
fixed |
- 3.17
- 4.5
- 4.10
- 4.14.303
- 4.19.270
- 5.4.229
- 5.10.163
- 5.15.87
- 6.0.19
- 6.1.5
|
The current implementation of the prctl syscall does not issue an IBPB immediately during the syscall. The ib_prctl_set function updates the Thread Information Flags (TIFs) for the task and updates the SPEC_CTRL MSR on the function __speculation_ctrl_update, but the IBPB is only issued on the next schedule, when the TIF bits are checked. This leaves the victim vulnerable to values already injected on the BTB, prior to the prctl syscall. The patch that added the support for the conditional mitigation via prctl (ib_prctl_set) dates back to the kernel 4.9.176.
We recommend upgrading past commit a664ec9158eeddd75121d39c9a0758016097fa96 |
["https://git.kernel.org/tip/a664ec9158eeddd75121d39c9a0758016097fa96","https://github.com/google/security-research/security/advisories/GHSA-9x5g-vmxf-4qj8","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230714-0001/","https://git.kernel.org/tip/a664ec9158eeddd75121d39c9a0758016097fa96","https://github.com/google/security-research/security/advisories/GHSA-9x5g-vmxf-4qj8","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230714-0001/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-31248
|
High |
fixed |
- 5.10.188
- 5.15.121
- 6.1.39
- 6.4.4
|
Linux Kernel nftables Use-After-Free Local Privilege Escalation Vulnerability; `nft_chain_lookup_byid()` failed to check whether a chain was active and CAP_NET_ADMIN is in any user or network namespace |
["http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html","http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","http://www.openwall.com/lists/oss-security/2023/07/05/2","https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RGZC5XOANA75OJ4XARBBXYSLDKUIJI5E/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UPHI46ROSSLVAV4R5LJWJYU747JGOS6D/","https://lore.kernel.org/netfilter-devel/20230705121627.GC19489@breakpoint.cc/T/","https://security.netapp.com/advisory/ntap-20240201-0001/","https://www.debian.org/security/2023/dsa-5453","https://www.openwall.com/lists/oss-security/2023/07/05/2","http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html","http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","http://www.openwall.com/lists/oss-security/2023/07/05/2","https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RGZC5XOANA75OJ4XARBBXYSLDKUIJI5E/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UPHI46ROSSLVAV4R5LJWJYU747JGOS6D/","https://lore.kernel.org/netfilter-devel/20230705121627.GC19489@breakpoint.cc/T/","https://security.netapp.com/advisory/ntap-20240201-0001/","https://www.debian.org/security/2023/dsa-5453","https://www.openwall.com/lists/oss-security/2023/07/05/2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-41218
|
Medium |
|
N/A
|
In drivers/media/dvb-core/dmxdev.c in the Linux kernel through 5.19.10, there is a use-after-free caused by refcount races, affecting dvb_demux_open and dvb_dmxdev_release. |
["http://www.openwall.com/lists/oss-security/2022/09/23/4","http://www.openwall.com/lists/oss-security/2022/09/24/1","http://www.openwall.com/lists/oss-security/2022/09/24/2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fd3d91ab1c6ab0628fe642dd570b56302c30a792","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/media/dvb-core/dmxdev.c","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20220908132754.30532-1-tiwai%40suse.de/","https://www.debian.org/security/2023/dsa-5324","http://www.openwall.com/lists/oss-security/2022/09/23/4","http://www.openwall.com/lists/oss-security/2022/09/24/1","http://www.openwall.com/lists/oss-security/2022/09/24/2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fd3d91ab1c6ab0628fe642dd570b56302c30a792","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/media/dvb-core/dmxdev.c","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20220908132754.30532-1-tiwai%40suse.de/","https://www.debian.org/security/2023/dsa-5324"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35857
|
Medium |
fixed |
- 5.15.158
- 6.1.90
- 6.6.30
- 6.8.9
|
In the Linux kernel, the following vulnerability has been resolved:
icmp: prevent possible NULL dereferences from icmp_build_probe()
First problem is a double call to __in_dev_get_rcu(), because
the second one could return NULL.
if (__in_dev_get_rcu(dev) && __in_dev_get_rcu(dev)->ifa_list)
Second problem is a read from dev->ip6_ptr with no NULL check:
if (!list_empty(&rcu_dereference(dev->ip6_ptr)->addr_list))
Use the correct RCU API to fix these.
v2: add missing include <net/addrconf.h> |
["https://git.kernel.org/stable/c/23b7ee4a8d559bf38eac7ce5bb2f6ebf76f9c401","https://git.kernel.org/stable/c/3e2979bf080c40da4f7c93aff8575ab8bc62b767","https://git.kernel.org/stable/c/599c9ad5e1d43f5c12d869f5fd406ba5d8c55270","https://git.kernel.org/stable/c/c58e88d49097bd12dfcfef4f075b43f5d5830941","https://git.kernel.org/stable/c/d68dc711d84fdcf698e5d45308c3ddeede586350","https://git.kernel.org/stable/c/23b7ee4a8d559bf38eac7ce5bb2f6ebf76f9c401","https://git.kernel.org/stable/c/3e2979bf080c40da4f7c93aff8575ab8bc62b767","https://git.kernel.org/stable/c/599c9ad5e1d43f5c12d869f5fd406ba5d8c55270","https://git.kernel.org/stable/c/c58e88d49097bd12dfcfef4f075b43f5d5830941","https://git.kernel.org/stable/c/d68dc711d84fdcf698e5d45308c3ddeede586350"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-42703
|
Medium |
fixed |
|
mm/rmap.c in the Linux kernel before 5.19.7 has a use-after-free related to leaf anon_vma double reuse. |
["https://bugs.chromium.org/p/project-zero/issues/detail?id=2351","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.7","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2555283eb40df89945557273121e9393ef9b542b","https://github.com/torvalds/linux/commit/2555283eb40df89945557273121e9393ef9b542b","https://googleprojectzero.blogspot.com/2022/12/exploiting-CVE-2022-42703-bringing-back-the-stack-attack.html","https://bugs.chromium.org/p/project-zero/issues/detail?id=2351","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.7","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2555283eb40df89945557273121e9393ef9b542b","https://github.com/torvalds/linux/commit/2555283eb40df89945557273121e9393ef9b542b","https://googleprojectzero.blogspot.com/2022/12/exploiting-CVE-2022-42703-bringing-back-the-stack-attack.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50083
|
High |
fixed |
- 5.10.228
- 5.15.169
- 6.1.114
- 6.6.58
- 6.11.5
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: fix mptcp DSS corruption due to large pmtu xmit
Syzkaller was able to trigger a DSS corruption:
TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies.
------------[ cut here ]------------
WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695
Modules linked in:
CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695
Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff
RSP: 0018:ffffc90000006db8 EFLAGS: 00010246
RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00
RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0
RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8
R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000
R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5
FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<IRQ>
move_skbs_to_msk net/mptcp/protocol.c:811 [inline]
mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854
subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490
tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283
tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237
tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915
tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350
ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205
ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233
NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314
NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314
__netif_receive_skb_one_core net/core/dev.c:5662 [inline]
__netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775
process_backlog+0x662/0x15b0 net/core/dev.c:6107
__napi_poll+0xcb/0x490 net/core/dev.c:6771
napi_poll net/core/dev.c:6840 [inline]
net_rx_action+0x89b/0x1240 net/core/dev.c:6962
handle_softirqs+0x2c5/0x980 kernel/softirq.c:554
do_softirq+0x11b/0x1e0 kernel/softirq.c:455
</IRQ>
<TASK>
__local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382
local_bh_enable include/linux/bottom_half.h:33 [inline]
rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]
__dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451
dev_queue_xmit include/linux/netdevice.h:3094 [inline]
neigh_hh_output include/net/neighbour.h:526 [inline]
neigh_output include/net/neighbour.h:540 [inline]
ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236
ip_local_out net/ipv4/ip_output.c:130 [inline]
__ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536
__tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466
tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]
tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline]
tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752
__tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015
tcp_push_pending_frames include/net/tcp.h:2107 [inline]
tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline]
tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239
tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915
sk_backlog_rcv include/net/sock.h:1113 [inline]
__release_sock+0x214/0x350 net/core/sock.c:3072
release_sock+0x61/0x1f0 net/core/sock.c:3626
mptcp_push_
---truncated--- |
["https://git.kernel.org/stable/c/229dfdc36f31a8d47433438bc0e6e1662c4ab404","https://git.kernel.org/stable/c/4dabcdf581217e60690467a37c956a5b8dbc6bd9","https://git.kernel.org/stable/c/9729010a0ac5945c1bf6847dd0778d8a1a4b72ac","https://git.kernel.org/stable/c/ba8e65814e519eeb17d086952bce7de93f7a40da","https://git.kernel.org/stable/c/c38add9ac0e4d4f418e6443a688491499021add9","https://git.kernel.org/stable/c/db04d1848777ae52a7ab93c4591e7c0bf8f55fb4","https://security.netapp.com/advisory/ntap-20250523-0010/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-42720
|
High |
fixed |
- 5.4.218
- 5.10.148
- 5.15.74
- 5.19.16
- 6.0.2
|
Various refcounting bugs in the multi-BSS handling in the mac80211 stack in the Linux kernel 5.1 through 5.19.x before 5.19.16 could be used by local attackers (able to inject WLAN frames) to trigger use-after-free conditions to potentially execute code. |
["http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html","http://www.openwall.com/lists/oss-security/2022/10/13/5","https://bugzilla.suse.com/show_bug.cgi?id=1204059","https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=0b7808818cb9df6680f98996b8e9a439fa7bcc2f","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://security.netapp.com/advisory/ntap-20230203-0008/","https://www.debian.org/security/2022/dsa-5257","http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html","http://www.openwall.com/lists/oss-security/2022/10/13/5","https://bugzilla.suse.com/show_bug.cgi?id=1204059","https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=0b7808818cb9df6680f98996b8e9a439fa7bcc2f","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://security.netapp.com/advisory/ntap-20230203-0008/","https://www.debian.org/security/2022/dsa-5257"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-42719
|
High |
fixed |
- 5.4.219
- 5.10.149
- 5.15.74
- 5.19.16
- 6.0.2
|
A use-after-free in the mac80211 stack when parsing a multi-BSSID element in the Linux kernel 5.2 through 5.19.x before 5.19.16 could be used by attackers (able to inject WLAN frames) to crash the kernel and potentially execute code. |
["http://packetstormsecurity.com/files/171005/Kernel-Live-Patch-Security-Notice-LNS-0091-1.html","http://www.openwall.com/lists/oss-security/2022/10/13/2","http://www.openwall.com/lists/oss-security/2022/10/13/5","https://bugzilla.suse.com/show_bug.cgi?id=1204051","https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=ff05d4b45dd89b922578dac497dcabf57cf771c6","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://security.netapp.com/advisory/ntap-20230203-0008/","https://www.debian.org/security/2022/dsa-5257","http://packetstormsecurity.com/files/171005/Kernel-Live-Patch-Security-Notice-LNS-0091-1.html","http://www.openwall.com/lists/oss-security/2022/10/13/2","http://www.openwall.com/lists/oss-security/2022/10/13/5","https://bugzilla.suse.com/show_bug.cgi?id=1204051","https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=ff05d4b45dd89b922578dac497dcabf57cf771c6","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://security.netapp.com/advisory/ntap-20230203-0008/","https://www.debian.org/security/2022/dsa-5257"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52699
|
Medium |
fixed |
- 4.19.312
- 5.4.274
- 5.10.215
- 5.15.155
- 6.1.86
- 6.6.27
- 6.8.6
|
In the Linux kernel, the following vulnerability has been resolved:
sysv: don't call sb_bread() with pointers_lock held
syzbot is reporting sleep in atomic context in SysV filesystem [1], for
sb_bread() is called with rw_spinlock held.
A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug
and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by
"Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12.
Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the
former bug by moving pointers_lock lock to the callers, but instead
introduced a "sb_bread() with read_lock(&pointers_lock)" bug (which made
this problem easier to hit).
Al Viro suggested that why not to do like get_branch()/get_block()/
find_shared() in Minix filesystem does. And doing like that is almost a
revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch()
from with find_shared() is called without write_lock(&pointers_lock). |
["https://git.kernel.org/stable/c/13b33feb2ebddc2b1aa607f553566b18a4af1d76","https://git.kernel.org/stable/c/1b4fe801b5bedec2b622ddb18e5c9bf26c63d79f","https://git.kernel.org/stable/c/53cb1e52c9db618c08335984d1ca80db220ccf09","https://git.kernel.org/stable/c/674c1c4229e743070e09db63a23442950ff000d1","https://git.kernel.org/stable/c/89e8524135a3902e7563a5a59b7b5ec1bf4904ac","https://git.kernel.org/stable/c/a69224223746ab96d43e5db9d22d136827b7e2d3","https://git.kernel.org/stable/c/f123dc86388cb669c3d6322702dc441abc35c31e","https://git.kernel.org/stable/c/fd203d2c671bdee9ab77090ff394d3b71b627927","https://git.kernel.org/stable/c/13b33feb2ebddc2b1aa607f553566b18a4af1d76","https://git.kernel.org/stable/c/1b4fe801b5bedec2b622ddb18e5c9bf26c63d79f","https://git.kernel.org/stable/c/53cb1e52c9db618c08335984d1ca80db220ccf09","https://git.kernel.org/stable/c/674c1c4229e743070e09db63a23442950ff000d1","https://git.kernel.org/stable/c/89e8524135a3902e7563a5a59b7b5ec1bf4904ac","https://git.kernel.org/stable/c/a69224223746ab96d43e5db9d22d136827b7e2d3","https://git.kernel.org/stable/c/f123dc86388cb669c3d6322702dc441abc35c31e","https://git.kernel.org/stable/c/fd203d2c671bdee9ab77090ff394d3b71b627927","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3646
|
Medium |
|
N/A
|
A vulnerability, which was classified as problematic, has been found in Linux Kernel. This issue affects the function nilfs_attach_log_writer of the file fs/nilfs2/segment.c of the component BPF. The manipulation leads to memory leak. The attack may be initiated remotely. It is recommended to apply a patch to fix this issue. The identifier VDB-211961 was assigned to this vulnerability. |
["https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d0d51a97063db4704a5ef6bc978dddab1636a306","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://vuldb.com/?id.211961","https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d0d51a97063db4704a5ef6bc978dddab1636a306","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://vuldb.com/?id.211961"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-6931
|
High |
fixed |
|
A heap out-of-bounds write vulnerability in the Linux kernel's Performance Events system component can be exploited to achieve local privilege escalation.
A perf_event's read_size can overflow, leading to an heap out-of-bounds increment or write in perf_read_group().
We recommend upgrading past commit 382c27f4ed28f803b1f1473ac2d8db0afc795a1b. |
["https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=382c27f4ed28f803b1f1473ac2d8db0afc795a1b","https://kernel.dance/382c27f4ed28f803b1f1473ac2d8db0afc795a1b","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=382c27f4ed28f803b1f1473ac2d8db0afc795a1b","https://kernel.dance/382c27f4ed28f803b1f1473ac2d8db0afc795a1b","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1652
|
High |
fixed |
- 4.9.316
- 4.14.281
- 4.19.245
- 5.4.196
- 5.10.118
- 5.15.42
- 5.17.10
|
Linux Kernel could allow a local attacker to execute arbitrary code on the system, caused by a concurrency use-after-free flaw in the bad_flp_intr function. By executing a specially-crafted program, an attacker could exploit this vulnerability to execute arbitrary code or cause a denial of service condition on the system. |
["https://bugzilla.redhat.com/show_bug.cgi?id=1832397","https://francozappa.github.io/about-bias/","https://kb.cert.org/vuls/id/647177/","https://security.netapp.com/advisory/ntap-20220722-0002/","https://www.debian.org/security/2022/dsa-5173","https://bugzilla.redhat.com/show_bug.cgi?id=1832397","https://francozappa.github.io/about-bias/","https://kb.cert.org/vuls/id/647177/","https://security.netapp.com/advisory/ntap-20220722-0002/","https://www.debian.org/security/2022/dsa-5173"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3621
|
Medium |
|
N/A
|
A vulnerability was found in Linux Kernel. It has been classified as problematic. Affected is the function nilfs_bmap_lookup_at_level of the file fs/nilfs2/inode.c of the component nilfs2. The manipulation leads to null pointer dereference. It is possible to launch the attack remotely. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211920. |
["https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=21a87d88c2253350e115029f14fe2a10a7e6c856","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://vuldb.com/?id.211920","https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=21a87d88c2253350e115029f14fe2a10a7e6c856","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://vuldb.com/?id.211920"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35970
|
Medium |
fixed |
- 5.15.156
- 6.1.87
- 6.6.28
- 6.8.7
|
In the Linux kernel, the following vulnerability has been resolved:
af_unix: Clear stale u->oob_skb.
syzkaller started to report deadlock of unix_gc_lock after commit
4090fa373f0e ("af_unix: Replace garbage collection algorithm."), but
it just uncovers the bug that has been there since commit 314001f0bf92
("af_unix: Add OOB support").
The repro basically does the following.
from socket import *
from array import array
c1, c2 = socketpair(AF_UNIX, SOCK_STREAM)
c1.sendmsg([b'a'], [(SOL_SOCKET, SCM_RIGHTS, array("i", [c2.fileno()]))], MSG_OOB)
c2.recv(1) # blocked as no normal data in recv queue
c2.close() # done async and unblock recv()
c1.close() # done async and trigger GC
A socket sends its file descriptor to itself as OOB data and tries to
receive normal data, but finally recv() fails due to async close().
The problem here is wrong handling of OOB skb in manage_oob(). When
recvmsg() is called without MSG_OOB, manage_oob() is called to check
if the peeked skb is OOB skb. In such a case, manage_oob() pops it
out of the receive queue but does not clear unix_sock(sk)->oob_skb.
This is wrong in terms of uAPI.
Let's say we send "hello" with MSG_OOB, and "world" without MSG_OOB.
The 'o' is handled as OOB data. When recv() is called twice without
MSG_OOB, the OOB data should be lost.
>>> from socket import *
>>> c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0)
>>> c1.send(b'hello', MSG_OOB) # 'o' is OOB data
5
>>> c1.send(b'world')
5
>>> c2.recv(5) # OOB data is not received
b'hell'
>>> c2.recv(5) # OOB date is skipped
b'world'
>>> c2.recv(5, MSG_OOB) # This should return an error
b'o'
In the same situation, TCP actually returns -EINVAL for the last
recv().
Also, if we do not clear unix_sk(sk)->oob_skb, unix_poll() always set
EPOLLPRI even though the data has passed through by previous recv().
To avoid these issues, we must clear unix_sk(sk)->oob_skb when dequeuing
it from recv queue.
The reason why the old GC did not trigger the deadlock is because the
old GC relied on the receive queue to detect the loop.
When it is triggered, the socket with OOB data is marked as GC candidate
because file refcount == inflight count (1). However, after traversing
all inflight sockets, the socket still has a positive inflight count (1),
thus the socket is excluded from candidates. Then, the old GC lose the
chance to garbage-collect the socket.
With the old GC, the repro continues to create true garbage that will
never be freed nor detected by kmemleak as it's linked to the global
inflight list. That's why we couldn't even notice the issue. |
["https://git.kernel.org/stable/c/601a89ea24d05089debfa2dc896ea9f5937ac7a6","https://git.kernel.org/stable/c/698a95ade1a00e6494482046902b986dfffd1caf","https://git.kernel.org/stable/c/84a352b7eba1142a95441380058985ff19f25ec9","https://git.kernel.org/stable/c/b46f4eaa4f0ec38909fb0072eea3aeddb32f954e","https://git.kernel.org/stable/c/b4bc99d04c689b5652665394ae8d3e02fb754153","https://git.kernel.org/stable/c/601a89ea24d05089debfa2dc896ea9f5937ac7a6","https://git.kernel.org/stable/c/698a95ade1a00e6494482046902b986dfffd1caf","https://git.kernel.org/stable/c/84a352b7eba1142a95441380058985ff19f25ec9","https://git.kernel.org/stable/c/b46f4eaa4f0ec38909fb0072eea3aeddb32f954e","https://git.kernel.org/stable/c/b4bc99d04c689b5652665394ae8d3e02fb754153"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1829
|
High |
fixed |
- 4.14.308
- 4.19.276
- 5.4.235
- 5.10.173
- 5.15.100
- 6.1.18
- 6.2.5
|
A use-after-free vulnerability in the Linux Kernel traffic control index filter (tcindex) can be exploited to achieve local privilege escalation. The tcindex_delete function which does not properly deactivate filters in case of a perfect hashes while deleting the underlying structure which can later lead to double freeing the structure. A local attacker user can use this vulnerability to elevate its privileges to root.
We recommend upgrading past commit 8c710f75256bb3cf05ac7b1672c82b92c43f3d28. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8c710f75256bb3cf05ac7b1672c82b92c43f3d28","https://kernel.dance/#8c710f75256bb3cf05ac7b1672c82b92c43f3d28","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230601-0001/","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8c710f75256bb3cf05ac7b1672c82b92c43f3d28","https://kernel.dance/#8c710f75256bb3cf05ac7b1672c82b92c43f3d28","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230601-0001/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-46813
|
High |
fixed |
|
An issue was discovered in the Linux kernel before 6.5.9, exploitable by local users with userspace access to MMIO registers. Incorrect access checking in the #VC handler and instruction emulation of the SEV-ES emulation of MMIO accesses could lead to arbitrary write access to kernel memory (and thus privilege escalation). This depends on a race condition through which userspace can replace an instruction before the #VC handler reads it. |
["https://bugzilla.suse.com/show_bug.cgi?id=1212649","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.5.9","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=63e44bc52047f182601e7817da969a105aa1f721","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a37cd2a59d0cb270b1bba568fd3a3b8668b9d3ba","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b9cb9c45583b911e0db71d09caa6b56469eb2bdf","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://bugzilla.suse.com/show_bug.cgi?id=1212649","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.5.9","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=63e44bc52047f182601e7817da969a105aa1f721","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a37cd2a59d0cb270b1bba568fd3a3b8668b9d3ba","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b9cb9c45583b911e0db71d09caa6b56469eb2bdf","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47693
|
Medium |
fixed |
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
IB/core: Fix ib_cache_setup_one error flow cleanup
When ib_cache_update return an error, we exit ib_cache_setup_one
instantly with no proper cleanup, even though before this we had
already successfully done gid_table_setup_one, that results in
the kernel WARN below.
Do proper cleanup using gid_table_cleanup_one before returning
the err in order to fix the issue.
WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0
Modules linked in:
CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:gid_table_release_one+0x181/0x1a0
Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41
RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527
RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001
RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631
R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001
R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001
FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
? show_regs+0x94/0xa0
? __warn+0x9e/0x1c0
? gid_table_release_one+0x181/0x1a0
? report_bug+0x1f9/0x340
? gid_table_release_one+0x181/0x1a0
? handle_bug+0xa2/0x110
? exc_invalid_op+0x31/0xa0
? asm_exc_invalid_op+0x16/0x20
? __warn_printk+0xc7/0x180
? __warn_printk+0xd4/0x180
? gid_table_release_one+0x181/0x1a0
ib_device_release+0x71/0xe0
? __pfx_ib_device_release+0x10/0x10
device_release+0x44/0xd0
kobject_put+0x135/0x3d0
put_device+0x20/0x30
rxe_net_add+0x7d/0xa0
rxe_newlink+0xd7/0x190
nldev_newlink+0x1b0/0x2a0
? __pfx_nldev_newlink+0x10/0x10
rdma_nl_rcv_msg+0x1ad/0x2e0
rdma_nl_rcv_skb.constprop.0+0x176/0x210
netlink_unicast+0x2de/0x400
netlink_sendmsg+0x306/0x660
__sock_sendmsg+0x110/0x120
____sys_sendmsg+0x30e/0x390
___sys_sendmsg+0x9b/0xf0
? kstrtouint+0x6e/0xa0
? kstrtouint_from_user+0x7c/0xb0
? get_pid_task+0xb0/0xd0
? proc_fail_nth_write+0x5b/0x140
? __fget_light+0x9a/0x200
? preempt_count_add+0x47/0xa0
__sys_sendmsg+0x61/0xd0
do_syscall_64+0x50/0x110
entry_SYSCALL_64_after_hwframe+0x76/0x7e |
["https://git.kernel.org/stable/c/1403c8b14765eab805377dd3b75e96ace8747aed","https://git.kernel.org/stable/c/1730d47d1865af89efd01cf0469a9a739cbf60f2","https://git.kernel.org/stable/c/290fe42fe0165205c4451334d8833a9202ae1d52","https://git.kernel.org/stable/c/45f63f4bb9a7128a6209d766c2fc02b3d42fbf3e","https://git.kernel.org/stable/c/af633fd9d9fff59e31c804f47ca0c8a784977773","https://git.kernel.org/stable/c/d08754be993f270e3d296d8f5d8e071fe6638651"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2020-27815
|
High |
fixed |
- 4.9.249
- 4.14.213
- 4.19.164
- 5.4.86
- 5.10.4
|
A flaw was found in the JFS filesystem code in the Linux Kernel which allows a local attacker with the ability to set extended attributes to panic the system, causing memory corruption or escalating privileges. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability. |
["http://www.openwall.com/lists/oss-security/2020/11/30/5","http://www.openwall.com/lists/oss-security/2020/12/28/1","https://bugzilla.redhat.com/show_bug.cgi?id=1897668%2C","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c61b3e4839007668360ed8b87d7da96d2e59fc6c","https://lists.debian.org/debian-lts-announce/2021/02/msg00018.html","https://lists.debian.org/debian-lts-announce/2021/03/msg00010.html","https://security.netapp.com/advisory/ntap-20210702-0004/","https://www.debian.org/security/2021/dsa-4843","https://www.openwall.com/lists/oss-security/2020/11/30/5%2C","https://www.openwall.com/lists/oss-security/2020/12/28/1%2C","http://www.openwall.com/lists/oss-security/2020/11/30/5","http://www.openwall.com/lists/oss-security/2020/12/28/1","https://bugzilla.redhat.com/show_bug.cgi?id=1897668%2C","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c61b3e4839007668360ed8b87d7da96d2e59fc6c","https://lists.debian.org/debian-lts-announce/2021/02/msg00018.html","https://lists.debian.org/debian-lts-announce/2021/03/msg00010.html","https://security.netapp.com/advisory/ntap-20210702-0004/","https://www.debian.org/security/2021/dsa-4843","https://www.openwall.com/lists/oss-security/2020/11/30/5%2C","https://www.openwall.com/lists/oss-security/2020/12/28/1%2C"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47692
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
nfsd: return -EINVAL when namelen is 0
When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may
result in namelen being 0, which will cause memdup_user() to return
ZERO_SIZE_PTR.
When we access the name.data that has been assigned the value of
ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is
triggered.
[ T1205] ==================================================================
[ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260
[ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205
[ T1205]
[ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406
[ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
[ T1205] Call Trace:
[ T1205] dump_stack+0x9a/0xd0
[ T1205] ? nfs4_client_to_reclaim+0xe9/0x260
[ T1205] __kasan_report.cold+0x34/0x84
[ T1205] ? nfs4_client_to_reclaim+0xe9/0x260
[ T1205] kasan_report+0x3a/0x50
[ T1205] nfs4_client_to_reclaim+0xe9/0x260
[ T1205] ? nfsd4_release_lockowner+0x410/0x410
[ T1205] cld_pipe_downcall+0x5ca/0x760
[ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0
[ T1205] ? down_write_killable_nested+0x170/0x170
[ T1205] ? avc_policy_seqno+0x28/0x40
[ T1205] ? selinux_file_permission+0x1b4/0x1e0
[ T1205] rpc_pipe_write+0x84/0xb0
[ T1205] vfs_write+0x143/0x520
[ T1205] ksys_write+0xc9/0x170
[ T1205] ? __ia32_sys_read+0x50/0x50
[ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110
[ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110
[ T1205] do_syscall_64+0x33/0x40
[ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1
[ T1205] RIP: 0033:0x7fdbdb761bc7
[ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514
[ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7
[ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008
[ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001
[ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b
[ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000
[ T1205] ==================================================================
Fix it by checking namelen. |
["https://git.kernel.org/stable/c/0f1d007bbea38a61cf9c5392708dc70ae9d84a3d","https://git.kernel.org/stable/c/1ff8be8d008b9ddc8e7043fbddd37d5d451b271b","https://git.kernel.org/stable/c/22451a16b7ab7debefce660672566be887db1637","https://git.kernel.org/stable/c/318f70857caab3da9a6ada9bc8c1f4f7591b695e","https://git.kernel.org/stable/c/6d07040ae5c2214e39c7444d898039c9e655a79a","https://git.kernel.org/stable/c/766d5fbd78f7a52b3888449a0358760477b74602","https://git.kernel.org/stable/c/84a563d136faf514fdad1ade28d7a142fd313cb8","https://git.kernel.org/stable/c/b7b7a8df41ef18862dd6b22289fb46c2c12398af"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-41674
|
High |
fixed |
- 5.4.218
- 5.10.148
- 5.15.74
- 5.19.16
- 6.0.2
|
An issue was discovered in the Linux kernel before 5.19.16. Attackers able to inject WLAN frames could cause a buffer overflow in the ieee80211_bss_info_update function in net/mac80211/scan.c. |
["http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html","http://www.openwall.com/lists/oss-security/2022/10/13/2","https://bugzilla.suse.com/show_bug.cgi?id=1203770","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/net/mac80211/scan.c","https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=aebe9f4639b13a1f4e9a6b42cdd2e38c617b442d","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://www.debian.org/security/2022/dsa-5257","https://www.openwall.com/lists/oss-security/2022/10/13/5","http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html","http://www.openwall.com/lists/oss-security/2022/10/13/2","https://bugzilla.suse.com/show_bug.cgi?id=1203770","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/net/mac80211/scan.c","https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=aebe9f4639b13a1f4e9a6b42cdd2e38c617b442d","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://www.debian.org/security/2022/dsa-5257","https://www.openwall.com/lists/oss-security/2022/10/13/5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49997
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: lantiq_etop: fix memory disclosure
When applying padding, the buffer is not zeroed, which results in memory
disclosure. The mentioned data is observed on the wire. This patch uses
skb_put_padto() to pad Ethernet frames properly. The mentioned function
zeroes the expanded buffer.
In case the packet cannot be padded it is silently dropped. Statistics
are also not incremented. This driver does not support statistics in the
old 32-bit format or the new 64-bit format. These will be added in the
future. In its current form, the patch should be easily backported to
stable versions.
Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets
in hardware, so software padding must be applied. |
["https://git.kernel.org/stable/c/1097bf16501ed5e35358d848b0a94ad2830b0f65","https://git.kernel.org/stable/c/185df159843d30fb71f821e7ea4368c2a3bfcd36","https://git.kernel.org/stable/c/2bf4c101d7c99483b8b15a0c8f881e3f399f7e18","https://git.kernel.org/stable/c/431b122933b197820d319eb3987a67d04346ce9e","https://git.kernel.org/stable/c/45c0de18ff2dc9af01236380404bbd6a46502c69","https://git.kernel.org/stable/c/469856f76f4802c5d7e3d20e343185188de1e2db","https://git.kernel.org/stable/c/60c068444c20bf9a3e22b65b5f6f3d9edc852931","https://git.kernel.org/stable/c/905f06a34f960676e7dc77bea00f2f8fe18177ad","https://git.kernel.org/stable/c/e66e38d07b31e177ca430758ed97fbc79f27d966"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-47940
|
High |
fixed |
|
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.18 before 5.18.18. fs/ksmbd/smb2pdu.c lacks length validation in the non-padding case in smb2_write. |
["http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.18","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=158a66b245739e15858de42c0ba60fcf3de9b8e6","https://github.com/torvalds/linux/commit/158a66b245739e15858de42c0ba60fcf3de9b8e6","http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.18","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=158a66b245739e15858de42c0ba60fcf3de9b8e6","https://github.com/torvalds/linux/commit/158a66b245739e15858de42c0ba60fcf3de9b8e6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4147
|
High |
fixed |
- 5.10.190
- 5.15.124
- 6.1.43
- 6.4.8
|
A use-after-free flaw was found in the Linux kernel’s Netfilter functionality when adding a rule with NFTA_RULE_CHAIN_ID. This flaw allows a local user to crash or escalate their privileges on the system. |
["https://access.redhat.com/errata/RHSA-2023:5069","https://access.redhat.com/errata/RHSA-2023:5091","https://access.redhat.com/errata/RHSA-2023:5093","https://access.redhat.com/errata/RHSA-2023:7382","https://access.redhat.com/errata/RHSA-2023:7389","https://access.redhat.com/errata/RHSA-2023:7411","https://access.redhat.com/security/cve/CVE-2023-4147","https://bugzilla.redhat.com/show_bug.cgi?id=2225239","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0ebc1064e4874d5987722a2ddbc18f94aa53b211","https://www.spinics.net/lists/stable/msg671573.html","https://access.redhat.com/errata/RHSA-2023:5069","https://access.redhat.com/errata/RHSA-2023:5091","https://access.redhat.com/errata/RHSA-2023:5093","https://access.redhat.com/errata/RHSA-2023:7382","https://access.redhat.com/errata/RHSA-2023:7389","https://access.redhat.com/errata/RHSA-2023:7411","https://access.redhat.com/security/cve/CVE-2023-4147","https://bugzilla.redhat.com/show_bug.cgi?id=2225239","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0ebc1064e4874d5987722a2ddbc18f94aa53b211","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20231020-0006/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492","https://www.spinics.net/lists/stable/msg671573.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52766
|
High |
fixed |
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
i3c: mipi-i3c-hci: Fix out of bounds access in hci_dma_irq_handler
Do not loop over ring headers in hci_dma_irq_handler() that are not
allocated and enabled in hci_dma_init(). Otherwise out of bounds access
will occur from rings->headers[i] access when i >= number of allocated
ring headers. |
["https://git.kernel.org/stable/c/45a832f989e520095429589d5b01b0c65da9b574","https://git.kernel.org/stable/c/4c86cb2321bd9c72d3b945ce7f747961beda8e65","https://git.kernel.org/stable/c/7c2b91b30d74d7c407118ad72502d4ca28af1af6","https://git.kernel.org/stable/c/8be39f66915b40d26ea2c18ba84b5c3d5da6809b","https://git.kernel.org/stable/c/d23ad76f240c0f597b7a9eb79905d246f27d40df","https://git.kernel.org/stable/c/45a832f989e520095429589d5b01b0c65da9b574","https://git.kernel.org/stable/c/4c86cb2321bd9c72d3b945ce7f747961beda8e65","https://git.kernel.org/stable/c/7c2b91b30d74d7c407118ad72502d4ca28af1af6","https://git.kernel.org/stable/c/8be39f66915b40d26ea2c18ba84b5c3d5da6809b","https://git.kernel.org/stable/c/d23ad76f240c0f597b7a9eb79905d246f27d40df"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36931
|
High |
fixed |
- 5.15.159
- 6.1.91
- 6.6.31
- 6.8.10
|
In the Linux kernel, the following vulnerability has been resolved:
s390/cio: Ensure the copied buf is NUL terminated
Currently, we allocate a lbuf-sized kernel buffer and copy lbuf from
userspace to that buffer. Later, we use scanf on this buffer but we don't
ensure that the string is terminated inside the buffer, this can lead to
OOB read when using scanf. Fix this issue by using memdup_user_nul instead. |
["https://git.kernel.org/stable/c/06759ebaf75c19c87b2453a5e130e9e61e9b5d65","https://git.kernel.org/stable/c/10452edd175fcc4fd0f5ac782ed2a002e3e5d65c","https://git.kernel.org/stable/c/84b38f48836662c4bfae646c014f4e981e16a2b2","https://git.kernel.org/stable/c/c9d48ce163305595ae20aee27774192476d5e6a5","https://git.kernel.org/stable/c/da7c622cddd4fe36be69ca61e8c42e43cde94784","https://git.kernel.org/stable/c/06759ebaf75c19c87b2453a5e130e9e61e9b5d65","https://git.kernel.org/stable/c/10452edd175fcc4fd0f5ac782ed2a002e3e5d65c","https://git.kernel.org/stable/c/84b38f48836662c4bfae646c014f4e981e16a2b2","https://git.kernel.org/stable/c/c9d48ce163305595ae20aee27774192476d5e6a5","https://git.kernel.org/stable/c/da7c622cddd4fe36be69ca61e8c42e43cde94784"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-25265
|
High |
|
N/A
|
In the Linux kernel through 5.16.10, certain binary files may have the exec-all attribute if they were built in approximately 2003 (e.g., with GCC 3.2.2 and Linux kernel 2.4.20). This can cause execution of bytes located in supposedly non-executable regions of a file. |
["https://github.com/torvalds/linux/blob/1c33bb0507508af24fd754dd7123bd8e997fab2f/arch/x86/include/asm/elf.h#L281-L294","https://github.com/x0reaxeax/exec-prot-bypass","https://security.netapp.com/advisory/ntap-20220318-0005/","https://github.com/torvalds/linux/blob/1c33bb0507508af24fd754dd7123bd8e997fab2f/arch/x86/include/asm/elf.h#L281-L294","https://github.com/x0reaxeax/exec-prot-bypass","https://security.netapp.com/advisory/ntap-20220318-0005/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-2078
|
Medium |
fixed |
|
A vulnerability was found in the Linux kernel's nft_set_desc_concat_parse() function .This flaw allows an attacker to trigger a buffer overflow via nft_set_desc_concat_parse() , causing a denial of service and possibly to run code. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2096178","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/net/netfilter/nf_tables_api.c?id=fecf31ee395b0295f2d7260aa29946b7605f7c85","https://www.debian.org/security/2022/dsa-5161","https://bugzilla.redhat.com/show_bug.cgi?id=2096178","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/net/netfilter/nf_tables_api.c?id=fecf31ee395b0295f2d7260aa29946b7605f7c85","https://www.debian.org/security/2022/dsa-5161"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42225
|
High |
fixed |
- 5.15.163
- 6.1.98
- 6.6.39
- 6.9.9
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: replace skb_put with skb_put_zero
Avoid potentially reusing uninitialized data |
["https://git.kernel.org/stable/c/22ea2a7f0b64d323625950414a4496520fb33657","https://git.kernel.org/stable/c/64f86337ccfe77fe3be5a9356b0dabde23fbb074","https://git.kernel.org/stable/c/7f819a2f4fbc510e088b49c79addcf1734503578","https://git.kernel.org/stable/c/dc7f14d00d0c4c21898f3504607f4a31079065a2","https://git.kernel.org/stable/c/ff6b26be13032c5fbd6b6a0b24358f8eaac4f3af","https://git.kernel.org/stable/c/22ea2a7f0b64d323625950414a4496520fb33657","https://git.kernel.org/stable/c/64f86337ccfe77fe3be5a9356b0dabde23fbb074","https://git.kernel.org/stable/c/7f819a2f4fbc510e088b49c79addcf1734503578","https://git.kernel.org/stable/c/dc7f14d00d0c4c21898f3504607f4a31079065a2","https://git.kernel.org/stable/c/ff6b26be13032c5fbd6b6a0b24358f8eaac4f3af"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-5717
|
High |
fixed |
- 3.3
- 3.17
- 4.14.328
- 4.19.297
- 5.4.259
- 5.10.199
- 5.15.137
- 6.1.60
- 6.5.9
|
A heap out-of-bounds write vulnerability in the Linux kernel's Linux Kernel Performance Events (perf) component can be exploited to achieve local privilege escalation.
If perf_read_group() is called while an event's sibling_list is smaller than its child's sibling_list, it can increment or write to memory locations outside of the allocated buffer.
We recommend upgrading past commit 32671e3799ca2e4590773fd0e63aaa4229e50c06. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel/events?id=32671e3799ca2e4590773fd0e63aaa4229e50c06","https://kernel.dance/32671e3799ca2e4590773fd0e63aaa4229e50c06","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel/events?id=32671e3799ca2e4590773fd0e63aaa4229e50c06","https://kernel.dance/32671e3799ca2e4590773fd0e63aaa4229e50c06","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35878
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
of: module: prevent NULL pointer dereference in vsnprintf()
In of_modalias(), we can get passed the str and len parameters which would
cause a kernel oops in vsnprintf() since it only allows passing a NULL ptr
when the length is also 0. Also, we need to filter out the negative values
of the len parameter as these will result in a really huge buffer since
snprintf() takes size_t parameter while ours is ssize_t...
Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool. |
["https://git.kernel.org/stable/c/544561dc56f7e69a053c25e11e6170f48bb97898","https://git.kernel.org/stable/c/a1aa5390cc912934fee76ce80af5f940452fa987","https://git.kernel.org/stable/c/e4a449368a2ce6d57a775d0ead27fc07f5a86e5b","https://git.kernel.org/stable/c/544561dc56f7e69a053c25e11e6170f48bb97898","https://git.kernel.org/stable/c/a1aa5390cc912934fee76ce80af5f940452fa987","https://git.kernel.org/stable/c/e4a449368a2ce6d57a775d0ead27fc07f5a86e5b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52755
|
High |
fixed |
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix slab out of bounds write in smb_inherit_dacl()
slab out-of-bounds write is caused by that offsets is bigger than pntsd
allocation size. This patch add the check to validate 3 offsets using
allocation size. |
["https://git.kernel.org/stable/c/09d9d8b40a3338193619c14ed4dc040f4f119e70","https://git.kernel.org/stable/c/712e01f32e577e7e48ab0adb5fe550646a3d93cb","https://git.kernel.org/stable/c/8387c94d73ec66eb597c7a23a8d9eadf64bfbafa","https://git.kernel.org/stable/c/aaf0a07d60887d6c36fc46a24de0083744f07819","https://git.kernel.org/stable/c/eebff19acaa35820cb09ce2ccb3d21bee2156ffb","https://git.kernel.org/stable/c/09d9d8b40a3338193619c14ed4dc040f4f119e70","https://git.kernel.org/stable/c/712e01f32e577e7e48ab0adb5fe550646a3d93cb","https://git.kernel.org/stable/c/8387c94d73ec66eb597c7a23a8d9eadf64bfbafa","https://git.kernel.org/stable/c/aaf0a07d60887d6c36fc46a24de0083744f07819","https://git.kernel.org/stable/c/eebff19acaa35820cb09ce2ccb3d21bee2156ffb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3640
|
High |
|
N/A
|
A possible unauthorized memory access flaw was found in the Linux kernel's cpu_entry_area mapping of X86 CPU data to memory, where a user may guess the location of exception stacks or other important data. Based on the previous CVE-2023-0597, the 'Randomize per-cpu entry area' feature was implemented in /arch/x86/mm/cpu_entry_area.c, which works through the init_cea_offsets() function when KASLR is enabled. However, despite this feature, there is still a risk of per-cpu entry area leaks. This issue could allow a local user to gain access to some important data with memory in an expected location and potentially escalate their privileges on the system. |
["https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/security/cve/CVE-2023-3640","https://bugzilla.redhat.com/show_bug.cgi?id=2217523","https://access.redhat.com/security/cve/CVE-2023-3640","https://bugzilla.redhat.com/show_bug.cgi?id=2217523"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39277
|
High |
fixed |
- 5.15.161
- 6.1.93
- 6.6.33
- 6.9.4
|
In the Linux kernel, the following vulnerability has been resolved:
dma-mapping: benchmark: handle NUMA_NO_NODE correctly
cpumask_of_node() can be called for NUMA_NO_NODE inside do_map_benchmark()
resulting in the following sanitizer report:
UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28
index -1 is out of range for type 'cpumask [64][1]'
CPU: 1 PID: 990 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #29
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Call Trace:
<TASK>
dump_stack_lvl (lib/dump_stack.c:117)
ubsan_epilogue (lib/ubsan.c:232)
__ubsan_handle_out_of_bounds (lib/ubsan.c:429)
cpumask_of_node (arch/x86/include/asm/topology.h:72) [inline]
do_map_benchmark (kernel/dma/map_benchmark.c:104)
map_benchmark_ioctl (kernel/dma/map_benchmark.c:246)
full_proxy_unlocked_ioctl (fs/debugfs/file.c:333)
__x64_sys_ioctl (fs/ioctl.c:890)
do_syscall_64 (arch/x86/entry/common.c:83)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
Use cpumask_of_node() in place when binding a kernel thread to a cpuset
of a particular node.
Note that the provided node id is checked inside map_benchmark_ioctl().
It's just a NUMA_NO_NODE case which is not handled properly later.
Found by Linux Verification Center (linuxtesting.org). |
["https://git.kernel.org/stable/c/50ee21bfc005e69f183d6b4b454e33f0c2571e1f","https://git.kernel.org/stable/c/5a91116b003175302f2e6ad94b76fb9b5a141a41","https://git.kernel.org/stable/c/8e1ba9df9a35e8dc64f657a64e523c79ba01e464","https://git.kernel.org/stable/c/b41b0018e8ca06e985e87220a618ec633988fd13","https://git.kernel.org/stable/c/e64746e74f717961250a155e14c156616fcd981f","https://git.kernel.org/stable/c/50ee21bfc005e69f183d6b4b454e33f0c2571e1f","https://git.kernel.org/stable/c/5a91116b003175302f2e6ad94b76fb9b5a141a41","https://git.kernel.org/stable/c/8e1ba9df9a35e8dc64f657a64e523c79ba01e464","https://git.kernel.org/stable/c/b41b0018e8ca06e985e87220a618ec633988fd13","https://git.kernel.org/stable/c/e64746e74f717961250a155e14c156616fcd981f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-32252
|
High |
fixed |
- 5.15.145
- 6.1.29
- 6.2.16
- 6.3.2
|
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the handling of SMB2_LOGOFF commands. The issue results from the lack of proper validation of a pointer prior to accessing it. An attacker can leverage this vulnerability to create a denial-of-service condition on the system. |
["https://access.redhat.com/security/cve/CVE-2023-32252","https://bugzilla.redhat.com/show_bug.cgi?id=2219815","https://security.netapp.com/advisory/ntap-20231124-0001/","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20590/","https://access.redhat.com/security/cve/CVE-2023-32252","https://bugzilla.redhat.com/show_bug.cgi?id=2219815","https://security.netapp.com/advisory/ntap-20231124-0001/","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20590/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-2663
|
Medium |
|
N/A
|
An issue was found in the Linux kernel in nf_conntrack_irc where the message handling can be confused and incorrectly matches the message. A firewall may be able to be bypassed when users are using unencrypted IRC with nf_conntrack_irc configured. |
["https://dgl.cx/2022/08/nat-again-irc-cve-2022-2663","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/netfilter-devel/20220826045658.100360-1-dgl%40dgl.cx/T/","https://www.debian.org/security/2022/dsa-5257","https://www.openwall.com/lists/oss-security/2022/08/30/1","https://www.youtube.com/watch?v=WIq-YgQuYCA","https://dgl.cx/2022/08/nat-again-irc-cve-2022-2663","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/netfilter-devel/20220826045658.100360-1-dgl%40dgl.cx/T/","https://www.debian.org/security/2022/dsa-5257","https://www.openwall.com/lists/oss-security/2022/08/30/1","https://www.youtube.com/watch?v=WIq-YgQuYCA"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-0461
|
High |
fixed |
- 4.14.303
- 4.19.270
- 5.4.229
- 5.10.163
- 5.15.88
- 6.0.19
- 6.1.5
|
There is a use-after-free vulnerability in the Linux Kernel which can be exploited to achieve local privilege escalation. To reach the vulnerability kernel configuration flag CONFIG_TLS or CONFIG_XFRM_ESPINTCP has to be configured, but the operation does not require any privilege.
There is a use-after-free bug of icsk_ulp_data of a struct inet_connection_sock.
When CONFIG_TLS is enabled, user can install a tls context (struct tls_context) on a connected tcp socket. The context is not cleared if this socket is disconnected and reused as a listener. If a new socket is created from the listener, the context is inherited and vulnerable.
The setsockopt TCP_ULP operation does not require any privilege.
We recommend upgrading past commit 2c02d41d71f90a5168391b6a5f2954112ba2307c |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2c02d41d71f90a5168391b6a5f2954112ba2307c","https://kernel.dance/#2c02d41d71f90a5168391b6a5f2954112ba2307c","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2c02d41d71f90a5168391b6a5f2954112ba2307c","https://kernel.dance/#2c02d41d71f90a5168391b6a5f2954112ba2307c","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230331-0006/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1011
|
High |
fixed |
|
A use-after-free flaw was found in the Linux kernel’s FUSE filesystem in the way a user triggers write(). This flaw allows a local user to gain unauthorized access to data from the FUSE filesystem, resulting in privilege escalation. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2064855","https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git/commit/?h=for-next","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://www.debian.org/security/2022/dsa-5173","https://www.oracle.com/security-alerts/cpujul2022.html","https://bugzilla.redhat.com/show_bug.cgi?id=2064855","https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git/commit/?h=for-next","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://www.debian.org/security/2022/dsa-5173","https://www.oracle.com/security-alerts/cpujul2022.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3526
|
High |
fixed |
|
A vulnerability classified as problematic was found in Linux Kernel. This vulnerability affects the function macvlan_handle_frame of the file drivers/net/macvlan.c of the component skb. The manipulation leads to memory leak. The attack can be initiated remotely. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211024. |
["https://git.kernel.org/pub/scm/linux/kernel/git/pabeni/net-next.git/commit/?id=e16b859872b87650bb55b12cca5a5fcdc49c1442","https://vuldb.com/?id.211024","https://git.kernel.org/pub/scm/linux/kernel/git/pabeni/net-next.git/commit/?id=e16b859872b87650bb55b12cca5a5fcdc49c1442","https://vuldb.com/?id.211024"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36013
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect()
Extend a critical section to prevent chan from early freeing.
Also make the l2cap_connect() return type void. Nothing is using the
returned value but it is ugly to return a potentially freed pointer.
Making it void will help with backports because earlier kernels did use
the return value. Now the compile will break for kernels where this
patch is not a complete fix.
Call stack summary:
[use]
l2cap_bredr_sig_cmd
l2cap_connect
┌ mutex_lock(&conn->chan_lock);
│ chan = pchan->ops->new_connection(pchan); <- alloc chan
│ __l2cap_chan_add(conn, chan);
│ l2cap_chan_hold(chan);
│ list_add(&chan->list, &conn->chan_l); ... (1)
└ mutex_unlock(&conn->chan_lock);
chan->conf_state ... (4) <- use after free
[free]
l2cap_conn_del
┌ mutex_lock(&conn->chan_lock);
│ foreach chan in conn->chan_l: ... (2)
│ l2cap_chan_put(chan);
│ l2cap_chan_destroy
│ kfree(chan) ... (3) <- chan freed
└ mutex_unlock(&conn->chan_lock);
==================================================================
BUG: KASAN: slab-use-after-free in instrument_atomic_read
include/linux/instrumented.h:68 [inline]
BUG: KASAN: slab-use-after-free in _test_bit
include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
BUG: KASAN: slab-use-after-free in l2cap_connect+0xa67/0x11a0
net/bluetooth/l2cap_core.c:4260
Read of size 8 at addr ffff88810bf040a0 by task kworker/u3:1/311 |
["https://git.kernel.org/stable/c/4d7b41c0e43995b0e992b9f8903109275744b658","https://git.kernel.org/stable/c/826af9d2f69567c646ff46d10393d47e30ad23c6","https://git.kernel.org/stable/c/cfe560c7050bfb37b0d2491bbe7cd8b59e77fdc5","http://www.openwall.com/lists/oss-security/2024/05/30/1","http://www.openwall.com/lists/oss-security/2024/05/30/2","https://git.kernel.org/stable/c/4d7b41c0e43995b0e992b9f8903109275744b658","https://git.kernel.org/stable/c/826af9d2f69567c646ff46d10393d47e30ad23c6","https://git.kernel.org/stable/c/cfe560c7050bfb37b0d2491bbe7cd8b59e77fdc5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1199
|
High |
|
N/A
|
A flaw was found in the Linux kernel. This flaw allows an attacker to crash the Linux kernel by simulating amateur radio from the user space, resulting in a null-ptr-deref vulnerability and a use-after-free vulnerability. |
["https://access.redhat.com/security/cve/CVE-2022-1199","https://bugzilla.redhat.com/show_bug.cgi?id=2070694","https://github.com/torvalds/linux/commit/4e0f718daf97d47cf7dec122da1be970f145c809","https://github.com/torvalds/linux/commit/71171ac8eb34ce7fe6b3267dce27c313ab3cb3ac","https://github.com/torvalds/linux/commit/7ec02f5ac8a5be5a3f20611731243dc5e1d9ba10","https://security.netapp.com/advisory/ntap-20221228-0006/","https://www.openwall.com/lists/oss-security/2022/04/02/5","https://access.redhat.com/security/cve/CVE-2022-1199","https://bugzilla.redhat.com/show_bug.cgi?id=2070694","https://github.com/torvalds/linux/commit/4e0f718daf97d47cf7dec122da1be970f145c809","https://github.com/torvalds/linux/commit/71171ac8eb34ce7fe6b3267dce27c313ab3cb3ac","https://github.com/torvalds/linux/commit/7ec02f5ac8a5be5a3f20611731243dc5e1d9ba10","https://security.netapp.com/advisory/ntap-20221228-0006/","https://www.openwall.com/lists/oss-security/2022/04/02/5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48657
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
arm64: topology: fix possible overflow in amu_fie_setup()
cpufreq_get_hw_max_freq() returns max frequency in kHz as *unsigned int*,
while freq_inv_set_max_ratio() gets passed this frequency in Hz as 'u64'.
Multiplying max frequency by 1000 can potentially result in overflow --
multiplying by 1000ULL instead should avoid that...
Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool. |
["https://git.kernel.org/stable/c/3c3edb82d67b2be9231174ac2af4af60d4af7549","https://git.kernel.org/stable/c/904f881b57360cf85de962d84d8614d94431f60e","https://git.kernel.org/stable/c/bb6d99e27cbe6b30e4e3bbd32927fd3b0bdec6eb","https://git.kernel.org/stable/c/d4955c0ad77dbc684fc716387070ac24801b8bca","https://git.kernel.org/stable/c/3c3edb82d67b2be9231174ac2af4af60d4af7549","https://git.kernel.org/stable/c/904f881b57360cf85de962d84d8614d94431f60e","https://git.kernel.org/stable/c/bb6d99e27cbe6b30e4e3bbd32927fd3b0bdec6eb","https://git.kernel.org/stable/c/d4955c0ad77dbc684fc716387070ac24801b8bca"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48686
|
High |
fixed |
- 5.4.213
- 5.10.143
- 5.15.68
- 5.19.9
|
In the Linux kernel, the following vulnerability has been resolved:
nvme-tcp: fix UAF when detecting digest errors
We should also bail from the io_work loop when we set rd_enabled to true,
so we don't attempt to read data from the socket when the TCP stream is
already out-of-sync or corrupted. |
["https://git.kernel.org/stable/c/13c80a6c112467bab5e44d090767930555fc17a5","https://git.kernel.org/stable/c/160f3549a907a50e51a8518678ba2dcf2541abea","https://git.kernel.org/stable/c/19816a0214684f70b49b25075ff8c402fdd611d3","https://git.kernel.org/stable/c/5914fa32ef1b7766fea933f9eed94ac5c00aa7ff","https://git.kernel.org/stable/c/c3eb461aa56e6fa94fb80442ba2586bd223a8886","https://git.kernel.org/stable/c/13c80a6c112467bab5e44d090767930555fc17a5","https://git.kernel.org/stable/c/160f3549a907a50e51a8518678ba2dcf2541abea","https://git.kernel.org/stable/c/19816a0214684f70b49b25075ff8c402fdd611d3","https://git.kernel.org/stable/c/5914fa32ef1b7766fea933f9eed94ac5c00aa7ff","https://git.kernel.org/stable/c/c3eb461aa56e6fa94fb80442ba2586bd223a8886"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26817
|
Medium |
fixed |
- 4.19.312
- 5.4.274
- 5.10.215
- 5.15.155
- 6.1.86
- 6.6.27
- 6.8.6
|
In the Linux kernel, the following vulnerability has been resolved:
amdkfd: use calloc instead of kzalloc to avoid integer overflow
This uses calloc instead of doing the multiplication which might
overflow. |
["https://git.kernel.org/stable/c/0c33d11153949310d76631d8f4a4736519eacd3a","https://git.kernel.org/stable/c/315eb3c2df7e4cb18e3eacfa18a53a46f2bf0ef7","https://git.kernel.org/stable/c/3b0daecfeac0103aba8b293df07a0cbaf8b43f29","https://git.kernel.org/stable/c/8b0564704255c6b3c6a7188e86939f754e1577c0","https://git.kernel.org/stable/c/cbac7de1d9901521e78cdc34e15451df3611f2ad","https://git.kernel.org/stable/c/e6721ea845fcb93a764a92bd40f1afc0d6c69751","https://git.kernel.org/stable/c/e6768c6737f4c02cba193a3339f0cc2907f0b86a","https://git.kernel.org/stable/c/fcbd99b3c73309107e3be71f20dff9414df64f91","https://git.kernel.org/stable/c/0c33d11153949310d76631d8f4a4736519eacd3a","https://git.kernel.org/stable/c/315eb3c2df7e4cb18e3eacfa18a53a46f2bf0ef7","https://git.kernel.org/stable/c/3b0daecfeac0103aba8b293df07a0cbaf8b43f29","https://git.kernel.org/stable/c/8b0564704255c6b3c6a7188e86939f754e1577c0","https://git.kernel.org/stable/c/cbac7de1d9901521e78cdc34e15451df3611f2ad","https://git.kernel.org/stable/c/e6721ea845fcb93a764a92bd40f1afc0d6c69751","https://git.kernel.org/stable/c/e6768c6737f4c02cba193a3339f0cc2907f0b86a","https://git.kernel.org/stable/c/fcbd99b3c73309107e3be71f20dff9414df64f91","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-32248
|
High |
fixed |
- 5.15.111
- 6.1.28
- 6.2.15
- 6.3.2
|
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the handling of SMB2_TREE_CONNECT and SMB2_QUERY_INFO commands. The issue results from the lack of proper validation of a pointer prior to accessing it. An attacker can leverage this vulnerability to create a denial-of-service condition on the system. |
["https://access.redhat.com/security/cve/CVE-2023-32248","https://bugzilla.redhat.com/show_bug.cgi?id=2219818","https://security.netapp.com/advisory/ntap-20230915-0006/","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20479/","https://access.redhat.com/security/cve/CVE-2023-32248","https://bugzilla.redhat.com/show_bug.cgi?id=2219818","https://security.netapp.com/advisory/ntap-20230915-0006/","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20479/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48999
|
High |
fixed |
- 5.4.226
- 5.10.158
- 5.15.82
- 6.0.12
|
In the Linux kernel, the following vulnerability has been resolved:
ipv4: Handle attempt to delete multipath route when fib_info contains an nh reference
Gwangun Jung reported a slab-out-of-bounds access in fib_nh_match:
fib_nh_match+0xf98/0x1130 linux-6.0-rc7/net/ipv4/fib_semantics.c:961
fib_table_delete+0x5f3/0xa40 linux-6.0-rc7/net/ipv4/fib_trie.c:1753
inet_rtm_delroute+0x2b3/0x380 linux-6.0-rc7/net/ipv4/fib_frontend.c:874
Separate nexthop objects are mutually exclusive with the legacy
multipath spec. Fix fib_nh_match to return if the config for the
to be deleted route contains a multipath spec while the fib_info
is using a nexthop object. |
["https://git.kernel.org/stable/c/0b5394229ebae09afc07aabccb5ffd705ffd250e","https://git.kernel.org/stable/c/25174d91e4a32a24204060d283bd5fa6d0ddf133","https://git.kernel.org/stable/c/61b91eb33a69c3be11b259c5ea484505cd79f883","https://git.kernel.org/stable/c/bb20a2ae241be846bc3c11ea4b3a3c69e41d51f2","https://git.kernel.org/stable/c/cc3cd130ecfb8b0ae52e235e487bae3f16a24a32"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-32258
|
High |
fixed |
- 5.15.145
- 6.1.29
- 6.2.16
- 6.3.2
|
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the processing of SMB2_LOGOFF and SMB2_CLOSE commands. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to execute code in the context of the kernel. |
["https://access.redhat.com/security/cve/CVE-2023-32258","https://bugzilla.redhat.com/show_bug.cgi?id=2219809","https://security.netapp.com/advisory/ntap-20230915-0011/","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20796/","https://access.redhat.com/security/cve/CVE-2023-32258","https://bugzilla.redhat.com/show_bug.cgi?id=2219809","https://security.netapp.com/advisory/ntap-20230915-0011/","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20796/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-58087
|
High |
fixed |
- 5.15.176
- 6.1.121
- 6.6.67
- 6.12.6
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix racy issue from session lookup and expire
Increment the session reference count within the lock for lookup to avoid
racy issue with session expire. |
["https://git.kernel.org/stable/c/2107ab40629aeabbec369cf34b8cf0f288c3eb1b","https://git.kernel.org/stable/c/37a0e2b362b3150317fb6e2139de67b1e29ae5ff","https://git.kernel.org/stable/c/450a844c045ff0895d41b05a1cbe8febd1acfcfd","https://git.kernel.org/stable/c/a39e31e22a535d47b14656a7d6a893c7f6cf758c","https://git.kernel.org/stable/c/b95629435b84b9ecc0c765995204a4d8a913ed52","https://www.zerodayinitiative.com/advisories/ZDI-25-100/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-1999-0524
|
Low |
|
N/A
|
ICMP information such as (1) netmask and (2) timestamp is allowed from arbitrary hosts. |
["http://descriptions.securescout.com/tc/11010","http://descriptions.securescout.com/tc/11011","http://kb.juniper.net/InfoCenter/index?page=content\u0026id=JSA10705","http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC\u0026externalId=1434","http://www.osvdb.org/95","https://exchange.xforce.ibmcloud.com/vulnerabilities/306","https://exchange.xforce.ibmcloud.com/vulnerabilities/322","https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10053","http://descriptions.securescout.com/tc/11010","http://descriptions.securescout.com/tc/11011","http://kb.juniper.net/InfoCenter/index?page=content\u0026id=JSA10705","http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC\u0026externalId=1434","http://www.osvdb.org/95","https://exchange.xforce.ibmcloud.com/vulnerabilities/306","https://exchange.xforce.ibmcloud.com/vulnerabilities/322","https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10053","https://support.f5.com/csp/article/K15277"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39490
|
Medium |
fixed |
- 5.15.161
- 6.1.93
- 6.6.33
- 6.9.4
|
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: fix missing sk_buff release in seg6_input_core
The seg6_input() function is responsible for adding the SRH into a
packet, delegating the operation to the seg6_input_core(). This function
uses the skb_cow_head() to ensure that there is sufficient headroom in
the sk_buff for accommodating the link-layer header.
In the event that the skb_cow_header() function fails, the
seg6_input_core() catches the error but it does not release the sk_buff,
which will result in a memory leak.
This issue was introduced in commit af3b5158b89d ("ipv6: sr: fix BUG due
to headroom too small after SRH push") and persists even after commit
7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6 data plane"),
where the entire seg6_input() code was refactored to deal with netfilter
hooks.
The proposed patch addresses the identified memory leak by requiring the
seg6_input_core() function to release the sk_buff in the event that
skb_cow_head() fails. |
["https://git.kernel.org/stable/c/5447f9708d9e4c17a647b16a9cb29e9e02820bd9","https://git.kernel.org/stable/c/8f1fc3b86eaea70be6abcae2e9aa7e7b99453864","https://git.kernel.org/stable/c/e8688218e38111ace457509d8f0cad75f79c1a7a","https://git.kernel.org/stable/c/f4df8c7670a73752201cbde215254598efdf6ce8","https://git.kernel.org/stable/c/f5fec1588642e415a3d72e02140160661b303940","https://git.kernel.org/stable/c/5447f9708d9e4c17a647b16a9cb29e9e02820bd9","https://git.kernel.org/stable/c/8f1fc3b86eaea70be6abcae2e9aa7e7b99453864","https://git.kernel.org/stable/c/e8688218e38111ace457509d8f0cad75f79c1a7a","https://git.kernel.org/stable/c/f4df8c7670a73752201cbde215254598efdf6ce8","https://git.kernel.org/stable/c/f5fec1588642e415a3d72e02140160661b303940"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52442
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate session id and tree id in compound request
`smb2_get_msg()` in smb2_get_ksmbd_tcon() and smb2_check_user_session()
will always return the first request smb2 header in a compound request.
if `SMB2_TREE_CONNECT_HE` is the first command in compound request, will
return 0, i.e. The tree id check is skipped.
This patch use ksmbd_req_buf_next() to get current command in compound. |
["https://git.kernel.org/stable/c/017d85c94f02090a87f4a473dbe0d6ee0da72693","https://git.kernel.org/stable/c/3df0411e132ee74a87aa13142dfd2b190275332e","https://git.kernel.org/stable/c/4c2b350b2e269e3fd17bbfa42de1b42775b777ac","https://git.kernel.org/stable/c/becb5191d1d5fdfca0198a2e37457bbbf4fe266f","https://git.kernel.org/stable/c/017d85c94f02090a87f4a473dbe0d6ee0da72693","https://git.kernel.org/stable/c/3df0411e132ee74a87aa13142dfd2b190275332e","https://git.kernel.org/stable/c/4c2b350b2e269e3fd17bbfa42de1b42775b777ac","https://git.kernel.org/stable/c/becb5191d1d5fdfca0198a2e37457bbbf4fe266f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52738
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini
Currently amdgpu calls drm_sched_fini() from the fence driver sw fini
routine - such function is expected to be called only after the
respective init function - drm_sched_init() - was executed successfully.
Happens that we faced a driver probe failure in the Steam Deck
recently, and the function drm_sched_fini() was called even without
its counter-part had been previously called, causing the following oops:
amdgpu: probe of 0000:04:00.0 failed with error -110
BUG: kernel NULL pointer dereference, address: 0000000000000090
PGD 0 P4D 0
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 609 Comm: systemd-udevd Not tainted 6.2.0-rc3-gpiccoli #338
Hardware name: Valve Jupiter/Jupiter, BIOS F7A0113 11/04/2022
RIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched]
[...]
Call Trace:
<TASK>
amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu]
amdgpu_device_fini_sw+0x2b/0x3b0 [amdgpu]
amdgpu_driver_release_kms+0x16/0x30 [amdgpu]
devm_drm_dev_init_release+0x49/0x70
[...]
To prevent that, check if the drm_sched was properly initialized for a
given ring before calling its fini counter-part.
Notice ideally we'd use sched.ready for that; such field is set as the latest
thing on drm_sched_init(). But amdgpu seems to "override" the meaning of such
field - in the above oops for example, it was a GFX ring causing the crash, and
the sched.ready field was set to true in the ring init routine, regardless of
the state of the DRM scheduler. Hence, we ended-up using sched.ops as per
Christian's suggestion [0], and also removed the no_scheduler check [1].
[0] https://lore.kernel.org/amd-gfx/984ee981-2906-0eaf-ccec-9f80975cb136@amd.com/
[1] https://lore.kernel.org/amd-gfx/cd0e2994-f85f-d837-609f-7056d5fb7231@amd.com/ |
["https://git.kernel.org/stable/c/2bcbbef9cace772f5b7128b11401c515982de34b","https://git.kernel.org/stable/c/2e557c8ca2c585bdef591b8503ba83b85f5d0afd","https://git.kernel.org/stable/c/5ad7bbf3dba5c4a684338df1f285080f2588b535","https://git.kernel.org/stable/c/2bcbbef9cace772f5b7128b11401c515982de34b","https://git.kernel.org/stable/c/2e557c8ca2c585bdef591b8503ba83b85f5d0afd","https://git.kernel.org/stable/c/5ad7bbf3dba5c4a684338df1f285080f2588b535"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-47942
|
High |
fixed |
|
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. There is a heap-based buffer overflow in set_ntacl_dacl, related to use of SMB2_QUERY_INFO_HE after a malformed SMB2_SET_INFO_HE command. |
["http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8f0541186e9ad1b62accc9519cc2b7a7240272a7","https://github.com/torvalds/linux/commit/8f0541186e9ad1b62accc9519cc2b7a7240272a7","https://www.zerodayinitiative.com/advisories/ZDI-22-1688/","http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8f0541186e9ad1b62accc9519cc2b7a7240272a7","https://github.com/torvalds/linux/commit/8f0541186e9ad1b62accc9519cc2b7a7240272a7","https://www.zerodayinitiative.com/advisories/ZDI-22-1688/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1193
|
Medium |
fixed |
|
A use-after-free flaw was found in setup_async_work in the KSMBD implementation of the in-kernel samba server and CIFS in the Linux kernel. This issue could allow an attacker to crash the system by accessing freed work. |
["https://access.redhat.com/security/cve/CVE-2023-1193","https://bugzilla.redhat.com/show_bug.cgi?id=2154177","https://lkml.kernel.org/linux-cifs/20230401084951.6085-2-linkinjeon@kernel.org/T/","https://access.redhat.com/security/cve/CVE-2023-1193","https://bugzilla.redhat.com/show_bug.cgi?id=2154177","https://lkml.kernel.org/linux-cifs/20230401084951.6085-2-linkinjeon@kernel.org/T/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-20194
|
High |
|
N/A
|
There is a vulnerability in the linux kernel versions higher than 5.2 (if kernel compiled with config params CONFIG_BPF_SYSCALL=y , CONFIG_BPF=y , CONFIG_CGROUPS=y , CONFIG_CGROUP_BPF=y , CONFIG_HARDENED_USERCOPY not set, and BPF hook to getsockopt is registered). As result of BPF execution, the local user can trigger bug in __cgroup_bpf_run_filter_getsockopt() function that can lead to heap overflow (because of non-hardened usercopy). The impact of attack could be deny of service or possibly privileges escalation. |
["https://bugzilla.redhat.com/show_bug.cgi?id=1912683","https://security.netapp.com/advisory/ntap-20210326-0003/","https://bugzilla.redhat.com/show_bug.cgi?id=1912683","https://security.netapp.com/advisory/ntap-20210326-0003/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1729
|
High |
fixed |
- 3.3
- 3.17
- 3.19
- 4.9.316
- 4.14.281
- 4.19.245
- 5.4.196
- 5.10.118
- 5.15.42
- 5.17.10
|
A race condition was found the Linux kernel in perf_event_open() which can be exploited by an unprivileged user to gain root privileges. The bug allows to build several exploit primitives such as kernel address information leak, arbitrary execution, etc. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3ac6487e584a1eb54071dbe1212e05b884136704","https://security.netapp.com/advisory/ntap-20230214-0006/","https://www.openwall.com/lists/oss-security/2022/05/20/2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3ac6487e584a1eb54071dbe1212e05b884136704","https://security.netapp.com/advisory/ntap-20230214-0006/","https://www.openwall.com/lists/oss-security/2022/05/20/2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38556
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Add a timeout to acquire the command queue semaphore
Prevent forced completion handling on an entry that has not yet been
assigned an index, causing an out of bounds access on idx = -22.
Instead of waiting indefinitely for the sem, blocking flow now waits for
index to be allocated or a sem acquisition timeout before beginning the
timer for FW completion.
Kernel log example:
mlx5_core 0000:06:00.0: wait_func_handle_exec_timeout:1128:(pid 185911): cmd[-22]: CREATE_UCTX(0xa04) No done completion |
["https://git.kernel.org/stable/c/2d0962d05c93de391ce85f6e764df895f47c8918","https://git.kernel.org/stable/c/485d65e1357123a697c591a5aeb773994b247ad7","https://git.kernel.org/stable/c/4baae687a20ef2b82fde12de3c04461e6f2521d6","https://git.kernel.org/stable/c/94024332a129c6e4275569d85c0c1bfb2ae2d71b","https://git.kernel.org/stable/c/f9caccdd42e999b74303c9b0643300073ed5d319","https://git.kernel.org/stable/c/2d0962d05c93de391ce85f6e764df895f47c8918","https://git.kernel.org/stable/c/485d65e1357123a697c591a5aeb773994b247ad7","https://git.kernel.org/stable/c/4baae687a20ef2b82fde12de3c04461e6f2521d6","https://git.kernel.org/stable/c/94024332a129c6e4275569d85c0c1bfb2ae2d71b","https://git.kernel.org/stable/c/f9caccdd42e999b74303c9b0643300073ed5d319"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-2163
|
High |
fixed |
- 5.4.242
- 5.10.179
- 5.15.109
- 6.1.26
- 6.2.13
|
Incorrect verifier pruning in BPF in Linux Kernel >=5.4 leads to unsafe
code paths being incorrectly marked as safe, resulting in arbitrary read/write in
kernel memory, lateral privilege escalation, and container escape. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71b547f561247897a0a14f3082730156c0533fed","https://bughunters.google.com/blog/6303226026131456/a-deep-dive-into-cve-2023-2163-how-we-found-and-fixed-an-ebpf-linux-kernel-vulnerability","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71b547f561247897a0a14f3082730156c0533fed"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-25375
|
Medium |
fixed |
|
An issue was discovered in drivers/usb/gadget/function/rndis.c in the Linux kernel before 5.16.10. The RNDIS USB gadget lacks validation of the size of the RNDIS_MSG_SET command. Attackers can obtain sensitive information from kernel memory. |
["http://www.openwall.com/lists/oss-security/2022/02/21/1","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.10","https://github.com/szymonh/rndis-co","https://github.com/torvalds/linux/commit/38ea1eac7d88072bbffb630e2b3db83ca649b826","https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://www.debian.org/security/2022/dsa-5092","https://www.debian.org/security/2022/dsa-5096","http://www.openwall.com/lists/oss-security/2022/02/21/1","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.10","https://github.com/szymonh/rndis-co","https://github.com/torvalds/linux/commit/38ea1eac7d88072bbffb630e2b3db83ca649b826","https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://www.debian.org/security/2022/dsa-5092","https://www.debian.org/security/2022/dsa-5096"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-32257
|
High |
fixed |
- 5.15.145
- 6.1.29
- 6.2.16
- 6.3.2
|
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the processing of SMB2_SESSION_SETUP and SMB2_LOGOFF commands. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to execute code in the context of the kernel. |
["https://access.redhat.com/security/cve/CVE-2023-32257","https://bugzilla.redhat.com/show_bug.cgi?id=2219806","https://security.netapp.com/advisory/ntap-20230915-0011/","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20596/","https://access.redhat.com/security/cve/CVE-2023-32257","https://bugzilla.redhat.com/show_bug.cgi?id=2219806","https://security.netapp.com/advisory/ntap-20230915-0011/","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20596/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-38427
|
Critical |
fixed |
|
An issue was discovered in the Linux kernel before 6.3.8. fs/smb/server/smb2pdu.c in ksmbd has an integer underflow and out-of-bounds read in deassemble_neg_contexts. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.8","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=f1a411873c85b642f13b01f21b534c2bab81fc1b","https://security.netapp.com/advisory/ntap-20230824-0011/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.8","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=f1a411873c85b642f13b01f21b534c2bab81fc1b","https://security.netapp.com/advisory/ntap-20230824-0011/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44986
|
High |
fixed |
- 5.15.166
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix possible UAF in ip6_finish_output2()
If skb_expand_head() returns NULL, skb has been freed
and associated dst/idev could also have been freed.
We need to hold rcu_read_lock() to make sure the dst and
associated idev are alive. |
["https://git.kernel.org/stable/c/3574d28caf9a09756ae87ad1ea096c6f47b6101e","https://git.kernel.org/stable/c/56efc253196751ece1fc535a5b582be127b0578a","https://git.kernel.org/stable/c/6ab6bf731354a6fdbaa617d1ec194960db61cf3b","https://git.kernel.org/stable/c/da273b377ae0d9bd255281ed3c2adb228321687b","https://git.kernel.org/stable/c/e891b36de161fcd96f12ff83667473e5067b9037"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-32250
|
High |
fixed |
- 5.15.145
- 6.1.29
- 6.2.16
- 6.3.2
|
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the processing of SMB2_SESSION_SETUP commands. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to execute code in the context of the kernel. |
["https://access.redhat.com/security/cve/CVE-2023-32250","https://bugzilla.redhat.com/show_bug.cgi?id=2208849","https://security.netapp.com/advisory/ntap-20230824-0004/","https://www.zerodayinitiative.com/advisories/ZDI-23-698/","https://access.redhat.com/security/cve/CVE-2023-32250","https://bugzilla.redhat.com/show_bug.cgi?id=2208849","https://security.netapp.com/advisory/ntap-20230824-0004/","https://www.zerodayinitiative.com/advisories/ZDI-23-698/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26739
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_mirred: don't override retval if we already lost the skb
If we're redirecting the skb, and haven't called tcf_mirred_forward(),
yet, we need to tell the core to drop the skb by setting the retcode
to SHOT. If we have called tcf_mirred_forward(), however, the skb
is out of our hands and returning SHOT will lead to UaF.
Move the retval override to the error path which actually need it. |
["https://git.kernel.org/stable/c/166c2c8a6a4dc2e4ceba9e10cfe81c3e469e3210","https://git.kernel.org/stable/c/28cdbbd38a4413b8eff53399b3f872fd4e80db9d","https://git.kernel.org/stable/c/9d3ef89b6a5e9f2e940de2cef3d543be0be8dec5","https://git.kernel.org/stable/c/e873e8f7d03a2ee5b77fb1a305c782fed98e2754","https://git.kernel.org/stable/c/f4e294bbdca8ac8757db436fc82214f3882fc7e7","https://git.kernel.org/stable/c/166c2c8a6a4dc2e4ceba9e10cfe81c3e469e3210","https://git.kernel.org/stable/c/28cdbbd38a4413b8eff53399b3f872fd4e80db9d","https://git.kernel.org/stable/c/f4e294bbdca8ac8757db436fc82214f3882fc7e7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46774
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
powerpc/rtas: Prevent Spectre v1 gadget construction in sys_rtas()
Smatch warns:
arch/powerpc/kernel/rtas.c:1932 __do_sys_rtas() warn: potential
spectre issue 'args.args' [r] (local cap)
The 'nargs' and 'nret' locals come directly from a user-supplied
buffer and are used as indexes into a small stack-based array and as
inputs to copy_to_user() after they are subject to bounds checks.
Use array_index_nospec() after the bounds checks to clamp these values
for speculative execution. |
["https://git.kernel.org/stable/c/0974d03eb479384466d828d65637814bee6b26d7","https://git.kernel.org/stable/c/1f1feff02e9da0dd0cdb195c428c42b5f9b6c771","https://git.kernel.org/stable/c/68d8156480940b79227d58865ec5d2947b9384a8","https://git.kernel.org/stable/c/a262c2dc833f2fe1bd5c53a4d899e7077d3b1da9","https://git.kernel.org/stable/c/b137af795399d8b657bad1646c18561530f35ed1","https://git.kernel.org/stable/c/d2834ff1d9641a8695a09ea79cd901c7b6d4d05f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52667
|
High |
fixed |
- 5.15.149
- 6.1.76
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: fix a potential double-free in fs_any_create_groups
When kcalloc() for ft->g succeeds but kvzalloc() for in fails,
fs_any_create_groups() will free ft->g. However, its caller
fs_any_create_table() will free ft->g again through calling
mlx5e_destroy_flow_table(), which will lead to a double-free.
Fix this by setting ft->g to NULL in fs_any_create_groups(). |
["https://git.kernel.org/stable/c/2897c981ee63e1be5e530b1042484626a10b26d8","https://git.kernel.org/stable/c/65a4ade8a6d205979292e88beeb6a626ddbd4779","https://git.kernel.org/stable/c/72a729868592752b5a294d27453da264106983b1","https://git.kernel.org/stable/c/aef855df7e1bbd5aa4484851561211500b22707e","https://git.kernel.org/stable/c/b2fa86b2aceb4bc9ada51cea90f61546d7512cbe","https://git.kernel.org/stable/c/2897c981ee63e1be5e530b1042484626a10b26d8","https://git.kernel.org/stable/c/65a4ade8a6d205979292e88beeb6a626ddbd4779","https://git.kernel.org/stable/c/72a729868592752b5a294d27453da264106983b1","https://git.kernel.org/stable/c/aef855df7e1bbd5aa4484851561211500b22707e","https://git.kernel.org/stable/c/b2fa86b2aceb4bc9ada51cea90f61546d7512cbe"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-32247
|
High |
fixed |
- 5.15.145
- 6.1.29
- 6.2.16
- 6.3.2
|
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the handling of SMB2_SESSION_SETUP commands. The issue results from the lack of control of resource consumption. An attacker can leverage this vulnerability to create a denial-of-service condition on the system. |
["https://access.redhat.com/security/cve/CVE-2023-32247","https://bugzilla.redhat.com/show_bug.cgi?id=2219803","https://security.netapp.com/advisory/ntap-20230915-0011/","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20478/","https://access.redhat.com/security/cve/CVE-2023-32247","https://bugzilla.redhat.com/show_bug.cgi?id=2219803","https://security.netapp.com/advisory/ntap-20230915-0011/","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20478/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-29582
|
High |
fixed |
|
In the Linux kernel before 5.17.3, fs/io_uring.c has a use-after-free due to a race condition in io_uring timeouts. This can be triggered by a local user who has no access to any user namespace; however, the race condition perhaps can only be exploited infrequently. |
["http://www.openwall.com/lists/oss-security/2022/04/22/4","http://www.openwall.com/lists/oss-security/2022/08/08/3","http://www.openwall.com/lists/oss-security/2024/04/24/3","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.3","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e677edbcabee849bfdd43f1602bccbecf736a646","https://github.com/Ruia-ruia/CVE-2022-29582-Exploit","https://github.com/torvalds/linux/commit/e677edbcabee849bfdd43f1602bccbecf736a646","https://ruia-ruia.github.io/2022/08/05/CVE-2022-29582-io-uring/","https://www.debian.org/security/2022/dsa-5127","https://www.openwall.com/lists/oss-security/2022/04/22/3","http://www.openwall.com/lists/oss-security/2022/04/22/4","http://www.openwall.com/lists/oss-security/2022/08/08/3","http://www.openwall.com/lists/oss-security/2024/04/24/3","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.3","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e677edbcabee849bfdd43f1602bccbecf736a646","https://github.com/Ruia-ruia/CVE-2022-29582-Exploit","https://github.com/torvalds/linux/commit/e677edbcabee849bfdd43f1602bccbecf736a646","https://ruia-ruia.github.io/2022/08/05/CVE-2022-29582-io-uring/","https://www.debian.org/security/2022/dsa-5127","https://www.openwall.com/lists/oss-security/2022/04/22/3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2018-10902
|
High |
|
N/A
|
It was found that the raw midi kernel driver does not protect against concurrent access which leads to a double realloc (double free) in snd_rawmidi_input_params() and snd_rawmidi_output_status() which are part of snd_rawmidi_ioctl() handler in rawmidi.c file. A malicious local attacker could possibly use this for privilege escalation. |
["http://www.securityfocus.com/bid/105119","http://www.securitytracker.com/id/1041529","https://access.redhat.com/errata/RHSA-2018:3083","https://access.redhat.com/errata/RHSA-2018:3096","https://access.redhat.com/errata/RHSA-2019:0415","https://access.redhat.com/errata/RHSA-2019:0641","https://access.redhat.com/errata/RHSA-2019:3217","https://access.redhat.com/errata/RHSA-2019:3967","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10902","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=39675f7a7c7e7702f7d5341f1e0d01db746543a0","https://lists.debian.org/debian-lts-announce/2018/10/msg00003.html","https://usn.ubuntu.com/3776-1/","https://usn.ubuntu.com/3776-2/","https://usn.ubuntu.com/3847-1/","https://usn.ubuntu.com/3847-2/","https://usn.ubuntu.com/3847-3/","https://usn.ubuntu.com/3849-1/","https://usn.ubuntu.com/3849-2/","https://www.debian.org/security/2018/dsa-4308","http://www.securityfocus.com/bid/105119","http://www.securitytracker.com/id/1041529","https://access.redhat.com/errata/RHSA-2018:3083","https://access.redhat.com/errata/RHSA-2018:3096","https://access.redhat.com/errata/RHSA-2019:0415","https://access.redhat.com/errata/RHSA-2019:0641","https://access.redhat.com/errata/RHSA-2019:3217","https://access.redhat.com/errata/RHSA-2019:3967","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10902","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=39675f7a7c7e7702f7d5341f1e0d01db746543a0","https://lists.debian.org/debian-lts-announce/2018/10/msg00003.html","https://usn.ubuntu.com/3776-1/","https://usn.ubuntu.com/3776-2/","https://usn.ubuntu.com/3847-1/","https://usn.ubuntu.com/3847-2/","https://usn.ubuntu.com/3847-3/","https://usn.ubuntu.com/3849-1/","https://usn.ubuntu.com/3849-2/","https://www.debian.org/security/2018/dsa-4308"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3390
|
High |
fixed |
- 4.14.322
- 4.19.291
- 5.4.251
- 5.10.188
- 5.15.118
- 6.1.35
- 6.3.9
|
A use-after-free vulnerability was found in the Linux kernel's netfilter subsystem in net/netfilter/nf_tables_api.c.
Mishandled error handling with NFT_MSG_NEWRULE makes it possible to use a dangling pointer in the same transaction causing a use-after-free vulnerability. This flaw allows a local attacker with user access to cause a privilege escalation issue.
We recommend upgrading past commit 1240eb93f0616b21c675416516ff3d74798fdc97. |
["http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1240eb93f0616b21c675416516ff3d74798fdc97","https://kernel.dance/1240eb93f0616b21c675416516ff3d74798fdc97","https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230818-0004/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5461","http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1240eb93f0616b21c675416516ff3d74798fdc97","https://kernel.dance/1240eb93f0616b21c675416516ff3d74798fdc97","https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230818-0004/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5461"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-38432
|
Critical |
fixed |
|
An issue was discovered in the Linux kernel before 6.3.10. fs/smb/server/smb2misc.c in ksmbd does not validate the relationship between the command payload size and the RFC1002 length specification, leading to an out-of-bounds read. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.10","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=2b9b8f3b68edb3d67d79962f02e26dbb5ae3808d","https://security.netapp.com/advisory/ntap-20230831-0002/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.10","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=2b9b8f3b68edb3d67d79962f02e26dbb5ae3808d","https://security.netapp.com/advisory/ntap-20230831-0002/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1679
|
High |
fixed |
- 4.14.291
- 4.19.256
- 5.4.211
- 5.10.137
- 5.15.61
- 5.18.18
- 5.19.2
|
A use-after-free flaw was found in the Linux kernel’s Atheros wireless adapter driver in the way a user forces the ath9k_htc_wait_for_target function to fail with some input messages. This flaw allows a local user to crash or potentially escalate their privileges on the system. |
["https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/lkml/87ilqc7jv9.fsf%40kernel.org/t/","https://security.netapp.com/advisory/ntap-20220629-0007/","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/lkml/87ilqc7jv9.fsf%40kernel.org/t/","https://security.netapp.com/advisory/ntap-20220629-0007/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36894
|
Medium |
fixed |
- 4.19.317
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.95
- 6.6.31
- 6.8.10
|
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete
FFS based applications can utilize the aio_cancel() callback to dequeue
pending USB requests submitted to the UDC. There is a scenario where the
FFS application issues an AIO cancel call, while the UDC is handling a
soft disconnect. For a DWC3 based implementation, the callstack looks
like the following:
DWC3 Gadget FFS Application
dwc3_gadget_soft_disconnect() ...
--> dwc3_stop_active_transfers()
--> dwc3_gadget_giveback(-ESHUTDOWN)
--> ffs_epfile_async_io_complete() ffs_aio_cancel()
--> usb_ep_free_request() --> usb_ep_dequeue()
There is currently no locking implemented between the AIO completion
handler and AIO cancel, so the issue occurs if the completion routine is
running in parallel to an AIO cancel call coming from the FFS application.
As the completion call frees the USB request (io_data->req) the FFS
application is also referencing it for the usb_ep_dequeue() call. This can
lead to accessing a stale/hanging pointer.
commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently")
relocated the usb_ep_free_request() into ffs_epfile_async_io_complete().
However, in order to properly implement locking to mitigate this issue, the
spinlock can't be added to ffs_epfile_async_io_complete(), as
usb_ep_dequeue() (if successfully dequeuing a USB request) will call the
function driver's completion handler in the same context. Hence, leading
into a deadlock.
Fix this issue by moving the usb_ep_free_request() back to
ffs_user_copy_worker(), and ensuring that it explicitly sets io_data->req
to NULL after freeing it within the ffs->eps_lock. This resolves the race
condition above, as the ffs_aio_cancel() routine will not continue
attempting to dequeue a request that has already been freed, or the
ffs_user_copy_work() not freeing the USB request until the AIO cancel is
done referencing it.
This fix depends on
commit b566d38857fc ("usb: gadget: f_fs: use io_data->status
consistently") |
["https://git.kernel.org/stable/c/24729b307eefcd7c476065cd7351c1a018082c19","https://git.kernel.org/stable/c/3613e5023f09b3308545e9d1acda86017ebd418a","https://git.kernel.org/stable/c/73c05ad46bb4fbbdb346004651576d1c8dbcffbb","https://git.kernel.org/stable/c/9e72ef59cbe61cd1243857a6418ca92104275867","https://git.kernel.org/stable/c/a0fdccb1c9e027e3195f947f61aa87d6d0d2ea14","https://git.kernel.org/stable/c/d7461830823242702f5d84084bcccb25159003f4","https://git.kernel.org/stable/c/e500b1c4e29ad0bd1c1332a1eaea2913627a92dd","https://git.kernel.org/stable/c/f71a53148ce34898fef099b75386a3a9f4449311","https://git.kernel.org/stable/c/24729b307eefcd7c476065cd7351c1a018082c19","https://git.kernel.org/stable/c/3613e5023f09b3308545e9d1acda86017ebd418a","https://git.kernel.org/stable/c/73c05ad46bb4fbbdb346004651576d1c8dbcffbb","https://git.kernel.org/stable/c/9e72ef59cbe61cd1243857a6418ca92104275867","https://git.kernel.org/stable/c/a0fdccb1c9e027e3195f947f61aa87d6d0d2ea14","https://git.kernel.org/stable/c/d7461830823242702f5d84084bcccb25159003f4","https://git.kernel.org/stable/c/e500b1c4e29ad0bd1c1332a1eaea2913627a92dd","https://git.kernel.org/stable/c/f71a53148ce34898fef099b75386a3a9f4449311"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48855
|
High |
fixed |
- 4.9.307
- 4.14.272
- 4.19.235
- 5.4.185
- 5.10.106
- 5.15.29
- 5.16.15
|
In the Linux kernel, the following vulnerability has been resolved:
sctp: fix kernel-infoleak for SCTP sockets
syzbot reported a kernel infoleak [1] of 4 bytes.
After analysis, it turned out r->idiag_expires is not initialized
if inet_sctp_diag_fill() calls inet_diag_msg_common_fill()
Make sure to clear idiag_timer/idiag_retrans/idiag_expires
and let inet_diag_msg_sctpasoc_fill() fill them again if needed.
[1]
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]
BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:154 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668
instrument_copy_to_user include/linux/instrumented.h:121 [inline]
copyout lib/iov_iter.c:154 [inline]
_copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668
copy_to_iter include/linux/uio.h:162 [inline]
simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519
__skb_datagram_iter+0x2d5/0x11b0 net/core/datagram.c:425
skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533
skb_copy_datagram_msg include/linux/skbuff.h:3696 [inline]
netlink_recvmsg+0x669/0x1c80 net/netlink/af_netlink.c:1977
sock_recvmsg_nosec net/socket.c:948 [inline]
sock_recvmsg net/socket.c:966 [inline]
__sys_recvfrom+0x795/0xa10 net/socket.c:2097
__do_sys_recvfrom net/socket.c:2115 [inline]
__se_sys_recvfrom net/socket.c:2111 [inline]
__x64_sys_recvfrom+0x19d/0x210 net/socket.c:2111
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x44/0xae
Uninit was created at:
slab_post_alloc_hook mm/slab.h:737 [inline]
slab_alloc_node mm/slub.c:3247 [inline]
__kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4975
kmalloc_reserve net/core/skbuff.c:354 [inline]
__alloc_skb+0x545/0xf90 net/core/skbuff.c:426
alloc_skb include/linux/skbuff.h:1158 [inline]
netlink_dump+0x3e5/0x16c0 net/netlink/af_netlink.c:2248
__netlink_dump_start+0xcf8/0xe90 net/netlink/af_netlink.c:2373
netlink_dump_start include/linux/netlink.h:254 [inline]
inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1341
sock_diag_rcv_msg+0x24a/0x620
netlink_rcv_skb+0x40c/0x7e0 net/netlink/af_netlink.c:2494
sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:277
netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
netlink_unicast+0x1093/0x1360 net/netlink/af_netlink.c:1343
netlink_sendmsg+0x14d9/0x1720 net/netlink/af_netlink.c:1919
sock_sendmsg_nosec net/socket.c:705 [inline]
sock_sendmsg net/socket.c:725 [inline]
sock_write_iter+0x594/0x690 net/socket.c:1061
do_iter_readv_writev+0xa7f/0xc70
do_iter_write+0x52c/0x1500 fs/read_write.c:851
vfs_writev fs/read_write.c:924 [inline]
do_writev+0x645/0xe00 fs/read_write.c:967
__do_sys_writev fs/read_write.c:1040 [inline]
__se_sys_writev fs/read_write.c:1037 [inline]
__x64_sys_writev+0xe5/0x120 fs/read_write.c:1037
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x44/0xae
Bytes 68-71 of 2508 are uninitialized
Memory access of size 2508 starts at ffff888114f9b000
Data copied to user address 00007f7fe09ff2e0
CPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 |
["https://git.kernel.org/stable/c/1502f15b9f29c41883a6139f2923523873282a83","https://git.kernel.org/stable/c/2d8fa3fdf4542a2174a72d92018f488d65d848c5","https://git.kernel.org/stable/c/3fc0fd724d199e061432b66a8d85b7d48fe485f7","https://git.kernel.org/stable/c/41a2864cf719c17294f417726edd411643462ab8","https://git.kernel.org/stable/c/633593a808980f82d251d0ca89730d8bb8b0220c","https://git.kernel.org/stable/c/b7e4d9ba2ddb78801488b4c623875b81fb46b545","https://git.kernel.org/stable/c/bbf59d7ae558940cfa2b36a287fd1e88d83f89f8","https://git.kernel.org/stable/c/d828b0fe6631f3ae8709ac9a10c77c5836c76a08","https://git.kernel.org/stable/c/1502f15b9f29c41883a6139f2923523873282a83","https://git.kernel.org/stable/c/2d8fa3fdf4542a2174a72d92018f488d65d848c5","https://git.kernel.org/stable/c/3fc0fd724d199e061432b66a8d85b7d48fe485f7","https://git.kernel.org/stable/c/41a2864cf719c17294f417726edd411643462ab8","https://git.kernel.org/stable/c/633593a808980f82d251d0ca89730d8bb8b0220c","https://git.kernel.org/stable/c/b7e4d9ba2ddb78801488b4c623875b81fb46b545","https://git.kernel.org/stable/c/bbf59d7ae558940cfa2b36a287fd1e88d83f89f8","https://git.kernel.org/stable/c/d828b0fe6631f3ae8709ac9a10c77c5836c76a08"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48672
|
High |
fixed |
- 4.14.295
- 4.19.260
- 5.4.215
- 5.10.145
- 5.15.70
- 5.19.11
|
In the Linux kernel, the following vulnerability has been resolved:
of: fdt: fix off-by-one error in unflatten_dt_nodes()
Commit 78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree")
forgot to fix up the depth check in the loop body in unflatten_dt_nodes()
which makes it possible to overflow the nps[] buffer...
Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool. |
["https://git.kernel.org/stable/c/2133f451311671c7c42b5640d2b999326b39aa0e","https://git.kernel.org/stable/c/2566706ac6393386a4e7c4ce23fe17f4c98d9aa0","https://git.kernel.org/stable/c/2f945a792f67815abca26fa8a5e863ccf3fa1181","https://git.kernel.org/stable/c/ba6b9f7cc1108bad6e2c53b1d6e0156379188db7","https://git.kernel.org/stable/c/cbdda20ce363356698835185801a58a28f644853","https://git.kernel.org/stable/c/e0e88c25f88b9805572263c9ed20f1d88742feaf","https://git.kernel.org/stable/c/ee4369260e77821602102dcc7d792de39a56365c","https://git.kernel.org/stable/c/2133f451311671c7c42b5640d2b999326b39aa0e","https://git.kernel.org/stable/c/2566706ac6393386a4e7c4ce23fe17f4c98d9aa0","https://git.kernel.org/stable/c/2f945a792f67815abca26fa8a5e863ccf3fa1181","https://git.kernel.org/stable/c/ba6b9f7cc1108bad6e2c53b1d6e0156379188db7","https://git.kernel.org/stable/c/cbdda20ce363356698835185801a58a28f644853","https://git.kernel.org/stable/c/e0e88c25f88b9805572263c9ed20f1d88742feaf","https://git.kernel.org/stable/c/ee4369260e77821602102dcc7d792de39a56365c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3586
|
Medium |
fixed |
|
A flaw was found in the Linux kernel’s networking code. A use-after-free was found in the way the sch_sfb enqueue function used the socket buffer (SKB) cb field after the same SKB had been enqueued (and freed) into a child qdisc. This flaw allows a local, unprivileged user to crash the system, causing a denial of service. |
["https://github.com/torvalds/linux/commit/9efd23297cca","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://www.zerodayinitiative.com/advisories/upcoming/","https://github.com/torvalds/linux/commit/9efd23297cca","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://www.zerodayinitiative.com/advisories/upcoming/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-38426
|
Critical |
fixed |
|
An issue was discovered in the Linux kernel before 6.3.4. ksmbd has an out-of-bounds read in smb2_find_context_vals when create_context's name_len is larger than the tag length. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/ksmbd?id=02f76c401d17e409ed45bf7887148fcc22c93c85","https://security.netapp.com/advisory/ntap-20230915-0010/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/ksmbd?id=02f76c401d17e409ed45bf7887148fcc22c93c85","https://security.netapp.com/advisory/ntap-20230915-0010/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-38428
|
Critical |
fixed |
|
An issue was discovered in the Linux kernel before 6.3.4. fs/ksmbd/smb2pdu.c in ksmbd does not properly check the UserName value because it does not consider the address of security buffer, leading to an out-of-bounds read. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/ksmbd?id=f0a96d1aafd8964e1f9955c830a3e5cb3c60a90f","https://security.netapp.com/advisory/ntap-20230831-0001/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/ksmbd?id=f0a96d1aafd8964e1f9955c830a3e5cb3c60a90f","https://security.netapp.com/advisory/ntap-20230831-0001/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-44879
|
Medium |
fixed |
|
In gc_data_segment in fs/f2fs/gc.c in the Linux kernel before 5.16.3, special files are not considered, leading to a move_data_page NULL pointer dereference. |
["https://bugzilla.kernel.org/show_bug.cgi?id=215231","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.3","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9056d6489f5a41cfbb67f719d2c0ce61ead72d9f","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://lore.kernel.org/linux-f2fs-devel/20211206144421.3735-3-chao%40kernel.org/T/","https://bugzilla.kernel.org/show_bug.cgi?id=215231","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.3","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9056d6489f5a41cfbb67f719d2c0ce61ead72d9f","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://lore.kernel.org/linux-f2fs-devel/20211206144421.3735-3-chao%40kernel.org/T/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2018-10840
|
Medium |
|
N/A
|
Linux kernel is vulnerable to a heap-based buffer overflow in the fs/ext4/xattr.c:ext4_xattr_set_entry() function. An attacker could exploit this by operating on a mounted crafted ext4 image. |
["http://www.securityfocus.com/bid/104858","https://access.redhat.com/errata/RHSA-2019:0162","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10840","https://usn.ubuntu.com/3752-1/","https://usn.ubuntu.com/3752-2/","https://usn.ubuntu.com/3752-3/","http://www.securityfocus.com/bid/104858","https://access.redhat.com/errata/RHSA-2019:0162","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10840","https://usn.ubuntu.com/3752-1/","https://usn.ubuntu.com/3752-2/","https://usn.ubuntu.com/3752-3/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-32254
|
High |
fixed |
- 5.15.145
- 6.1.28
- 6.2.15
- 6.3.2
|
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the processing of SMB2_TREE_DISCONNECT commands. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to execute code in the context of the kernel. |
["https://access.redhat.com/security/cve/CVE-2023-32254","https://bugzilla.redhat.com/show_bug.cgi?id=2191658","https://security.netapp.com/advisory/ntap-20230824-0004/","https://www.zerodayinitiative.com/advisories/ZDI-23-702/","https://access.redhat.com/security/cve/CVE-2023-32254","https://bugzilla.redhat.com/show_bug.cgi?id=2191658","https://security.netapp.com/advisory/ntap-20230824-0004/","https://www.zerodayinitiative.com/advisories/ZDI-23-702/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26996
|
High |
fixed |
- 5.15.157
- 6.1.88
- 6.6.29
- 6.8.8
|
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error
When ncm function is working and then stop usb0 interface for link down,
eth_stop() is called. At this piont, accidentally if usb transport error
should happen in usb_ep_enable(), 'in_ep' and/or 'out_ep' may not be enabled.
After that, ncm_disable() is called to disable for ncm unbind
but gether_disconnect() is never called since 'in_ep' is not enabled.
As the result, ncm object is released in ncm unbind
but 'dev->port_usb' associated to 'ncm->port' is not NULL.
And when ncm bind again to recover netdev, ncm object is reallocated
but usb0 interface is already associated to previous released ncm object.
Therefore, once usb0 interface is up and eth_start_xmit() is called,
released ncm object is dereferrenced and it might cause use-after-free memory.
[function unlink via configfs]
usb0: eth_stop dev->port_usb=ffffff9b179c3200
--> error happens in usb_ep_enable().
NCM: ncm_disable: ncm=ffffff9b179c3200
--> no gether_disconnect() since ncm->port.in_ep->enabled is false.
NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200
NCM: ncm_free: ncm free ncm=ffffff9b179c3200 <-- released ncm
[function link via configfs]
NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000
NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000
NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0
usb0: eth_open dev->port_usb=ffffff9b179c3200 <-- previous released ncm
usb0: eth_start dev->port_usb=ffffff9b179c3200 <--
eth_start_xmit()
--> dev->wrap()
Unable to handle kernel paging request at virtual address dead00000000014f
This patch addresses the issue by checking if 'ncm->netdev' is not NULL at
ncm_disable() to call gether_disconnect() to deassociate 'dev->port_usb'.
It's more reasonable to check 'ncm->netdev' to call gether_connect/disconnect
rather than check 'ncm->port.in_ep->enabled' since it might not be enabled
but the gether connection might be established. |
["https://git.kernel.org/stable/c/0588bbbd718a8130b98c54518f1e0b569ce60a93","https://git.kernel.org/stable/c/6334b8e4553cc69f51e383c9de545082213d785e","https://git.kernel.org/stable/c/7250326cbb1f4f90391ac511a126b936cefb5bb7","https://git.kernel.org/stable/c/7f67c2020cb08499c400abf0fc32c65e4d9a09ca","https://git.kernel.org/stable/c/f356fd0cbd9c9cbd0854657a80d1608d0d732db3","https://git.kernel.org/stable/c/0588bbbd718a8130b98c54518f1e0b569ce60a93","https://git.kernel.org/stable/c/6334b8e4553cc69f51e383c9de545082213d785e","https://git.kernel.org/stable/c/7250326cbb1f4f90391ac511a126b936cefb5bb7","https://git.kernel.org/stable/c/7f67c2020cb08499c400abf0fc32c65e4d9a09ca","https://git.kernel.org/stable/c/f356fd0cbd9c9cbd0854657a80d1608d0d732db3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-0458
|
Medium |
fixed |
|
A speculative pointer dereference problem exists in the Linux Kernel on the do_prlimit() function. The resource argument value is controlled and is used in pointer arithmetic for the 'rlim' variable and can be used to leak the contents. We recommend upgrading past version 6.1.8 or commit 739790605705ddcf18f21782b9c99ad7d53a8c11 |
["https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/kernel/sys.c?id=v6.1.8\u0026id2=v6.1.7","https://github.com/torvalds/linux/commit/739790605705ddcf18f21782b9c99ad7d53a8c11","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/kernel/sys.c?id=v6.1.8\u0026id2=v6.1.7","https://github.com/torvalds/linux/commit/739790605705ddcf18f21782b9c99ad7d53a8c11","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49377
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
blk-mq: don't touch ->tagset in blk_mq_get_sq_hctx
blk_mq_run_hw_queues() could be run when there isn't queued request and
after queue is cleaned up, at that time tagset is freed, because tagset
lifetime is covered by driver, and often freed after blk_cleanup_queue()
returns.
So don't touch ->tagset for figuring out current default hctx by the mapping
built in request queue, so use-after-free on tagset can be avoided. Meantime
this way should be fast than retrieving mapping from tagset. |
["https://git.kernel.org/stable/c/460aa288c5cd0544dcf933a2f0ad0e8c6d2d35ff","https://git.kernel.org/stable/c/5d05426e2d5fd7df8afc866b78c36b37b00188b7","https://git.kernel.org/stable/c/70fdd922c7bf8949f8df109cf2635dff64c90392","https://git.kernel.org/stable/c/b140bac470b4f707cda59c7266214246238661df"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49426
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
iommu/arm-smmu-v3-sva: Fix mm use-after-free
We currently call arm64_mm_context_put() without holding a reference to
the mm, which can result in use-after-free. Call mmgrab()/mmdrop() to
ensure the mm only gets freed after we unpinned the ASID. |
["https://git.kernel.org/stable/c/9aa215450888cf29af0c479e14a712dc6b0c506c","https://git.kernel.org/stable/c/cbd23144f7662b00bcde32a938c4a4057e476d68","https://git.kernel.org/stable/c/e3cbbdbff8a4db5d053c53fd71be62ccccdb52b0","https://git.kernel.org/stable/c/fc90f13ea0dcd960e5002d204fa55cec4e0db2fa"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49541
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix potential double free during failed mount
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=2088799 |
["https://git.kernel.org/stable/c/8378a51e3f8140f60901fb27208cc7a6e47047b5","https://git.kernel.org/stable/c/9a167fc440e5693c1cdd7f07071e05658bd9d89d","https://git.kernel.org/stable/c/ce0008a0e410cdd95f0d8cd81b2902ec10a660c4","https://git.kernel.org/stable/c/ee71f8f1cd3c8c4a251fd3e8abc89215ae3457cb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49548
|
High |
fixed |
- 5.10.120
- 5.15.45
- 5.17.13
- 5.18.2
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix potential array overflow in bpf_trampoline_get_progs()
The cnt value in the 'cnt >= BPF_MAX_TRAMP_PROGS' check does not
include BPF_TRAMP_MODIFY_RETURN bpf programs, so the number of
the attached BPF_TRAMP_MODIFY_RETURN bpf programs in a trampoline
can exceed BPF_MAX_TRAMP_PROGS.
When this happens, the assignment '*progs++ = aux->prog' in
bpf_trampoline_get_progs() will cause progs array overflow as the
progs field in the bpf_tramp_progs struct can only hold at most
BPF_MAX_TRAMP_PROGS bpf programs. |
["https://git.kernel.org/stable/c/32c4559c61652f24c9fdd5440342196fe37453bc","https://git.kernel.org/stable/c/4f8897bcc20b9ae44758e0572538d741ab66f0dc","https://git.kernel.org/stable/c/7f845de2863334bed4f362e95853f5e7bc323737","https://git.kernel.org/stable/c/a2aa95b71c9bbec793b5c5fa50f0a80d882b3e8d","https://git.kernel.org/stable/c/e36452d5da6325df7c10cffc60a9e68d21e2606d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49695
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
igb: fix a use-after-free issue in igb_clean_tx_ring
Fix the following use-after-free bug in igb_clean_tx_ring routine when
the NIC is running in XDP mode. The issue can be triggered redirecting
traffic into the igb NIC and then closing the device while the traffic
is flowing.
[ 73.322719] CPU: 1 PID: 487 Comm: xdp_redirect Not tainted 5.18.3-apu2 #9
[ 73.330639] Hardware name: PC Engines APU2/APU2, BIOS 4.0.7 02/28/2017
[ 73.337434] RIP: 0010:refcount_warn_saturate+0xa7/0xf0
[ 73.362283] RSP: 0018:ffffc9000081f798 EFLAGS: 00010282
[ 73.367761] RAX: 0000000000000000 RBX: ffffc90000420f80 RCX: 0000000000000000
[ 73.375200] RDX: ffff88811ad22d00 RSI: ffff88811ad171e0 RDI: ffff88811ad171e0
[ 73.382590] RBP: 0000000000000900 R08: ffffffff82298f28 R09: 0000000000000058
[ 73.390008] R10: 0000000000000219 R11: ffffffff82280f40 R12: 0000000000000090
[ 73.397356] R13: ffff888102343a40 R14: ffff88810359e0e4 R15: 0000000000000000
[ 73.404806] FS: 00007ff38d31d740(0000) GS:ffff88811ad00000(0000) knlGS:0000000000000000
[ 73.413129] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 73.419096] CR2: 000055cff35f13f8 CR3: 0000000106391000 CR4: 00000000000406e0
[ 73.426565] Call Trace:
[ 73.429087] <TASK>
[ 73.431314] igb_clean_tx_ring+0x43/0x140 [igb]
[ 73.436002] igb_down+0x1d7/0x220 [igb]
[ 73.439974] __igb_close+0x3c/0x120 [igb]
[ 73.444118] igb_xdp+0x10c/0x150 [igb]
[ 73.447983] ? igb_pci_sriov_configure+0x70/0x70 [igb]
[ 73.453362] dev_xdp_install+0xda/0x110
[ 73.457371] dev_xdp_attach+0x1da/0x550
[ 73.461369] do_setlink+0xfd0/0x10f0
[ 73.465166] ? __nla_validate_parse+0x89/0xc70
[ 73.469714] rtnl_setlink+0x11a/0x1e0
[ 73.473547] rtnetlink_rcv_msg+0x145/0x3d0
[ 73.477709] ? rtnl_calcit.isra.0+0x130/0x130
[ 73.482258] netlink_rcv_skb+0x8d/0x110
[ 73.486229] netlink_unicast+0x230/0x340
[ 73.490317] netlink_sendmsg+0x215/0x470
[ 73.494395] __sys_sendto+0x179/0x190
[ 73.498268] ? move_addr_to_user+0x37/0x70
[ 73.502547] ? __sys_getsockname+0x84/0xe0
[ 73.506853] ? netlink_setsockopt+0x1c1/0x4a0
[ 73.511349] ? __sys_setsockopt+0xc8/0x1d0
[ 73.515636] __x64_sys_sendto+0x20/0x30
[ 73.519603] do_syscall_64+0x3b/0x80
[ 73.523399] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 73.528712] RIP: 0033:0x7ff38d41f20c
[ 73.551866] RSP: 002b:00007fff3b945a68 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
[ 73.559640] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ff38d41f20c
[ 73.567066] RDX: 0000000000000034 RSI: 00007fff3b945b30 RDI: 0000000000000003
[ 73.574457] RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000
[ 73.581852] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff3b945ab0
[ 73.589179] R13: 0000000000000000 R14: 0000000000000003 R15: 00007fff3b945b30
[ 73.596545] </TASK>
[ 73.598842] ---[ end trace 0000000000000000 ]--- |
["https://git.kernel.org/stable/c/2af944210dc23d43d8208dafac4df7be7e3c168b","https://git.kernel.org/stable/c/3f6a57ee8544ec3982f8a3cbcbf4aea7d47eb9ec","https://git.kernel.org/stable/c/68a0ed06dcd5d3ea732d011c0b83d66e4791f521","https://git.kernel.org/stable/c/c12a2c9b1b460ed72e6b3c33aac1ef51b0329b66"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49696
|
High |
fixed |
- 5.5
- 5.10.127
- 5.15.51
- 5.18.8
|
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix use-after-free Read in tipc_named_reinit
syzbot found the following issue on:
==================================================================
BUG: KASAN: use-after-free in tipc_named_reinit+0x94f/0x9b0
net/tipc/name_distr.c:413
Read of size 8 at addr ffff88805299a000 by task kworker/1:9/23764
CPU: 1 PID: 23764 Comm: kworker/1:9 Not tainted
5.18.0-rc4-syzkaller-00878-g17d49e6e8012 #0
Hardware name: Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
Workqueue: events tipc_net_finalize_work
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description.constprop.0.cold+0xeb/0x495
mm/kasan/report.c:313
print_report mm/kasan/report.c:429 [inline]
kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491
tipc_named_reinit+0x94f/0x9b0 net/tipc/name_distr.c:413
tipc_net_finalize+0x234/0x3d0 net/tipc/net.c:138
process_one_work+0x996/0x1610 kernel/workqueue.c:2289
worker_thread+0x665/0x1080 kernel/workqueue.c:2436
kthread+0x2e9/0x3a0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298
</TASK>
[...]
==================================================================
In the commit
d966ddcc3821 ("tipc: fix a deadlock when flushing scheduled work"),
the cancel_work_sync() function just to make sure ONLY the work
tipc_net_finalize_work() is executing/pending on any CPU completed before
tipc namespace is destroyed through tipc_exit_net(). But this function
is not guaranteed the work is the last queued. So, the destroyed instance
may be accessed in the work which will try to enqueue later.
In order to completely fix, we re-order the calling of cancel_work_sync()
to make sure the work tipc_net_finalize_work() was last queued and it
must be completed by calling cancel_work_sync(). |
["https://git.kernel.org/stable/c/361c5521c1e49843b710f455cae3c0a50b714323","https://git.kernel.org/stable/c/8b246ddd394d7d9640816611693b0096b998e27a","https://git.kernel.org/stable/c/911600bf5a5e84bfda4d33ee32acc75ecf6159f0","https://git.kernel.org/stable/c/cd7789e659e84f137631dc1f5ec8d794f2700e6c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49720
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
block: Fix handling of offline queues in blk_mq_alloc_request_hctx()
This patch prevents that test nvme/004 triggers the following:
UBSAN: array-index-out-of-bounds in block/blk-mq.h:135:9
index 512 is out of range for type 'long unsigned int [512]'
Call Trace:
show_stack+0x52/0x58
dump_stack_lvl+0x49/0x5e
dump_stack+0x10/0x12
ubsan_epilogue+0x9/0x3b
__ubsan_handle_out_of_bounds.cold+0x44/0x49
blk_mq_alloc_request_hctx+0x304/0x310
__nvme_submit_sync_cmd+0x70/0x200 [nvme_core]
nvmf_connect_io_queue+0x23e/0x2a0 [nvme_fabrics]
nvme_loop_connect_io_queues+0x8d/0xb0 [nvme_loop]
nvme_loop_create_ctrl+0x58e/0x7d0 [nvme_loop]
nvmf_create_ctrl+0x1d7/0x4d0 [nvme_fabrics]
nvmf_dev_write+0xae/0x111 [nvme_fabrics]
vfs_write+0x144/0x560
ksys_write+0xb7/0x140
__x64_sys_write+0x42/0x50
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae |
["https://git.kernel.org/stable/c/14dc7a18abbe4176f5626c13c333670da8e06aa1","https://git.kernel.org/stable/c/7fa28a7c3d74933a4fc22d341b60927952f31c19","https://git.kernel.org/stable/c/b202a0bd2580ee5b0453772c46d464152fafff73","https://git.kernel.org/stable/c/b5e65ef044d627effdc2599040b6d204e003f955"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3643
|
Medium |
fixed |
- 4.9.336
- 4.14.302
- 4.19.269
- 5.4.227
- 5.10.159
- 5.15.83
- 6.0.13
|
Guests can trigger NIC interface reset/abort/crash via netback It is possible for a guest to trigger a NIC interface reset/abort/crash in a Linux based network backend by sending certain kinds of packets. It appears to be an (unwritten?) assumption in the rest of the Linux network stack that packet protocol headers are all contained within the linear section of the SKB and some NICs behave badly if this is not the case. This has been reported to occur with Cisco (enic) and Broadcom NetXtrem II BCM5780 (bnx2x) though it may be an issue with other NICs/drivers as well. In case the frontend is sending requests with split headers, netback will forward those violating above mentioned assumption to the networking core, resulting in said misbehavior. |
["http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","http://www.openwall.com/lists/oss-security/2022/12/07/2","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://xenbits.xenproject.org/xsa/advisory-423.txt","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","http://www.openwall.com/lists/oss-security/2022/12/07/2","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://xenbits.xenproject.org/xsa/advisory-423.txt"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48658
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mm: slub: fix flush_cpu_slab()/__free_slab() invocations in task context.
Commit 5a836bf6b09f ("mm: slub: move flush_cpu_slab() invocations
__free_slab() invocations out of IRQ context") moved all flush_cpu_slab()
invocations to the global workqueue to avoid a problem related
with deactivate_slab()/__free_slab() being called from an IRQ context
on PREEMPT_RT kernels.
When the flush_all_cpu_locked() function is called from a task context
it may happen that a workqueue with WQ_MEM_RECLAIM bit set ends up
flushing the global workqueue, this will cause a dependency issue.
workqueue: WQ_MEM_RECLAIM nvme-delete-wq:nvme_delete_ctrl_work [nvme_core]
is flushing !WQ_MEM_RECLAIM events:flush_cpu_slab
WARNING: CPU: 37 PID: 410 at kernel/workqueue.c:2637
check_flush_dependency+0x10a/0x120
Workqueue: nvme-delete-wq nvme_delete_ctrl_work [nvme_core]
RIP: 0010:check_flush_dependency+0x10a/0x120[ 453.262125] Call Trace:
__flush_work.isra.0+0xbf/0x220
? __queue_work+0x1dc/0x420
flush_all_cpus_locked+0xfb/0x120
__kmem_cache_shutdown+0x2b/0x320
kmem_cache_destroy+0x49/0x100
bioset_exit+0x143/0x190
blk_release_queue+0xb9/0x100
kobject_cleanup+0x37/0x130
nvme_fc_ctrl_free+0xc6/0x150 [nvme_fc]
nvme_free_ctrl+0x1ac/0x2b0 [nvme_core]
Fix this bug by creating a workqueue for the flush operation with
the WQ_MEM_RECLAIM bit set. |
["https://git.kernel.org/stable/c/61703b248be993eb4997b00ae5d3318e6d8f3c5b","https://git.kernel.org/stable/c/df6cb39335cf5a1b918e8dbd8ba7cd9f1d00e45a","https://git.kernel.org/stable/c/e45cc288724f0cfd497bb5920bcfa60caa335729","https://git.kernel.org/stable/c/61703b248be993eb4997b00ae5d3318e6d8f3c5b","https://git.kernel.org/stable/c/df6cb39335cf5a1b918e8dbd8ba7cd9f1d00e45a","https://git.kernel.org/stable/c/e45cc288724f0cfd497bb5920bcfa60caa335729"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48662
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gem: Really move i915_gem_context.link under ref protection
i915_perf assumes that it can use the i915_gem_context reference to
protect its i915->gem.contexts.list iteration. However, this requires
that we do not remove the context from the list until after we drop the
final reference and release the struct. If, as currently, we remove the
context from the list during context_close(), the link.next pointer may
be poisoned while we are holding the context reference and cause a GPF:
[ 4070.573157] i915 0000:00:02.0: [drm:i915_perf_open_ioctl [i915]] filtering on ctx_id=0x1fffff ctx_id_mask=0x1fffff
[ 4070.574881] general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP
[ 4070.574897] CPU: 1 PID: 284392 Comm: amd_performance Tainted: G E 5.17.9 #180
[ 4070.574903] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017
[ 4070.574907] RIP: 0010:oa_configure_all_contexts.isra.0+0x222/0x350 [i915]
[ 4070.574982] Code: 08 e8 32 6e 10 e1 4d 8b 6d 50 b8 ff ff ff ff 49 83 ed 50 f0 41 0f c1 04 24 83 f8 01 0f 84 e3 00 00 00 85 c0 0f 8e fa 00 00 00 <49> 8b 45 50 48 8d 70 b0 49 8d 45 50 48 39 44 24 10 0f 85 34 fe ff
[ 4070.574990] RSP: 0018:ffffc90002077b78 EFLAGS: 00010202
[ 4070.574995] RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000000
[ 4070.575000] RDX: 0000000000000001 RSI: ffffc90002077b20 RDI: ffff88810ddc7c68
[ 4070.575004] RBP: 0000000000000001 R08: ffff888103242648 R09: fffffffffffffffc
[ 4070.575008] R10: ffffffff82c50bc0 R11: 0000000000025c80 R12: ffff888101bf1860
[ 4070.575012] R13: dead0000000000b0 R14: ffffc90002077c04 R15: ffff88810be5cabc
[ 4070.575016] FS: 00007f1ed50c0780(0000) GS:ffff88885ec80000(0000) knlGS:0000000000000000
[ 4070.575021] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4070.575025] CR2: 00007f1ed5590280 CR3: 000000010ef6f005 CR4: 00000000003706e0
[ 4070.575029] Call Trace:
[ 4070.575033] <TASK>
[ 4070.575037] lrc_configure_all_contexts+0x13e/0x150 [i915]
[ 4070.575103] gen8_enable_metric_set+0x4d/0x90 [i915]
[ 4070.575164] i915_perf_open_ioctl+0xbc0/0x1500 [i915]
[ 4070.575224] ? asm_common_interrupt+0x1e/0x40
[ 4070.575232] ? i915_oa_init_reg_state+0x110/0x110 [i915]
[ 4070.575290] drm_ioctl_kernel+0x85/0x110
[ 4070.575296] ? update_load_avg+0x5f/0x5e0
[ 4070.575302] drm_ioctl+0x1d3/0x370
[ 4070.575307] ? i915_oa_init_reg_state+0x110/0x110 [i915]
[ 4070.575382] ? gen8_gt_irq_handler+0x46/0x130 [i915]
[ 4070.575445] __x64_sys_ioctl+0x3c4/0x8d0
[ 4070.575451] ? __do_softirq+0xaa/0x1d2
[ 4070.575456] do_syscall_64+0x35/0x80
[ 4070.575461] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 4070.575467] RIP: 0033:0x7f1ed5c10397
[ 4070.575471] Code: 3c 1c e8 1c ff ff ff 85 c0 79 87 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a9 da 0d 00 f7 d8 64 89 01 48
[ 4070.575478] RSP: 002b:00007ffd65c8d7a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 4070.575484] RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00007f1ed5c10397
[ 4070.575488] RDX: 00007ffd65c8d7c0 RSI: 0000000040106476 RDI: 0000000000000006
[ 4070.575492] RBP: 00005620972f9c60 R08: 000000000000000a R09: 0000000000000005
[ 4070.575496] R10: 000000000000000d R11: 0000000000000246 R12: 000000000000000a
[ 4070.575500] R13: 000000000000000d R14: 0000000000000000 R15: 00007ffd65c8d7c0
[ 4070.575505] </TASK>
[ 4070.575507] Modules linked in: nls_ascii(E) nls_cp437(E) vfat(E) fat(E) i915(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) aesni_intel(E) crypto_simd(E) intel_gtt(E) cryptd(E) ttm(E) rapl(E) intel_cstate(E) drm_kms_helper(E) cfbfillrect(E) syscopyarea(E) cfbimgblt(E) intel_uncore(E) sysfillrect(E) mei_me(E) sysimgblt(E) i2c_i801(E) fb_sys_fops(E) mei(E) intel_pch_thermal(E) i2c_smbus
---truncated--- |
["https://git.kernel.org/stable/c/713fa3e4591f65f804bdc88e8648e219fabc9ee1","https://git.kernel.org/stable/c/d119888b09bd567e07c6b93a07f175df88857e02","https://git.kernel.org/stable/c/f799e0568d6c153368b177e0bbbde7dcc4ce7f1d","https://git.kernel.org/stable/c/713fa3e4591f65f804bdc88e8648e219fabc9ee1","https://git.kernel.org/stable/c/d119888b09bd567e07c6b93a07f175df88857e02","https://git.kernel.org/stable/c/f799e0568d6c153368b177e0bbbde7dcc4ce7f1d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52818
|
High |
fixed |
- 4.14.331
- 4.19.300
- 5.4.262
- 5.10.202
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd: Fix UBSAN array-index-out-of-bounds for SMU7
For pptable structs that use flexible array sizes, use flexible arrays. |
["https://git.kernel.org/stable/c/6dffdddfca818c02a42b6caa1d9845995f0a1f94","https://git.kernel.org/stable/c/760efbca74a405dc439a013a5efaa9fadc95a8c3","https://git.kernel.org/stable/c/8af28ae3acb736ada4ce3457662fa446cc913bb4","https://git.kernel.org/stable/c/92a775e7c9707aed28782bafe636bf87675f5a97","https://git.kernel.org/stable/c/acdb6830de02cf2873aeaccdf2d9bca4aee50e47","https://git.kernel.org/stable/c/c847379a5d00078ad6fcb1c24230e72c5609342f","https://git.kernel.org/stable/c/cfd8cd907fd94538561479a43aea455f5cf16928","https://git.kernel.org/stable/c/e52e324a21341c97350d5f11de14721c1c609498","https://git.kernel.org/stable/c/fc9ac0e8e0bcb3740c6eaad3a1a50c20016d422b","https://git.kernel.org/stable/c/6dffdddfca818c02a42b6caa1d9845995f0a1f94","https://git.kernel.org/stable/c/760efbca74a405dc439a013a5efaa9fadc95a8c3","https://git.kernel.org/stable/c/8af28ae3acb736ada4ce3457662fa446cc913bb4","https://git.kernel.org/stable/c/92a775e7c9707aed28782bafe636bf87675f5a97","https://git.kernel.org/stable/c/acdb6830de02cf2873aeaccdf2d9bca4aee50e47","https://git.kernel.org/stable/c/c847379a5d00078ad6fcb1c24230e72c5609342f","https://git.kernel.org/stable/c/cfd8cd907fd94538561479a43aea455f5cf16928","https://git.kernel.org/stable/c/e52e324a21341c97350d5f11de14721c1c609498","https://git.kernel.org/stable/c/fc9ac0e8e0bcb3740c6eaad3a1a50c20016d422b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49560
|
High |
fixed |
- 5.10.120
- 5.15.45
- 5.17.13
- 5.18.2
|
In the Linux kernel, the following vulnerability has been resolved:
exfat: check if cluster num is valid
Syzbot reported slab-out-of-bounds read in exfat_clear_bitmap.
This was triggered by reproducer calling truncute with size 0,
which causes the following trace:
BUG: KASAN: slab-out-of-bounds in exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174
Read of size 8 at addr ffff888115aa9508 by task syz-executor251/365
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack_lvl+0x1e2/0x24b lib/dump_stack.c:118
print_address_description+0x81/0x3c0 mm/kasan/report.c:233
__kasan_report mm/kasan/report.c:419 [inline]
kasan_report+0x1a4/0x1f0 mm/kasan/report.c:436
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:309
exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174
exfat_free_cluster+0x25a/0x4a0 fs/exfat/fatent.c:181
__exfat_truncate+0x99e/0xe00 fs/exfat/file.c:217
exfat_truncate+0x11b/0x4f0 fs/exfat/file.c:243
exfat_setattr+0xa03/0xd40 fs/exfat/file.c:339
notify_change+0xb76/0xe10 fs/attr.c:336
do_truncate+0x1ea/0x2d0 fs/open.c:65
Move the is_valid_cluster() helper from fatent.c to a common
header to make it reusable in other *.c files. And add is_valid_cluster()
to validate if cluster number is within valid range in exfat_clear_bitmap()
and exfat_set_bitmap(). |
["https://git.kernel.org/stable/c/2193286402df2d9c53294f7a858d5e6fd7346e08","https://git.kernel.org/stable/c/64ba4b15e5c045f8b746c6da5fc9be9a6b00b61d","https://git.kernel.org/stable/c/7c58b14b6f9cde9f69e7fa053ab73f6e013a7131","https://git.kernel.org/stable/c/82f723b8a5adf497f9e34c702a30ca7298615654","https://git.kernel.org/stable/c/c504167adc3248095a905fa0700a9693897cb5ed"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52733
|
High |
fixed |
- 5.4.232
- 5.10.169
- 5.15.95
- 6.1.13
|
In the Linux kernel, the following vulnerability has been resolved:
s390/decompressor: specify __decompress() buf len to avoid overflow
Historically calls to __decompress() didn't specify "out_len" parameter
on many architectures including s390, expecting that no writes beyond
uncompressed kernel image are performed. This has changed since commit
2aa14b1ab2c4 ("zstd: import usptream v1.5.2") which includes zstd library
commit 6a7ede3dfccb ("Reduce size of dctx by reutilizing dst buffer
(#2751)"). Now zstd decompression code might store literal buffer in
the unwritten portion of the destination buffer. Since "out_len" is
not set, it is considered to be unlimited and hence free to use for
optimization needs. On s390 this might corrupt initrd or ipl report
which are often placed right after the decompressor buffer. Luckily the
size of uncompressed kernel image is already known to the decompressor,
so to avoid the problem simply specify it in the "out_len" parameter. |
["https://git.kernel.org/stable/c/16409f7d9ca5bb8220e1049ea9aae0d3c94d2dfb","https://git.kernel.org/stable/c/55dbd6f4ea954751340f4f73d5dcd7c8f12208b2","https://git.kernel.org/stable/c/7ab41c2c08a32132ba8c14624910e2fe8ce4ba4b","https://git.kernel.org/stable/c/9ed522143f959630f8b7782ddc212900d8f609a9","https://git.kernel.org/stable/c/f1eb22d0ff064ad458b3b1a1eaa84ac3996206c2","https://git.kernel.org/stable/c/16409f7d9ca5bb8220e1049ea9aae0d3c94d2dfb","https://git.kernel.org/stable/c/55dbd6f4ea954751340f4f73d5dcd7c8f12208b2","https://git.kernel.org/stable/c/7ab41c2c08a32132ba8c14624910e2fe8ce4ba4b","https://git.kernel.org/stable/c/9ed522143f959630f8b7782ddc212900d8f609a9","https://git.kernel.org/stable/c/f1eb22d0ff064ad458b3b1a1eaa84ac3996206c2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-46838
|
High |
fixed |
- 4.19.306
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
Transmit requests in Xen's virtual network protocol can consist of
multiple parts. While not really useful, except for the initial part
any of them may be of zero length, i.e. carry no data at all. Besides a
certain initial portion of the to be transferred data, these parts are
directly translated into what Linux calls SKB fragments. Such converted
request parts can, when for a particular SKB they are all of length
zero, lead to a de-reference of NULL in core networking code. |
["https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RGEKT4DKSDXDS34EL7M4UVJMMPH7Z3ZZ/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZFYW6R64GPLUOXSQBJI3JBUX3HGLAYPP/","https://xenbits.xenproject.org/xsa/advisory-448.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RGEKT4DKSDXDS34EL7M4UVJMMPH7Z3ZZ/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZFYW6R64GPLUOXSQBJI3JBUX3HGLAYPP/","https://xenbits.xenproject.org/xsa/advisory-448.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48695
|
High |
fixed |
- 4.9.328
- 4.14.293
- 4.19.258
- 5.4.213
- 5.10.143
- 5.15.168
- 5.19.9
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Fix use-after-free warning
Fix the following use-after-free warning which is observed during
controller reset:
refcount_t: underflow; use-after-free.
WARNING: CPU: 23 PID: 5399 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0 |
["https://git.kernel.org/stable/c/41acb064c4e013808bc7d5fc1b506fa449425b0b","https://git.kernel.org/stable/c/5682c94644fde72f72bded6580c38189ffc856b5","https://git.kernel.org/stable/c/6229fa494a5949be209bc73afbc5d0a749c2e3c7","https://git.kernel.org/stable/c/82efb917eeb27454dc4c6fe26432fc8f6c75bc16","https://git.kernel.org/stable/c/991df3dd5144f2e6b1c38b8d20ed3d4d21e20b34","https://git.kernel.org/stable/c/b8fc9e91b931215110ba824d1a2983c5f60b6f82","https://git.kernel.org/stable/c/d4959d09b76eb7a4146f5133962b88d3bddb63d6","https://git.kernel.org/stable/c/ea10a652ad2ae2cf3eced6f632a5c98f26727057","https://git.kernel.org/stable/c/41acb064c4e013808bc7d5fc1b506fa449425b0b","https://git.kernel.org/stable/c/5682c94644fde72f72bded6580c38189ffc856b5","https://git.kernel.org/stable/c/6229fa494a5949be209bc73afbc5d0a749c2e3c7","https://git.kernel.org/stable/c/82efb917eeb27454dc4c6fe26432fc8f6c75bc16","https://git.kernel.org/stable/c/991df3dd5144f2e6b1c38b8d20ed3d4d21e20b34","https://git.kernel.org/stable/c/b8fc9e91b931215110ba824d1a2983c5f60b6f82","https://git.kernel.org/stable/c/d4959d09b76eb7a4146f5133962b88d3bddb63d6","https://git.kernel.org/stable/c/ea10a652ad2ae2cf3eced6f632a5c98f26727057"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52707
|
High |
fixed |
- 5.4.232
- 5.10.169
- 5.15.95
- 6.1.13
|
In the Linux kernel, the following vulnerability has been resolved:
sched/psi: Fix use-after-free in ep_remove_wait_queue()
If a non-root cgroup gets removed when there is a thread that registered
trigger and is polling on a pressure file within the cgroup, the polling
waitqueue gets freed in the following path:
do_rmdir
cgroup_rmdir
kernfs_drain_open_files
cgroup_file_release
cgroup_pressure_release
psi_trigger_destroy
However, the polling thread still has a reference to the pressure file and
will access the freed waitqueue when the file is closed or upon exit:
fput
ep_eventpoll_release
ep_free
ep_remove_wait_queue
remove_wait_queue
This results in use-after-free as pasted below.
The fundamental problem here is that cgroup_file_release() (and
consequently waitqueue's lifetime) is not tied to the file's real lifetime.
Using wake_up_pollfree() here might be less than ideal, but it is in line
with the comment at commit 42288cb44c4b ("wait: add wake_up_pollfree()")
since the waitqueue's lifetime is not tied to file's one and can be
considered as another special case. While this would be fixable by somehow
making cgroup_file_release() be tied to the fput(), it would require
sizable refactoring at cgroups or higher layer which might be more
justifiable if we identify more cases like this.
BUG: KASAN: use-after-free in _raw_spin_lock_irqsave+0x60/0xc0
Write of size 4 at addr ffff88810e625328 by task a.out/4404
CPU: 19 PID: 4404 Comm: a.out Not tainted 6.2.0-rc6 #38
Hardware name: Amazon EC2 c5a.8xlarge/, BIOS 1.0 10/16/2017
Call Trace:
<TASK>
dump_stack_lvl+0x73/0xa0
print_report+0x16c/0x4e0
kasan_report+0xc3/0xf0
kasan_check_range+0x2d2/0x310
_raw_spin_lock_irqsave+0x60/0xc0
remove_wait_queue+0x1a/0xa0
ep_free+0x12c/0x170
ep_eventpoll_release+0x26/0x30
__fput+0x202/0x400
task_work_run+0x11d/0x170
do_exit+0x495/0x1130
do_group_exit+0x100/0x100
get_signal+0xd67/0xde0
arch_do_signal_or_restart+0x2a/0x2b0
exit_to_user_mode_prepare+0x94/0x100
syscall_exit_to_user_mode+0x20/0x40
do_syscall_64+0x52/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
</TASK>
Allocated by task 4404:
kasan_set_track+0x3d/0x60
__kasan_kmalloc+0x85/0x90
psi_trigger_create+0x113/0x3e0
pressure_write+0x146/0x2e0
cgroup_file_write+0x11c/0x250
kernfs_fop_write_iter+0x186/0x220
vfs_write+0x3d8/0x5c0
ksys_write+0x90/0x110
do_syscall_64+0x43/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Freed by task 4407:
kasan_set_track+0x3d/0x60
kasan_save_free_info+0x27/0x40
____kasan_slab_free+0x11d/0x170
slab_free_freelist_hook+0x87/0x150
__kmem_cache_free+0xcb/0x180
psi_trigger_destroy+0x2e8/0x310
cgroup_file_release+0x4f/0xb0
kernfs_drain_open_files+0x165/0x1f0
kernfs_drain+0x162/0x1a0
__kernfs_remove+0x1fb/0x310
kernfs_remove_by_name_ns+0x95/0xe0
cgroup_addrm_files+0x67f/0x700
cgroup_destroy_locked+0x283/0x3c0
cgroup_rmdir+0x29/0x100
kernfs_iop_rmdir+0xd1/0x140
vfs_rmdir+0xfe/0x240
do_rmdir+0x13d/0x280
__x64_sys_rmdir+0x2c/0x30
do_syscall_64+0x43/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd |
["https://git.kernel.org/stable/c/7caeb5457bd01ccba0df1d6f4872f20d28e50b38","https://git.kernel.org/stable/c/c2dbe32d5db5c4ead121cf86dabd5ab691fb47fe","https://git.kernel.org/stable/c/c6879a4dcefe92d870ab68cabaa9caeda4f2af5a","https://git.kernel.org/stable/c/cca2b3feb70170ef6f0fbc4b4d91eea235a2b73a","https://git.kernel.org/stable/c/ec9c7aa08819f976b2492fa63c41b5712d2924b5","https://git.kernel.org/stable/c/7caeb5457bd01ccba0df1d6f4872f20d28e50b38","https://git.kernel.org/stable/c/c2dbe32d5db5c4ead121cf86dabd5ab691fb47fe","https://git.kernel.org/stable/c/c6879a4dcefe92d870ab68cabaa9caeda4f2af5a","https://git.kernel.org/stable/c/cca2b3feb70170ef6f0fbc4b4d91eea235a2b73a","https://git.kernel.org/stable/c/ec9c7aa08819f976b2492fa63c41b5712d2924b5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52772
|
High |
fixed |
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
af_unix: fix use-after-free in unix_stream_read_actor()
syzbot reported the following crash [1]
After releasing unix socket lock, u->oob_skb can be changed
by another thread. We must temporarily increase skb refcount
to make sure this other thread will not free the skb under us.
[1]
BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa7/0xc0 net/unix/af_unix.c:2866
Read of size 4 at addr ffff88801f3b9cc4 by task syz-executor107/5297
CPU: 1 PID: 5297 Comm: syz-executor107 Not tainted 6.6.0-syzkaller-15910-gb8e3a87a627b #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:364 [inline]
print_report+0xc4/0x620 mm/kasan/report.c:475
kasan_report+0xda/0x110 mm/kasan/report.c:588
unix_stream_read_actor+0xa7/0xc0 net/unix/af_unix.c:2866
unix_stream_recv_urg net/unix/af_unix.c:2587 [inline]
unix_stream_read_generic+0x19a5/0x2480 net/unix/af_unix.c:2666
unix_stream_recvmsg+0x189/0x1b0 net/unix/af_unix.c:2903
sock_recvmsg_nosec net/socket.c:1044 [inline]
sock_recvmsg+0xe2/0x170 net/socket.c:1066
____sys_recvmsg+0x21f/0x5c0 net/socket.c:2803
___sys_recvmsg+0x115/0x1a0 net/socket.c:2845
__sys_recvmsg+0x114/0x1e0 net/socket.c:2875
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x63/0x6b
RIP: 0033:0x7fc67492c559
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fc6748ab228 EFLAGS: 00000246 ORIG_RAX: 000000000000002f
RAX: ffffffffffffffda RBX: 000000000000001c RCX: 00007fc67492c559
RDX: 0000000040010083 RSI: 0000000020000140 RDI: 0000000000000004
RBP: 00007fc6749b6348 R08: 00007fc6748ab6c0 R09: 00007fc6748ab6c0
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fc6749b6340
R13: 00007fc6749b634c R14: 00007ffe9fac52a0 R15: 00007ffe9fac5388
</TASK>
Allocated by task 5295:
kasan_save_stack+0x33/0x50 mm/kasan/common.c:45
kasan_set_track+0x25/0x30 mm/kasan/common.c:52
__kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:328
kasan_slab_alloc include/linux/kasan.h:188 [inline]
slab_post_alloc_hook mm/slab.h:763 [inline]
slab_alloc_node mm/slub.c:3478 [inline]
kmem_cache_alloc_node+0x180/0x3c0 mm/slub.c:3523
__alloc_skb+0x287/0x330 net/core/skbuff.c:641
alloc_skb include/linux/skbuff.h:1286 [inline]
alloc_skb_with_frags+0xe4/0x710 net/core/skbuff.c:6331
sock_alloc_send_pskb+0x7e4/0x970 net/core/sock.c:2780
sock_alloc_send_skb include/net/sock.h:1884 [inline]
queue_oob net/unix/af_unix.c:2147 [inline]
unix_stream_sendmsg+0xb5f/0x10a0 net/unix/af_unix.c:2301
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0xd5/0x180 net/socket.c:745
____sys_sendmsg+0x6ac/0x940 net/socket.c:2584
___sys_sendmsg+0x135/0x1d0 net/socket.c:2638
__sys_sendmsg+0x117/0x1e0 net/socket.c:2667
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Freed by task 5295:
kasan_save_stack+0x33/0x50 mm/kasan/common.c:45
kasan_set_track+0x25/0x30 mm/kasan/common.c:52
kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:522
____kasan_slab_free mm/kasan/common.c:236 [inline]
____kasan_slab_free+0x15b/0x1b0 mm/kasan/common.c:200
kasan_slab_free include/linux/kasan.h:164 [inline]
slab_free_hook mm/slub.c:1800 [inline]
slab_free_freelist_hook+0x114/0x1e0 mm/slub.c:1826
slab_free mm/slub.c:3809 [inline]
kmem_cache_free+0xf8/0x340 mm/slub.c:3831
kfree_skbmem+0xef/0x1b0 net/core/skbuff.c:1015
__kfree_skb net/core/skbuff.c:1073 [inline]
consume_skb net/core/skbuff.c:1288 [inline]
consume_skb+0xdf/0x170 net/core/skbuff.c:1282
queue_oob net/unix/af_unix.c:2178 [inline]
u
---truncated--- |
["https://git.kernel.org/stable/c/069a3ec329ff43e7869a3d94c62cd03203016bce","https://git.kernel.org/stable/c/4b7b492615cf3017190f55444f7016812b66611d","https://git.kernel.org/stable/c/75bcfc188abf4fae9c1d5f5dc0a03540be602eef","https://git.kernel.org/stable/c/d179189eec426fe4801e4b91efa1889faed12700","https://git.kernel.org/stable/c/eae0b295ce16d8c8b4114c3037993191b4bb92f0","https://git.kernel.org/stable/c/069a3ec329ff43e7869a3d94c62cd03203016bce","https://git.kernel.org/stable/c/4b7b492615cf3017190f55444f7016812b66611d","https://git.kernel.org/stable/c/75bcfc188abf4fae9c1d5f5dc0a03540be602eef","https://git.kernel.org/stable/c/d179189eec426fe4801e4b91efa1889faed12700","https://git.kernel.org/stable/c/eae0b295ce16d8c8b4114c3037993191b4bb92f0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52859
|
High |
fixed |
- 5.15.139
- 6.1.63
- 6.5.12
- 6.6.2
|
In the Linux kernel, the following vulnerability has been resolved:
perf: hisi: Fix use-after-free when register pmu fails
When we fail to register the uncore pmu, the pmu context may not been
allocated. The error handing will call cpuhp_state_remove_instance()
to call uncore pmu offline callback, which migrate the pmu context.
Since that's liable to lead to some kind of use-after-free.
Use cpuhp_state_remove_instance_nocalls() instead of
cpuhp_state_remove_instance() so that the notifiers don't execute after
the PMU device has been failed to register. |
["https://git.kernel.org/stable/c/0e1e88bba286621b886218363de07b319d6208b2","https://git.kernel.org/stable/c/3405f364f82d4f5407a8b4c519dc15d24b847fda","https://git.kernel.org/stable/c/75bab28ffd05ec8879c197890b1bd1dfec8d3f63","https://git.kernel.org/stable/c/b660420f449d094b1fabfa504889810b3a63cdd5","https://git.kernel.org/stable/c/b805cafc604bfdb671fae7347a57f51154afa735","https://git.kernel.org/stable/c/0e1e88bba286621b886218363de07b319d6208b2","https://git.kernel.org/stable/c/3405f364f82d4f5407a8b4c519dc15d24b847fda","https://git.kernel.org/stable/c/75bab28ffd05ec8879c197890b1bd1dfec8d3f63","https://git.kernel.org/stable/c/b660420f449d094b1fabfa504889810b3a63cdd5","https://git.kernel.org/stable/c/b805cafc604bfdb671fae7347a57f51154afa735"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50128
|
High |
fixed |
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
net: wwan: fix global oob in wwan_rtnl_policy
The variable wwan_rtnl_link_ops assign a *bigger* maxtype which leads to
a global out-of-bounds read when parsing the netlink attributes. Exactly
same bug cause as the oob fixed in commit b33fb5b801c6 ("net: qualcomm:
rmnet: fix global oob in rmnet_policy").
==================================================================
BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:388 [inline]
BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603
Read of size 1 at addr ffffffff8b09cb60 by task syz.1.66276/323862
CPU: 0 PID: 323862 Comm: syz.1.66276 Not tainted 6.1.70 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x177/0x231 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:284 [inline]
print_report+0x14f/0x750 mm/kasan/report.c:395
kasan_report+0x139/0x170 mm/kasan/report.c:495
validate_nla lib/nlattr.c:388 [inline]
__nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603
__nla_parse+0x3c/0x50 lib/nlattr.c:700
nla_parse_nested_deprecated include/net/netlink.h:1269 [inline]
__rtnl_newlink net/core/rtnetlink.c:3514 [inline]
rtnl_newlink+0x7bc/0x1fd0 net/core/rtnetlink.c:3623
rtnetlink_rcv_msg+0x794/0xef0 net/core/rtnetlink.c:6122
netlink_rcv_skb+0x1de/0x420 net/netlink/af_netlink.c:2508
netlink_unicast_kernel net/netlink/af_netlink.c:1326 [inline]
netlink_unicast+0x74b/0x8c0 net/netlink/af_netlink.c:1352
netlink_sendmsg+0x882/0xb90 net/netlink/af_netlink.c:1874
sock_sendmsg_nosec net/socket.c:716 [inline]
__sock_sendmsg net/socket.c:728 [inline]
____sys_sendmsg+0x5cc/0x8f0 net/socket.c:2499
___sys_sendmsg+0x21c/0x290 net/socket.c:2553
__sys_sendmsg net/socket.c:2582 [inline]
__do_sys_sendmsg net/socket.c:2591 [inline]
__se_sys_sendmsg+0x19e/0x270 net/socket.c:2589
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x45/0x90 arch/x86/entry/common.c:81
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f67b19a24ad
RSP: 002b:00007f67b17febb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f67b1b45f80 RCX: 00007f67b19a24ad
RDX: 0000000000000000 RSI: 0000000020005e40 RDI: 0000000000000004
RBP: 00007f67b1a1e01d R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffd2513764f R14: 00007ffd251376e0 R15: 00007f67b17fed40
</TASK>
The buggy address belongs to the variable:
wwan_rtnl_policy+0x20/0x40
The buggy address belongs to the physical page:
page:ffffea00002c2700 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xb09c
flags: 0xfff00000001000(reserved|node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000001000 ffffea00002c2708 ffffea00002c2708 0000000000000000
raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner info is not present (never set?)
Memory state around the buggy address:
ffffffff8b09ca00: 05 f9 f9 f9 05 f9 f9 f9 00 01 f9 f9 00 01 f9 f9
ffffffff8b09ca80: 00 00 00 05 f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9
>ffffffff8b09cb00: 00 00 00 00 05 f9 f9 f9 00 00 00 00 f9 f9 f9 f9
^
ffffffff8b09cb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================
According to the comment of `nla_parse_nested_deprecated`, use correct size
`IFLA_WWAN_MAX` here to fix this issue. |
["https://git.kernel.org/stable/c/47dd5447cab8ce30a847a0337d5341ae4c7476a7","https://git.kernel.org/stable/c/69076f8435c1c5dae5f814eaf4c361d1f00b22a3","https://git.kernel.org/stable/c/9683804e36668f6093fb06e202eed2f188ba437e","https://git.kernel.org/stable/c/a3ffce63dcc0c208edd4d196e17baed22ebcb643","https://git.kernel.org/stable/c/c9a0aed51977198df005d0a623090e38e2d77d7b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43884
|
Medium |
|
N/A
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: Add error handling to pair_device()
hci_conn_params_add() never checks for a NULL value and could lead to a NULL
pointer dereference causing a crash.
Fixed by adding error handling in the function. |
["https://git.kernel.org/stable/c/064dd929c76532359d2905d90a7c12348043cfd4","https://git.kernel.org/stable/c/11b4b0e63f2621b33b2e107407a7d67a65994ca1","https://git.kernel.org/stable/c/538fd3921afac97158d4177139a0ad39f056dbb2","https://git.kernel.org/stable/c/5da2884292329bc9be32a7778e0e119f06abe503","https://git.kernel.org/stable/c/90e1ff1c15e5a8f3023ca8266e3a85869ed03ee9","https://git.kernel.org/stable/c/951d6cb5eaac5130d076c728f2a6db420621afdb","https://git.kernel.org/stable/c/9df9783bd85610d3d6e126a1aca221531f6f6dcb","https://git.kernel.org/stable/c/ee0799103b1ae4bcfd80dc11a15df085f6ee1b61"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41002
|
Medium |
fixed |
- 5.15.162
- 6.1.96
- 6.6.36
- 6.9.7
|
In the Linux kernel, the following vulnerability has been resolved:
crypto: hisilicon/sec - Fix memory leak for sec resource release
The AIV is one of the SEC resources. When releasing resources,
it need to release the AIV resources at the same time.
Otherwise, memory leakage occurs.
The aiv resource release is added to the sec resource release
function. |
["https://git.kernel.org/stable/c/36810d2db3496bb8b4db7ccda666674a5efc7b47","https://git.kernel.org/stable/c/7c42ce556ff65995c8875c9ed64141c14238e7e6","https://git.kernel.org/stable/c/9f21886370db451b0fdc651f6e41550a1da70601","https://git.kernel.org/stable/c/a886bcb0f67d1e3d6b2da25b3519de59098200c2","https://git.kernel.org/stable/c/bba4250757b4ae1680fea435a358d8093f254094","https://git.kernel.org/stable/c/36810d2db3496bb8b4db7ccda666674a5efc7b47","https://git.kernel.org/stable/c/7c42ce556ff65995c8875c9ed64141c14238e7e6","https://git.kernel.org/stable/c/9f21886370db451b0fdc651f6e41550a1da70601","https://git.kernel.org/stable/c/a886bcb0f67d1e3d6b2da25b3519de59098200c2","https://git.kernel.org/stable/c/bba4250757b4ae1680fea435a358d8093f254094"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39463
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
9p: add missing locking around taking dentry fid list
Fix a use-after-free on dentry's d_fsdata fid list when a thread
looks up a fid through dentry while another thread unlinks it:
UAF thread:
refcount_t: addition on 0; use-after-free.
p9_fid_get linux/./include/net/9p/client.h:262
v9fs_fid_find+0x236/0x280 linux/fs/9p/fid.c:129
v9fs_fid_lookup_with_uid linux/fs/9p/fid.c:181
v9fs_fid_lookup+0xbf/0xc20 linux/fs/9p/fid.c:314
v9fs_vfs_getattr_dotl+0xf9/0x360 linux/fs/9p/vfs_inode_dotl.c:400
vfs_statx+0xdd/0x4d0 linux/fs/stat.c:248
Freed by:
p9_fid_destroy (inlined)
p9_client_clunk+0xb0/0xe0 linux/net/9p/client.c:1456
p9_fid_put linux/./include/net/9p/client.h:278
v9fs_dentry_release+0xb5/0x140 linux/fs/9p/vfs_dentry.c:55
v9fs_remove+0x38f/0x620 linux/fs/9p/vfs_inode.c:518
vfs_unlink+0x29a/0x810 linux/fs/namei.c:4335
The problem is that d_fsdata was not accessed under d_lock, because
d_release() normally is only called once the dentry is otherwise no
longer accessible but since we also call it explicitly in v9fs_remove
that lock is required:
move the hlist out of the dentry under lock then unref its fids once
they are no longer accessible. |
["https://git.kernel.org/stable/c/3bb6763a8319170c2d41c4232c8e7e4c37dcacfb","https://git.kernel.org/stable/c/c898afdc15645efb555acb6d85b484eb40a45409","https://git.kernel.org/stable/c/cb299cdba09f46f090b843d78ba26b667d50a456","https://git.kernel.org/stable/c/f0c5c944c6d8614c19e6e9a97fd2011dcd30e8f5","https://git.kernel.org/stable/c/fe17ebf22feb4ad7094d597526d558a49aac92b4","https://www.zerodayinitiative.com/advisories/ZDI-24-1194/","https://git.kernel.org/stable/c/c898afdc15645efb555acb6d85b484eb40a45409","https://git.kernel.org/stable/c/cb299cdba09f46f090b843d78ba26b667d50a456","https://git.kernel.org/stable/c/f0c5c944c6d8614c19e6e9a97fd2011dcd30e8f5","https://git.kernel.org/stable/c/fe17ebf22feb4ad7094d597526d558a49aac92b4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26765
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Disable IRQ before init_fn() for nonboot CPUs
Disable IRQ before init_fn() for nonboot CPUs when hotplug, in order to
silence such warnings (and also avoid potential errors due to unexpected
interrupts):
WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:4503 rcu_cpu_starting+0x214/0x280
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198
pc 90000000048e3334 ra 90000000047bd56c tp 900000010039c000 sp 900000010039fdd0
a0 0000000000000001 a1 0000000000000006 a2 900000000802c040 a3 0000000000000000
a4 0000000000000001 a5 0000000000000004 a6 0000000000000000 a7 90000000048e3f4c
t0 0000000000000001 t1 9000000005c70968 t2 0000000004000000 t3 000000000005e56e
t4 00000000000002e4 t5 0000000000001000 t6 ffffffff80000000 t7 0000000000040000
t8 9000000007931638 u0 0000000000000006 s9 0000000000000004 s0 0000000000000001
s1 9000000006356ac0 s2 9000000007244000 s3 0000000000000001 s4 0000000000000001
s5 900000000636f000 s6 7fffffffffffffff s7 9000000002123940 s8 9000000001ca55f8
ra: 90000000047bd56c tlb_init+0x24c/0x528
ERA: 90000000048e3334 rcu_cpu_starting+0x214/0x280
CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
PRMD: 00000000 (PPLV0 -PIE -PWE)
EUEN: 00000000 (-FPE -SXE -ASXE -BTE)
ECFG: 00071000 (LIE=12 VS=7)
ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0)
PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198
Stack : 0000000000000000 9000000006375000 9000000005b61878 900000010039c000
900000010039fa30 0000000000000000 900000010039fa38 900000000619a140
9000000006456888 9000000006456880 900000010039f950 0000000000000001
0000000000000001 cb0cb028ec7e52e1 0000000002b90000 9000000100348700
0000000000000000 0000000000000001 ffffffff916d12f1 0000000000000003
0000000000040000 9000000007930370 0000000002b90000 0000000000000004
9000000006366000 900000000619a140 0000000000000000 0000000000000004
0000000000000000 0000000000000009 ffffffffffc681f2 9000000002123940
9000000001ca55f8 9000000006366000 90000000047a4828 00007ffff057ded8
00000000000000b0 0000000000000000 0000000000000000 0000000000071000
...
Call Trace:
[<90000000047a4828>] show_stack+0x48/0x1a0
[<9000000005b61874>] dump_stack_lvl+0x84/0xcc
[<90000000047f60ac>] __warn+0x8c/0x1e0
[<9000000005b0ab34>] report_bug+0x1b4/0x280
[<9000000005b63110>] do_bp+0x2d0/0x480
[<90000000047a2e20>] handle_bp+0x120/0x1c0
[<90000000048e3334>] rcu_cpu_starting+0x214/0x280
[<90000000047bd568>] tlb_init+0x248/0x528
[<90000000047a4c44>] per_cpu_trap_init+0x124/0x160
[<90000000047a19f4>] cpu_probe+0x494/0xa00
[<90000000047b551c>] start_secondary+0x3c/0xc0
[<9000000005b66134>] smpboot_entry+0x50/0x58 |
["https://git.kernel.org/stable/c/1001db6c42e4012b55e5ee19405490f23e033b5a","https://git.kernel.org/stable/c/8bf2ca8c60712af288b88ba80f8e4df4573d923f","https://git.kernel.org/stable/c/a262b78dd085dbe9b3c75dc1d9c4cd102b110b53","https://git.kernel.org/stable/c/dffdf7c783ef291eef38a5a0037584fd1a7fa464","https://git.kernel.org/stable/c/1001db6c42e4012b55e5ee19405490f23e033b5a","https://git.kernel.org/stable/c/8bf2ca8c60712af288b88ba80f8e4df4573d923f","https://git.kernel.org/stable/c/a262b78dd085dbe9b3c75dc1d9c4cd102b110b53","https://git.kernel.org/stable/c/dffdf7c783ef291eef38a5a0037584fd1a7fa464"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26770
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
HID: nvidia-shield: Add missing null pointer checks to LED initialization
devm_kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
[jkosina@suse.com: tweak changelog a bit] |
["https://git.kernel.org/stable/c/83527a13740f57b45f162e3af4c7db4b88521100","https://git.kernel.org/stable/c/b6eda11c44dc89a681e1c105f0f4660e69b1e183","https://git.kernel.org/stable/c/e71cc4a1e584293deafff1a7dea614b0210d0443","https://git.kernel.org/stable/c/83527a13740f57b45f162e3af4c7db4b88521100","https://git.kernel.org/stable/c/b6eda11c44dc89a681e1c105f0f4660e69b1e183","https://git.kernel.org/stable/c/e71cc4a1e584293deafff1a7dea614b0210d0443"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26989
|
High |
fixed |
- 5.15.157
- 6.1.88
- 6.6.29
- 6.8.8
|
In the Linux kernel, the following vulnerability has been resolved:
arm64: hibernate: Fix level3 translation fault in swsusp_save()
On arm64 machines, swsusp_save() faults if it attempts to access
MEMBLOCK_NOMAP memory ranges. This can be reproduced in QEMU using UEFI
when booting with rodata=off debug_pagealloc=off and CONFIG_KFENCE=n:
Unable to handle kernel paging request at virtual address ffffff8000000000
Mem abort info:
ESR = 0x0000000096000007
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x07: level 3 translation fault
Data abort info:
ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
swapper pgtable: 4k pages, 39-bit VAs, pgdp=00000000eeb0b000
[ffffff8000000000] pgd=180000217fff9803, p4d=180000217fff9803, pud=180000217fff9803, pmd=180000217fff8803, pte=0000000000000000
Internal error: Oops: 0000000096000007 [#1] SMP
Internal error: Oops: 0000000096000007 [#1] SMP
Modules linked in: xt_multiport ipt_REJECT nf_reject_ipv4 xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter bpfilter rfkill at803x snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg dwmac_generic stmmac_platform snd_hda_codec stmmac joydev pcs_xpcs snd_hda_core phylink ppdev lp parport ramoops reed_solomon ip_tables x_tables nls_iso8859_1 vfat multipath linear amdgpu amdxcp drm_exec gpu_sched drm_buddy hid_generic usbhid hid radeon video drm_suballoc_helper drm_ttm_helper ttm i2c_algo_bit drm_display_helper cec drm_kms_helper drm
CPU: 0 PID: 3663 Comm: systemd-sleep Not tainted 6.6.2+ #76
Source Version: 4e22ed63a0a48e7a7cff9b98b7806d8d4add7dc0
Hardware name: Greatwall GW-XXXXXX-XXX/GW-XXXXXX-XXX, BIOS KunLun BIOS V4.0 01/19/2021
pstate: 600003c5 (nZCv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : swsusp_save+0x280/0x538
lr : swsusp_save+0x280/0x538
sp : ffffffa034a3fa40
x29: ffffffa034a3fa40 x28: ffffff8000001000 x27: 0000000000000000
x26: ffffff8001400000 x25: ffffffc08113e248 x24: 0000000000000000
x23: 0000000000080000 x22: ffffffc08113e280 x21: 00000000000c69f2
x20: ffffff8000000000 x19: ffffffc081ae2500 x18: 0000000000000000
x17: 6666662074736420 x16: 3030303030303030 x15: 3038666666666666
x14: 0000000000000b69 x13: ffffff9f89088530 x12: 00000000ffffffea
x11: 00000000ffff7fff x10: 00000000ffff7fff x9 : ffffffc08193f0d0
x8 : 00000000000bffe8 x7 : c0000000ffff7fff x6 : 0000000000000001
x5 : ffffffa0fff09dc8 x4 : 0000000000000000 x3 : 0000000000000027
x2 : 0000000000000000 x1 : 0000000000000000 x0 : 000000000000004e
Call trace:
swsusp_save+0x280/0x538
swsusp_arch_suspend+0x148/0x190
hibernation_snapshot+0x240/0x39c
hibernate+0xc4/0x378
state_store+0xf0/0x10c
kobj_attr_store+0x14/0x24
The reason is swsusp_save() -> copy_data_pages() -> page_is_saveable()
-> kernel_page_present() assuming that a page is always present when
can_set_direct_map() is false (all of rodata_full,
debug_pagealloc_enabled() and arm64_kfence_can_set_direct_map() false),
irrespective of the MEMBLOCK_NOMAP ranges. Such MEMBLOCK_NOMAP regions
should not be saved during hibernation.
This problem was introduced by changes to the pfn_valid() logic in
commit a7d9f306ba70 ("arm64: drop pfn_valid_within() and simplify
pfn_valid()").
Similar to other architectures, drop the !can_set_direct_map() check in
kernel_page_present() so that page_is_savable() skips such pages.
[catalin.marinas@arm.com: rework commit message] |
["https://git.kernel.org/stable/c/022b19ebc31cce369c407617041a3db810db23b3","https://git.kernel.org/stable/c/31f815cb436082e72d34ed2e8a182140a73ebdf4","https://git.kernel.org/stable/c/50449ca66cc5a8cbc64749cf4b9f3d3fc5f4b457","https://git.kernel.org/stable/c/813f5213f2c612dc800054859aaa396ec8ad7069","https://git.kernel.org/stable/c/f7e71a7cf399f53ff9fc314ca3836dc913b05bd6","https://git.kernel.org/stable/c/022b19ebc31cce369c407617041a3db810db23b3","https://git.kernel.org/stable/c/31f815cb436082e72d34ed2e8a182140a73ebdf4","https://git.kernel.org/stable/c/50449ca66cc5a8cbc64749cf4b9f3d3fc5f4b457","https://git.kernel.org/stable/c/813f5213f2c612dc800054859aaa396ec8ad7069","https://git.kernel.org/stable/c/f7e71a7cf399f53ff9fc314ca3836dc913b05bd6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3649
|
High |
fixed |
- 4.9.331
- 4.14.296
- 4.19.262
- 5.4.220
- 5.10.148
- 5.15.74
- 5.19.16
- 6.0.2
|
A vulnerability was found in Linux Kernel. It has been classified as problematic. Affected is the function nilfs_new_inode of the file fs/nilfs2/inode.c of the component BPF. The manipulation leads to use after free. It is possible to launch the attack remotely. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211992. |
["https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d325dc6eb763c10f591c239550b8c7e5466a5d09","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://security.netapp.com/advisory/ntap-20230214-0009/","https://vuldb.com/?id.211992","https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d325dc6eb763c10f591c239550b8c7e5466a5d09","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://security.netapp.com/advisory/ntap-20230214-0009/","https://vuldb.com/?id.211992"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43819
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
kvm: s390: Reject memory region operations for ucontrol VMs
This change rejects the KVM_SET_USER_MEMORY_REGION and
KVM_SET_USER_MEMORY_REGION2 ioctls when called on a ucontrol VM.
This is necessary since ucontrol VMs have kvm->arch.gmap set to 0 and
would thus result in a null pointer dereference further in.
Memory management needs to be performed in userspace and using the
ioctls KVM_S390_UCAS_MAP and KVM_S390_UCAS_UNMAP.
Also improve s390 specific documentation for KVM_SET_USER_MEMORY_REGION
and KVM_SET_USER_MEMORY_REGION2.
[frankja@linux.ibm.com: commit message spelling fix, subject prefix fix] |
["https://git.kernel.org/stable/c/49c9945c054df4c22008e2bf87ca74d3e2507aa6","https://git.kernel.org/stable/c/7816e58967d0e6cadce05c8540b47ed027dc2499"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40970
|
Medium |
fixed |
- 5.15.162
- 6.1.96
- 6.6.36
- 6.9.7
|
In the Linux kernel, the following vulnerability has been resolved:
Avoid hw_desc array overrun in dw-axi-dmac
I have a use case where nr_buffers = 3 and in which each descriptor is composed by 3
segments, resulting in the DMA channel descs_allocated to be 9. Since axi_desc_put()
handles the hw_desc considering the descs_allocated, this scenario would result in a
kernel panic (hw_desc array will be overrun).
To fix this, the proposal is to add a new member to the axi_dma_desc structure,
where we keep the number of allocated hw_descs (axi_desc_alloc()) and use it in
axi_desc_put() to handle the hw_desc array correctly.
Additionally I propose to remove the axi_chan_start_first_queued() call after completing
the transfer, since it was identified that unbalance can occur (started descriptors can
be interrupted and transfer ignored due to DMA channel not being enabled). |
["https://git.kernel.org/stable/c/333e11bf47fa8d477db90e2900b1ed3c9ae9b697","https://git.kernel.org/stable/c/7c3bb96a20cd8db3b8824b2ff08b6cde4505c7e5","https://git.kernel.org/stable/c/9004784e8d68bcd1ac1376407ba296fa28f04dbe","https://git.kernel.org/stable/c/dd42570018f5962c10f215ad9c21274ed5d3541e","https://git.kernel.org/stable/c/e151ae1ee065cf4b8ce4394ddb9d9c8df6370c66","https://git.kernel.org/stable/c/333e11bf47fa8d477db90e2900b1ed3c9ae9b697","https://git.kernel.org/stable/c/7c3bb96a20cd8db3b8824b2ff08b6cde4505c7e5","https://git.kernel.org/stable/c/9004784e8d68bcd1ac1376407ba296fa28f04dbe","https://git.kernel.org/stable/c/dd42570018f5962c10f215ad9c21274ed5d3541e","https://git.kernel.org/stable/c/e151ae1ee065cf4b8ce4394ddb9d9c8df6370c66"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-4095
|
Medium |
|
N/A
|
A NULL pointer dereference was found in the Linux kernel's KVM when dirty ring logging is enabled without an active vCPU context. An unprivileged local attacker on the host may use this flaw to cause a kernel oops condition and thus a denial of service by issuing a KVM_XEN_HVM_SET_ATTR ioctl. This flaw affects Linux kernel versions prior to 5.17-rc1. |
["http://www.openwall.com/lists/oss-security/2022/01/17/1","https://bugzilla.redhat.com/show_bug.cgi?id=2031194","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/QIOQN7JJNN6ABIDGRSTVZA65MHRLMH2Q/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VT6573CGKVK3DU2632VVO5BVM4IU7SBV/","http://www.openwall.com/lists/oss-security/2022/01/17/1","https://bugzilla.redhat.com/show_bug.cgi?id=2031194","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/QIOQN7JJNN6ABIDGRSTVZA65MHRLMH2Q/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VT6573CGKVK3DU2632VVO5BVM4IU7SBV/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35849
|
High |
fixed |
- 4.19.313
- 5.4.275
- 5.10.216
- 5.15.158
- 6.1.90
- 6.6.30
- 6.8.9
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix information leak in btrfs_ioctl_logical_to_ino()
Syzbot reported the following information leak for in
btrfs_ioctl_logical_to_ino():
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
_copy_to_user+0xbc/0x110 lib/usercopy.c:40
copy_to_user include/linux/uaccess.h:191 [inline]
btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499
btrfs_ioctl+0x714/0x1260
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:904 [inline]
__se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
__x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at:
__kmalloc_large_node+0x231/0x370 mm/slub.c:3921
__do_kmalloc_node mm/slub.c:3954 [inline]
__kmalloc_node+0xb07/0x1060 mm/slub.c:3973
kmalloc_node include/linux/slab.h:648 [inline]
kvmalloc_node+0xc0/0x2d0 mm/util.c:634
kvmalloc include/linux/slab.h:766 [inline]
init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779
btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480
btrfs_ioctl+0x714/0x1260
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:904 [inline]
__se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
__x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Bytes 40-65535 of 65536 are uninitialized
Memory access of size 65536 starts at ffff888045a40000
This happens, because we're copying a 'struct btrfs_data_container' back
to user-space. This btrfs_data_container is allocated in
'init_data_container()' via kvmalloc(), which does not zero-fill the
memory.
Fix this by using kvzalloc() which zeroes out the memory on allocation. |
["https://git.kernel.org/stable/c/2f7ef5bb4a2f3e481ef05fab946edb97c84f67cf","https://git.kernel.org/stable/c/30189e54ba80e3209d34cfeea87b848f6ae025e6","https://git.kernel.org/stable/c/3a63cee1a5e14a3e52c19142c61dd5fcb524f6dc","https://git.kernel.org/stable/c/689efe22e9b5b7d9d523119a9a5c3c17107a0772","https://git.kernel.org/stable/c/73db209dcd4ae026021234d40cfcb2fb5b564b86","https://git.kernel.org/stable/c/8bdbcfaf3eac42f98e5486b3d7e130fa287811f6","https://git.kernel.org/stable/c/e58047553a4e859dafc8d1d901e1de77c9dd922d","https://git.kernel.org/stable/c/fddc19631c51d9c17d43e9f822a7bc403af88d54","https://git.kernel.org/stable/c/2f7ef5bb4a2f3e481ef05fab946edb97c84f67cf","https://git.kernel.org/stable/c/30189e54ba80e3209d34cfeea87b848f6ae025e6","https://git.kernel.org/stable/c/3a63cee1a5e14a3e52c19142c61dd5fcb524f6dc","https://git.kernel.org/stable/c/689efe22e9b5b7d9d523119a9a5c3c17107a0772","https://git.kernel.org/stable/c/73db209dcd4ae026021234d40cfcb2fb5b564b86","https://git.kernel.org/stable/c/8bdbcfaf3eac42f98e5486b3d7e130fa287811f6","https://git.kernel.org/stable/c/e58047553a4e859dafc8d1d901e1de77c9dd922d","https://git.kernel.org/stable/c/fddc19631c51d9c17d43e9f822a7bc403af88d54","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52741
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix use-after-free in rdata->read_into_pages()
When the network status is unstable, use-after-free may occur when
read data from the server.
BUG: KASAN: use-after-free in readpages_fill_pages+0x14c/0x7e0
Call Trace:
<TASK>
dump_stack_lvl+0x38/0x4c
print_report+0x16f/0x4a6
kasan_report+0xb7/0x130
readpages_fill_pages+0x14c/0x7e0
cifs_readv_receive+0x46d/0xa40
cifs_demultiplex_thread+0x121c/0x1490
kthread+0x16b/0x1a0
ret_from_fork+0x2c/0x50
</TASK>
Allocated by task 2535:
kasan_save_stack+0x22/0x50
kasan_set_track+0x25/0x30
__kasan_kmalloc+0x82/0x90
cifs_readdata_direct_alloc+0x2c/0x110
cifs_readdata_alloc+0x2d/0x60
cifs_readahead+0x393/0xfe0
read_pages+0x12f/0x470
page_cache_ra_unbounded+0x1b1/0x240
filemap_get_pages+0x1c8/0x9a0
filemap_read+0x1c0/0x540
cifs_strict_readv+0x21b/0x240
vfs_read+0x395/0x4b0
ksys_read+0xb8/0x150
do_syscall_64+0x3f/0x90
entry_SYSCALL_64_after_hwframe+0x72/0xdc
Freed by task 79:
kasan_save_stack+0x22/0x50
kasan_set_track+0x25/0x30
kasan_save_free_info+0x2e/0x50
__kasan_slab_free+0x10e/0x1a0
__kmem_cache_free+0x7a/0x1a0
cifs_readdata_release+0x49/0x60
process_one_work+0x46c/0x760
worker_thread+0x2a4/0x6f0
kthread+0x16b/0x1a0
ret_from_fork+0x2c/0x50
Last potentially related work creation:
kasan_save_stack+0x22/0x50
__kasan_record_aux_stack+0x95/0xb0
insert_work+0x2b/0x130
__queue_work+0x1fe/0x660
queue_work_on+0x4b/0x60
smb2_readv_callback+0x396/0x800
cifs_abort_connection+0x474/0x6a0
cifs_reconnect+0x5cb/0xa50
cifs_readv_from_socket.cold+0x22/0x6c
cifs_read_page_from_socket+0xc1/0x100
readpages_fill_pages.cold+0x2f/0x46
cifs_readv_receive+0x46d/0xa40
cifs_demultiplex_thread+0x121c/0x1490
kthread+0x16b/0x1a0
ret_from_fork+0x2c/0x50
The following function calls will cause UAF of the rdata pointer.
readpages_fill_pages
cifs_read_page_from_socket
cifs_readv_from_socket
cifs_reconnect
__cifs_reconnect
cifs_abort_connection
mid->callback() --> smb2_readv_callback
queue_work(&rdata->work) # if the worker completes first,
# the rdata is freed
cifs_readv_complete
kref_put
cifs_readdata_release
kfree(rdata)
return rdata->... # UAF in readpages_fill_pages()
Similarly, this problem also occurs in the uncache_fill_pages().
Fix this by adjusts the order of condition judgment in the return
statement. |
["https://git.kernel.org/stable/c/2b693fe3f760c87fd9768e759f6297f743a1b3b0","https://git.kernel.org/stable/c/3684a2f6affa1ca52a5d4a12f04d0652efdee65e","https://git.kernel.org/stable/c/aa5465aeca3c66fecdf7efcf554aed79b4c4b211","https://git.kernel.org/stable/c/d1fba1e096ffc7ec11df863a97c50203c47315b9","https://git.kernel.org/stable/c/2b693fe3f760c87fd9768e759f6297f743a1b3b0","https://git.kernel.org/stable/c/3684a2f6affa1ca52a5d4a12f04d0652efdee65e","https://git.kernel.org/stable/c/aa5465aeca3c66fecdf7efcf554aed79b4c4b211","https://git.kernel.org/stable/c/d1fba1e096ffc7ec11df863a97c50203c47315b9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48858
|
High |
fixed |
- 5.4.185
- 5.10.106
- 5.15.29
- 5.16.15
|
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix a race on command flush flow
Fix a refcount use after free warning due to a race on command entry.
Such race occurs when one of the commands releases its last refcount and
frees its index and entry while another process running command flush
flow takes refcount to this command entry. The process which handles
commands flush may see this command as needed to be flushed if the other
process released its refcount but didn't release the index yet. Fix it
by adding the needed spin lock.
It fixes the following warning trace:
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 11 PID: 540311 at lib/refcount.c:25 refcount_warn_saturate+0x80/0xe0
...
RIP: 0010:refcount_warn_saturate+0x80/0xe0
...
Call Trace:
<TASK>
mlx5_cmd_trigger_completions+0x293/0x340 [mlx5_core]
mlx5_cmd_flush+0x3a/0xf0 [mlx5_core]
enter_error_state+0x44/0x80 [mlx5_core]
mlx5_fw_fatal_reporter_err_work+0x37/0xe0 [mlx5_core]
process_one_work+0x1be/0x390
worker_thread+0x4d/0x3d0
? rescuer_thread+0x350/0x350
kthread+0x141/0x160
? set_kthread_struct+0x40/0x40
ret_from_fork+0x1f/0x30
</TASK> |
["https://git.kernel.org/stable/c/0401bfb27a91d7bdd74b1635c1aae57cbb128da6","https://git.kernel.org/stable/c/063bd355595428750803d8736a9bb7c8db67d42d","https://git.kernel.org/stable/c/1a4017926eeea56c7540cc41b42106746ee8a0ee","https://git.kernel.org/stable/c/7c519f769f555ff7d9d4ccba3497bbb589df360a","https://git.kernel.org/stable/c/f3331bc17449f15832c31823f27573f4c0e13e5f","https://git.kernel.org/stable/c/0401bfb27a91d7bdd74b1635c1aae57cbb128da6","https://git.kernel.org/stable/c/063bd355595428750803d8736a9bb7c8db67d42d","https://git.kernel.org/stable/c/1a4017926eeea56c7540cc41b42106746ee8a0ee","https://git.kernel.org/stable/c/7c519f769f555ff7d9d4ccba3497bbb589df360a","https://git.kernel.org/stable/c/f3331bc17449f15832c31823f27573f4c0e13e5f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27407
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fixed overflow check in mi_enum_attr() |
["https://git.kernel.org/stable/c/1c0a95d99b1b2b5d842e5abc7ef7eed1193b60d7","https://git.kernel.org/stable/c/652cfeb43d6b9aba5c7c4902bed7a7340df131fb","https://git.kernel.org/stable/c/8c77398c72618101d66480b94b34fe9087ee3d08","https://git.kernel.org/stable/c/e99faa97359654b6e4e769246c72cf50a57e05b2","https://git.kernel.org/stable/c/1c0a95d99b1b2b5d842e5abc7ef7eed1193b60d7","https://git.kernel.org/stable/c/652cfeb43d6b9aba5c7c4902bed7a7340df131fb","https://git.kernel.org/stable/c/8c77398c72618101d66480b94b34fe9087ee3d08"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48981
|
High |
fixed |
- 5.4.227
- 5.10.159
- 5.15.83
- 6.0.13
|
In the Linux kernel, the following vulnerability has been resolved:
drm/shmem-helper: Remove errant put in error path
drm_gem_shmem_mmap() doesn't own this reference, resulting in the GEM
object getting prematurely freed leading to a later use-after-free. |
["https://git.kernel.org/stable/c/24013314be6ee4ee456114a671e9fa3461323de8","https://git.kernel.org/stable/c/585a07b820059462e0c93b76c7de2cd946b26b40","https://git.kernel.org/stable/c/586847b98e20ab02212ca5c1fc46680384e68a28","https://git.kernel.org/stable/c/6a4da05acd062ae7774b6b19cef2b7d922902d36","https://git.kernel.org/stable/c/83e3da8bb92fcfa7a1d232cf55f9e6c49bb84942"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49025
|
High |
fixed |
- 5.4.226
- 5.10.158
- 5.15.82
- 6.0.12
|
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix use-after-free when reverting termination table
When having multiple dests with termination tables and second one
or afterwards fails the driver reverts usage of term tables but
doesn't reset the assignment in attr->dests[num_vport_dests].termtbl
which case a use-after-free when releasing the rule.
Fix by resetting the assignment of termtbl to null. |
["https://git.kernel.org/stable/c/0a2d73a77060c3cbdc6e801cd5d979d674cd404b","https://git.kernel.org/stable/c/0d2f9d95d9fbe993f3c4bafb87d59897b0325aff","https://git.kernel.org/stable/c/372eb550faa0757349040fd43f59483cbfdb2c0b","https://git.kernel.org/stable/c/52c795af04441d76f565c4634f893e5b553df2ae","https://git.kernel.org/stable/c/e6d2d26a49c3a9cd46b232975e45236304810904"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26610
|
High |
fixed |
- 5.10.210
- 5.15.149
- 6.1.76
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: fix a memory corruption
iwl_fw_ini_trigger_tlv::data is a pointer to a __le32, which means that
if we copy to iwl_fw_ini_trigger_tlv::data + offset while offset is in
bytes, we'll write past the buffer. |
["https://git.kernel.org/stable/c/05dd9facfb9a1e056752c0901c6e86416037d15a","https://git.kernel.org/stable/c/870171899d75d43e3d14360f3a4850e90a9c289b","https://git.kernel.org/stable/c/99a23462fe1a6f709f0fda3ebbe8b6b193ac75bd","https://git.kernel.org/stable/c/aa2cc9363926991ba74411e3aa0a0ea82c1ffe32","https://git.kernel.org/stable/c/cf4a0d840ecc72fcf16198d5e9c505ab7d5a5e4d","https://git.kernel.org/stable/c/f32a81999d0b8e5ce60afb5f6a3dd7241c17dd67","https://git.kernel.org/stable/c/05dd9facfb9a1e056752c0901c6e86416037d15a","https://git.kernel.org/stable/c/870171899d75d43e3d14360f3a4850e90a9c289b","https://git.kernel.org/stable/c/99a23462fe1a6f709f0fda3ebbe8b6b193ac75bd","https://git.kernel.org/stable/c/aa2cc9363926991ba74411e3aa0a0ea82c1ffe32","https://git.kernel.org/stable/c/cf4a0d840ecc72fcf16198d5e9c505ab7d5a5e4d","https://git.kernel.org/stable/c/f32a81999d0b8e5ce60afb5f6a3dd7241c17dd67","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49017
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
tipc: re-fetch skb cb after tipc_msg_validate
As the call trace shows, the original skb was freed in tipc_msg_validate(),
and dereferencing the old skb cb would cause an use-after-free crash.
BUG: KASAN: use-after-free in tipc_crypto_rcv_complete+0x1835/0x2240 [tipc]
Call Trace:
<IRQ>
tipc_crypto_rcv_complete+0x1835/0x2240 [tipc]
tipc_crypto_rcv+0xd32/0x1ec0 [tipc]
tipc_rcv+0x744/0x1150 [tipc]
...
Allocated by task 47078:
kmem_cache_alloc_node+0x158/0x4d0
__alloc_skb+0x1c1/0x270
tipc_buf_acquire+0x1e/0xe0 [tipc]
tipc_msg_create+0x33/0x1c0 [tipc]
tipc_link_build_proto_msg+0x38a/0x2100 [tipc]
tipc_link_timeout+0x8b8/0xef0 [tipc]
tipc_node_timeout+0x2a1/0x960 [tipc]
call_timer_fn+0x2d/0x1c0
...
Freed by task 47078:
tipc_msg_validate+0x7b/0x440 [tipc]
tipc_crypto_rcv_complete+0x4b5/0x2240 [tipc]
tipc_crypto_rcv+0xd32/0x1ec0 [tipc]
tipc_rcv+0x744/0x1150 [tipc]
This patch fixes it by re-fetching the skb cb from the new allocated skb
after calling tipc_msg_validate(). |
["https://git.kernel.org/stable/c/1daec0815655e110c6f206c5e777a4af8168ff58","https://git.kernel.org/stable/c/3067bc61fcfe3081bf4807ce65560f499e895e77","https://git.kernel.org/stable/c/a1ba595e35aa3afbe417ff0af353afb9f65559c0","https://git.kernel.org/stable/c/e128190adb2edfd5042105b5d1ed4553f295f5ef"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49006
|
High |
fixed |
- 5.4.226
- 5.10.158
- 5.15.82
- 6.0.12
|
In the Linux kernel, the following vulnerability has been resolved:
tracing: Free buffers when a used dynamic event is removed
After 65536 dynamic events have been added and removed, the "type" field
of the event then uses the first type number that is available (not
currently used by other events). A type number is the identifier of the
binary blobs in the tracing ring buffer (known as events) to map them to
logic that can parse the binary blob.
The issue is that if a dynamic event (like a kprobe event) is traced and
is in the ring buffer, and then that event is removed (because it is
dynamic, which means it can be created and destroyed), if another dynamic
event is created that has the same number that new event's logic on
parsing the binary blob will be used.
To show how this can be an issue, the following can crash the kernel:
# cd /sys/kernel/tracing
# for i in `seq 65536`; do
echo 'p:kprobes/foo do_sys_openat2 $arg1:u32' > kprobe_events
# done
For every iteration of the above, the writing to the kprobe_events will
remove the old event and create a new one (with the same format) and
increase the type number to the next available on until the type number
reaches over 65535 which is the max number for the 16 bit type. After it
reaches that number, the logic to allocate a new number simply looks for
the next available number. When an dynamic event is removed, that number
is then available to be reused by the next dynamic event created. That is,
once the above reaches the max number, the number assigned to the event in
that loop will remain the same.
Now that means deleting one dynamic event and created another will reuse
the previous events type number. This is where bad things can happen.
After the above loop finishes, the kprobes/foo event which reads the
do_sys_openat2 function call's first parameter as an integer.
# echo 1 > kprobes/foo/enable
# cat /etc/passwd > /dev/null
# cat trace
cat-2211 [005] .... 2007.849603: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196
cat-2211 [005] .... 2007.849620: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196
cat-2211 [005] .... 2007.849838: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196
cat-2211 [005] .... 2007.849880: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196
# echo 0 > kprobes/foo/enable
Now if we delete the kprobe and create a new one that reads a string:
# echo 'p:kprobes/foo do_sys_openat2 +0($arg2):string' > kprobe_events
And now we can the trace:
# cat trace
sendmail-1942 [002] ..... 530.136320: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930817: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������"
cat-2046 [004] ..... 530.930961: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������"
cat-2046 [004] ..... 530.934278: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������"
cat-2046 [004] ..... 530.934563: foo: (do_sys_openat2+0x0/0x240) arg1="���������������������������������������
---truncated--- |
["https://git.kernel.org/stable/c/1603feac154ff38514e8354e3079a455eb4801e2","https://git.kernel.org/stable/c/417d5ea6e735e5d88ffb6c436cf2938f3f476dd1","https://git.kernel.org/stable/c/4313e5a613049dfc1819a6dfb5f94cf2caff9452","https://git.kernel.org/stable/c/be111ebd8868d4b7c041cb3c6102e1ae27d6dc1d","https://git.kernel.org/stable/c/c52d0c8c4f38f7580cff61c4dfe1034c580cedfd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48892
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
sched/core: Fix use-after-free bug in dup_user_cpus_ptr()
Since commit 07ec77a1d4e8 ("sched: Allow task CPU affinity to be
restricted on asymmetric systems"), the setting and clearing of
user_cpus_ptr are done under pi_lock for arm64 architecture. However,
dup_user_cpus_ptr() accesses user_cpus_ptr without any lock
protection. Since sched_setaffinity() can be invoked from another
process, the process being modified may be undergoing fork() at
the same time. When racing with the clearing of user_cpus_ptr in
__set_cpus_allowed_ptr_locked(), it can lead to user-after-free and
possibly double-free in arm64 kernel.
Commit 8f9ea86fdf99 ("sched: Always preserve the user requested
cpumask") fixes this problem as user_cpus_ptr, once set, will never
be cleared in a task's lifetime. However, this bug was re-introduced
in commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in
do_set_cpus_allowed()") which allows the clearing of user_cpus_ptr in
do_set_cpus_allowed(). This time, it will affect all arches.
Fix this bug by always clearing the user_cpus_ptr of the newly
cloned/forked task before the copying process starts and check the
user_cpus_ptr state of the source task under pi_lock.
Note to stable, this patch won't be applicable to stable releases.
Just copy the new dup_user_cpus_ptr() function over. |
["https://git.kernel.org/stable/c/7b5cc7fd1789ea5dbb942c9f8207b076d365badc","https://git.kernel.org/stable/c/87ca4f9efbd7cc649ff43b87970888f2812945b8","https://git.kernel.org/stable/c/b22faa21b6230d5eccd233e1b7e0026a5002b287"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-53025
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
NFSD: fix use-after-free in nfsd4_ssc_setup_dul()
If signal_pending() returns true, schedule_timeout() will not be executed,
causing the waiting task to remain in the wait queue.
Fixed by adding a call to finish_wait(), which ensures that the waiting
task will always be removed from the wait queue. |
["https://git.kernel.org/stable/c/0a27dcd5343026ac0cb168ee63304255372b7a36","https://git.kernel.org/stable/c/32d5eb95f8f0e362e37c393310b13b9e95404560","https://git.kernel.org/stable/c/6ac4c383c39f8f2f955f868d1ad9365c2363e80b","https://git.kernel.org/stable/c/e6cf91b7b47ff82b624bdfe2fdcde32bb52e71dd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26944
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: zoned: fix use-after-free in do_zone_finish()
Shinichiro reported the following use-after-free triggered by the device
replace operation in fstests btrfs/070.
BTRFS info (device nullb1): scrub: finished on devid 1 with status: 0
==================================================================
BUG: KASAN: slab-use-after-free in do_zone_finish+0x91a/0xb90 [btrfs]
Read of size 8 at addr ffff8881543c8060 by task btrfs-cleaner/3494007
CPU: 0 PID: 3494007 Comm: btrfs-cleaner Tainted: G W 6.8.0-rc5-kts #1
Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020
Call Trace:
<TASK>
dump_stack_lvl+0x5b/0x90
print_report+0xcf/0x670
? __virt_addr_valid+0x200/0x3e0
kasan_report+0xd8/0x110
? do_zone_finish+0x91a/0xb90 [btrfs]
? do_zone_finish+0x91a/0xb90 [btrfs]
do_zone_finish+0x91a/0xb90 [btrfs]
btrfs_delete_unused_bgs+0x5e1/0x1750 [btrfs]
? __pfx_btrfs_delete_unused_bgs+0x10/0x10 [btrfs]
? btrfs_put_root+0x2d/0x220 [btrfs]
? btrfs_clean_one_deleted_snapshot+0x299/0x430 [btrfs]
cleaner_kthread+0x21e/0x380 [btrfs]
? __pfx_cleaner_kthread+0x10/0x10 [btrfs]
kthread+0x2e3/0x3c0
? __pfx_kthread+0x10/0x10
ret_from_fork+0x31/0x70
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1b/0x30
</TASK>
Allocated by task 3493983:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
__kasan_kmalloc+0xaa/0xb0
btrfs_alloc_device+0xb3/0x4e0 [btrfs]
device_list_add.constprop.0+0x993/0x1630 [btrfs]
btrfs_scan_one_device+0x219/0x3d0 [btrfs]
btrfs_control_ioctl+0x26e/0x310 [btrfs]
__x64_sys_ioctl+0x134/0x1b0
do_syscall_64+0x99/0x190
entry_SYSCALL_64_after_hwframe+0x6e/0x76
Freed by task 3494056:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3f/0x60
poison_slab_object+0x102/0x170
__kasan_slab_free+0x32/0x70
kfree+0x11b/0x320
btrfs_rm_dev_replace_free_srcdev+0xca/0x280 [btrfs]
btrfs_dev_replace_finishing+0xd7e/0x14f0 [btrfs]
btrfs_dev_replace_by_ioctl+0x1286/0x25a0 [btrfs]
btrfs_ioctl+0xb27/0x57d0 [btrfs]
__x64_sys_ioctl+0x134/0x1b0
do_syscall_64+0x99/0x190
entry_SYSCALL_64_after_hwframe+0x6e/0x76
The buggy address belongs to the object at ffff8881543c8000
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 96 bytes inside of
freed 1024-byte region [ffff8881543c8000, ffff8881543c8400)
The buggy address belongs to the physical page:
page:00000000fe2c1285 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1543c8
head:00000000fe2c1285 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0x17ffffc0000840(slab|head|node=0|zone=2|lastcpupid=0x1fffff)
page_type: 0xffffffff()
raw: 0017ffffc0000840 ffff888100042dc0 ffffea0019e8f200 dead000000000002
raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8881543c7f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8881543c7f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff8881543c8000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8881543c8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8881543c8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
This UAF happens because we're accessing stale zone information of a
already removed btrfs_device in do_zone_finish().
The sequence of events is as follows:
btrfs_dev_replace_start
btrfs_scrub_dev
btrfs_dev_replace_finishing
btrfs_dev_replace_update_device_in_mapping_tree <-- devices replaced
btrfs_rm_dev_replace_free_srcdev
btrfs_free_device <-- device freed
cleaner_kthread
btrfs_delete_unused_bgs
btrfs_zone_finish
do_zone_finish <-- refers the freed device
The reason for this is that we're using a
---truncated--- |
["https://git.kernel.org/stable/c/1ec17ef59168a1a6f1105f5dc517f783839a5302","https://git.kernel.org/stable/c/34ca809e055eca5cfe63d9c7efbf80b7c21b4e57","https://git.kernel.org/stable/c/1ec17ef59168a1a6f1105f5dc517f783839a5302","https://git.kernel.org/stable/c/34ca809e055eca5cfe63d9c7efbf80b7c21b4e57"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26933
|
High |
fixed |
- 6.1.84
- 6.6.24
- 6.7.12
- 6.8.3
|
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix deadlock in port "disable" sysfs attribute
The show and store callback routines for the "disable" sysfs attribute
file in port.c acquire the device lock for the port's parent hub
device. This can cause problems if another process has locked the hub
to remove it or change its configuration:
Removing the hub or changing its configuration requires the
hub interface to be removed, which requires the port device
to be removed, and device_del() waits until all outstanding
sysfs attribute callbacks for the ports have returned. The
lock can't be released until then.
But the disable_show() or disable_store() routine can't return
until after it has acquired the lock.
The resulting deadlock can be avoided by calling
sysfs_break_active_protection(). This will cause the sysfs core not
to wait for the attribute's callback routine to return, allowing the
removal to proceed. The disadvantage is that after making this call,
there is no guarantee that the hub structure won't be deallocated at
any moment. To prevent this, we have to acquire a reference to it
first by calling hub_get(). |
["https://git.kernel.org/stable/c/4facc9421117ba9d8148c73771b213887fec77f7","https://git.kernel.org/stable/c/73d1589b91f2099e5f6534a8497b7c6b527e064e","https://git.kernel.org/stable/c/9dac54f08198147f5ec0ec52fcf1bc8ac899ac05","https://git.kernel.org/stable/c/f4d1960764d8a70318b02f15203a1be2b2554ca1","https://git.kernel.org/stable/c/f51849833705dea5b4f9b0c8de714dd87bd6c95c","https://git.kernel.org/stable/c/4facc9421117ba9d8148c73771b213887fec77f7","https://git.kernel.org/stable/c/73d1589b91f2099e5f6534a8497b7c6b527e064e","https://git.kernel.org/stable/c/9dac54f08198147f5ec0ec52fcf1bc8ac899ac05","https://git.kernel.org/stable/c/f4d1960764d8a70318b02f15203a1be2b2554ca1","https://git.kernel.org/stable/c/f51849833705dea5b4f9b0c8de714dd87bd6c95c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26736
|
High |
fixed |
- 5.4.270
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
afs: Increase buffer size in afs_update_volume_status()
The max length of volume->vid value is 20 characters.
So increase idbuf[] size up to 24 to avoid overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
[DH: Actually, it's 20 + NUL, so increase it to 24 and use snprintf()] |
["https://git.kernel.org/stable/c/5c27d85a69fa16a08813ba37ddfb4bbc9a1ed6b5","https://git.kernel.org/stable/c/6e6065dd25b661420fac19c34282b6c626fcd35e","https://git.kernel.org/stable/c/6ea38e2aeb72349cad50e38899b0ba6fbcb2af3d","https://git.kernel.org/stable/c/d34a5e57632bb5ff825196ddd9a48ca403626dfa","https://git.kernel.org/stable/c/d9b5e2b7a8196850383c70d099bfd39e81ab6637","https://git.kernel.org/stable/c/e56662160fc24d28cb75ac095cc6415ae1bda43e","https://git.kernel.org/stable/c/e8530b170e464017203e3b8c6c49af6e916aece1","https://git.kernel.org/stable/c/5c27d85a69fa16a08813ba37ddfb4bbc9a1ed6b5","https://git.kernel.org/stable/c/6e6065dd25b661420fac19c34282b6c626fcd35e","https://git.kernel.org/stable/c/6ea38e2aeb72349cad50e38899b0ba6fbcb2af3d","https://git.kernel.org/stable/c/d34a5e57632bb5ff825196ddd9a48ca403626dfa","https://git.kernel.org/stable/c/d9b5e2b7a8196850383c70d099bfd39e81ab6637","https://git.kernel.org/stable/c/e56662160fc24d28cb75ac095cc6415ae1bda43e","https://git.kernel.org/stable/c/e8530b170e464017203e3b8c6c49af6e916aece1","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50244
|
Medium |
fixed |
- 5.15.171
- 6.1.116
- 6.6.60
- 6.11.7
|
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Additional check in ni_clear()
Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to
uninitialized bitmap during replay process. |
["https://git.kernel.org/stable/c/14a23e15a5e8331bb0cf21288723fa530a45b2a4","https://git.kernel.org/stable/c/60fb94ef46c2359dd06cbe30bfc2499f639433df","https://git.kernel.org/stable/c/7a4ace681dbb652aeb40e1b88f9134b880fdeeb5","https://git.kernel.org/stable/c/80824967ec714dda02cd79091aa186bbc16c5cf3","https://git.kernel.org/stable/c/d178944db36b3369b78a08ba520de109b89bf2a9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50067
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
uprobe: avoid out-of-bounds memory access of fetching args
Uprobe needs to fetch args into a percpu buffer, and then copy to ring
buffer to avoid non-atomic context problem.
Sometimes user-space strings, arrays can be very large, but the size of
percpu buffer is only page size. And store_trace_args() won't check
whether these data exceeds a single page or not, caused out-of-bounds
memory access.
It could be reproduced by following steps:
1. build kernel with CONFIG_KASAN enabled
2. save follow program as test.c
```
\#include <stdio.h>
\#include <stdlib.h>
\#include <string.h>
// If string length large than MAX_STRING_SIZE, the fetch_store_strlen()
// will return 0, cause __get_data_size() return shorter size, and
// store_trace_args() will not trigger out-of-bounds access.
// So make string length less than 4096.
\#define STRLEN 4093
void generate_string(char *str, int n)
{
int i;
for (i = 0; i < n; ++i)
{
char c = i % 26 + 'a';
str[i] = c;
}
str[n-1] = '\0';
}
void print_string(char *str)
{
printf("%s\n", str);
}
int main()
{
char tmp[STRLEN];
generate_string(tmp, STRLEN);
print_string(tmp);
return 0;
}
```
3. compile program
`gcc -o test test.c`
4. get the offset of `print_string()`
```
objdump -t test | grep -w print_string
0000000000401199 g F .text 000000000000001b print_string
```
5. configure uprobe with offset 0x1199
```
off=0x1199
cd /sys/kernel/debug/tracing/
echo "p /root/test:${off} arg1=+0(%di):ustring arg2=\$comm arg3=+0(%di):ustring"
> uprobe_events
echo 1 > events/uprobes/enable
echo 1 > tracing_on
```
6. run `test`, and kasan will report error.
==================================================================
BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0
Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18
Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x55/0x70
print_address_description.constprop.0+0x27/0x310
kasan_report+0x10f/0x120
? strncpy_from_user+0x1d6/0x1f0
strncpy_from_user+0x1d6/0x1f0
? rmqueue.constprop.0+0x70d/0x2ad0
process_fetch_insn+0xb26/0x1470
? __pfx_process_fetch_insn+0x10/0x10
? _raw_spin_lock+0x85/0xe0
? __pfx__raw_spin_lock+0x10/0x10
? __pte_offset_map+0x1f/0x2d0
? unwind_next_frame+0xc5f/0x1f80
? arch_stack_walk+0x68/0xf0
? is_bpf_text_address+0x23/0x30
? kernel_text_address.part.0+0xbb/0xd0
? __kernel_text_address+0x66/0xb0
? unwind_get_return_address+0x5e/0xa0
? __pfx_stack_trace_consume_entry+0x10/0x10
? arch_stack_walk+0xa2/0xf0
? _raw_spin_lock_irqsave+0x8b/0xf0
? __pfx__raw_spin_lock_irqsave+0x10/0x10
? depot_alloc_stack+0x4c/0x1f0
? _raw_spin_unlock_irqrestore+0xe/0x30
? stack_depot_save_flags+0x35d/0x4f0
? kasan_save_stack+0x34/0x50
? kasan_save_stack+0x24/0x50
? mutex_lock+0x91/0xe0
? __pfx_mutex_lock+0x10/0x10
prepare_uprobe_buffer.part.0+0x2cd/0x500
uprobe_dispatcher+0x2c3/0x6a0
? __pfx_uprobe_dispatcher+0x10/0x10
? __kasan_slab_alloc+0x4d/0x90
handler_chain+0xdd/0x3e0
handle_swbp+0x26e/0x3d0
? __pfx_handle_swbp+0x10/0x10
? uprobe_pre_sstep_notifier+0x151/0x1b0
irqentry_exit_to_user_mode+0xe2/0x1b0
asm_exc_int3+0x39/0x40
RIP: 0033:0x401199
Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce
RSP: 002b:00007ffdf00576a8 EFLAGS: 00000206
RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2
RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0
RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20
R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040
R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000
</TASK>
This commit enforces the buffer's maxlen less than a page-size to avoid
store_trace_args() out-of-memory access. |
["https://git.kernel.org/stable/c/0dc3ad9ad2188da7f090b3dbe4d2fcd9ae8ae64f","https://git.kernel.org/stable/c/373b9338c9722a368925d83bc622c596896b328e","https://git.kernel.org/stable/c/537ad4a431f6dddbf15d40d19f24bb9ee12b55cb","https://git.kernel.org/stable/c/9e5f93788c9dd4309e75a56860a1ac44a8e117b9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49996
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix buffer overflow when parsing NFS reparse points
ReparseDataLength is sum of the InodeType size and DataBuffer size.
So to get DataBuffer size it is needed to subtract InodeType's size from
ReparseDataLength.
Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer
at position after the end of the buffer because it does not subtract
InodeType size from the length. Fix this problem and correctly subtract
variable len.
Member InodeType is present only when reparse buffer is large enough. Check
for ReparseDataLength before accessing InodeType to prevent another invalid
memory access.
Major and minor rdev values are present also only when reparse buffer is
large enough. Check for reparse buffer size before calling reparse_mkdev(). |
["https://git.kernel.org/stable/c/01cdddde39b065074fd48f07027757783cbf5b7d","https://git.kernel.org/stable/c/73b078e3314d4854fd8286f3ba65c860ddd3a3dd","https://git.kernel.org/stable/c/7b222d6cb87077faf56a687a72af1951cf78c8a9","https://git.kernel.org/stable/c/803b3a39cb096d8718c0aebc03fd19f11c7dc919","https://git.kernel.org/stable/c/c173d47b69f07cd7ca08efb4e458adbd4725d8e9","https://git.kernel.org/stable/c/c6db81c550cea0c73bd72ef55f579991e0e4ba07","https://git.kernel.org/stable/c/e2a8910af01653c1c268984855629d71fb81f404","https://git.kernel.org/stable/c/ec79e6170bcae8a6036a4b6960f5e7e59a785601"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3564
|
High |
fixed |
- 4.9.333
- 4.14.299
- 4.19.265
- 5.4.224
- 5.10.154
- 5.15.78
- 6.0.8
|
A vulnerability classified as critical was found in Linux Kernel. Affected by this vulnerability is the function l2cap_reassemble_sdu of the file net/bluetooth/l2cap_core.c of the component Bluetooth. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211087. |
["https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=89f9f3cb86b1c63badaf392a83dd661d56cc50b1","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://security.netapp.com/advisory/ntap-20221223-0001/","https://vuldb.com/?id.211087","https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=89f9f3cb86b1c63badaf392a83dd661d56cc50b1","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://security.netapp.com/advisory/ntap-20221223-0001/","https://vuldb.com/?id.211087"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36955
|
High |
fixed |
- 5.15.159
- 6.1.91
- 6.6.31
- 6.8.10
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: hda: intel-sdw-acpi: fix usage of device_get_named_child_node()
The documentation for device_get_named_child_node() mentions this
important point:
"
The caller is responsible for calling fwnode_handle_put() on the
returned fwnode pointer.
"
Add fwnode_handle_put() to avoid a leaked reference. |
["https://git.kernel.org/stable/c/722d33c442e66e4aabd3e778958d696ff3a2777e","https://git.kernel.org/stable/c/7db626d2730d3d80fd31638169054b1e507f07bf","https://git.kernel.org/stable/c/7ef6ecf98ce309b1f4e5a25cddd5965d01feea07","https://git.kernel.org/stable/c/bd2d9641a39e6b5244230c4b41c4aca83b54b377","https://git.kernel.org/stable/c/c158cf914713efc3bcdc25680c7156c48c12ef6a","https://git.kernel.org/stable/c/722d33c442e66e4aabd3e778958d696ff3a2777e","https://git.kernel.org/stable/c/7db626d2730d3d80fd31638169054b1e507f07bf","https://git.kernel.org/stable/c/7ef6ecf98ce309b1f4e5a25cddd5965d01feea07","https://git.kernel.org/stable/c/bd2d9641a39e6b5244230c4b41c4aca83b54b377","https://git.kernel.org/stable/c/c158cf914713efc3bcdc25680c7156c48c12ef6a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48666
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Fix a use-after-free
There are two .exit_cmd_priv implementations. Both implementations use
resources associated with the SCSI host. Make sure that these resources are
still available when .exit_cmd_priv is called by waiting inside
scsi_remove_host() until the tag set has been freed.
This commit fixes the following use-after-free:
==================================================================
BUG: KASAN: use-after-free in srp_exit_cmd_priv+0x27/0xd0 [ib_srp]
Read of size 8 at addr ffff888100337000 by task multipathd/16727
Call Trace:
<TASK>
dump_stack_lvl+0x34/0x44
print_report.cold+0x5e/0x5db
kasan_report+0xab/0x120
srp_exit_cmd_priv+0x27/0xd0 [ib_srp]
scsi_mq_exit_request+0x4d/0x70
blk_mq_free_rqs+0x143/0x410
__blk_mq_free_map_and_rqs+0x6e/0x100
blk_mq_free_tag_set+0x2b/0x160
scsi_host_dev_release+0xf3/0x1a0
device_release+0x54/0xe0
kobject_put+0xa5/0x120
device_release+0x54/0xe0
kobject_put+0xa5/0x120
scsi_device_dev_release_usercontext+0x4c1/0x4e0
execute_in_process_context+0x23/0x90
device_release+0x54/0xe0
kobject_put+0xa5/0x120
scsi_disk_release+0x3f/0x50
device_release+0x54/0xe0
kobject_put+0xa5/0x120
disk_release+0x17f/0x1b0
device_release+0x54/0xe0
kobject_put+0xa5/0x120
dm_put_table_device+0xa3/0x160 [dm_mod]
dm_put_device+0xd0/0x140 [dm_mod]
free_priority_group+0xd8/0x110 [dm_multipath]
free_multipath+0x94/0xe0 [dm_multipath]
dm_table_destroy+0xa2/0x1e0 [dm_mod]
__dm_destroy+0x196/0x350 [dm_mod]
dev_remove+0x10c/0x160 [dm_mod]
ctl_ioctl+0x2c2/0x590 [dm_mod]
dm_ctl_ioctl+0x5/0x10 [dm_mod]
__x64_sys_ioctl+0xb4/0xf0
dm_ctl_ioctl+0x5/0x10 [dm_mod]
__x64_sys_ioctl+0xb4/0xf0
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x46/0xb0 |
["https://git.kernel.org/stable/c/2e7eb4c1e8af8385de22775bd0be552f59b28c9a","https://git.kernel.org/stable/c/5ce8fad941233e81f2afb5b52a3fcddd3ba8732f","https://git.kernel.org/stable/c/8fe4ce5836e932f5766317cb651c1ff2a4cd0506","https://git.kernel.org/stable/c/f818708eeeae793e12dc39f8984ed7732048a7d9","https://git.kernel.org/stable/c/2e7eb4c1e8af8385de22775bd0be552f59b28c9a","https://git.kernel.org/stable/c/5ce8fad941233e81f2afb5b52a3fcddd3ba8732f","https://git.kernel.org/stable/c/8fe4ce5836e932f5766317cb651c1ff2a4cd0506","https://git.kernel.org/stable/c/f818708eeeae793e12dc39f8984ed7732048a7d9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-25744
|
High |
fixed |
|
In the Linux kernel before 6.6.7, an untrusted VMM can trigger int80 syscall handling at any given point. This is related to arch/x86/coco/tdx/tdx.c and arch/x86/mm/mem_encrypt_amd.c. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.7","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b82a8dbd3d2f4563156f7150c6f2ecab6e960b30","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.7","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b82a8dbd3d2f4563156f7150c6f2ecab6e960b30","https://security.netapp.com/advisory/ntap-20241115-0006/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36478
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
null_blk: fix null-ptr-dereference while configuring 'power' and 'submit_queues'
Writing 'power' and 'submit_queues' concurrently will trigger kernel
panic:
Test script:
modprobe null_blk nr_devices=0
mkdir -p /sys/kernel/config/nullb/nullb0
while true; do echo 1 > submit_queues; echo 4 > submit_queues; done &
while true; do echo 1 > power; echo 0 > power; done
Test result:
BUG: kernel NULL pointer dereference, address: 0000000000000148
Oops: 0000 [#1] PREEMPT SMP
RIP: 0010:__lock_acquire+0x41d/0x28f0
Call Trace:
<TASK>
lock_acquire+0x121/0x450
down_write+0x5f/0x1d0
simple_recursive_removal+0x12f/0x5c0
blk_mq_debugfs_unregister_hctxs+0x7c/0x100
blk_mq_update_nr_hw_queues+0x4a3/0x720
nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]
nullb_device_submit_queues_store+0x79/0xf0 [null_blk]
configfs_write_iter+0x119/0x1e0
vfs_write+0x326/0x730
ksys_write+0x74/0x150
This is because del_gendisk() can concurrent with
blk_mq_update_nr_hw_queues():
nullb_device_power_store nullb_apply_submit_queues
null_del_dev
del_gendisk
nullb_update_nr_hw_queues
if (!dev->nullb)
// still set while gendisk is deleted
return 0
blk_mq_update_nr_hw_queues
dev->nullb = NULL
Fix this problem by resuing the global mutex to protect
nullb_device_power_store() and nullb_update_nr_hw_queues() from configfs. |
["https://git.kernel.org/stable/c/1d4c8baef435c98e8d5aa7027dc5a9f70834ba16","https://git.kernel.org/stable/c/5d0495473ee4c1d041b5a917f10446a22c047f47","https://git.kernel.org/stable/c/a2db328b0839312c169eb42746ec46fc1ab53ed2","https://git.kernel.org/stable/c/aaadb755f2d684f715a6eb85cb7243aa0c67dfa9","https://git.kernel.org/stable/c/5d0495473ee4c1d041b5a917f10446a22c047f47","https://git.kernel.org/stable/c/a2db328b0839312c169eb42746ec46fc1ab53ed2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48851
|
High |
fixed |
- 4.9.307
- 4.14.272
- 4.19.235
- 5.4.185
- 5.10.106
- 5.15.29
- 5.16.15
|
In the Linux kernel, the following vulnerability has been resolved:
staging: gdm724x: fix use after free in gdm_lte_rx()
The netif_rx_ni() function frees the skb so we can't dereference it to
save the skb->len. |
["https://git.kernel.org/stable/c/1fb9dd3787495b4deb0efe66c58306b65691a48f","https://git.kernel.org/stable/c/403e3afe241b62401de1f8629c9c6b9b3d69dbff","https://git.kernel.org/stable/c/48ecdf3e29a6e514e8196691589c7dfc6c4ac169","https://git.kernel.org/stable/c/6d9700b445098dbbce0caff4b8cfca214cf1e757","https://git.kernel.org/stable/c/6dc7b87c62423bfa68139fe95e85028aab584c9a","https://git.kernel.org/stable/c/83a9c886c2b5a0d28c0b37e1736b47f38d61332a","https://git.kernel.org/stable/c/d39dc79513e99147b4c158a8a9e46743e23944f5","https://git.kernel.org/stable/c/fc7f750dc9d102c1ed7bbe4591f991e770c99033","https://git.kernel.org/stable/c/1fb9dd3787495b4deb0efe66c58306b65691a48f","https://git.kernel.org/stable/c/403e3afe241b62401de1f8629c9c6b9b3d69dbff","https://git.kernel.org/stable/c/48ecdf3e29a6e514e8196691589c7dfc6c4ac169","https://git.kernel.org/stable/c/6d9700b445098dbbce0caff4b8cfca214cf1e757","https://git.kernel.org/stable/c/6dc7b87c62423bfa68139fe95e85028aab584c9a","https://git.kernel.org/stable/c/83a9c886c2b5a0d28c0b37e1736b47f38d61332a","https://git.kernel.org/stable/c/d39dc79513e99147b4c158a8a9e46743e23944f5","https://git.kernel.org/stable/c/fc7f750dc9d102c1ed7bbe4591f991e770c99033"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4206
|
High |
fixed |
- 4.14.322
- 4.19.291
- 5.4.253
- 5.10.190
- 5.15.126
- 6.1.45
- 6.4.10
|
A use-after-free vulnerability in the Linux kernel's net/sched: cls_route component can be exploited to achieve local privilege escalation.
When route4_change() is called on an existing filter, the whole tcf_result struct is always copied into the new instance of the filter. This causes a problem when updating a filter bound to a class, as tcf_unbind_filter() is always called on the old instance in the success path, decreasing filter_cnt of the still referenced class and allowing it to be deleted, leading to a use-after-free.
We recommend upgrading past commit b80b829e9e2c1b3f7aae34855e04d8f6ecaf13c8. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b80b829e9e2c1b3f7aae34855e04d8f6ecaf13c8","https://kernel.dance/b80b829e9e2c1b3f7aae34855e04d8f6ecaf13c8","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.debian.org/security/2023/dsa-5492","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b80b829e9e2c1b3f7aae34855e04d8f6ecaf13c8","https://kernel.dance/b80b829e9e2c1b3f7aae34855e04d8f6ecaf13c8","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.debian.org/security/2023/dsa-5492"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46746
|
High |
fixed |
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
HID: amd_sfh: free driver_data after destroying hid device
HID driver callbacks aren't called anymore once hid_destroy_device() has
been called. Hence, hid driver_data should be freed only after the
hid_destroy_device() function returned as driver_data is used in several
callbacks.
I observed a crash with kernel 6.10.0 on my T14s Gen 3, after enabling
KASAN to debug memory allocation, I got this output:
[ 13.050438] ==================================================================
[ 13.054060] BUG: KASAN: slab-use-after-free in amd_sfh_get_report+0x3ec/0x530 [amd_sfh]
[ 13.054809] psmouse serio1: trackpoint: Synaptics TrackPoint firmware: 0x02, buttons: 3/3
[ 13.056432] Read of size 8 at addr ffff88813152f408 by task (udev-worker)/479
[ 13.060970] CPU: 5 PID: 479 Comm: (udev-worker) Not tainted 6.10.0-arch1-2 #1 893bb55d7f0073f25c46adbb49eb3785fefd74b0
[ 13.063978] Hardware name: LENOVO 21CQCTO1WW/21CQCTO1WW, BIOS R22ET70W (1.40 ) 03/21/2024
[ 13.067860] Call Trace:
[ 13.069383] input: TPPS/2 Synaptics TrackPoint as /devices/platform/i8042/serio1/input/input8
[ 13.071486] <TASK>
[ 13.071492] dump_stack_lvl+0x5d/0x80
[ 13.074870] snd_hda_intel 0000:33:00.6: enabling device (0000 -> 0002)
[ 13.078296] ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]
[ 13.082199] print_report+0x174/0x505
[ 13.085776] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 13.089367] ? srso_alias_return_thunk+0x5/0xfbef5
[ 13.093255] ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]
[ 13.097464] kasan_report+0xc8/0x150
[ 13.101461] ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]
[ 13.105802] amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]
[ 13.110303] amdtp_hid_request+0xb8/0x110 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]
[ 13.114879] ? srso_alias_return_thunk+0x5/0xfbef5
[ 13.119450] sensor_hub_get_feature+0x1d3/0x540 [hid_sensor_hub 3f13be3016ff415bea03008d45d99da837ee3082]
[ 13.124097] hid_sensor_parse_common_attributes+0x4d0/0xad0 [hid_sensor_iio_common c3a5cbe93969c28b122609768bbe23efe52eb8f5]
[ 13.127404] ? srso_alias_return_thunk+0x5/0xfbef5
[ 13.131925] ? __pfx_hid_sensor_parse_common_attributes+0x10/0x10 [hid_sensor_iio_common c3a5cbe93969c28b122609768bbe23efe52eb8f5]
[ 13.136455] ? _raw_spin_lock_irqsave+0x96/0xf0
[ 13.140197] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 13.143602] ? devm_iio_device_alloc+0x34/0x50 [industrialio 3d261d5e5765625d2b052be40e526d62b1d2123b]
[ 13.147234] ? srso_alias_return_thunk+0x5/0xfbef5
[ 13.150446] ? __devm_add_action+0x167/0x1d0
[ 13.155061] hid_gyro_3d_probe+0x120/0x7f0 [hid_sensor_gyro_3d 63da36a143b775846ab2dbb86c343b401b5e3172]
[ 13.158581] ? srso_alias_return_thunk+0x5/0xfbef5
[ 13.161814] platform_probe+0xa2/0x150
[ 13.165029] really_probe+0x1e3/0x8a0
[ 13.168243] __driver_probe_device+0x18c/0x370
[ 13.171500] driver_probe_device+0x4a/0x120
[ 13.175000] __driver_attach+0x190/0x4a0
[ 13.178521] ? __pfx___driver_attach+0x10/0x10
[ 13.181771] bus_for_each_dev+0x106/0x180
[ 13.185033] ? __pfx__raw_spin_lock+0x10/0x10
[ 13.188229] ? __pfx_bus_for_each_dev+0x10/0x10
[ 13.191446] ? srso_alias_return_thunk+0x5/0xfbef5
[ 13.194382] bus_add_driver+0x29e/0x4d0
[ 13.197328] driver_register+0x1a5/0x360
[ 13.200283] ? __pfx_hid_gyro_3d_platform_driver_init+0x10/0x10 [hid_sensor_gyro_3d 63da36a143b775846ab2dbb86c343b401b5e3172]
[ 13.203362] do_one_initcall+0xa7/0x380
[ 13.206432] ? __pfx_do_one_initcall+0x10/0x10
[ 13.210175] ? srso_alias_return_thunk+0x5/0xfbef5
[ 13.213211] ? kasan_unpoison+0x44/0x70
[ 13.216688] do_init_module+0x238/0x750
[ 13.2196
---truncated--- |
["https://git.kernel.org/stable/c/60dc4ee0428d70bcbb41436b6729d29f1cbdfb89","https://git.kernel.org/stable/c/775125c7fe38533aaa4b20769f5b5e62cc1170a0","https://git.kernel.org/stable/c/86b4f5cf91ca03c08e3822ac89476a677a780bcc","https://git.kernel.org/stable/c/97155021ae17b86985121b33cf8098bcde00d497","https://git.kernel.org/stable/c/adb3e3c1ddb5a23b8b7122ef1913f528d728937c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52930
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/i915: Fix potential bit_17 double-free
A userspace with multiple threads racing I915_GEM_SET_TILING to set the
tiling to I915_TILING_NONE could trigger a double free of the bit_17
bitmask. (Or conversely leak memory on the transition to tiled.) Move
allocation/free'ing of the bitmask within the section protected by the
obj lock.
[tursulin: Correct fixes tag and added cc stable.]
(cherry picked from commit 10e0cbaaf1104f449d695c80bcacf930dcd3c42e) |
["https://git.kernel.org/stable/c/0769f997a7b6d5cb8336db0b4ec3d2d311b8097c","https://git.kernel.org/stable/c/7057a8f126f14f14b040faecfa220fd27c6c2f85","https://git.kernel.org/stable/c/b591abac78e25269b12e3d7170c99463f8c5cb02","https://git.kernel.org/stable/c/e3ebc3e23bd9028a8a9a26cbc5985f99be445f65"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49992
|
High |
fixed |
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/stm: Avoid use-after-free issues with crtc and plane
ltdc_load() calls functions drm_crtc_init_with_planes(),
drm_universal_plane_init() and drm_encoder_init(). These functions
should not be called with parameters allocated with devm_kzalloc()
to avoid use-after-free issues [1].
Use allocations managed by the DRM framework.
Found by Linux Verification Center (linuxtesting.org).
[1]
https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/ |
["https://git.kernel.org/stable/c/0a1741d10da29aa84955ef89ae9a03c4b6038657","https://git.kernel.org/stable/c/19dd9780b7ac673be95bf6fd6892a184c9db611f","https://git.kernel.org/stable/c/454e5d7e671946698af0f201e48469e5ddb42851","https://git.kernel.org/stable/c/b22eec4b57d04befa90e8554ede34e6c67257606","https://git.kernel.org/stable/c/d02611ff001454358be6910cb926799e2d818716"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48950
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
perf: Fix perf_pending_task() UaF
Per syzbot it is possible for perf_pending_task() to run after the
event is free()'d. There are two related but distinct cases:
- the task_work was already queued before destroying the event;
- destroying the event itself queues the task_work.
The first cannot be solved using task_work_cancel() since
perf_release() itself might be called from a task_work (____fput),
which means the current->task_works list is already empty and
task_work_cancel() won't be able to find the perf_pending_task()
entry.
The simplest alternative is extending the perf_event lifetime to cover
the task_work.
The second is just silly, queueing a task_work while you know the
event is going away makes no sense and is easily avoided by
re-arranging how the event is marked STATE_DEAD and ensuring it goes
through STATE_OFF on the way down. |
["https://git.kernel.org/stable/c/517e6a301f34613bff24a8e35b5455884f2d83d8","https://git.kernel.org/stable/c/78e1317a174edbfd1182599bf76c092a2877672c","https://git.kernel.org/stable/c/8bffa95ac19ff27c8261904f89d36c7fcf215d59"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53063
|
Medium |
fixed |
- 4.19.324
- 5.4.286
- 5.10.230
- 5.15.172
- 6.1.117
- 6.6.61
- 6.11.8
|
In the Linux kernel, the following vulnerability has been resolved:
media: dvbdev: prevent the risk of out of memory access
The dvbdev contains a static variable used to store dvb minors.
The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set
or not. When not set, dvb_register_device() won't check for
boundaries, as it will rely that a previous call to
dvb_register_adapter() would already be enforcing it.
On a similar way, dvb_device_open() uses the assumption
that the register functions already did the needed checks.
This can be fragile if some device ends using different
calls. This also generate warnings on static check analysers
like Coverity.
So, add explicit guards to prevent potential risk of OOM issues. |
["https://git.kernel.org/stable/c/1e461672616b726f29261ee81bb991528818537c","https://git.kernel.org/stable/c/3b88675e18b6517043a6f734eaa8ea6eb3bfa140","https://git.kernel.org/stable/c/5f76f7df14861e3a560898fa41979ec92424b58f","https://git.kernel.org/stable/c/972e63e895abbe8aa1ccbdbb4e6362abda7cd457","https://git.kernel.org/stable/c/9c17085fabbde2041c893d29599800f2d4992b23","https://git.kernel.org/stable/c/a4a17210c03ade1c8d9a9f193a105654b7a05c11","https://git.kernel.org/stable/c/b751a96025275c17f04083cbfe856822f1658946","https://git.kernel.org/stable/c/fedfde9deb83ac8d2f3d5f36f111023df34b1684"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36016
|
High |
fixed |
- 4.19.316
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
Assuming the following:
- side A configures the n_gsm in basic option mode
- side B sends the header of a basic option mode frame with data length 1
- side A switches to advanced option mode
- side B sends 2 data bytes which exceeds gsm->len
Reason: gsm->len is not used in advanced option mode.
- side A switches to basic option mode
- side B keeps sending until gsm0_receive() writes past gsm->buf
Reason: Neither gsm->state nor gsm->len have been reset after
reconfiguration.
Fix this by changing gsm->count to gsm->len comparison from equal to less
than. Also add upper limit checks against the constant MAX_MRU in
gsm0_receive() and gsm1_receive() to harden against memory corruption of
gsm->len and gsm->mru.
All other checks remain as we still need to limit the data according to the
user configuration and actual payload size. |
["https://git.kernel.org/stable/c/0fb736c9931e02dbc7d9a75044c8e1c039e50f04","https://git.kernel.org/stable/c/46f52c89a7e7d2691b97a9728e4591d071ca8abc","https://git.kernel.org/stable/c/47388e807f85948eefc403a8a5fdc5b406a65d5a","https://git.kernel.org/stable/c/4c267110fc110390704cc065edb9817fdd10ff54","https://git.kernel.org/stable/c/774d83b008eccb1c48c14dc5486e7aa255731350","https://git.kernel.org/stable/c/9513d4148950b05bc99fa7314dc883cc0e1605e5","https://git.kernel.org/stable/c/b229bc6c6ea9fe459fc3fa94fd0a27a2f32aca56","https://git.kernel.org/stable/c/b890d45aaf02b564e6cae2d2a590f9649330857d","https://git.kernel.org/stable/c/f126ce7305fe88f49cdabc6db4168b9318898ea3","https://git.kernel.org/stable/c/0fb736c9931e02dbc7d9a75044c8e1c039e50f04","https://git.kernel.org/stable/c/46f52c89a7e7d2691b97a9728e4591d071ca8abc","https://git.kernel.org/stable/c/47388e807f85948eefc403a8a5fdc5b406a65d5a","https://git.kernel.org/stable/c/4c267110fc110390704cc065edb9817fdd10ff54","https://git.kernel.org/stable/c/774d83b008eccb1c48c14dc5486e7aa255731350","https://git.kernel.org/stable/c/9513d4148950b05bc99fa7314dc883cc0e1605e5","https://git.kernel.org/stable/c/b229bc6c6ea9fe459fc3fa94fd0a27a2f32aca56","https://git.kernel.org/stable/c/b890d45aaf02b564e6cae2d2a590f9649330857d","https://git.kernel.org/stable/c/f126ce7305fe88f49cdabc6db4168b9318898ea3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44983
|
High |
fixed |
- 5.15.166
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: flowtable: validate vlan header
Ensure there is sufficient room to access the protocol field of the
VLAN header, validate it once before the flowtable lookup.
=====================================================
BUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32
nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32
nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626
nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline]
nf_ingress net/core/dev.c:5440 [inline] |
["https://git.kernel.org/stable/c/0279c35d242d037abeb73d60d06a6d1bb7f672d9","https://git.kernel.org/stable/c/043a18bb6cf16adaa2f8642acfde6e8956a9caaa","https://git.kernel.org/stable/c/6ea14ccb60c8ab829349979b22b58a941ec4a3ee","https://git.kernel.org/stable/c/c05155cc455785916164aa5e1b4605a2ae946537","https://git.kernel.org/stable/c/d9384ae7aec46036d248d1c2c2757e471ab486c3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46732
|
Medium |
fixed |
- 5.15.167
- 6.1.109
- 6.6.50
- 6.10.9
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Assign linear_pitch_alignment even for VM
[Description]
Assign linear_pitch_alignment so we don't cause a divide by 0
error in VM environments |
["https://git.kernel.org/stable/c/4bd7710f2fecfc5fb2dda1ca2adc69db8a66b8b6","https://git.kernel.org/stable/c/984debc133efa05e62f5aa1a7a1dd8ca0ef041f4","https://git.kernel.org/stable/c/c44b568931d23aed9d37ecbb31fb5fbdd198bf7b","https://git.kernel.org/stable/c/d219f902b16d42f0cb8c499ea8f31cf3c0f36349","https://git.kernel.org/stable/c/d2fe7ac613a1ea8c346c9f5c89dc6ecc27232997"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40967
|
Medium |
fixed |
- 5.15.162
- 6.1.96
- 6.6.36
- 6.9.7
|
In the Linux kernel, the following vulnerability has been resolved:
serial: imx: Introduce timeout when waiting on transmitter empty
By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential
deadlock.
In case of the timeout, there is not much we can do, so we simply ignore
the transmitter state and optimistically try to continue. |
["https://git.kernel.org/stable/c/53b2c95547427c358f45515a9f144efee95e3701","https://git.kernel.org/stable/c/7f2b9ab6d0b26f16cd38dd9fd91d51899635f7c7","https://git.kernel.org/stable/c/7f9e70c68b7ace0141fe3bc94bf7b61296b71916","https://git.kernel.org/stable/c/982ae3376c4c91590d38dc8a676c10f7df048a44","https://git.kernel.org/stable/c/e533e4c62e9993e62e947ae9bbec34e4c7ae81c2","https://git.kernel.org/stable/c/53b2c95547427c358f45515a9f144efee95e3701","https://git.kernel.org/stable/c/7f2b9ab6d0b26f16cd38dd9fd91d51899635f7c7","https://git.kernel.org/stable/c/7f9e70c68b7ace0141fe3bc94bf7b61296b71916","https://git.kernel.org/stable/c/982ae3376c4c91590d38dc8a676c10f7df048a44","https://git.kernel.org/stable/c/e533e4c62e9993e62e947ae9bbec34e4c7ae81c2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43854
|
Medium |
fixed |
- 5.15.165
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
block: initialize integrity buffer to zero before writing it to media
Metadata added by bio_integrity_prep is using plain kmalloc, which leads
to random kernel memory being written media. For PI metadata this is
limited to the app tag that isn't used by kernel generated metadata,
but for non-PI metadata the entire buffer leaks kernel memory.
Fix this by adding the __GFP_ZERO flag to allocations for writes. |
["https://git.kernel.org/stable/c/129f95948a96105c1fad8e612c9097763e88ac5f","https://git.kernel.org/stable/c/23a19655fb56f241e592041156dfb1c6d04da644","https://git.kernel.org/stable/c/3fd11fe4f20756b4c0847f755a64cd96f8c6a005","https://git.kernel.org/stable/c/899ee2c3829c5ac14bfc7d3c4a5846c0b709b78f","https://git.kernel.org/stable/c/9f4af4cf08f9a0329ade3d938f55d2220c40d0a6","https://git.kernel.org/stable/c/cf6b45ea7a8df0f61bded1dc4a8561ac6ad143d2","https://git.kernel.org/stable/c/d418313bd8f55c079a7da12651951b489a638ac1","https://git.kernel.org/stable/c/ebc0e91ba76dc6544fff9f5b66408b1982806a00"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-45028
|
Medium |
fixed |
- 4.19.321
- 5.4.283
- 5.10.225
- 5.15.166
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
mmc: mmc_test: Fix NULL dereference on allocation failure
If the "test->highmem = alloc_pages()" allocation fails then calling
__free_pages(test->highmem) will result in a NULL dereference. Also
change the error code to -ENOMEM instead of returning success. |
["https://git.kernel.org/stable/c/2b507b03991f44dfb202fc2a82c9874d1b1f0c06","https://git.kernel.org/stable/c/3b4e76ceae5b5a46c968bd952f551ce173809f63","https://git.kernel.org/stable/c/9b9ba386d7bfdbc38445932c90fa9444c0524bea","https://git.kernel.org/stable/c/a1e627af32ed60713941cbfc8075d44cad07f6dd","https://git.kernel.org/stable/c/cac2815f49d343b2f0acc4973d2c14918ac3ab0c","https://git.kernel.org/stable/c/e40515582141a9e7c84b269be699c05236a499a6","https://git.kernel.org/stable/c/e97be13a9f51284da450dd2a592e3fa87b49cdc9","https://git.kernel.org/stable/c/ecb15b8ca12c0cbdab81e307e9795214d8b90890"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46685
|
Medium |
fixed |
- 4.19.321
- 5.4.283
- 5.10.225
- 5.15.166
- 6.1.108
- 6.6.49
- 6.10.8
|
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: single: fix potential NULL dereference in pcs_get_function()
pinmux_generic_get_function() can return NULL and the pointer 'function'
was dereferenced without checking against NULL. Add checking of pointer
'function' in pcs_get_function().
Found by code review. |
["https://git.kernel.org/stable/c/0a2bab5ed161318f57134716accba0a30f3af191","https://git.kernel.org/stable/c/1c38a62f15e595346a1106025722869e87ffe044","https://git.kernel.org/stable/c/292151af6add3e5ab11b2e9916cffa5f52859a1f","https://git.kernel.org/stable/c/2cea369a5c2e85ab14ae716da1d1cc6d25c85e11","https://git.kernel.org/stable/c/4e9436375fcc9bd2a60ee96aba6ed53f7a377d10","https://git.kernel.org/stable/c/4ed45fe99ec9e3c9478bd634624cd05a57d002f7","https://git.kernel.org/stable/c/6341c2856785dca7006820b127278058a180c075","https://git.kernel.org/stable/c/8f0bd526921b6867c2f10a83cd4fd14139adcd92"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49030
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
libbpf: Handle size overflow for ringbuf mmap
The maximum size of ringbuf is 2GB on x86-64 host, so 2 * max_entries
will overflow u32 when mapping producer page and data pages. Only
casting max_entries to size_t is not enough, because for 32-bits
application on 64-bits kernel the size of read-only mmap region
also could overflow size_t.
So fixing it by casting the size of read-only mmap region into a __u64
and checking whether or not there will be overflow during mmap. |
["https://git.kernel.org/stable/c/0140e079a42064680394fff1199a7b5483688dec","https://git.kernel.org/stable/c/535a25ab4f9a45f74ba38ab71de95e97474922ed","https://git.kernel.org/stable/c/8a549ab6724520aa3c07f47e0eba820293551490","https://git.kernel.org/stable/c/927cbb478adf917e0a142b94baa37f06279cc466"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26945
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
crypto: iaa - Fix nr_cpus < nr_iaa case
If nr_cpus < nr_iaa, the calculated cpus_per_iaa will be 0, which
causes a divide-by-0 in rebalance_wq_table().
Make sure cpus_per_iaa is 1 in that case, and also in the nr_iaa == 0
case, even though cpus_per_iaa is never used if nr_iaa == 0, for
paranoia. |
["https://git.kernel.org/stable/c/5a7e89d3315d1be86aff8a8bf849023cda6547f7","https://git.kernel.org/stable/c/a5ca1be7f9817de4e93085778b3ee2219bdc2664","https://git.kernel.org/stable/c/5a7e89d3315d1be86aff8a8bf849023cda6547f7","https://git.kernel.org/stable/c/a5ca1be7f9817de4e93085778b3ee2219bdc2664"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42247
|
Medium |
fixed |
- 5.10.222
- 5.15.163
- 6.1.100
- 6.6.41
- 6.9.10
|
In the Linux kernel, the following vulnerability has been resolved:
wireguard: allowedips: avoid unaligned 64-bit memory accesses
On the parisc platform, the kernel issues kernel warnings because
swap_endian() tries to load a 128-bit IPv6 address from an unaligned
memory location:
Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df)
Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)
Avoid such unaligned memory accesses by instead using the
get_unaligned_be64() helper macro.
[Jason: replace src[8] in original patch with src+8] |
["https://git.kernel.org/stable/c/217978a29c6ceca76d3c640bf94bdf50c268d801","https://git.kernel.org/stable/c/2fb34bf76431e831f9863cd59adc0bd1f67b0fbf","https://git.kernel.org/stable/c/6638a203abad35fa636d59ac47bdbc4bc100fd74","https://git.kernel.org/stable/c/948f991c62a4018fb81d85804eeab3029c6209f8","https://git.kernel.org/stable/c/ae630de24efb123d7199a43256396d7758f4cb75","https://git.kernel.org/stable/c/b4764f0ad3d68de8a0b847c05f427afb86dd54e6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-23307
|
High |
fixed |
- 6.1.84
- 6.6.24
- 6.7.12
- 6.8.3
|
Integer Overflow or Wraparound vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (md, raid, raid5 modules) allows Forced Integer Overflow. |
["https://bugzilla.openanolis.cn/show_bug.cgi?id=7975","https://bugzilla.openanolis.cn/show_bug.cgi?id=7975"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39301
|
Medium |
fixed |
- 4.19.316
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.94
- 6.6.34
- 6.9.5
|
In the Linux kernel, the following vulnerability has been resolved:
net/9p: fix uninit-value in p9_client_rpc()
Syzbot with the help of KMSAN reported the following error:
BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline]
BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
trace_9p_client_res include/trace/events/9p.h:146 [inline]
p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
legacy_get_tree+0x114/0x290 fs/fs_context.c:662
vfs_get_tree+0xa7/0x570 fs/super.c:1797
do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
path_mount+0x742/0x1f20 fs/namespace.c:3679
do_mount fs/namespace.c:3692 [inline]
__do_sys_mount fs/namespace.c:3898 [inline]
__se_sys_mount+0x725/0x810 fs/namespace.c:3875
__x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
do_syscall_64+0xd5/0x1f0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
Uninit was created at:
__alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598
__alloc_pages_node include/linux/gfp.h:238 [inline]
alloc_pages_node include/linux/gfp.h:261 [inline]
alloc_slab_page mm/slub.c:2175 [inline]
allocate_slab mm/slub.c:2338 [inline]
new_slab+0x2de/0x1400 mm/slub.c:2391
___slab_alloc+0x1184/0x33d0 mm/slub.c:3525
__slab_alloc mm/slub.c:3610 [inline]
__slab_alloc_node mm/slub.c:3663 [inline]
slab_alloc_node mm/slub.c:3835 [inline]
kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852
p9_tag_alloc net/9p/client.c:278 [inline]
p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641
p9_client_rpc+0x27e/0x1340 net/9p/client.c:688
p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
legacy_get_tree+0x114/0x290 fs/fs_context.c:662
vfs_get_tree+0xa7/0x570 fs/super.c:1797
do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
path_mount+0x742/0x1f20 fs/namespace.c:3679
do_mount fs/namespace.c:3692 [inline]
__do_sys_mount fs/namespace.c:3898 [inline]
__se_sys_mount+0x725/0x810 fs/namespace.c:3875
__x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
do_syscall_64+0xd5/0x1f0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag
will not be properly initialized. However, trace_9p_client_res()
ends up trying to print it out anyway before p9_client_rpc()
finishes.
Fix this issue by assigning default values to p9_fcall fields
such as 'tag' and (just in case KMSAN unearths something new) 'id'
during the tag allocation stage. |
["https://git.kernel.org/stable/c/124947855564572713d705a13be7d0c9dae16a17","https://git.kernel.org/stable/c/2101901dd58c6da4924bc5efb217a1d83436290b","https://git.kernel.org/stable/c/25460d6f39024cc3b8241b14c7ccf0d6f11a736a","https://git.kernel.org/stable/c/6c1791130b781c843572fb6391c4a4c5d857ab17","https://git.kernel.org/stable/c/72c5d8e416ecc46af370a1340b3db5ff0b0cc867","https://git.kernel.org/stable/c/89969ffbeb948ffc159d19252e7469490103011b","https://git.kernel.org/stable/c/ca71f204711ad24113e8b344dc5bb8b0385f5672","https://git.kernel.org/stable/c/fe5c604053c36c62af24eee8a76407d026ea5163","https://git.kernel.org/stable/c/124947855564572713d705a13be7d0c9dae16a17","https://git.kernel.org/stable/c/2101901dd58c6da4924bc5efb217a1d83436290b","https://git.kernel.org/stable/c/25460d6f39024cc3b8241b14c7ccf0d6f11a736a","https://git.kernel.org/stable/c/6c1791130b781c843572fb6391c4a4c5d857ab17","https://git.kernel.org/stable/c/72c5d8e416ecc46af370a1340b3db5ff0b0cc867","https://git.kernel.org/stable/c/89969ffbeb948ffc159d19252e7469490103011b","https://git.kernel.org/stable/c/ca71f204711ad24113e8b344dc5bb8b0385f5672","https://git.kernel.org/stable/c/fe5c604053c36c62af24eee8a76407d026ea5163"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43839
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bna: adjust 'name' buf size of bna_tcb and bna_ccb structures
To have enough space to write all possible sprintf() args. Currently
'name' size is 16, but the first '%s' specifier may already need at
least 16 characters, since 'bnad->netdev->name' is used there.
For '%d' specifiers, assume that they require:
* 1 char for 'tx_id + tx_info->tcb[i]->id' sum, BNAD_MAX_TXQ_PER_TX is 8
* 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX
is 16
And replace sprintf with snprintf.
Detected using the static analysis tool - Svace. |
["https://git.kernel.org/stable/c/6ce46045f9b90d952602e2c0b8886cfadf860bf1","https://git.kernel.org/stable/c/6d20c4044ab4d0e6a99aa35853e66f0aed5589e3","https://git.kernel.org/stable/c/ab748dd10d8742561f2980fea08ffb4f0cacfdef","https://git.kernel.org/stable/c/b0ff0cd0847b03c0a0abe20cfa900eabcfcb9e43","https://git.kernel.org/stable/c/c90b1cd7758fd4839909e838ae195d19f8065d76","https://git.kernel.org/stable/c/c9741a03dc8e491e57b95fba0058ab46b7e506da","https://git.kernel.org/stable/c/e0f48f51d55fb187400e9787192eda09fa200ff5","https://git.kernel.org/stable/c/f121740f69eda4da2de9a20a6687a13593e72540"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-47646
|
High |
fixed |
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
Revert "Revert "block, bfq: honor already-setup queue merges""
A crash [1] happened to be triggered in conjunction with commit
2d52c58b9c9b ("block, bfq: honor already-setup queue merges"). The
latter was then reverted by commit ebc69e897e17 ("Revert "block, bfq:
honor already-setup queue merges""). Yet, the reverted commit was not
the one introducing the bug. In fact, it actually triggered a UAF
introduced by a different commit, and now fixed by commit d29bd41428cf
("block, bfq: reset last_bfqq_created on group change").
So, there is no point in keeping commit 2d52c58b9c9b ("block, bfq:
honor already-setup queue merges") out. This commit restores it.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=214503 |
["https://git.kernel.org/stable/c/15729ff8143f8135b03988a100a19e66d7cb7ecd","https://git.kernel.org/stable/c/4083925bd6dc89216d156474a8076feec904e607","https://git.kernel.org/stable/c/65d8a737452e88f251fe5d925371de6d606df613","https://git.kernel.org/stable/c/931aff627469a75c77b9fd3823146d0575afffd6","https://git.kernel.org/stable/c/abc2129e646af7b43025d90a071f83043f1ae76c","https://git.kernel.org/stable/c/cc051f497eac9d8a0d816cd4bffa3415f2724871","https://git.kernel.org/stable/c/f990f0985eda59d4f29fc83fcf300c92b1225d39"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49078
|
High |
fixed |
- 5.4.189
- 5.10.111
- 5.15.34
- 5.16.20
- 5.17.3
|
In the Linux kernel, the following vulnerability has been resolved:
lz4: fix LZ4_decompress_safe_partial read out of bound
When partialDecoding, it is EOF if we've either filled the output buffer
or can't proceed with reading an offset for following match.
In some extreme corner cases when compressed data is suitably corrupted,
UAF will occur. As reported by KASAN [1], LZ4_decompress_safe_partial
may lead to read out of bound problem during decoding. lz4 upstream has
fixed it [2] and this issue has been disscussed here [3] before.
current decompression routine was ported from lz4 v1.8.3, bumping
lib/lz4 to v1.9.+ is certainly a huge work to be done later, so, we'd
better fix it first.
[1] https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/
[2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad#
[3] https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/ |
["https://git.kernel.org/stable/c/467d5e200ab4486b744fe1776154a43d1aa22d4b","https://git.kernel.org/stable/c/6adc01a7aa37445dafe8846faa0610a86029b253","https://git.kernel.org/stable/c/73953dfa9d50e5c9fe98ee13fd1d3427aa12a0a3","https://git.kernel.org/stable/c/9fb8bc6cfc58773ce95414e11c9ccc8fc6ac4927","https://git.kernel.org/stable/c/e64dbe97c05c769525cbca099ddbd22485630235","https://git.kernel.org/stable/c/eafc0a02391b7b36617b36c97c4b5d6832cf5e24"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49385
|
High |
fixed |
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
driver: base: fix UAF when driver_attach failed
When driver_attach(drv); failed, the driver_private will be freed.
But it has been added to the bus, which caused a UAF.
To fix it, we need to delete it from the bus when failed. |
["https://git.kernel.org/stable/c/310862e574001a97ad02272bac0fd13f75f42a27","https://git.kernel.org/stable/c/5389101257828d1913d713d9a40acbe14f5961df","https://git.kernel.org/stable/c/5d709f58c743166fe1c6914b9de0ae8868600d9b","https://git.kernel.org/stable/c/823f24f2e329babd0330200d0b74882516fe57f4","https://git.kernel.org/stable/c/c059665c84feab46b7173d3a1bf36c2fb7f9df86","https://git.kernel.org/stable/c/cdf1a683a01583bca4b618dd16223cbd6e462e21"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49411
|
High |
fixed |
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
bfq: Make sure bfqg for which we are queueing requests is online
Bios queued into BFQ IO scheduler can be associated with a cgroup that
was already offlined. This may then cause insertion of this bfq_group
into a service tree. But this bfq_group will get freed as soon as last
bio associated with it is completed leading to use after free issues for
service tree users. Fix the problem by making sure we always operate on
online bfq_group. If the bfq_group associated with the bio is not
online, we pick the first online parent. |
["https://git.kernel.org/stable/c/075a53b78b815301f8d3dd1ee2cd99554e34f0dd","https://git.kernel.org/stable/c/51f724bffa3403a5236597e6b75df7329c1ec6e9","https://git.kernel.org/stable/c/6ee0868b0c3ccead5907685fcdcdd0c08dfe4b0b","https://git.kernel.org/stable/c/7781c38552e6cc54ed8e9040279561340516b881","https://git.kernel.org/stable/c/97bd6c56bdcb41079e488e31df56809e3b2ce628","https://git.kernel.org/stable/c/ccddf8cd411c1800863ed357064e56ceffd356bb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49412
|
High |
fixed |
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
bfq: Avoid merging queues with different parents
It can happen that the parent of a bfqq changes between the moment we
decide two queues are worth to merge (and set bic->stable_merge_bfqq)
and the moment bfq_setup_merge() is called. This can happen e.g. because
the process submitted IO for a different cgroup and thus bfqq got
reparented. It can even happen that the bfqq we are merging with has
parent cgroup that is already offline and going to be destroyed in which
case the merge can lead to use-after-free issues such as:
BUG: KASAN: use-after-free in __bfq_deactivate_entity+0x9cb/0xa50
Read of size 8 at addr ffff88800693c0c0 by task runc:[2:INIT]/10544
CPU: 0 PID: 10544 Comm: runc:[2:INIT] Tainted: G E 5.15.2-0.g5fb85fd-default #1 openSUSE Tumbleweed (unreleased) f1f3b891c72369aebecd2e43e4641a6358867c70
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014
Call Trace:
<IRQ>
dump_stack_lvl+0x46/0x5a
print_address_description.constprop.0+0x1f/0x140
? __bfq_deactivate_entity+0x9cb/0xa50
kasan_report.cold+0x7f/0x11b
? __bfq_deactivate_entity+0x9cb/0xa50
__bfq_deactivate_entity+0x9cb/0xa50
? update_curr+0x32f/0x5d0
bfq_deactivate_entity+0xa0/0x1d0
bfq_del_bfqq_busy+0x28a/0x420
? resched_curr+0x116/0x1d0
? bfq_requeue_bfqq+0x70/0x70
? check_preempt_wakeup+0x52b/0xbc0
__bfq_bfqq_expire+0x1a2/0x270
bfq_bfqq_expire+0xd16/0x2160
? try_to_wake_up+0x4ee/0x1260
? bfq_end_wr_async_queues+0xe0/0xe0
? _raw_write_unlock_bh+0x60/0x60
? _raw_spin_lock_irq+0x81/0xe0
bfq_idle_slice_timer+0x109/0x280
? bfq_dispatch_request+0x4870/0x4870
__hrtimer_run_queues+0x37d/0x700
? enqueue_hrtimer+0x1b0/0x1b0
? kvm_clock_get_cycles+0xd/0x10
? ktime_get_update_offsets_now+0x6f/0x280
hrtimer_interrupt+0x2c8/0x740
Fix the problem by checking that the parent of the two bfqqs we are
merging in bfq_setup_merge() is the same. |
["https://git.kernel.org/stable/c/5ee21edaed09e6b25f2c007b3f326752bc89bacf","https://git.kernel.org/stable/c/7d172b9dc913e161d8ff88770eea01701ff553de","https://git.kernel.org/stable/c/8abc8763b11c35e03cc91d59fd0cd28d39f88ca9","https://git.kernel.org/stable/c/97be7d13fbd4001eeab49b1be6399f23a8c66160","https://git.kernel.org/stable/c/a16c65cca7d2c7ff965fdd3adc8df2156529caf1","https://git.kernel.org/stable/c/c1cee4ab36acef271be9101590756ed0c0c374d9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49413
|
High |
fixed |
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
bfq: Update cgroup information before merging bio
When the process is migrated to a different cgroup (or in case of
writeback just starts submitting bios associated with a different
cgroup) bfq_merge_bio() can operate with stale cgroup information in
bic. Thus the bio can be merged to a request from a different cgroup or
it can result in merging of bfqqs for different cgroups or bfqqs of
already dead cgroups and causing possible use-after-free issues. Fix the
problem by updating cgroup information in bfq_merge_bio(). |
["https://git.kernel.org/stable/c/2a1077f17169a6059992a0bbdb330e0abad1e6d9","https://git.kernel.org/stable/c/b06691af08b41dfd81052a3362514d9827b44bb1","https://git.kernel.org/stable/c/d9165200c5627a2cf4408eefabdf0058bdf95e1a","https://git.kernel.org/stable/c/da9f3025d595956410ceaab2bea01980d7775948","https://git.kernel.org/stable/c/e8821f45612f2e6d9adb9c6ba0fb4184f57692aa","https://git.kernel.org/stable/c/ea591cd4eb270393810e7be01feb8fde6a34fbbe"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49508
|
High |
fixed |
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
HID: elan: Fix potential double free in elan_input_configured
'input' is a managed resource allocated with devm_input_allocate_device(),
so there is no need to call input_free_device() explicitly or
there will be a double free.
According to the doc of devm_input_allocate_device():
* Managed input devices do not need to be explicitly unregistered or
* freed as it will be done automatically when owner device unbinds from
* its driver (or binding fails). |
["https://git.kernel.org/stable/c/1af20714fedad238362571620be0bd690ded05b6","https://git.kernel.org/stable/c/24f9dfdaece9bd75bb8dbfdba83eddeefdf7dc47","https://git.kernel.org/stable/c/5291451851feeb66fd4bf0826710f482f3b1ab38","https://git.kernel.org/stable/c/6d0726725c7c560495f5ff364862a2cefea542e3","https://git.kernel.org/stable/c/8bb1716507ebf12d50bbf181764481de3b6bc7fd","https://git.kernel.org/stable/c/c92ec22a991778a096342cf1a917ae36c5c86a90","https://git.kernel.org/stable/c/f1d4f19a796551edc6679a681ea1756b8c578c08"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49647
|
High |
fixed |
- 4.14.289
- 4.19.253
- 5.4.207
- 5.10.132
- 5.15.56
- 5.18.13
|
In the Linux kernel, the following vulnerability has been resolved:
cgroup: Use separate src/dst nodes when preloading css_sets for migration
Each cset (css_set) is pinned by its tasks. When we're moving tasks around
across csets for a migration, we need to hold the source and destination
csets to ensure that they don't go away while we're moving tasks about. This
is done by linking cset->mg_preload_node on either the
mgctx->preloaded_src_csets or mgctx->preloaded_dst_csets list. Using the
same cset->mg_preload_node for both the src and dst lists was deemed okay as
a cset can't be both the source and destination at the same time.
Unfortunately, this overloading becomes problematic when multiple tasks are
involved in a migration and some of them are identity noop migrations while
others are actually moving across cgroups. For example, this can happen with
the following sequence on cgroup1:
#1> mkdir -p /sys/fs/cgroup/misc/a/b
#2> echo $$ > /sys/fs/cgroup/misc/a/cgroup.procs
#3> RUN_A_COMMAND_WHICH_CREATES_MULTIPLE_THREADS &
#4> PID=$!
#5> echo $PID > /sys/fs/cgroup/misc/a/b/tasks
#6> echo $PID > /sys/fs/cgroup/misc/a/cgroup.procs
the process including the group leader back into a. In this final migration,
non-leader threads would be doing identity migration while the group leader
is doing an actual one.
After #3, let's say the whole process was in cset A, and that after #4, the
leader moves to cset B. Then, during #6, the following happens:
1. cgroup_migrate_add_src() is called on B for the leader.
2. cgroup_migrate_add_src() is called on A for the other threads.
3. cgroup_migrate_prepare_dst() is called. It scans the src list.
4. It notices that B wants to migrate to A, so it tries to A to the dst
list but realizes that its ->mg_preload_node is already busy.
5. and then it notices A wants to migrate to A as it's an identity
migration, it culls it by list_del_init()'ing its ->mg_preload_node and
putting references accordingly.
6. The rest of migration takes place with B on the src list but nothing on
the dst list.
This means that A isn't held while migration is in progress. If all tasks
leave A before the migration finishes and the incoming task pins it, the
cset will be destroyed leading to use-after-free.
This is caused by overloading cset->mg_preload_node for both src and dst
preload lists. We wanted to exclude the cset from the src list but ended up
inadvertently excluding it from the dst list too.
This patch fixes the issue by separating out cset->mg_preload_node into
->mg_src_preload_node and ->mg_dst_preload_node, so that the src and dst
preloadings don't interfere with each other. |
["https://git.kernel.org/stable/c/05f7658210d1d331e8dd4cb6e7bbbe3df5f5ac27","https://git.kernel.org/stable/c/07fd5b6cdf3cc30bfde8fe0f644771688be04447","https://git.kernel.org/stable/c/0e41774b564befa6d271e8d5086bf870d617a4e6","https://git.kernel.org/stable/c/54aee4e5ce8c21555286a6333e46c1713880cf93","https://git.kernel.org/stable/c/7657e3958535d101a24ab4400f9b8062b9107cc4","https://git.kernel.org/stable/c/ad44e05f3e016bdcb1ad25af35ade5b5f41ccd68","https://git.kernel.org/stable/c/cec2bbdcc14fbaa6b95ee15a7c423b05d97038be"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26961
|
High |
fixed |
- 5.10.215
- 5.15.154
- 6.1.84
- 6.6.24
- 6.7.12
- 6.8.3
|
In the Linux kernel, the following vulnerability has been resolved:
mac802154: fix llsec key resources release in mac802154_llsec_key_del
mac802154_llsec_key_del() can free resources of a key directly without
following the RCU rules for waiting before the end of a grace period. This
may lead to use-after-free in case llsec_lookup_key() is traversing the
list of keys in parallel with a key deletion:
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0
Modules linked in:
CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:refcount_warn_saturate+0x162/0x2a0
Call Trace:
<TASK>
llsec_lookup_key.isra.0+0x890/0x9e0
mac802154_llsec_encrypt+0x30c/0x9c0
ieee802154_subif_start_xmit+0x24/0x1e0
dev_hard_start_xmit+0x13e/0x690
sch_direct_xmit+0x2ae/0xbc0
__dev_queue_xmit+0x11dd/0x3c20
dgram_sendmsg+0x90b/0xd60
__sys_sendto+0x466/0x4c0
__x64_sys_sendto+0xe0/0x1c0
do_syscall_64+0x45/0xf0
entry_SYSCALL_64_after_hwframe+0x6e/0x76
Also, ieee802154_llsec_key_entry structures are not freed by
mac802154_llsec_key_del():
unreferenced object 0xffff8880613b6980 (size 64):
comm "iwpan", pid 2176, jiffies 4294761134 (age 60.475s)
hex dump (first 32 bytes):
78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de x.......".......
00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ................
backtrace:
[<ffffffff81dcfa62>] __kmem_cache_alloc_node+0x1e2/0x2d0
[<ffffffff81c43865>] kmalloc_trace+0x25/0xc0
[<ffffffff88968b09>] mac802154_llsec_key_add+0xac9/0xcf0
[<ffffffff8896e41a>] ieee802154_add_llsec_key+0x5a/0x80
[<ffffffff8892adc6>] nl802154_add_llsec_key+0x426/0x5b0
[<ffffffff86ff293e>] genl_family_rcv_msg_doit+0x1fe/0x2f0
[<ffffffff86ff46d1>] genl_rcv_msg+0x531/0x7d0
[<ffffffff86fee7a9>] netlink_rcv_skb+0x169/0x440
[<ffffffff86ff1d88>] genl_rcv+0x28/0x40
[<ffffffff86fec15c>] netlink_unicast+0x53c/0x820
[<ffffffff86fecd8b>] netlink_sendmsg+0x93b/0xe60
[<ffffffff86b91b35>] ____sys_sendmsg+0xac5/0xca0
[<ffffffff86b9c3dd>] ___sys_sendmsg+0x11d/0x1c0
[<ffffffff86b9c65a>] __sys_sendmsg+0xfa/0x1d0
[<ffffffff88eadbf5>] do_syscall_64+0x45/0xf0
[<ffffffff890000ea>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
Handle the proper resource release in the RCU callback function
mac802154_llsec_key_del_rcu().
Note that if llsec_lookup_key() finds a key, it gets a refcount via
llsec_key_get() and locally copies key id from key_entry (which is a
list element). So it's safe to call llsec_key_put() and free the list
entry after the RCU grace period elapses.
Found by Linux Verification Center (linuxtesting.org). |
["https://git.kernel.org/stable/c/068ab2759bc0b4daf0b964de61b2731449c86531","https://git.kernel.org/stable/c/20d3e1c8a1847497269f04d874b2a5818ec29e2d","https://git.kernel.org/stable/c/49c8951680d7b76fceaee89dcfbab1363fb24fd1","https://git.kernel.org/stable/c/640297c3e897bd7e1481466a6a5cb9560f1edb88","https://git.kernel.org/stable/c/d3d858650933d44ac12c1f31337e7110c2071821","https://git.kernel.org/stable/c/dcd51ab42b7a0431575689c5f74b8b6efd45fc2f","https://git.kernel.org/stable/c/e8a1e58345cf40b7b272e08ac7b32328b2543e40","https://git.kernel.org/stable/c/068ab2759bc0b4daf0b964de61b2731449c86531","https://git.kernel.org/stable/c/20d3e1c8a1847497269f04d874b2a5818ec29e2d","https://git.kernel.org/stable/c/49c8951680d7b76fceaee89dcfbab1363fb24fd1","https://git.kernel.org/stable/c/640297c3e897bd7e1481466a6a5cb9560f1edb88","https://git.kernel.org/stable/c/d3d858650933d44ac12c1f31337e7110c2071821","https://git.kernel.org/stable/c/dcd51ab42b7a0431575689c5f74b8b6efd45fc2f","https://git.kernel.org/stable/c/e8a1e58345cf40b7b272e08ac7b32328b2543e40","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35869
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
smb: client: guarantee refcounted children from parent session
Avoid potential use-after-free bugs when walking DFS referrals,
mounting and performing DFS failover by ensuring that all children
from parent @tcon->ses are also refcounted. They're all needed across
the entire DFS mount. Get rid of @tcon->dfs_ses_list while we're at
it, too. |
["https://git.kernel.org/stable/c/062a7f0ff46eb57aff526897bd2bebfdb1d3046a","https://git.kernel.org/stable/c/645f332c6b63499cc76197f9b6bffcc659ba64cc","https://git.kernel.org/stable/c/e1db9ae87b7148c021daee1fcc4bc71b2ac58a79","https://git.kernel.org/stable/c/062a7f0ff46eb57aff526897bd2bebfdb1d3046a","https://git.kernel.org/stable/c/645f332c6b63499cc76197f9b6bffcc659ba64cc","https://git.kernel.org/stable/c/e1db9ae87b7148c021daee1fcc4bc71b2ac58a79"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-6240
|
Medium |
|
N/A
|
A Marvin vulnerability side-channel leakage was found in the RSA decryption operation in the Linux Kernel. This issue may allow a network attacker to decrypt ciphertexts or forge signatures, limiting the services that use that private key. |
["https://access.redhat.com/errata/RHSA-2024:1881","https://access.redhat.com/errata/RHSA-2024:1882","https://access.redhat.com/errata/RHSA-2024:2758","https://access.redhat.com/errata/RHSA-2024:3414","https://access.redhat.com/errata/RHSA-2024:3421","https://access.redhat.com/errata/RHSA-2024:3618","https://access.redhat.com/errata/RHSA-2024:3627","https://access.redhat.com/security/cve/CVE-2023-6240","https://bugzilla.redhat.com/show_bug.cgi?id=2250843","https://people.redhat.com/~hkario/marvin/","https://securitypitfalls.wordpress.com/2023/10/16/experiment-with-side-channel-attacks-yourself/","https://access.redhat.com/errata/RHSA-2024:1881","https://access.redhat.com/errata/RHSA-2024:1882","https://access.redhat.com/errata/RHSA-2024:2758","https://access.redhat.com/errata/RHSA-2024:3414","https://access.redhat.com/errata/RHSA-2024:3421","https://access.redhat.com/errata/RHSA-2024:3618","https://access.redhat.com/errata/RHSA-2024:3627","https://access.redhat.com/security/cve/CVE-2023-6240","https://bugzilla.redhat.com/show_bug.cgi?id=2250843","https://people.redhat.com/~hkario/marvin/","https://security.netapp.com/advisory/ntap-20240628-0002/","https://securitypitfalls.wordpress.com/2023/10/16/experiment-with-side-channel-attacks-yourself/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27052
|
High |
fixed |
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work
The workqueue might still be running, when the driver is stopped. To
avoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop(). |
["https://git.kernel.org/stable/c/1213acb478a7181cd73eeaf00db430f1e45b1361","https://git.kernel.org/stable/c/156012667b85ca7305cb363790d3ae8519a6f41e","https://git.kernel.org/stable/c/3518cea837de4d106efa84ddac18a07b6de1384e","https://git.kernel.org/stable/c/58fe3bbddfec10c6b216096d8c0e517cd8463e3a","https://git.kernel.org/stable/c/7059cdb69f8e1a2707dd1e2f363348b507ed7707","https://git.kernel.org/stable/c/ac512507ac89c01ed6cd4ca53032f52cdb23ea59","https://git.kernel.org/stable/c/dddedfa3b29a63c2ca4336663806a6128b8545b4","https://git.kernel.org/stable/c/1213acb478a7181cd73eeaf00db430f1e45b1361","https://git.kernel.org/stable/c/156012667b85ca7305cb363790d3ae8519a6f41e","https://git.kernel.org/stable/c/3518cea837de4d106efa84ddac18a07b6de1384e","https://git.kernel.org/stable/c/58fe3bbddfec10c6b216096d8c0e517cd8463e3a","https://git.kernel.org/stable/c/7059cdb69f8e1a2707dd1e2f363348b507ed7707","https://git.kernel.org/stable/c/ac512507ac89c01ed6cd4ca53032f52cdb23ea59","https://git.kernel.org/stable/c/dddedfa3b29a63c2ca4336663806a6128b8545b4","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-42721
|
Medium |
fixed |
|
A list management bug in BSS handling in the mac80211 stack in the Linux kernel 5.1 through 5.19.x before 5.19.16 could be used by local attackers (able to inject WLAN frames) to corrupt a linked list and, in turn, potentially execute code. |
["http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html","http://www.openwall.com/lists/oss-security/2022/10/13/5","https://bugzilla.suse.com/show_bug.cgi?id=1204060","https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=bcca852027e5878aec911a347407ecc88d6fff7f","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://security.netapp.com/advisory/ntap-20230203-0008/","https://www.debian.org/security/2022/dsa-5257","http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html","http://www.openwall.com/lists/oss-security/2022/10/13/5","https://bugzilla.suse.com/show_bug.cgi?id=1204060","https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=bcca852027e5878aec911a347407ecc88d6fff7f","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://security.netapp.com/advisory/ntap-20230203-0008/","https://www.debian.org/security/2022/dsa-5257"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52852
|
High |
fixed |
- 5.15.139
- 6.1.63
- 6.5.12
- 6.6.2
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: compress: fix to avoid use-after-free on dic
Call trace:
__memcpy+0x128/0x250
f2fs_read_multi_pages+0x940/0xf7c
f2fs_mpage_readpages+0x5a8/0x624
f2fs_readahead+0x5c/0x110
page_cache_ra_unbounded+0x1b8/0x590
do_sync_mmap_readahead+0x1dc/0x2e4
filemap_fault+0x254/0xa8c
f2fs_filemap_fault+0x2c/0x104
__do_fault+0x7c/0x238
do_handle_mm_fault+0x11bc/0x2d14
do_mem_abort+0x3a8/0x1004
el0_da+0x3c/0xa0
el0t_64_sync_handler+0xc4/0xec
el0t_64_sync+0x1b4/0x1b8
In f2fs_read_multi_pages(), once f2fs_decompress_cluster() was called if
we hit cached page in compress_inode's cache, dic may be released, it needs
break the loop rather than continuing it, in order to avoid accessing
invalid dic pointer. |
["https://git.kernel.org/stable/c/8c4504cc0c64862740a6acb301e0cfa59580dbc5","https://git.kernel.org/stable/c/932ddb5c29e884cc6fac20417ece72ba4a35c401","https://git.kernel.org/stable/c/9375ea7f269093d7c884857ae1f47633a91f429c","https://git.kernel.org/stable/c/9d065aa52b6ee1b06f9c4eca881c9b4425a12ba2","https://git.kernel.org/stable/c/b0327c84e91a0f4f0abced8cb83ec86a7083f086","https://git.kernel.org/stable/c/8c4504cc0c64862740a6acb301e0cfa59580dbc5","https://git.kernel.org/stable/c/932ddb5c29e884cc6fac20417ece72ba4a35c401","https://git.kernel.org/stable/c/9375ea7f269093d7c884857ae1f47633a91f429c","https://git.kernel.org/stable/c/9d065aa52b6ee1b06f9c4eca881c9b4425a12ba2","https://git.kernel.org/stable/c/b0327c84e91a0f4f0abced8cb83ec86a7083f086"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2019-25162
|
High |
fixed |
- 4.14.291
- 4.19.256
- 5.4.211
- 5.10.137
- 5.15.61
- 5.18.18
- 5.19.2
|
In the Linux kernel, the following vulnerability has been resolved:
i2c: Fix a potential use after free
Free the adap structure only after we are done using it.
This patch just moves the put_device() down a bit to avoid the
use after free.
[wsa: added comment to the code, added Fixes tag] |
["https://git.kernel.org/stable/c/12b0606000d0828630c033bf0c74c748464fe87d","https://git.kernel.org/stable/c/23a191b132cd87f746c62f3dc27da33683d85829","https://git.kernel.org/stable/c/35927d7509ab9bf41896b7e44f639504eae08af7","https://git.kernel.org/stable/c/81cb31756888bb062e92d2dca21cd629d77a46a9","https://git.kernel.org/stable/c/871a1e94929a27bf6e2cd99523865c840bbc2d87","https://git.kernel.org/stable/c/e4c72c06c367758a14f227c847f9d623f1994ecf","https://git.kernel.org/stable/c/e6412ba3b6508bdf9c074d310bf4144afa6aec1a","https://git.kernel.org/stable/c/e8e1a046cf87c8b1363e5de835114f2779e2aaf4","https://git.kernel.org/stable/c/12b0606000d0828630c033bf0c74c748464fe87d","https://git.kernel.org/stable/c/23a191b132cd87f746c62f3dc27da33683d85829","https://git.kernel.org/stable/c/35927d7509ab9bf41896b7e44f639504eae08af7","https://git.kernel.org/stable/c/81cb31756888bb062e92d2dca21cd629d77a46a9","https://git.kernel.org/stable/c/871a1e94929a27bf6e2cd99523865c840bbc2d87","https://git.kernel.org/stable/c/e4c72c06c367758a14f227c847f9d623f1994ecf","https://git.kernel.org/stable/c/e6412ba3b6508bdf9c074d310bf4144afa6aec1a","https://git.kernel.org/stable/c/e8e1a046cf87c8b1363e5de835114f2779e2aaf4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2017-1000377
|
Medium |
|
N/A
|
An issue was discovered in the size of the default stack guard page on PAX Linux (originally from GRSecurity but shipped by other Linux vendors), specifically the default stack guard page is not sufficiently large and can be "jumped" over (the stack guard page is bypassed), this affects PAX Linux Kernel versions as of June 19, 2017 (specific version information is not available at this time). |
["http://www.securityfocus.com/bid/99129","https://access.redhat.com/security/cve/CVE-2017-1000377","https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt","http://www.securityfocus.com/bid/99129","https://access.redhat.com/security/cve/CVE-2017-1000377","https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50265
|
Medium |
fixed |
- 4.19.324
- 5.4.286
- 5.10.230
- 5.15.172
- 6.1.117
- 6.6.61
- 6.11.8
|
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove()
Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove():
[ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12
[ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry
[ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004
[...]
[ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0
[...]
[ 57.331328] Call Trace:
[ 57.331477] <TASK>
[...]
[ 57.333511] ? do_user_addr_fault+0x3e5/0x740
[ 57.333778] ? exc_page_fault+0x70/0x170
[ 57.334016] ? asm_exc_page_fault+0x2b/0x30
[ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10
[ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0
[ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0
[ 57.335164] ocfs2_xa_set+0x704/0xcf0
[ 57.335381] ? _raw_spin_unlock+0x1a/0x40
[ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20
[ 57.335915] ? trace_preempt_on+0x1e/0x70
[ 57.336153] ? start_this_handle+0x16c/0x500
[ 57.336410] ? preempt_count_sub+0x50/0x80
[ 57.336656] ? _raw_read_unlock+0x20/0x40
[ 57.336906] ? start_this_handle+0x16c/0x500
[ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0
[ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0
[ 57.337706] ? ocfs2_start_trans+0x13d/0x290
[ 57.337971] ocfs2_xattr_set+0xb13/0xfb0
[ 57.338207] ? dput+0x46/0x1c0
[ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30
[ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30
[ 57.338948] __vfs_removexattr+0x92/0xc0
[ 57.339182] __vfs_removexattr_locked+0xd5/0x190
[ 57.339456] ? preempt_count_sub+0x50/0x80
[ 57.339705] vfs_removexattr+0x5f/0x100
[...]
Reproducer uses faultinject facility to fail ocfs2_xa_remove() ->
ocfs2_xa_value_truncate() with -ENOMEM.
In this case the comment mentions that we can return 0 if
ocfs2_xa_cleanup_value_truncate() is going to wipe the entry
anyway. But the following 'rc' check is wrong and execution flow do
'ocfs2_xa_remove_entry(loc);' twice:
* 1st: in ocfs2_xa_cleanup_value_truncate();
* 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'.
Fix this by skipping the 2nd removal of the same entry and making
syzkaller repro happy. |
["https://git.kernel.org/stable/c/0b63c0e01fba40e3992bc627272ec7b618ccaef7","https://git.kernel.org/stable/c/168a9b8303fcb0317db4c06b23ce1c0ce2af4e10","https://git.kernel.org/stable/c/2b5369528ee63c88371816178a05b5e664c87386","https://git.kernel.org/stable/c/38cbf13b2e7a31362babe411f7c2c3c52cd2734b","https://git.kernel.org/stable/c/6a7e6dcf90fe7721d0863067b6ca9a9442134692","https://git.kernel.org/stable/c/86dd0e8d42828923c68ad506933336bcd6f2317d","https://git.kernel.org/stable/c/dcc8fe8c83145041cb6c80cac21f6173a3ff0204","https://git.kernel.org/stable/c/dd73c942eed76a014c7a5597e6926435274d2c4c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48983
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
io_uring: Fix a null-ptr-deref in io_tctx_exit_cb()
Syzkaller reports a NULL deref bug as follows:
BUG: KASAN: null-ptr-deref in io_tctx_exit_cb+0x53/0xd3
Read of size 4 at addr 0000000000000138 by task file1/1955
CPU: 1 PID: 1955 Comm: file1 Not tainted 6.1.0-rc7-00103-gef4d3ea40565 #75
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0xcd/0x134
? io_tctx_exit_cb+0x53/0xd3
kasan_report+0xbb/0x1f0
? io_tctx_exit_cb+0x53/0xd3
kasan_check_range+0x140/0x190
io_tctx_exit_cb+0x53/0xd3
task_work_run+0x164/0x250
? task_work_cancel+0x30/0x30
get_signal+0x1c3/0x2440
? lock_downgrade+0x6e0/0x6e0
? lock_downgrade+0x6e0/0x6e0
? exit_signals+0x8b0/0x8b0
? do_raw_read_unlock+0x3b/0x70
? do_raw_spin_unlock+0x50/0x230
arch_do_signal_or_restart+0x82/0x2470
? kmem_cache_free+0x260/0x4b0
? putname+0xfe/0x140
? get_sigframe_size+0x10/0x10
? do_execveat_common.isra.0+0x226/0x710
? lockdep_hardirqs_on+0x79/0x100
? putname+0xfe/0x140
? do_execveat_common.isra.0+0x238/0x710
exit_to_user_mode_prepare+0x15f/0x250
syscall_exit_to_user_mode+0x19/0x50
do_syscall_64+0x42/0xb0
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0023:0x0
Code: Unable to access opcode bytes at 0xffffffffffffffd6.
RSP: 002b:00000000fffb7790 EFLAGS: 00000200 ORIG_RAX: 000000000000000b
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
</TASK>
Kernel panic - not syncing: panic_on_warn set ...
This happens because the adding of task_work from io_ring_exit_work()
isn't synchronized with canceling all work items from eg exec. The
execution of the two are ordered in that they are both run by the task
itself, but if io_tctx_exit_cb() is queued while we're canceling all
work items off exec AND gets executed when the task exits to userspace
rather than in the main loop in io_uring_cancel_generic(), then we can
find current->io_uring == NULL and hit the above crash.
It's safe to add this NULL check here, because the execution of the two
paths are done by the task itself.
[axboe: add code comment and also put an explanation in the commit msg] |
["https://git.kernel.org/stable/c/998b30c3948e4d0b1097e639918c5cff332acac5","https://git.kernel.org/stable/c/d91edca1943453aaaba4f380f6f364346222e5cf","https://git.kernel.org/stable/c/f895511de9d27fff71dad2c234ad53b4afd2b06c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52819
|
Medium |
fixed |
- 4.14.331
- 4.19.300
- 5.4.262
- 5.10.202
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga
For pptable structs that use flexible array sizes, use flexible arrays. |
["https://git.kernel.org/stable/c/0f0e59075b5c22f1e871fbd508d6e4f495048356","https://git.kernel.org/stable/c/60a00dfc7c5deafd1dd393beaf53224f7256dad6","https://git.kernel.org/stable/c/7c68283f3166221af3df5791f0e13d3137a72216","https://git.kernel.org/stable/c/8c1dbddbfcb051e82cea0c197c620f9dcdc38e92","https://git.kernel.org/stable/c/a237675aa1e62bbfaa341c535331c8656a508fa1","https://git.kernel.org/stable/c/a63fd579e7b1c3a9ebd6e6c494d49b1b6cf5515e","https://git.kernel.org/stable/c/b3b8b7c040cf069da7afe11c5bd73b870b8f3d18","https://git.kernel.org/stable/c/d0725232da777840703f5f1e22f2e3081d712aa4","https://git.kernel.org/stable/c/d50a56749e5afdc63491b88f5153c1aae00d4679","https://git.kernel.org/stable/c/0f0e59075b5c22f1e871fbd508d6e4f495048356","https://git.kernel.org/stable/c/60a00dfc7c5deafd1dd393beaf53224f7256dad6","https://git.kernel.org/stable/c/7c68283f3166221af3df5791f0e13d3137a72216","https://git.kernel.org/stable/c/8c1dbddbfcb051e82cea0c197c620f9dcdc38e92","https://git.kernel.org/stable/c/a237675aa1e62bbfaa341c535331c8656a508fa1","https://git.kernel.org/stable/c/a63fd579e7b1c3a9ebd6e6c494d49b1b6cf5515e","https://git.kernel.org/stable/c/b3b8b7c040cf069da7afe11c5bd73b870b8f3d18","https://git.kernel.org/stable/c/d0725232da777840703f5f1e22f2e3081d712aa4","https://git.kernel.org/stable/c/d50a56749e5afdc63491b88f5153c1aae00d4679"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2018-10882
|
Medium |
|
N/A
|
A flaw was found in the Linux kernel's ext4 filesystem. A local user can cause an out-of-bound write in in fs/jbd2/transaction.c code, a denial of service, and a system crash by unmounting a crafted ext4 filesystem image. |
["http://www.securityfocus.com/bid/106503","https://access.redhat.com/errata/RHSA-2018:2948","https://bugzilla.kernel.org/show_bug.cgi?id=200069","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10882","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c37e9e013469521d9adb932d17a1795c139b36db","https://lists.debian.org/debian-lts-announce/2018/07/msg00020.html","https://usn.ubuntu.com/3753-1/","https://usn.ubuntu.com/3753-2/","https://usn.ubuntu.com/3871-1/","https://usn.ubuntu.com/3871-3/","https://usn.ubuntu.com/3871-4/","https://usn.ubuntu.com/3871-5/","http://www.securityfocus.com/bid/106503","https://access.redhat.com/errata/RHSA-2018:2948","https://bugzilla.kernel.org/show_bug.cgi?id=200069","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10882","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c37e9e013469521d9adb932d17a1795c139b36db","https://lists.debian.org/debian-lts-announce/2018/07/msg00020.html","https://usn.ubuntu.com/3753-1/","https://usn.ubuntu.com/3753-2/","https://usn.ubuntu.com/3871-1/","https://usn.ubuntu.com/3871-3/","https://usn.ubuntu.com/3871-4/","https://usn.ubuntu.com/3871-5/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52837
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
nbd: fix uaf in nbd_open
Commit 4af5f2e03013 ("nbd: use blk_mq_alloc_disk and
blk_cleanup_disk") cleans up disk by blk_cleanup_disk() and it won't set
disk->private_data as NULL as before. UAF may be triggered in nbd_open()
if someone tries to open nbd device right after nbd_put() since nbd has
been free in nbd_dev_remove().
Fix this by implementing ->free_disk and free private data in it. |
["https://git.kernel.org/stable/c/327462725b0f759f093788dfbcb2f1fd132f956b","https://git.kernel.org/stable/c/4e9b3ec84dc97909876641dad14e0a2300d6c2a3","https://git.kernel.org/stable/c/56bd7901b5e9dbc9112036ea615ebcba1565fafe","https://git.kernel.org/stable/c/879947f4180bc6e83af64eb0515e0cf57fce15db","https://git.kernel.org/stable/c/327462725b0f759f093788dfbcb2f1fd132f956b","https://git.kernel.org/stable/c/4e9b3ec84dc97909876641dad14e0a2300d6c2a3","https://git.kernel.org/stable/c/56bd7901b5e9dbc9112036ea615ebcba1565fafe","https://git.kernel.org/stable/c/879947f4180bc6e83af64eb0515e0cf57fce15db"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35861
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in cifs_signal_cifsd_for_reconnect()
Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF. |
["https://git.kernel.org/stable/c/2cfff21732132e363b4cc275d63ea98f1af726c1","https://git.kernel.org/stable/c/7e8360ac8774e19b0b25f44fff84a105bb2417e4","https://git.kernel.org/stable/c/e0e50401cc3921c9eaf1b0e667db174519ea939f","https://git.kernel.org/stable/c/f9a96a7ad1e8d25dc6662bc7552e0752de74a20d","https://git.kernel.org/stable/c/2cfff21732132e363b4cc275d63ea98f1af726c1","https://git.kernel.org/stable/c/7e8360ac8774e19b0b25f44fff84a105bb2417e4","https://git.kernel.org/stable/c/e0e50401cc3921c9eaf1b0e667db174519ea939f","https://git.kernel.org/stable/c/f9a96a7ad1e8d25dc6662bc7552e0752de74a20d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35862
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in smb2_is_network_name_deleted()
Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF. |
["https://git.kernel.org/stable/c/63981561ffd2d4987807df4126f96a11e18b0c1d","https://git.kernel.org/stable/c/aa582b33f94453fdeaff1e7d0aa252c505975e01","https://git.kernel.org/stable/c/d919b6ea15ffa56fbafef4a1d92f47aeda9af645","https://git.kernel.org/stable/c/f9414004798d9742c1af23a1d839fe6a9503751c","https://git.kernel.org/stable/c/63981561ffd2d4987807df4126f96a11e18b0c1d","https://git.kernel.org/stable/c/aa582b33f94453fdeaff1e7d0aa252c505975e01","https://git.kernel.org/stable/c/d919b6ea15ffa56fbafef4a1d92f47aeda9af645","https://git.kernel.org/stable/c/f9414004798d9742c1af23a1d839fe6a9503751c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35863
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in is_valid_oplock_break()
Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF. |
["https://git.kernel.org/stable/c/0a15ba88a32fa7a516aff7ffd27befed5334dff2","https://git.kernel.org/stable/c/16d58c6a7db5050b9638669084b63fc05f951825","https://git.kernel.org/stable/c/494c91e1e9413b407d12166a61b84200d4d54fac","https://git.kernel.org/stable/c/69ccf040acddf33a3a85ec0f6b45ef84b0f7ec29","https://git.kernel.org/stable/c/0a15ba88a32fa7a516aff7ffd27befed5334dff2","https://git.kernel.org/stable/c/16d58c6a7db5050b9638669084b63fc05f951825","https://git.kernel.org/stable/c/494c91e1e9413b407d12166a61b84200d4d54fac","https://git.kernel.org/stable/c/69ccf040acddf33a3a85ec0f6b45ef84b0f7ec29"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35864
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in smb2_is_valid_lease_break()
Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF. |
["https://git.kernel.org/stable/c/705c76fbf726c7a2f6ff9143d4013b18daaaebf1","https://git.kernel.org/stable/c/a8344e2b69bde63f713b0aa796d70dbeadffddfb","https://git.kernel.org/stable/c/c868cabdf6fdd61bea54532271f4708254e57fc5","https://git.kernel.org/stable/c/f92739fdd4522c4291277136399353d7c341fae4","https://git.kernel.org/stable/c/705c76fbf726c7a2f6ff9143d4013b18daaaebf1","https://git.kernel.org/stable/c/a8344e2b69bde63f713b0aa796d70dbeadffddfb","https://git.kernel.org/stable/c/c868cabdf6fdd61bea54532271f4708254e57fc5","https://git.kernel.org/stable/c/f92739fdd4522c4291277136399353d7c341fae4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35868
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in cifs_stats_proc_write()
Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF. |
["https://git.kernel.org/stable/c/5b5475ce69f02ecc1b13ea23106e5b89c690429b","https://git.kernel.org/stable/c/8fefd166fcb368c5fcf48238e3f7c8af829e0a72","https://git.kernel.org/stable/c/cf03020c56d3ed28c4942280957a007b5e9544f7","https://git.kernel.org/stable/c/d3da25c5ac84430f89875ca7485a3828150a7e0a","https://git.kernel.org/stable/c/5b5475ce69f02ecc1b13ea23106e5b89c690429b","https://git.kernel.org/stable/c/8fefd166fcb368c5fcf48238e3f7c8af829e0a72","https://git.kernel.org/stable/c/cf03020c56d3ed28c4942280957a007b5e9544f7","https://git.kernel.org/stable/c/d3da25c5ac84430f89875ca7485a3828150a7e0a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36012
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: msft: fix slab-use-after-free in msft_do_close()
Tying the msft->data lifetime to hdev by freeing it in
hci_release_dev() to fix the following case:
[use]
msft_do_close()
msft = hdev->msft_data;
if (!msft) ...(1) <- passed.
return;
mutex_lock(&msft->filter_lock); ...(4) <- used after freed.
[free]
msft_unregister()
msft = hdev->msft_data;
hdev->msft_data = NULL; ...(2)
kfree(msft); ...(3) <- msft is freed.
==================================================================
BUG: KASAN: slab-use-after-free in __mutex_lock_common
kernel/locking/mutex.c:587 [inline]
BUG: KASAN: slab-use-after-free in __mutex_lock+0x8f/0xc30
kernel/locking/mutex.c:752
Read of size 8 at addr ffff888106cbbca8 by task kworker/u5:2/309 |
["https://git.kernel.org/stable/c/10f9f426ac6e752c8d87bf4346930ba347aaabac","https://git.kernel.org/stable/c/4f1de02de07748da80a8178879bc7a1df37fdf56","https://git.kernel.org/stable/c/a85a60e62355e3bf4802dead7938966824b23940","https://git.kernel.org/stable/c/e3880b531b68f98d3941d83f2f6dd11cf4fd6b76","https://git.kernel.org/stable/c/10f9f426ac6e752c8d87bf4346930ba347aaabac","https://git.kernel.org/stable/c/4f1de02de07748da80a8178879bc7a1df37fdf56","https://git.kernel.org/stable/c/a85a60e62355e3bf4802dead7938966824b23940","https://git.kernel.org/stable/c/e3880b531b68f98d3941d83f2f6dd11cf4fd6b76"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40956
|
High |
fixed |
- 5.15.162
- 6.1.96
- 6.6.36
- 6.9.7
|
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list
Use list_for_each_entry_safe() to allow iterating through the list and
deleting the entry in the iteration process. The descriptor is freed via
idxd_desc_complete() and there's a slight chance may cause issue for
the list iterator when the descriptor is reused by another thread
without it being deleted from the list. |
["https://git.kernel.org/stable/c/1b08bf5a17c66ab7dbb628df5344da53c8e7ab33","https://git.kernel.org/stable/c/83163667d881100a485b6c2daa30301b7f68d9b5","https://git.kernel.org/stable/c/a14968921486793f2a956086895c3793761309dd","https://git.kernel.org/stable/c/e3215deca4520773cd2b155bed164c12365149a7","https://git.kernel.org/stable/c/faa35db78b058a2ab6e074ee283f69fa398c36a8","https://git.kernel.org/stable/c/1b08bf5a17c66ab7dbb628df5344da53c8e7ab33","https://git.kernel.org/stable/c/83163667d881100a485b6c2daa30301b7f68d9b5","https://git.kernel.org/stable/c/a14968921486793f2a956086895c3793761309dd","https://git.kernel.org/stable/c/e3215deca4520773cd2b155bed164c12365149a7","https://git.kernel.org/stable/c/faa35db78b058a2ab6e074ee283f69fa398c36a8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49291
|
High |
fixed |
- 4.14.279
- 4.19.243
- 5.4.193
- 5.10.109
- 5.15.32
- 5.16.18
- 5.17.1
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: Fix races among concurrent hw_params and hw_free calls
Currently we have neither proper check nor protection against the
concurrent calls of PCM hw_params and hw_free ioctls, which may result
in a UAF. Since the existing PCM stream lock can't be used for
protecting the whole ioctl operations, we need a new mutex to protect
those racy calls.
This patch introduced a new mutex, runtime->buffer_mutex, and applies
it to both hw_params and hw_free ioctl code paths. Along with it, the
both functions are slightly modified (the mmap_count check is moved
into the state-check block) for code simplicity. |
["https://git.kernel.org/stable/c/0090c13cbbdffd7da079ac56f80373a9a1be0bf8","https://git.kernel.org/stable/c/0f6947f5f5208f6ebd4d76a82a4757e2839a23f8","https://git.kernel.org/stable/c/1bbf82d9f961414d6c76a08f7f843ea068e0ab7b","https://git.kernel.org/stable/c/33061d0fba51d2bf70a2ef9645f703c33fe8e438","https://git.kernel.org/stable/c/92ee3c60ec9fe64404dc035e7c41277d74aa26cb","https://git.kernel.org/stable/c/9cb6c40a6ebe4a0cfc9d6a181958211682cffea9","https://git.kernel.org/stable/c/a42aa926843acca96c0dfbde2e835b8137f2f092","https://git.kernel.org/stable/c/fbeb492694ce0441053de57699e1e2b7bc148a69"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49388
|
High |
fixed |
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
ubi: ubi_create_volume: Fix use-after-free when volume creation failed
There is an use-after-free problem for 'eba_tbl' in ubi_create_volume()'s
error handling path:
ubi_eba_replace_table(vol, eba_tbl)
vol->eba_tbl = tbl
out_mapping:
ubi_eba_destroy_table(eba_tbl) // Free 'eba_tbl'
out_unlock:
put_device(&vol->dev)
vol_release
kfree(tbl->entries) // UAF
Fix it by removing redundant 'eba_tbl' releasing.
Fetch a reproducer in [Link]. |
["https://git.kernel.org/stable/c/1174ab8ba36a48025b68b5ff1085000b1e510217","https://git.kernel.org/stable/c/25ff1e3a1351c0d936dd1ac2f9e58231ea1510c9","https://git.kernel.org/stable/c/5ff2514e4fb55dcf3d88294686040ca73ea0c1a2","https://git.kernel.org/stable/c/6d8d3f68cbecfd31925796f0fb668eb21ab06734","https://git.kernel.org/stable/c/8302620aeb940f386817321d272b12411ae7d39f","https://git.kernel.org/stable/c/8c03a1c21d72210f81cb369cc528e3fde4b45411","https://git.kernel.org/stable/c/abb67043060f2bf4c03d7c3debb9ae980e2b6db3","https://git.kernel.org/stable/c/e27ecf325e51abd06aaefba57a6322a46fa4178b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49700
|
High |
fixed |
- 4.9.323
- 4.14.288
- 4.19.252
- 5.4.205
- 5.10.130
- 5.15.54
- 5.18.8
|
In the Linux kernel, the following vulnerability has been resolved:
mm/slub: add missing TID updates on slab deactivation
The fastpath in slab_alloc_node() assumes that c->slab is stable as long as
the TID stays the same. However, two places in __slab_alloc() currently
don't update the TID when deactivating the CPU slab.
If multiple operations race the right way, this could lead to an object
getting lost; or, in an even more unlikely situation, it could even lead to
an object being freed onto the wrong slab's freelist, messing up the
`inuse` counter and eventually causing a page to be freed to the page
allocator while it still contains slab objects.
(I haven't actually tested these cases though, this is just based on
looking at the code. Writing testcases for this stuff seems like it'd be
a pain...)
The race leading to state inconsistency is (all operations on the same CPU
and kmem_cache):
- task A: begin do_slab_free():
- read TID
- read pcpu freelist (==NULL)
- check `slab == c->slab` (true)
- [PREEMPT A->B]
- task B: begin slab_alloc_node():
- fastpath fails (`c->freelist` is NULL)
- enter __slab_alloc()
- slub_get_cpu_ptr() (disables preemption)
- enter ___slab_alloc()
- take local_lock_irqsave()
- read c->freelist as NULL
- get_freelist() returns NULL
- write `c->slab = NULL`
- drop local_unlock_irqrestore()
- goto new_slab
- slub_percpu_partial() is NULL
- get_partial() returns NULL
- slub_put_cpu_ptr() (enables preemption)
- [PREEMPT B->A]
- task A: finish do_slab_free():
- this_cpu_cmpxchg_double() succeeds()
- [CORRUPT STATE: c->slab==NULL, c->freelist!=NULL]
From there, the object on c->freelist will get lost if task B is allowed to
continue from here: It will proceed to the retry_load_slab label,
set c->slab, then jump to load_freelist, which clobbers c->freelist.
But if we instead continue as follows, we get worse corruption:
- task A: run __slab_free() on object from other struct slab:
- CPU_PARTIAL_FREE case (slab was on no list, is now on pcpu partial)
- task A: run slab_alloc_node() with NUMA node constraint:
- fastpath fails (c->slab is NULL)
- call __slab_alloc()
- slub_get_cpu_ptr() (disables preemption)
- enter ___slab_alloc()
- c->slab is NULL: goto new_slab
- slub_percpu_partial() is non-NULL
- set c->slab to slub_percpu_partial(c)
- [CORRUPT STATE: c->slab points to slab-1, c->freelist has objects
from slab-2]
- goto redo
- node_match() fails
- goto deactivate_slab
- existing c->freelist is passed into deactivate_slab()
- inuse count of slab-1 is decremented to account for object from
slab-2
At this point, the inuse count of slab-1 is 1 lower than it should be.
This means that if we free all allocated objects in slab-1 except for one,
SLUB will think that slab-1 is completely unused, and may free its page,
leading to use-after-free. |
["https://git.kernel.org/stable/c/0515cc9b6b24877f59b222ade704bfaa42caa2a6","https://git.kernel.org/stable/c/197e257da473c725dfe47759c3ee02f2398d8ea5","https://git.kernel.org/stable/c/308c6d0e1f200fd26c71270c6e6bfcf0fc6ff082","https://git.kernel.org/stable/c/6c32496964da0dc230cea763a0e934b2e02dabd5","https://git.kernel.org/stable/c/d6a597450e686d4c6388bd3cdcb17224b4dae7f0","https://git.kernel.org/stable/c/e2b2f0e2e34d71ae6c2a1114fd3c525930e84bc7","https://git.kernel.org/stable/c/e7e3e90d671078455a3a08189f89d85b3da2de9e","https://git.kernel.org/stable/c/eeaa345e128515135ccb864c04482180c08e3259"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46674
|
High |
fixed |
- 4.19.321
- 5.4.283
- 5.10.225
- 5.15.166
- 6.1.108
- 6.6.49
- 6.10.8
|
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: st: fix probed platform device ref count on probe error path
The probe function never performs any paltform device allocation, thus
error path "undo_platform_dev_alloc" is entirely bogus. It drops the
reference count from the platform device being probed. If error path is
triggered, this will lead to unbalanced device reference counts and
premature release of device resources, thus possible use-after-free when
releasing remaining devm-managed resources. |
["https://git.kernel.org/stable/c/060f41243ad7f6f5249fa7290dda0c01f723d12d","https://git.kernel.org/stable/c/1de989668708ce5875efc9d669d227212aeb9a90","https://git.kernel.org/stable/c/4c6735299540f3c82a5033d35be76a5c42e0fb18","https://git.kernel.org/stable/c/6aee4c5635d81f4809c3b9f0c198a65adfbb2ada","https://git.kernel.org/stable/c/b0979a885b9d4df2a25b88e9d444ccaa5f9f495c","https://git.kernel.org/stable/c/ddfcfeba891064b88bb844208b43bef2ef970f0c","https://git.kernel.org/stable/c/e1e5e8ea2731150d5ba7c707f9e02fafebcfeb49","https://git.kernel.org/stable/c/f3498650df0805c75b4e1c94d07423c46cbf4ce1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52812
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd: check num of link levels when update pcie param
In SR-IOV environment, the value of pcie_table->num_of_link_levels will
be 0, and num_of_levels - 1 will cause array index out of bounds |
["https://git.kernel.org/stable/c/09f617219fe9ccd8d7b65dc3e879b5889f663b5a","https://git.kernel.org/stable/c/2f2d48b6247ae3001f83c98730b3cce475cb2927","https://git.kernel.org/stable/c/406e8845356d18bdf3d3a23b347faf67706472ec","https://git.kernel.org/stable/c/5b4574b663d0a1a0a62d5232429b7db9ae6d0670","https://git.kernel.org/stable/c/09f617219fe9ccd8d7b65dc3e879b5889f663b5a","https://git.kernel.org/stable/c/406e8845356d18bdf3d3a23b347faf67706472ec","https://git.kernel.org/stable/c/5b4574b663d0a1a0a62d5232429b7db9ae6d0670"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26983
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bootconfig: use memblock_free_late to free xbc memory to buddy
On the time to free xbc memory in xbc_exit(), memblock may has handed
over memory to buddy allocator. So it doesn't make sense to free memory
back to memblock. memblock_free() called by xbc_exit() even causes UAF bugs
on architectures with CONFIG_ARCH_KEEP_MEMBLOCK disabled like x86.
Following KASAN logs shows this case.
This patch fixes the xbc memory free problem by calling memblock_free()
in early xbc init error rewind path and calling memblock_free_late() in
xbc exit path to free memory to buddy allocator.
[ 9.410890] ==================================================================
[ 9.418962] BUG: KASAN: use-after-free in memblock_isolate_range+0x12d/0x260
[ 9.426850] Read of size 8 at addr ffff88845dd30000 by task swapper/0/1
[ 9.435901] CPU: 9 PID: 1 Comm: swapper/0 Tainted: G U 6.9.0-rc3-00208-g586b5dfb51b9 #5
[ 9.446403] Hardware name: Intel Corporation RPLP LP5 (CPU:RaptorLake)/RPLP LP5 (ID:13), BIOS IRPPN02.01.01.00.00.19.015.D-00000000 Dec 28 2023
[ 9.460789] Call Trace:
[ 9.463518] <TASK>
[ 9.465859] dump_stack_lvl+0x53/0x70
[ 9.469949] print_report+0xce/0x610
[ 9.473944] ? __virt_addr_valid+0xf5/0x1b0
[ 9.478619] ? memblock_isolate_range+0x12d/0x260
[ 9.483877] kasan_report+0xc6/0x100
[ 9.487870] ? memblock_isolate_range+0x12d/0x260
[ 9.493125] memblock_isolate_range+0x12d/0x260
[ 9.498187] memblock_phys_free+0xb4/0x160
[ 9.502762] ? __pfx_memblock_phys_free+0x10/0x10
[ 9.508021] ? mutex_unlock+0x7e/0xd0
[ 9.512111] ? __pfx_mutex_unlock+0x10/0x10
[ 9.516786] ? kernel_init_freeable+0x2d4/0x430
[ 9.521850] ? __pfx_kernel_init+0x10/0x10
[ 9.526426] xbc_exit+0x17/0x70
[ 9.529935] kernel_init+0x38/0x1e0
[ 9.533829] ? _raw_spin_unlock_irq+0xd/0x30
[ 9.538601] ret_from_fork+0x2c/0x50
[ 9.542596] ? __pfx_kernel_init+0x10/0x10
[ 9.547170] ret_from_fork_asm+0x1a/0x30
[ 9.551552] </TASK>
[ 9.555649] The buggy address belongs to the physical page:
[ 9.561875] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x45dd30
[ 9.570821] flags: 0x200000000000000(node=0|zone=2)
[ 9.576271] page_type: 0xffffffff()
[ 9.580167] raw: 0200000000000000 ffffea0011774c48 ffffea0012ba1848 0000000000000000
[ 9.588823] raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000
[ 9.597476] page dumped because: kasan: bad access detected
[ 9.605362] Memory state around the buggy address:
[ 9.610714] ffff88845dd2ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 9.618786] ffff88845dd2ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 9.626857] >ffff88845dd30000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 9.634930] ^
[ 9.638534] ffff88845dd30080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 9.646605] ffff88845dd30100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 9.654675] ================================================================== |
["https://git.kernel.org/stable/c/1e7feb31a18c197d63a5e606025ed63c762f8918","https://git.kernel.org/stable/c/5a7dfb8fcd3f29fc93161100179b27f24f3d5f35","https://git.kernel.org/stable/c/89f9a1e876b5a7ad884918c03a46831af202c8a0","https://git.kernel.org/stable/c/e46d3be714ad9652480c6db129ab8125e2d20ab7","https://git.kernel.org/stable/c/1e7feb31a18c197d63a5e606025ed63c762f8918","https://git.kernel.org/stable/c/5a7dfb8fcd3f29fc93161100179b27f24f3d5f35","https://git.kernel.org/stable/c/89f9a1e876b5a7ad884918c03a46831af202c8a0","https://git.kernel.org/stable/c/e46d3be714ad9652480c6db129ab8125e2d20ab7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52810
|
High |
fixed |
- 4.14.331
- 4.19.300
- 5.4.262
- 5.10.202
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
fs/jfs: Add check for negative db_l2nbperpage
l2nbperpage is log2(number of blks per page), and the minimum legal
value should be 0, not negative.
In the case of l2nbperpage being negative, an error will occur
when subsequently used as shift exponent.
Syzbot reported this bug:
UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12
shift exponent -16777216 is negative |
["https://git.kernel.org/stable/c/0cb567e727339a192f9fd0db00781d73a91d15a6","https://git.kernel.org/stable/c/1a7c53fdea1d189087544d9a606d249e93c4934b","https://git.kernel.org/stable/c/491085258185ffc4fb91555b0dba895fe7656a45","https://git.kernel.org/stable/c/524b4f203afcf87accfe387e846f33f916f0c907","https://git.kernel.org/stable/c/525b861a008143048535011f3816d407940f4bfa","https://git.kernel.org/stable/c/5f148b16972e5f4592629b244d5109b15135f53f","https://git.kernel.org/stable/c/8f2964df6bfce9d92d81ca552010b8677af8d9dc","https://git.kernel.org/stable/c/a81a56b4cbe3142cc99f6b98e8f9b3a631c768e1","https://git.kernel.org/stable/c/cc61fcf7d1c99f148fe8ddfb5c6ed0bb75861f01","https://git.kernel.org/stable/c/0cb567e727339a192f9fd0db00781d73a91d15a6","https://git.kernel.org/stable/c/1a7c53fdea1d189087544d9a606d249e93c4934b","https://git.kernel.org/stable/c/491085258185ffc4fb91555b0dba895fe7656a45","https://git.kernel.org/stable/c/524b4f203afcf87accfe387e846f33f916f0c907","https://git.kernel.org/stable/c/525b861a008143048535011f3816d407940f4bfa","https://git.kernel.org/stable/c/5f148b16972e5f4592629b244d5109b15135f53f","https://git.kernel.org/stable/c/8f2964df6bfce9d92d81ca552010b8677af8d9dc","https://git.kernel.org/stable/c/a81a56b4cbe3142cc99f6b98e8f9b3a631c768e1","https://git.kernel.org/stable/c/cc61fcf7d1c99f148fe8ddfb5c6ed0bb75861f01"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42309
|
Medium |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes
In psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is
assigned to mode, which will lead to a possible NULL pointer dereference
on failure of drm_mode_duplicate(). Add a check to avoid npd. |
["https://git.kernel.org/stable/c/13b5f3ee94bdbdc4b5f40582aab62977905aedee","https://git.kernel.org/stable/c/2df7aac81070987b0f052985856aa325a38debf6","https://git.kernel.org/stable/c/46d2ef272957879cbe30a884574320e7f7d78692","https://git.kernel.org/stable/c/475a5b3b7c8edf6e583a9eb59cf28ea770602e14","https://git.kernel.org/stable/c/6735d02ead7dd3adf74eb8b70aebd09e0ce78ec9","https://git.kernel.org/stable/c/7e52c62ff029f95005915c0a11863b5fb5185c8c","https://git.kernel.org/stable/c/d6ad202f73f8edba0cbc0065aa57a79ffe8fdcdc","https://git.kernel.org/stable/c/f70ffeca546452d1acd3a70ada56ecb2f3e7f811"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42310
|
Medium |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes
In cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate()
is assigned to mode, which will lead to a NULL pointer dereference on
failure of drm_mode_duplicate(). Add a check to avoid npd. |
["https://git.kernel.org/stable/c/08f45102c81ad8bc9f85f7a25e9f64e128edb87d","https://git.kernel.org/stable/c/2d209b2f862f6b8bff549ede541590a8d119da23","https://git.kernel.org/stable/c/977ee4fe895e1729cd36cc26916bbb10084713d6","https://git.kernel.org/stable/c/a658ae2173ab74667c009e2550455e6de5b33ddc","https://git.kernel.org/stable/c/b6ac46a00188cde50ffba233e6efb366354a1de5","https://git.kernel.org/stable/c/cb520c3f366c77e8d69e4e2e2781a8ce48d98e79","https://git.kernel.org/stable/c/e74eb5e8089427c8c49e0dd5067e5f39ce3a4d56","https://git.kernel.org/stable/c/f392c36cebf4c1d6997a4cc2c0f205254acef42a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43834
|
Medium |
fixed |
- 5.4
- 5.5
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
xdp: fix invalid wait context of page_pool_destroy()
If the driver uses a page pool, it creates a page pool with
page_pool_create().
The reference count of page pool is 1 as default.
A page pool will be destroyed only when a reference count reaches 0.
page_pool_destroy() is used to destroy page pool, it decreases a
reference count.
When a page pool is destroyed, ->disconnect() is called, which is
mem_allocator_disconnect().
This function internally acquires mutex_lock().
If the driver uses XDP, it registers a memory model with
xdp_rxq_info_reg_mem_model().
The xdp_rxq_info_reg_mem_model() internally increases a page pool
reference count if a memory model is a page pool.
Now the reference count is 2.
To destroy a page pool, the driver should call both page_pool_destroy()
and xdp_unreg_mem_model().
The xdp_unreg_mem_model() internally calls page_pool_destroy().
Only page_pool_destroy() decreases a reference count.
If a driver calls page_pool_destroy() then xdp_unreg_mem_model(), we
will face an invalid wait context warning.
Because xdp_unreg_mem_model() calls page_pool_destroy() with
rcu_read_lock().
The page_pool_destroy() internally acquires mutex_lock().
Splat looks like:
=============================
[ BUG: Invalid wait context ]
6.10.0-rc6+ #4 Tainted: G W
-----------------------------
ethtool/1806 is trying to lock:
ffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150
other info that might help us debug this:
context-{5:5}
3 locks held by ethtool/1806:
stack backtrace:
CPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed
Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021
Call Trace:
<TASK>
dump_stack_lvl+0x7e/0xc0
__lock_acquire+0x1681/0x4de0
? _printk+0x64/0xe0
? __pfx_mark_lock.part.0+0x10/0x10
? __pfx___lock_acquire+0x10/0x10
lock_acquire+0x1b3/0x580
? mem_allocator_disconnect+0x73/0x150
? __wake_up_klogd.part.0+0x16/0xc0
? __pfx_lock_acquire+0x10/0x10
? dump_stack_lvl+0x91/0xc0
__mutex_lock+0x15c/0x1690
? mem_allocator_disconnect+0x73/0x150
? __pfx_prb_read_valid+0x10/0x10
? mem_allocator_disconnect+0x73/0x150
? __pfx_llist_add_batch+0x10/0x10
? console_unlock+0x193/0x1b0
? lockdep_hardirqs_on+0xbe/0x140
? __pfx___mutex_lock+0x10/0x10
? tick_nohz_tick_stopped+0x16/0x90
? __irq_work_queue_local+0x1e5/0x330
? irq_work_queue+0x39/0x50
? __wake_up_klogd.part.0+0x79/0xc0
? mem_allocator_disconnect+0x73/0x150
mem_allocator_disconnect+0x73/0x150
? __pfx_mem_allocator_disconnect+0x10/0x10
? mark_held_locks+0xa5/0xf0
? rcu_is_watching+0x11/0xb0
page_pool_release+0x36e/0x6d0
page_pool_destroy+0xd7/0x440
xdp_unreg_mem_model+0x1a7/0x2a0
? __pfx_xdp_unreg_mem_model+0x10/0x10
? kfree+0x125/0x370
? bnxt_free_ring.isra.0+0x2eb/0x500
? bnxt_free_mem+0x5ac/0x2500
xdp_rxq_info_unreg+0x4a/0xd0
bnxt_free_mem+0x1356/0x2500
bnxt_close_nic+0xf0/0x3b0
? __pfx_bnxt_close_nic+0x10/0x10
? ethnl_parse_bit+0x2c6/0x6d0
? __pfx___nla_validate_parse+0x10/0x10
? __pfx_ethnl_parse_bit+0x10/0x10
bnxt_set_features+0x2a8/0x3e0
__netdev_update_features+0x4dc/0x1370
? ethnl_parse_bitset+0x4ff/0x750
? __pfx_ethnl_parse_bitset+0x10/0x10
? __pfx___netdev_update_features+0x10/0x10
? mark_held_locks+0xa5/0xf0
? _raw_spin_unlock_irqrestore+0x42/0x70
? __pm_runtime_resume+0x7d/0x110
ethnl_set_features+0x32d/0xa20
To fix this problem, it uses rhashtable_lookup_fast() instead of
rhashtable_lookup() with rcu_read_lock().
Using xa without rcu_read_lock() here is safe.
xa is freed by __xdp_mem_allocator_rcu_free() and this is called by
call_rcu() of mem_xa_remove().
The mem_xa_remove() is called by page_pool_destroy() if a reference
count reaches 0.
The xa is already protected by the reference count mechanism well in the
control plane.
So removing rcu_read_lock() for page_pool_destroy() is safe. |
["https://git.kernel.org/stable/c/12144069209eec7f2090ce9afa15acdcc2c2a537","https://git.kernel.org/stable/c/3fc1be360b99baeea15cdee3cf94252cd3a72d26","https://git.kernel.org/stable/c/59a931c5b732ca5fc2ca727f5a72aeabaafa85ec","https://git.kernel.org/stable/c/6c390ef198aa69795427a5cb5fd7cb4bc7e6cd7a","https://git.kernel.org/stable/c/be9d08ff102df3ac4f66e826ea935cf3af63a4bd","https://git.kernel.org/stable/c/bf0ce5aa5f2525ed1b921ba36de96e458e77f482"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43860
|
Medium |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
remoteproc: imx_rproc: Skip over memory region when node value is NULL
In imx_rproc_addr_init() "nph = of_count_phandle_with_args()" just counts
number of phandles. But phandles may be empty. So of_parse_phandle() in
the parsing loop (0 < a < nph) may return NULL which is later dereferenced.
Adjust this issue by adding NULL-return check.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
[Fixed title to fit within the prescribed 70-75 charcters] |
["https://git.kernel.org/stable/c/2fa26ca8b786888673689ccc9da6094150939982","https://git.kernel.org/stable/c/4e13b7c23988c0a13fdca92e94296a3bc2ff9f21","https://git.kernel.org/stable/c/6884fd0283e0831be153fb8d82d9eda8a55acaaa","https://git.kernel.org/stable/c/6b50462b473fdccdc0dfad73001147e40ff19a66","https://git.kernel.org/stable/c/6c9ea3547fad252fe9ae5d3ed7e066e2085bf3a2","https://git.kernel.org/stable/c/84beb7738459cac0ff9f8a7c4654b8ff82a702c0","https://git.kernel.org/stable/c/9a17cf8b2ce483fa75258bc2cdcf628f24bcf5f8","https://git.kernel.org/stable/c/c877a5f5268d4ab8224b9c9fbce3d746e4e72bc9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44988
|
Medium |
fixed |
- 4.20
- 5.0
- 5.4.283
- 5.10.225
- 5.15.166
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: mv88e6xxx: Fix out-of-bound access
If an ATU violation was caused by a CPU Load operation, the SPID could
be larger than DSA_MAX_PORTS (the size of mv88e6xxx_chip.ports[] array). |
["https://git.kernel.org/stable/c/050e7274ab2150cd212b2372595720e7b83a15bd","https://git.kernel.org/stable/c/18b2e833daf049223ab3c2efdf8cdee08854c484","https://git.kernel.org/stable/c/4a88fca95c8df3746b71e31f44a02d35f06f9864","https://git.kernel.org/stable/c/528876d867a23b5198022baf2e388052ca67c952","https://git.kernel.org/stable/c/a10d0337115a6d223a1563d853d4455f05d0b2e3","https://git.kernel.org/stable/c/d39f5be62f098fe367d672b4dd4bc4b2b80e08e7","https://git.kernel.org/stable/c/f7d8c2fabd39250cf2333fbf8eef67e837f90a5d","https://git.kernel.org/stable/c/f87ce03c652dba199aef15ac18ade3991db5477e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-45021
|
Medium |
fixed |
- 4.19.321
- 5.4.283
- 5.10.225
- 5.15.166
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
memcg_write_event_control(): fix a user-triggerable oops
we are *not* guaranteed that anything past the terminating NUL
is mapped (let alone initialized with anything sane). |
["https://git.kernel.org/stable/c/046667c4d3196938e992fba0dfcde570aa85cd0e","https://git.kernel.org/stable/c/0fbe2a72e853a1052abe9bc2b7df8ddb102da227","https://git.kernel.org/stable/c/1b37ec85ad95b612307627758c6018cd9d92cca8","https://git.kernel.org/stable/c/21b578f1d599edb87462f11113c5b0fc7a04ac61","https://git.kernel.org/stable/c/43768fa80fd192558737e24ed6548f74554611d7","https://git.kernel.org/stable/c/ad149f5585345e383baa65f1539d816cd715fd3b","https://git.kernel.org/stable/c/f1aa7c509aa766080db7ab3aec2e31b1df09e57c","https://git.kernel.org/stable/c/fa5bfdf6cb5846a00e712d630a43e3cf55ccb411"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46677
|
Medium |
fixed |
- 4.19.321
- 5.4.283
- 5.10.225
- 5.15.166
- 6.1.108
- 6.6.49
- 6.10.8
|
In the Linux kernel, the following vulnerability has been resolved:
gtp: fix a potential NULL pointer dereference
When sockfd_lookup() fails, gtp_encap_enable_socket() returns a
NULL pointer, but its callers only check for error pointers thus miss
the NULL pointer case.
Fix it by returning an error pointer with the error code carried from
sockfd_lookup().
(I found this bug during code inspection.) |
["https://git.kernel.org/stable/c/28c67f0f84f889fe9f4cbda8354132b20dc9212d","https://git.kernel.org/stable/c/4643b91691e969b1b9ad54bf552d7a990cfa3b87","https://git.kernel.org/stable/c/612edd35f2a3910ab1f61c1f2338889d4ba99fa2","https://git.kernel.org/stable/c/620fe9809752fae91b4190e897b81ed9976dfb39","https://git.kernel.org/stable/c/8bbb9e4e0e66a39282e582d0440724055404b38c","https://git.kernel.org/stable/c/bdd99e5f0ad5fa727b16f2101fe880aa2bff2f8e","https://git.kernel.org/stable/c/defd8b3c37b0f9cb3e0f60f47d3d78d459d57fda","https://git.kernel.org/stable/c/e8b9930b0eb045d19e883c65ff9676fc89320c70"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1194
|
High |
fixed |
|
An out-of-bounds (OOB) memory read flaw was found in parse_lease_state in the KSMBD implementation of the in-kernel samba server and CIFS in the Linux kernel. When an attacker sends the CREATE command with a malformed payload to KSMBD, due to a missing check of `NameOffset` in the `parse_lease_state()` function, the `create_context` object can access invalid memory. |
["https://access.redhat.com/security/cve/CVE-2023-1194","https://bugzilla.redhat.com/show_bug.cgi?id=2154176","https://security.netapp.com/advisory/ntap-20231221-0006/","https://www.spinics.net/lists/stable-commits/msg303065.html","https://access.redhat.com/security/cve/CVE-2023-1194","https://bugzilla.redhat.com/show_bug.cgi?id=2154176","https://security.netapp.com/advisory/ntap-20231221-0006/","https://www.spinics.net/lists/stable-commits/msg303065.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42224
|
Medium |
fixed |
- 4.19.318
- 5.4.280
- 5.10.222
- 5.15.163
- 6.1.98
- 6.6.39
- 6.9.9
|
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: mv88e6xxx: Correct check for empty list
Since commit a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIO
busses") mv88e6xxx_default_mdio_bus() has checked that the
return value of list_first_entry() is non-NULL.
This appears to be intended to guard against the list chip->mdios being
empty. However, it is not the correct check as the implementation of
list_first_entry is not designed to return NULL for empty lists.
Instead, use list_first_entry_or_null() which does return NULL if the
list is empty.
Flagged by Smatch.
Compile tested only. |
["https://git.kernel.org/stable/c/2a2fe25a103cef73cde356e6d09da10f607e93f5","https://git.kernel.org/stable/c/3bf8d70e1455f87856640c3433b3660a31001618","https://git.kernel.org/stable/c/3f25b5f1635449036692a44b771f39f772190c1d","https://git.kernel.org/stable/c/47d28dde172696031c880c5778633cdca30394ee","https://git.kernel.org/stable/c/4c7f3950a9fd53a62b156c0fe7c3a2c43b0ba19b","https://git.kernel.org/stable/c/8c2c3cca816d074c75a2801d1ca0dea7b0148114","https://git.kernel.org/stable/c/aa03f591ef31ba603a4a99d05d25a0f21ab1cd89","https://git.kernel.org/stable/c/f75625db838ade28f032dacd0f0c8baca42ecde4","https://git.kernel.org/stable/c/2a2fe25a103cef73cde356e6d09da10f607e93f5","https://git.kernel.org/stable/c/3bf8d70e1455f87856640c3433b3660a31001618","https://git.kernel.org/stable/c/3f25b5f1635449036692a44b771f39f772190c1d","https://git.kernel.org/stable/c/47d28dde172696031c880c5778633cdca30394ee","https://git.kernel.org/stable/c/4c7f3950a9fd53a62b156c0fe7c3a2c43b0ba19b","https://git.kernel.org/stable/c/8c2c3cca816d074c75a2801d1ca0dea7b0148114","https://git.kernel.org/stable/c/aa03f591ef31ba603a4a99d05d25a0f21ab1cd89","https://git.kernel.org/stable/c/f75625db838ade28f032dacd0f0c8baca42ecde4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48702
|
High |
fixed |
- 4.9.328
- 4.14.293
- 4.19.258
- 5.4.213
- 5.10.143
- 5.15.68
- 5.19.9
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc()
The voice allocator sometimes begins allocating from near the end of the
array and then wraps around, however snd_emu10k1_pcm_channel_alloc()
accesses the newly allocated voices as if it never wrapped around.
This results in out of bounds access if the first voice has a high enough
index so that first_voice + requested_voice_count > NUM_G (64).
The more voices are requested, the more likely it is for this to occur.
This was initially discovered using PipeWire, however it can be reproduced
by calling aplay multiple times with 16 channels:
aplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero
UBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40
index 65 is out of range for type 'snd_emu10k1_voice [64]'
CPU: 1 PID: 31977 Comm: aplay Tainted: G W IOE 6.0.0-rc2-emu10k1+ #7
Hardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002 07/22/2010
Call Trace:
<TASK>
dump_stack_lvl+0x49/0x63
dump_stack+0x10/0x16
ubsan_epilogue+0x9/0x3f
__ubsan_handle_out_of_bounds.cold+0x44/0x49
snd_emu10k1_playback_hw_params+0x3bc/0x420 [snd_emu10k1]
snd_pcm_hw_params+0x29f/0x600 [snd_pcm]
snd_pcm_common_ioctl+0x188/0x1410 [snd_pcm]
? exit_to_user_mode_prepare+0x35/0x170
? do_syscall_64+0x69/0x90
? syscall_exit_to_user_mode+0x26/0x50
? do_syscall_64+0x69/0x90
? exit_to_user_mode_prepare+0x35/0x170
snd_pcm_ioctl+0x27/0x40 [snd_pcm]
__x64_sys_ioctl+0x95/0xd0
do_syscall_64+0x5c/0x90
? do_syscall_64+0x69/0x90
? do_syscall_64+0x69/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd |
["https://git.kernel.org/stable/c/39a90720f3abe96625d1224e7a7463410875de4c","https://git.kernel.org/stable/c/4204a01ffce97cae1d59edc5848f02be5b2b9178","https://git.kernel.org/stable/c/45321a7d02b7cf9b3f97e3987fc1e4d649b82da2","https://git.kernel.org/stable/c/45814a53514e10a8014906c882e0d0d38df39cc1","https://git.kernel.org/stable/c/637c5310acb48fffcc5657568db3f3e9bc719bfa","https://git.kernel.org/stable/c/6b0e260ac3cf289e38446552461caa65e6dab275","https://git.kernel.org/stable/c/88aac6684cf8bc885cca15463cb4407e91f28ff7","https://git.kernel.org/stable/c/d29f59051d3a07b81281b2df2b8c9dfe4716067f","https://git.kernel.org/stable/c/39a90720f3abe96625d1224e7a7463410875de4c","https://git.kernel.org/stable/c/4204a01ffce97cae1d59edc5848f02be5b2b9178","https://git.kernel.org/stable/c/45321a7d02b7cf9b3f97e3987fc1e4d649b82da2","https://git.kernel.org/stable/c/45814a53514e10a8014906c882e0d0d38df39cc1","https://git.kernel.org/stable/c/637c5310acb48fffcc5657568db3f3e9bc719bfa","https://git.kernel.org/stable/c/6b0e260ac3cf289e38446552461caa65e6dab275","https://git.kernel.org/stable/c/88aac6684cf8bc885cca15463cb4407e91f28ff7","https://git.kernel.org/stable/c/d29f59051d3a07b81281b2df2b8c9dfe4716067f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52840
|
High |
fixed |
- 4.19.299
- 5.4.261
- 5.10.201
- 5.15.139
- 6.1.63
- 6.5.12
- 6.6.2
|
In the Linux kernel, the following vulnerability has been resolved:
Input: synaptics-rmi4 - fix use after free in rmi_unregister_function()
The put_device() calls rmi_release_function() which frees "fn" so the
dereference on the next line "fn->num_of_irqs" is a use after free.
Move the put_device() to the end to fix this. |
["https://git.kernel.org/stable/c/2f236d8638f5b43e0c72919a6a27fe286c32053f","https://git.kernel.org/stable/c/303766bb92c5c225cf40f9bbbe7e29749406e2f2","https://git.kernel.org/stable/c/50d12253666195a14c6cd2b81c376e2dbeedbdff","https://git.kernel.org/stable/c/6c71e065befb2fae8f1461559b940c04e1071bd5","https://git.kernel.org/stable/c/7082b1fb5321037bc11ba1cf2d7ed23c6b2b521f","https://git.kernel.org/stable/c/c8e639f5743cf4b01f8c65e0df075fe4d782b585","https://git.kernel.org/stable/c/cc56c4d17721dcb10ad4e9c9266e449be1462683","https://git.kernel.org/stable/c/eb988e46da2e4eae89f5337e047ce372fe33d5b1","https://git.kernel.org/stable/c/2f236d8638f5b43e0c72919a6a27fe286c32053f","https://git.kernel.org/stable/c/303766bb92c5c225cf40f9bbbe7e29749406e2f2","https://git.kernel.org/stable/c/50d12253666195a14c6cd2b81c376e2dbeedbdff","https://git.kernel.org/stable/c/6c71e065befb2fae8f1461559b940c04e1071bd5","https://git.kernel.org/stable/c/7082b1fb5321037bc11ba1cf2d7ed23c6b2b521f","https://git.kernel.org/stable/c/c8e639f5743cf4b01f8c65e0df075fe4d782b585","https://git.kernel.org/stable/c/cc56c4d17721dcb10ad4e9c9266e449be1462683","https://git.kernel.org/stable/c/eb988e46da2e4eae89f5337e047ce372fe33d5b1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38545
|
High |
fixed |
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix UAF for cq async event
The refcount of CQ is not protected by locks. When CQ asynchronous
events and CQ destruction are concurrent, CQ may have been released,
which will cause UAF.
Use the xa_lock() to protect the CQ refcount. |
["https://git.kernel.org/stable/c/330c825e66ef65278e4ebe57fd49c1d6f3f4e34e","https://git.kernel.org/stable/c/37a7559dc1358a8d300437e99ed8ecdab0671507","https://git.kernel.org/stable/c/39d26cf46306bdc7ae809ecfdbfeff5aa1098911","https://git.kernel.org/stable/c/63da190eeb5c9d849b71f457b15b308c94cbaf08","https://git.kernel.org/stable/c/763780ef0336a973e933e40e919339381732dcaf","https://git.kernel.org/stable/c/a942ec2745ca864cd8512142100e4027dc306a42","https://git.kernel.org/stable/c/37a7559dc1358a8d300437e99ed8ecdab0671507","https://git.kernel.org/stable/c/39d26cf46306bdc7ae809ecfdbfeff5aa1098911","https://git.kernel.org/stable/c/63da190eeb5c9d849b71f457b15b308c94cbaf08","https://git.kernel.org/stable/c/763780ef0336a973e933e40e919339381732dcaf","https://git.kernel.org/stable/c/a942ec2745ca864cd8512142100e4027dc306a42"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38588
|
High |
fixed |
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix possible use-after-free issue in ftrace_location()
KASAN reports a bug:
BUG: KASAN: use-after-free in ftrace_location+0x90/0x120
Read of size 8 at addr ffff888141d40010 by task insmod/424
CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+
[...]
Call Trace:
<TASK>
dump_stack_lvl+0x68/0xa0
print_report+0xcf/0x610
kasan_report+0xb5/0xe0
ftrace_location+0x90/0x120
register_kprobe+0x14b/0xa40
kprobe_init+0x2d/0xff0 [kprobe_example]
do_one_initcall+0x8f/0x2d0
do_init_module+0x13a/0x3c0
load_module+0x3082/0x33d0
init_module_from_file+0xd2/0x130
__x64_sys_finit_module+0x306/0x440
do_syscall_64+0x68/0x140
entry_SYSCALL_64_after_hwframe+0x71/0x79
The root cause is that, in lookup_rec(), ftrace record of some address
is being searched in ftrace pages of some module, but those ftrace pages
at the same time is being freed in ftrace_release_mod() as the
corresponding module is being deleted:
CPU1 | CPU2
register_kprobes() { | delete_module() {
check_kprobe_address_safe() { |
arch_check_ftrace_location() { |
ftrace_location() { |
lookup_rec() // USE! | ftrace_release_mod() // Free!
To fix this issue:
1. Hold rcu lock as accessing ftrace pages in ftrace_location_range();
2. Use ftrace_location_range() instead of lookup_rec() in
ftrace_location();
3. Call synchronize_rcu() before freeing any ftrace pages both in
ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem(). |
["https://git.kernel.org/stable/c/1880a324af1c95940a7c954b6b937e86844a33bd","https://git.kernel.org/stable/c/31310e373f4c8c74e029d4326b283e757edabc0b","https://git.kernel.org/stable/c/66df065b3106964e667b37bf8f7e55ec69d0c1f6","https://git.kernel.org/stable/c/7b4881da5b19f65709f5c18c1a4d8caa2e496461","https://git.kernel.org/stable/c/8ea8ef5e42173560ac510e92a1cc797ffeea8831","https://git.kernel.org/stable/c/dbff5f0bfb2416b8b55c105ddbcd4f885e98fada","https://git.kernel.org/stable/c/e60b613df8b6253def41215402f72986fee3fc8d","https://git.kernel.org/stable/c/eea46baf145150910ba134f75a67106ba2222c1b","https://git.kernel.org/stable/c/31310e373f4c8c74e029d4326b283e757edabc0b","https://git.kernel.org/stable/c/66df065b3106964e667b37bf8f7e55ec69d0c1f6","https://git.kernel.org/stable/c/7b4881da5b19f65709f5c18c1a4d8caa2e496461","https://git.kernel.org/stable/c/8ea8ef5e42173560ac510e92a1cc797ffeea8831","https://git.kernel.org/stable/c/dbff5f0bfb2416b8b55c105ddbcd4f885e98fada","https://git.kernel.org/stable/c/e60b613df8b6253def41215402f72986fee3fc8d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41087
|
High |
fixed |
- 4.19.317
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.97
- 6.6.37
- 6.9.8
|
In the Linux kernel, the following vulnerability has been resolved:
ata: libata-core: Fix double free on error
If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump
to the err_out label, which will call devres_release_group().
devres_release_group() will trigger a call to ata_host_release().
ata_host_release() calls kfree(host), so executing the kfree(host) in
ata_host_alloc() will lead to a double free:
kernel BUG at mm/slub.c:553!
Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:kfree+0x2cf/0x2f0
Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da
RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246
RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320
RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0
RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000
R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780
R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006
FS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
<TASK>
? __die_body.cold+0x19/0x27
? die+0x2e/0x50
? do_trap+0xca/0x110
? do_error_trap+0x6a/0x90
? kfree+0x2cf/0x2f0
? exc_invalid_op+0x50/0x70
? kfree+0x2cf/0x2f0
? asm_exc_invalid_op+0x1a/0x20
? ata_host_alloc+0xf5/0x120 [libata]
? ata_host_alloc+0xf5/0x120 [libata]
? kfree+0x2cf/0x2f0
ata_host_alloc+0xf5/0x120 [libata]
ata_host_alloc_pinfo+0x14/0xa0 [libata]
ahci_init_one+0x6c9/0xd20 [ahci]
Ensure that we will not call kfree(host) twice, by performing the kfree()
only if the devres_open_group() call failed. |
["https://git.kernel.org/stable/c/010de9acbea58fbcbda08e3793d6262086a493fe","https://git.kernel.org/stable/c/062e256516d7db5e7dcdef117f52025cd5c456e3","https://git.kernel.org/stable/c/290073b2b557e4dc21ee74a1e403d9ae79e393a2","https://git.kernel.org/stable/c/56f1c7e290cd6c69c948fcd2e2a49e6a637ec38f","https://git.kernel.org/stable/c/5dde5f8b790274723640d29a07c5a97d57d62047","https://git.kernel.org/stable/c/702c1edbafb2e6f9d20f6d391273b5be09d366a5","https://git.kernel.org/stable/c/8106da4d88bbaed809e023cc8014b766223d6e76","https://git.kernel.org/stable/c/ab9e0c529eb7cafebdd31fe1644524e80a48b05d","https://git.kernel.org/stable/c/010de9acbea58fbcbda08e3793d6262086a493fe","https://git.kernel.org/stable/c/062e256516d7db5e7dcdef117f52025cd5c456e3","https://git.kernel.org/stable/c/290073b2b557e4dc21ee74a1e403d9ae79e393a2","https://git.kernel.org/stable/c/56f1c7e290cd6c69c948fcd2e2a49e6a637ec38f","https://git.kernel.org/stable/c/5dde5f8b790274723640d29a07c5a97d57d62047","https://git.kernel.org/stable/c/702c1edbafb2e6f9d20f6d391273b5be09d366a5","https://git.kernel.org/stable/c/8106da4d88bbaed809e023cc8014b766223d6e76","https://git.kernel.org/stable/c/ab9e0c529eb7cafebdd31fe1644524e80a48b05d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39495
|
High |
fixed |
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.95
- 6.6.35
- 6.9.6
|
In the Linux kernel, the following vulnerability has been resolved:
greybus: Fix use-after-free bug in gb_interface_release due to race condition.
In gb_interface_create, &intf->mode_switch_completion is bound with
gb_interface_mode_switch_work. Then it will be started by
gb_interface_request_mode_switch. Here is the relevant code.
if (!queue_work(system_long_wq, &intf->mode_switch_work)) {
...
}
If we call gb_interface_release to make cleanup, there may be an
unfinished work. This function will call kfree to free the object
"intf". However, if gb_interface_mode_switch_work is scheduled to
run after kfree, it may cause use-after-free error as
gb_interface_mode_switch_work will use the object "intf".
The possible execution flow that may lead to the issue is as follows:
CPU0 CPU1
| gb_interface_create
| gb_interface_request_mode_switch
gb_interface_release |
kfree(intf) (free) |
| gb_interface_mode_switch_work
| mutex_lock(&intf->mutex) (use)
Fix it by canceling the work before kfree. |
["https://git.kernel.org/stable/c/03ea2b129344152157418929f06726989efc0445","https://git.kernel.org/stable/c/0b8fba38bdfb848fac52e71270b2aa3538c996ea","https://git.kernel.org/stable/c/2b6bb0b4abfd79b8698ee161bb73c0936a2aaf83","https://git.kernel.org/stable/c/5c9c5d7f26acc2c669c1dcf57d1bb43ee99220ce","https://git.kernel.org/stable/c/74cd0a421896b2e07eafe7da4275302bfecef201","https://git.kernel.org/stable/c/9a733d69a4a59c2d08620e6589d823c24be773dc","https://git.kernel.org/stable/c/fb071f5c75d4b1c177824de74ee75f9dd34123b9","https://git.kernel.org/stable/c/03ea2b129344152157418929f06726989efc0445","https://git.kernel.org/stable/c/0b8fba38bdfb848fac52e71270b2aa3538c996ea","https://git.kernel.org/stable/c/2b6bb0b4abfd79b8698ee161bb73c0936a2aaf83","https://git.kernel.org/stable/c/5c9c5d7f26acc2c669c1dcf57d1bb43ee99220ce","https://git.kernel.org/stable/c/74cd0a421896b2e07eafe7da4275302bfecef201","https://git.kernel.org/stable/c/9a733d69a4a59c2d08620e6589d823c24be773dc","https://git.kernel.org/stable/c/fb071f5c75d4b1c177824de74ee75f9dd34123b9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26748
|
High |
fixed |
- 5.4.270
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: fix memory double free when handle zero packet
829 if (request->complete) {
830 spin_unlock(&priv_dev->lock);
831 usb_gadget_giveback_request(&priv_ep->endpoint,
832 request);
833 spin_lock(&priv_dev->lock);
834 }
835
836 if (request->buf == priv_dev->zlp_buf)
837 cdns3_gadget_ep_free_request(&priv_ep->endpoint, request);
Driver append an additional zero packet request when queue a packet, which
length mod max packet size is 0. When transfer complete, run to line 831,
usb_gadget_giveback_request() will free this requestion. 836 condition is
true, so cdns3_gadget_ep_free_request() free this request again.
Log:
[ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3]
[ 1920.140696][ T150]
[ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36):
[ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3]
[ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3]
Add check at line 829, skip call usb_gadget_giveback_request() if it is
additional zero length packet request. Needn't call
usb_gadget_giveback_request() because it is allocated in this driver. |
["https://git.kernel.org/stable/c/1e204a8e9eb514e22a6567fb340ebb47df3f3a48","https://git.kernel.org/stable/c/3a2a909942b5335b7ea66366d84261b3ed5f89c8","https://git.kernel.org/stable/c/5fd9e45f1ebcd57181358af28506e8a661a260b3","https://git.kernel.org/stable/c/70e8038813f9d3e72df966748ebbc40efe466019","https://git.kernel.org/stable/c/92d20406a3d4ff3e8be667c79209dc9ed31df5b3","https://git.kernel.org/stable/c/9a52b694b066f299d8b9800854a8503457a8b64c","https://git.kernel.org/stable/c/aad6132ae6e4809e375431f8defd1521985e44e7","https://git.kernel.org/stable/c/1e204a8e9eb514e22a6567fb340ebb47df3f3a48","https://git.kernel.org/stable/c/3a2a909942b5335b7ea66366d84261b3ed5f89c8","https://git.kernel.org/stable/c/5fd9e45f1ebcd57181358af28506e8a661a260b3","https://git.kernel.org/stable/c/70e8038813f9d3e72df966748ebbc40efe466019","https://git.kernel.org/stable/c/92d20406a3d4ff3e8be667c79209dc9ed31df5b3","https://git.kernel.org/stable/c/9a52b694b066f299d8b9800854a8503457a8b64c","https://git.kernel.org/stable/c/aad6132ae6e4809e375431f8defd1521985e44e7","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26749
|
High |
fixed |
- 5.4.270
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable()
...
cdns3_gadget_ep_free_request(&priv_ep->endpoint, &priv_req->request);
list_del_init(&priv_req->list);
...
'priv_req' actually free at cdns3_gadget_ep_free_request(). But
list_del_init() use priv_req->list after it.
[ 1542.642868][ T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4
[ 1542.642868][ T534]
[ 1542.653162][ T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3):
[ 1542.660311][ T534] __list_del_entry_valid+0x10/0xd4
[ 1542.665375][ T534] cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3]
[ 1542.671571][ T534] usb_ep_disable+0x44/0xe4
[ 1542.675948][ T534] ffs_func_eps_disable+0x64/0xc8
[ 1542.680839][ T534] ffs_func_set_alt+0x74/0x368
[ 1542.685478][ T534] ffs_func_disable+0x18/0x28
Move list_del_init() before cdns3_gadget_ep_free_request() to resolve this
problem. |
["https://git.kernel.org/stable/c/2134e9906e17b1e5284300fab547869ebacfd7d9","https://git.kernel.org/stable/c/29e42e1578a10c611b3f1a38f3229b2d664b5d16","https://git.kernel.org/stable/c/4e5c73b15d95452c1ba9c771dd013a3fbe052ff3","https://git.kernel.org/stable/c/9a07244f614bc417de527b799da779dcae780b5d","https://git.kernel.org/stable/c/b40328eea93c75a5645891408010141a0159f643","https://git.kernel.org/stable/c/cd45f99034b0c8c9cb346dd0d6407a95ca3d36f6","https://git.kernel.org/stable/c/cfa9abb5570c489dabf6f7fb3a066cc576fc8824","https://git.kernel.org/stable/c/2134e9906e17b1e5284300fab547869ebacfd7d9","https://git.kernel.org/stable/c/29e42e1578a10c611b3f1a38f3229b2d664b5d16","https://git.kernel.org/stable/c/4e5c73b15d95452c1ba9c771dd013a3fbe052ff3","https://git.kernel.org/stable/c/9a07244f614bc417de527b799da779dcae780b5d","https://git.kernel.org/stable/c/b40328eea93c75a5645891408010141a0159f643","https://git.kernel.org/stable/c/cd45f99034b0c8c9cb346dd0d6407a95ca3d36f6","https://git.kernel.org/stable/c/cfa9abb5570c489dabf6f7fb3a066cc576fc8824","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52906
|
High |
fixed |
- 5.4.229
- 5.10.164
- 5.15.89
- 6.1.7
|
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_mpls: Fix warning during failed attribute validation
The 'TCA_MPLS_LABEL' attribute is of 'NLA_U32' type, but has a
validation type of 'NLA_VALIDATE_FUNCTION'. This is an invalid
combination according to the comment above 'struct nla_policy':
"
Meaning of `validate' field, use via NLA_POLICY_VALIDATE_FN:
NLA_BINARY Validation function called for the attribute.
All other Unused - but note that it's a union
"
This can trigger the warning [1] in nla_get_range_unsigned() when
validation of the attribute fails. Despite being of 'NLA_U32' type, the
associated 'min'/'max' fields in the policy are negative as they are
aliased by the 'validate' field.
Fix by changing the attribute type to 'NLA_BINARY' which is consistent
with the above comment and all other users of NLA_POLICY_VALIDATE_FN().
As a result, move the length validation to the validation function.
No regressions in MPLS tests:
# ./tdc.py -f tc-tests/actions/mpls.json
[...]
# echo $?
0
[1]
WARNING: CPU: 0 PID: 17743 at lib/nlattr.c:118
nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117
Modules linked in:
CPU: 0 PID: 17743 Comm: syz-executor.0 Not tainted 6.1.0-rc8 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014
RIP: 0010:nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117
[...]
Call Trace:
<TASK>
__netlink_policy_dump_write_attr+0x23d/0x990 net/netlink/policy.c:310
netlink_policy_dump_write_attr+0x22/0x30 net/netlink/policy.c:411
netlink_ack_tlv_fill net/netlink/af_netlink.c:2454 [inline]
netlink_ack+0x546/0x760 net/netlink/af_netlink.c:2506
netlink_rcv_skb+0x1b7/0x240 net/netlink/af_netlink.c:2546
rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:6109
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1921
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg net/socket.c:734 [inline]
____sys_sendmsg+0x38f/0x500 net/socket.c:2482
___sys_sendmsg net/socket.c:2536 [inline]
__sys_sendmsg+0x197/0x230 net/socket.c:2565
__do_sys_sendmsg net/socket.c:2574 [inline]
__se_sys_sendmsg net/socket.c:2572 [inline]
__x64_sys_sendmsg+0x42/0x50 net/socket.c:2572
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd |
["https://git.kernel.org/stable/c/2b157c3c5d6b8ddca48d53c9e662032f65af8d61","https://git.kernel.org/stable/c/453277feb41c2235cf2c0de9209eef962c401457","https://git.kernel.org/stable/c/8a97b544b98e44f596219ebb290fd2ba2fd5d644","https://git.kernel.org/stable/c/9e17f99220d111ea031b44153fdfe364b0024ff2","https://git.kernel.org/stable/c/9e2c38827cdc6fdd3bb375c8607fc04d289756f9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43873
|
High |
fixed |
- 5.15.165
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
vhost/vsock: always initialize seqpacket_allow
There are two issues around seqpacket_allow:
1. seqpacket_allow is not initialized when socket is
created. Thus if features are never set, it will be
read uninitialized.
2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared,
then seqpacket_allow will not be cleared appropriately
(existing apps I know about don't usually do this but
it's legal and there's no way to be sure no one relies
on this).
To fix:
- initialize seqpacket_allow after allocation
- set it unconditionally in set_features |
["https://git.kernel.org/stable/c/1e1fdcbdde3b7663e5d8faeb2245b9b151417d22","https://git.kernel.org/stable/c/3062cb100787a9ddf45de30004b962035cd497fb","https://git.kernel.org/stable/c/30bd4593669443ac58515e23557dc8cef70d8582","https://git.kernel.org/stable/c/ea558f10fb05a6503c6e655a1b7d81fdf8e5924c","https://git.kernel.org/stable/c/eab96e8716cbfc2834b54f71cc9501ad4eec963b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2019-14899
|
High |
|
N/A
|
A vulnerability was discovered in Linux, FreeBSD, OpenBSD, MacOS, iOS, and Android that allows a malicious access point, or an adjacent user, to determine if a connected user is using a VPN, make positive inferences about the websites they are visiting, and determine the correct sequence and acknowledgement numbers in use, allowing the bad actor to inject data into the TCP stream. This provides everything that is needed for an attacker to hijack active connections inside the VPN tunnel. |
["http://seclists.org/fulldisclosure/2020/Dec/32","http://seclists.org/fulldisclosure/2020/Jul/23","http://seclists.org/fulldisclosure/2020/Jul/24","http://seclists.org/fulldisclosure/2020/Jul/25","http://seclists.org/fulldisclosure/2020/Nov/20","http://www.openwall.com/lists/oss-security/2020/08/13/2","http://www.openwall.com/lists/oss-security/2020/10/07/3","http://www.openwall.com/lists/oss-security/2021/07/05/1","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-14899","https://openvpn.net/security-advisory/no-flaws-found-in-openvpn-software/","https://support.apple.com/kb/HT211288","https://support.apple.com/kb/HT211289","https://support.apple.com/kb/HT211290","https://support.apple.com/kb/HT211850","https://support.apple.com/kb/HT211931","http://seclists.org/fulldisclosure/2020/Dec/32","http://seclists.org/fulldisclosure/2020/Jul/23","http://seclists.org/fulldisclosure/2020/Jul/24","http://seclists.org/fulldisclosure/2020/Jul/25","http://seclists.org/fulldisclosure/2020/Nov/20","http://www.openwall.com/lists/oss-security/2020/08/13/2","http://www.openwall.com/lists/oss-security/2020/10/07/3","http://www.openwall.com/lists/oss-security/2021/07/05/1","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-14899","https://openvpn.net/security-advisory/no-flaws-found-in-openvpn-software/","https://support.apple.com/kb/HT211288","https://support.apple.com/kb/HT211289","https://support.apple.com/kb/HT211290","https://support.apple.com/kb/HT211850","https://support.apple.com/kb/HT211931"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44982
|
Medium |
fixed |
- 5.15.166
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dpu: cleanup FB if dpu_format_populate_layout fails
If the dpu_format_populate_layout() fails, then FB is prepared, but not
cleaned up. This ends up leaking the pin_count on the GEM object and
causes a splat during DRM file closure:
msm_obj->pin_count
WARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc
[...]
Call trace:
update_lru_locked+0xc4/0xcc
put_pages+0xac/0x100
msm_gem_free_object+0x138/0x180
drm_gem_object_free+0x1c/0x30
drm_gem_object_handle_put_unlocked+0x108/0x10c
drm_gem_object_release_handle+0x58/0x70
idr_for_each+0x68/0xec
drm_gem_release+0x28/0x40
drm_file_free+0x174/0x234
drm_release+0xb0/0x160
__fput+0xc0/0x2c8
__fput_sync+0x50/0x5c
__arm64_sys_close+0x38/0x7c
invoke_syscall+0x48/0x118
el0_svc_common.constprop.0+0x40/0xe0
do_el0_svc+0x1c/0x28
el0_svc+0x4c/0x120
el0t_64_sync_handler+0x100/0x12c
el0t_64_sync+0x190/0x194
irq event stamp: 129818
hardirqs last enabled at (129817): [<ffffa5f6d953fcc0>] console_unlock+0x118/0x124
hardirqs last disabled at (129818): [<ffffa5f6da7dcf04>] el1_dbg+0x24/0x8c
softirqs last enabled at (129808): [<ffffa5f6d94afc18>] handle_softirqs+0x4c8/0x4e8
softirqs last disabled at (129785): [<ffffa5f6d94105e4>] __do_softirq+0x14/0x20
Patchwork: https://patchwork.freedesktop.org/patch/600714/ |
["https://git.kernel.org/stable/c/02193c70723118889281f75b88722b26b58bf4ae","https://git.kernel.org/stable/c/7ecf85542169012765e4c2817cd3be6c2e009962","https://git.kernel.org/stable/c/9b8b65211a880af8fe8330a101e1e239a2d4008f","https://git.kernel.org/stable/c/a3c5815b07f4ee19d0b7e2ddf91ff9f03ecbf27d","https://git.kernel.org/stable/c/bfa1a6283be390947d3649c482e5167186a37016"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26980
|
Medium |
fixed |
- 5.15.159
- 6.1.88
- 6.6.29
- 6.8.8
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix slab-out-of-bounds in smb2_allocate_rsp_buf
If ->ProtocolId is SMB2_TRANSFORM_PROTO_NUM, smb2 request size
validation could be skipped. if request size is smaller than
sizeof(struct smb2_query_info_req), slab-out-of-bounds read can happen in
smb2_allocate_rsp_buf(). This patch allocate response buffer after
decrypting transform request. smb3_decrypt_req() will validate transform
request size and avoid slab-out-of-bound in smb2_allocate_rsp_buf(). |
["https://git.kernel.org/stable/c/0977f89722eceba165700ea384f075143f012085","https://git.kernel.org/stable/c/3160d9734453a40db248487f8204830879c207f1","https://git.kernel.org/stable/c/b80ba648714e6d790d69610cf14656be222d0248","https://git.kernel.org/stable/c/c119f4ede3fa90a9463f50831761c28f989bfb20","https://git.kernel.org/stable/c/da21401372607c49972ea87a6edaafb36a17c325","https://git.kernel.org/stable/c/0977f89722eceba165700ea384f075143f012085","https://git.kernel.org/stable/c/3160d9734453a40db248487f8204830879c207f1","https://git.kernel.org/stable/c/b80ba648714e6d790d69610cf14656be222d0248","https://git.kernel.org/stable/c/c119f4ede3fa90a9463f50831761c28f989bfb20","https://git.kernel.org/stable/c/da21401372607c49972ea87a6edaafb36a17c325"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42080
|
Medium |
fixed |
- 5.15.162
- 6.1.97
- 6.6.37
- 6.9.8
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/restrack: Fix potential invalid address access
struct rdma_restrack_entry's kern_name was set to KBUILD_MODNAME
in ib_create_cq(), while if the module exited but forgot del this
rdma_restrack_entry, it would cause a invalid address access in
rdma_restrack_clean() when print the owner of this rdma_restrack_entry.
These code is used to help find one forgotten PD release in one of the
ULPs. But it is not needed anymore, so delete them. |
["https://git.kernel.org/stable/c/782bdaf9d01658281bc813f3f873e6258aa1fd8d","https://git.kernel.org/stable/c/8656ef8a9288d6c932654f8d3856dc4ab1cfc6b5","https://git.kernel.org/stable/c/8ac281d42337f36cf7061cf1ea094181b84bc1a9","https://git.kernel.org/stable/c/ca537a34775c103f7b14d7bbd976403f1d1525d8","https://git.kernel.org/stable/c/f45b43d17240e9ca67ebf3cc82bb046b07cc1c61","https://git.kernel.org/stable/c/782bdaf9d01658281bc813f3f873e6258aa1fd8d","https://git.kernel.org/stable/c/8656ef8a9288d6c932654f8d3856dc4ab1cfc6b5","https://git.kernel.org/stable/c/8ac281d42337f36cf7061cf1ea094181b84bc1a9","https://git.kernel.org/stable/c/ca537a34775c103f7b14d7bbd976403f1d1525d8","https://git.kernel.org/stable/c/f45b43d17240e9ca67ebf3cc82bb046b07cc1c61"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49323
|
Medium |
fixed |
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
iommu/arm-smmu: fix possible null-ptr-deref in arm_smmu_device_probe()
It will cause null-ptr-deref when using 'res', if platform_get_resource()
returns NULL, so move using 'res' after devm_ioremap_resource() that
will check it to avoid null-ptr-deref.
And use devm_platform_get_and_ioremap_resource() to simplify code. |
["https://git.kernel.org/stable/c/3660db29b0305f9a1d95979c7af0f5db6ea99f5d","https://git.kernel.org/stable/c/449fc4561762ad9ad85362d5f01f0d0df397457a","https://git.kernel.org/stable/c/80776a71340f57d6a4952635fc89f0342072f3ca","https://git.kernel.org/stable/c/98dd53a92825747395649f54d23512a13c3ed471","https://git.kernel.org/stable/c/d9ed8af1dee37f181096631fb03729ece98ba816"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49468
|
Medium |
fixed |
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
thermal/core: Fix memory leak in __thermal_cooling_device_register()
I got memory leak as follows when doing fault injection test:
unreferenced object 0xffff888010080000 (size 264312):
comm "182", pid 102533, jiffies 4296434960 (age 10.100s)
hex dump (first 32 bytes):
00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
ff ff ff ff ff ff ff ff 40 7f 1f b9 ff ff ff ff ........@.......
backtrace:
[<0000000038b2f4fc>] kmalloc_order_trace+0x1d/0x110 mm/slab_common.c:969
[<00000000ebcb8da5>] __kmalloc+0x373/0x420 include/linux/slab.h:510
[<0000000084137f13>] thermal_cooling_device_setup_sysfs+0x15d/0x2d0 include/linux/slab.h:586
[<00000000352b8755>] __thermal_cooling_device_register+0x332/0xa60 drivers/thermal/thermal_core.c:927
[<00000000fb9f331b>] devm_thermal_of_cooling_device_register+0x6b/0xf0 drivers/thermal/thermal_core.c:1041
[<000000009b8012d2>] max6650_probe.cold+0x557/0x6aa drivers/hwmon/max6650.c:211
[<00000000da0b7e04>] i2c_device_probe+0x472/0xac0 drivers/i2c/i2c-core-base.c:561
If device_register() fails, thermal_cooling_device_destroy_sysfs() need be called
to free the memory allocated in thermal_cooling_device_setup_sysfs(). |
["https://git.kernel.org/stable/c/18530bedd221160823f63ccc20dd55c7a03edbcf","https://git.kernel.org/stable/c/21ccc58b671aea924f2481cf5c1cf0ebbfd3552d","https://git.kernel.org/stable/c/3802171f0b5b8b831f4ade5c827547cb323a5bb2","https://git.kernel.org/stable/c/98a160e898c0f4a979af9de3ab48b4b1d42d1dbb","https://git.kernel.org/stable/c/9abdf0c0184230f0cb5c6685aabf33dda89aa9fb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49546
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
x86/kexec: fix memory leak of elf header buffer
This is reported by kmemleak detector:
unreferenced object 0xffffc900002a9000 (size 4096):
comm "kexec", pid 14950, jiffies 4295110793 (age 373.951s)
hex dump (first 32 bytes):
7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............
04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 ..>.............
backtrace:
[<0000000016a8ef9f>] __vmalloc_node_range+0x101/0x170
[<000000002b66b6c0>] __vmalloc_node+0xb4/0x160
[<00000000ad40107d>] crash_prepare_elf64_headers+0x8e/0xcd0
[<0000000019afff23>] crash_load_segments+0x260/0x470
[<0000000019ebe95c>] bzImage64_load+0x814/0xad0
[<0000000093e16b05>] arch_kexec_kernel_image_load+0x1be/0x2a0
[<000000009ef2fc88>] kimage_file_alloc_init+0x2ec/0x5a0
[<0000000038f5a97a>] __do_sys_kexec_file_load+0x28d/0x530
[<0000000087c19992>] do_syscall_64+0x3b/0x90
[<0000000066e063a4>] entry_SYSCALL_64_after_hwframe+0x44/0xae
In crash_prepare_elf64_headers(), a buffer is allocated via vmalloc() to
store elf headers. While it's not freed back to system correctly when
kdump kernel is reloaded or unloaded. Then memory leak is caused. Fix it
by introducing x86 specific function arch_kimage_file_post_load_cleanup(),
and freeing the buffer there.
And also remove the incorrect elf header buffer freeing code. Before
calling arch specific kexec_file loading function, the image instance has
been initialized. So 'image->elf_headers' must be NULL. It doesn't make
sense to free the elf header buffer in the place.
Three different people have reported three bugs about the memory leak on
x86_64 inside Redhat. |
["https://git.kernel.org/stable/c/115ee42a4c2f26ba2b4ace2668a3f004621f6833","https://git.kernel.org/stable/c/23cf39dccf7653650701a6f39b119e9116a27f1a","https://git.kernel.org/stable/c/8765a423a87d74ef24ea02b43b2728fe4039f248","https://git.kernel.org/stable/c/b3e34a47f98974d0844444c5121aaff123004e57","https://git.kernel.org/stable/c/f675e3a9189d84a9324ab45b0cb19906c2bc8fcb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48654
|
Medium |
fixed |
- 5.4.215
- 5.10.146
- 5.15.71
- 5.19.12
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlink_osf: fix possible bogus match in nf_osf_find()
nf_osf_find() incorrectly returns true on mismatch, this leads to
copying uninitialized memory area in nft_osf which can be used to leak
stale kernel stack data to userspace. |
["https://git.kernel.org/stable/c/559c36c5a8d730c49ef805a72b213d3bba155cc8","https://git.kernel.org/stable/c/5d75fef3e61e797fab5c3fbba88caa74ab92ad47","https://git.kernel.org/stable/c/633c81c0449663f57d4138326d036dc6cfad674e","https://git.kernel.org/stable/c/721ea8ac063d70c2078c4e762212705de6151764","https://git.kernel.org/stable/c/816eab147e5c6f6621922b8515ad9010ceb1735e","https://git.kernel.org/stable/c/559c36c5a8d730c49ef805a72b213d3bba155cc8","https://git.kernel.org/stable/c/5d75fef3e61e797fab5c3fbba88caa74ab92ad47","https://git.kernel.org/stable/c/633c81c0449663f57d4138326d036dc6cfad674e","https://git.kernel.org/stable/c/721ea8ac063d70c2078c4e762212705de6151764","https://git.kernel.org/stable/c/816eab147e5c6f6621922b8515ad9010ceb1735e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52340
|
High |
fixed |
|
The IPv6 implementation in the Linux kernel before 6.3 has a net/ipv6/route.c max_size threshold that can be consumed easily, e.g., leading to a denial of service (network is unreachable errors) when IPv6 packets are sent in a loop via a raw socket. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=af6d10345ca76670c1b7c37799f0d5576ccef277","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=af6d10345ca76670c1b7c37799f0d5576ccef277","https://security.netapp.com/advisory/ntap-20240816-0005/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26993
|
Medium |
fixed |
- 3.17
- 3.19
- 4.5
- 4.10
- 4.15
- 4.19
- 5.15.157
- 6.1.88
- 6.6.29
- 6.8.8
|
In the Linux kernel, the following vulnerability has been resolved:
fs: sysfs: Fix reference leak in sysfs_break_active_protection()
The sysfs_break_active_protection() routine has an obvious reference
leak in its error path. If the call to kernfs_find_and_get() fails then
kn will be NULL, so the companion sysfs_unbreak_active_protection()
routine won't get called (and would only cause an access violation by
trying to dereference kn->parent if it was called). As a result, the
reference to kobj acquired at the start of the function will never be
released.
Fix the leak by adding an explicit kobject_put() call when kn is NULL. |
["https://git.kernel.org/stable/c/43f00210cb257bcb0387e8caeb4b46375d67f30c","https://git.kernel.org/stable/c/57baab0f376bec8f54b0fe6beb8f77a57c228063","https://git.kernel.org/stable/c/5d43e072285e81b0b63cee7189b3357c7768a43b","https://git.kernel.org/stable/c/84bd4c2ae9c3d0a7d3a5c032ea7efff17af17e17","https://git.kernel.org/stable/c/a4c99b57d43bab45225ba92d574a8683f9edc8e4","https://git.kernel.org/stable/c/a90bca2228c0646fc29a72689d308e5fe03e6d78","https://git.kernel.org/stable/c/ac107356aabc362aaeb77463e814fc067a5d3957","https://git.kernel.org/stable/c/f28bba37fe244889b81bb5c508d3f6e5c6e342c5","https://git.kernel.org/stable/c/43f00210cb257bcb0387e8caeb4b46375d67f30c","https://git.kernel.org/stable/c/57baab0f376bec8f54b0fe6beb8f77a57c228063","https://git.kernel.org/stable/c/5d43e072285e81b0b63cee7189b3357c7768a43b","https://git.kernel.org/stable/c/84bd4c2ae9c3d0a7d3a5c032ea7efff17af17e17","https://git.kernel.org/stable/c/a4c99b57d43bab45225ba92d574a8683f9edc8e4","https://git.kernel.org/stable/c/a90bca2228c0646fc29a72689d308e5fe03e6d78","https://git.kernel.org/stable/c/ac107356aabc362aaeb77463e814fc067a5d3957","https://git.kernel.org/stable/c/f28bba37fe244889b81bb5c508d3f6e5c6e342c5","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36270
|
Medium |
fixed |
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.9.4
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: tproxy: bail out if IP has been disabled on the device
syzbot reports:
general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
[..]
RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62
Call Trace:
nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline]
nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168
__in_dev_get_rcu() can return NULL, so check for this. |
["https://git.kernel.org/stable/c/07eeedafc59c45fe5de43958128542be3784764c","https://git.kernel.org/stable/c/10f0af5234dafd03d2b75233428ec3f11cf7e43d","https://git.kernel.org/stable/c/21a673bddc8fd4873c370caf9ae70ffc6d47e8d3","https://git.kernel.org/stable/c/570b4c52096e62fda562448f5760fd0ff06110f0","https://git.kernel.org/stable/c/6fe5af4ff06db3d4d80e07a19356640428159f03","https://git.kernel.org/stable/c/819bfeca16eb9ad647ddcae25e7e12c30612147c","https://git.kernel.org/stable/c/caf3a8afb5ea00db6d5398adf148d5534615fd80","https://git.kernel.org/stable/c/07eeedafc59c45fe5de43958128542be3784764c","https://git.kernel.org/stable/c/10f0af5234dafd03d2b75233428ec3f11cf7e43d","https://git.kernel.org/stable/c/21a673bddc8fd4873c370caf9ae70ffc6d47e8d3","https://git.kernel.org/stable/c/570b4c52096e62fda562448f5760fd0ff06110f0","https://git.kernel.org/stable/c/6fe5af4ff06db3d4d80e07a19356640428159f03","https://git.kernel.org/stable/c/819bfeca16eb9ad647ddcae25e7e12c30612147c","https://git.kernel.org/stable/c/caf3a8afb5ea00db6d5398adf148d5534615fd80"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36286
|
Medium |
fixed |
- 4.19.316
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.9.4
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()
syzbot reported that nf_reinject() could be called without rcu_read_lock() :
WARNING: suspicious RCU usage
6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted
net/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
2 locks held by syz-executor.4/13427:
#0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline]
#0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline]
#0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471
#1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
#1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline]
#1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172
stack backtrace:
CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712
nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline]
nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397
nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline]
instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172
rcu_do_batch kernel/rcu/tree.c:2196 [inline]
rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471
handle_softirqs+0x2d6/0x990 kernel/softirq.c:554
__do_softirq kernel/softirq.c:588 [inline]
invoke_softirq kernel/softirq.c:428 [inline]
__irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637
irq_exit_rcu+0x9/0x30 kernel/softirq.c:649
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]
sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043
</IRQ>
<TASK> |
["https://git.kernel.org/stable/c/215df6490e208bfdd5b3012f5075e7f8736f3e7a","https://git.kernel.org/stable/c/25ea5377e3d2921a0f96ae2551f5ab1b36825dd4","https://git.kernel.org/stable/c/3989b817857f4890fab9379221a9d3f52bf5c256","https://git.kernel.org/stable/c/68f40354a3851df46c27be96b84f11ae193e36c5","https://git.kernel.org/stable/c/8658bd777cbfcb0c13df23d0ea120e70517761b9","https://git.kernel.org/stable/c/8f365564af898819a523f1a8cf5c6ce053e9f718","https://git.kernel.org/stable/c/dc21c6cc3d6986d938efbf95de62473982c98dec","https://git.kernel.org/stable/c/e01065b339e323b3dfa1be217fd89e9b3208b0ab","https://git.kernel.org/stable/c/215df6490e208bfdd5b3012f5075e7f8736f3e7a","https://git.kernel.org/stable/c/25ea5377e3d2921a0f96ae2551f5ab1b36825dd4","https://git.kernel.org/stable/c/3989b817857f4890fab9379221a9d3f52bf5c256","https://git.kernel.org/stable/c/68f40354a3851df46c27be96b84f11ae193e36c5","https://git.kernel.org/stable/c/8658bd777cbfcb0c13df23d0ea120e70517761b9","https://git.kernel.org/stable/c/8f365564af898819a523f1a8cf5c6ce053e9f718","https://git.kernel.org/stable/c/dc21c6cc3d6986d938efbf95de62473982c98dec","https://git.kernel.org/stable/c/e01065b339e323b3dfa1be217fd89e9b3208b0ab"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36489
|
Medium |
fixed |
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.9.4
|
In the Linux kernel, the following vulnerability has been resolved:
tls: fix missing memory barrier in tls_init
In tls_init(), a write memory barrier is missing, and store-store
reordering may cause NULL dereference in tls_{setsockopt,getsockopt}.
CPU0 CPU1
----- -----
// In tls_init()
// In tls_ctx_create()
ctx = kzalloc()
ctx->sk_proto = READ_ONCE(sk->sk_prot) -(1)
// In update_sk_prot()
WRITE_ONCE(sk->sk_prot, tls_prots) -(2)
// In sock_common_setsockopt()
READ_ONCE(sk->sk_prot)->setsockopt()
// In tls_{setsockopt,getsockopt}()
ctx->sk_proto->setsockopt() -(3)
In the above scenario, when (1) and (2) are reordered, (3) can observe
the NULL value of ctx->sk_proto, causing NULL dereference.
To fix it, we rely on rcu_assign_pointer() which implies the release
barrier semantic. By moving rcu_assign_pointer() after ctx->sk_proto is
initialized, we can ensure that ctx->sk_proto are visible when
changing sk->sk_prot. |
["https://git.kernel.org/stable/c/2c260a24cf1c4d30ea3646124f766ee46169280b","https://git.kernel.org/stable/c/335c8f1566d8e44c384d16b450a18554896d4e8b","https://git.kernel.org/stable/c/91e61dd7a0af660408e87372d8330ceb218be302","https://git.kernel.org/stable/c/ab67c2fd3d070a21914d0c31319d3858ab4e199c","https://git.kernel.org/stable/c/d72e126e9a36d3d33889829df8fc90100bb0e071","https://git.kernel.org/stable/c/ef21007a7b581c7fe64d5a10c320880a033c837b","https://git.kernel.org/stable/c/2c260a24cf1c4d30ea3646124f766ee46169280b","https://git.kernel.org/stable/c/335c8f1566d8e44c384d16b450a18554896d4e8b","https://git.kernel.org/stable/c/91e61dd7a0af660408e87372d8330ceb218be302","https://git.kernel.org/stable/c/ab67c2fd3d070a21914d0c31319d3858ab4e199c","https://git.kernel.org/stable/c/d72e126e9a36d3d33889829df8fc90100bb0e071","https://git.kernel.org/stable/c/ef21007a7b581c7fe64d5a10c320880a033c837b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36938
|
Medium |
fixed |
- 5.15.159
- 6.1.91
- 6.6.31
- 6.8.10
|
In the Linux kernel, the following vulnerability has been resolved:
bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue
Fix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which
syzbot reported [1].
[1]
BUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue
write to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1:
sk_psock_stop_verdict net/core/skmsg.c:1257 [inline]
sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843
sk_psock_put include/linux/skmsg.h:459 [inline]
sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648
unix_release+0x4b/0x80 net/unix/af_unix.c:1048
__sock_release net/socket.c:659 [inline]
sock_close+0x68/0x150 net/socket.c:1421
__fput+0x2c1/0x660 fs/file_table.c:422
__fput_sync+0x44/0x60 fs/file_table.c:507
__do_sys_close fs/open.c:1556 [inline]
__se_sys_close+0x101/0x1b0 fs/open.c:1541
__x64_sys_close+0x1f/0x30 fs/open.c:1541
do_syscall_64+0xd3/0x1d0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
read to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0:
sk_psock_data_ready include/linux/skmsg.h:464 [inline]
sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555
sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606
sk_psock_verdict_apply net/core/skmsg.c:1008 [inline]
sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202
unix_read_skb net/unix/af_unix.c:2546 [inline]
unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682
sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223
unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x140/0x180 net/socket.c:745
____sys_sendmsg+0x312/0x410 net/socket.c:2584
___sys_sendmsg net/socket.c:2638 [inline]
__sys_sendmsg+0x1e9/0x280 net/socket.c:2667
__do_sys_sendmsg net/socket.c:2676 [inline]
__se_sys_sendmsg net/socket.c:2674 [inline]
__x64_sys_sendmsg+0x46/0x50 net/socket.c:2674
do_syscall_64+0xd3/0x1d0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
value changed: 0xffffffff83d7feb0 -> 0x0000000000000000
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G W 6.8.0-syzkaller-08951-gfe46a7dd189e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
Prior to this, commit 4cd12c6065df ("bpf, sockmap: Fix NULL pointer
dereference in sk_psock_verdict_data_ready()") fixed one NULL pointer
similarly due to no protection of saved_data_ready. Here is another
different caller causing the same issue because of the same reason. So
we should protect it with sk_callback_lock read lock because the writer
side in the sk_psock_drop() uses "write_lock_bh(&sk->sk_callback_lock);".
To avoid errors that could happen in future, I move those two pairs of
lock into the sk_psock_data_ready(), which is suggested by John Fastabend. |
["https://git.kernel.org/stable/c/39dc9e1442385d6e9be0b6491ee488dddd55ae27","https://git.kernel.org/stable/c/5965bc7535fb87510b724e5465ccc1a1cf00916d","https://git.kernel.org/stable/c/6648e613226e18897231ab5e42ffc29e63fa3365","https://git.kernel.org/stable/c/772d5729b5ff0df0d37b32db600ce635b2172f80","https://git.kernel.org/stable/c/b397a0ab8582c533ec0c6b732392f141fc364f87","https://git.kernel.org/stable/c/c0809c128dad4c3413818384eb06a341633db973","https://git.kernel.org/stable/c/39dc9e1442385d6e9be0b6491ee488dddd55ae27","https://git.kernel.org/stable/c/5965bc7535fb87510b724e5465ccc1a1cf00916d","https://git.kernel.org/stable/c/6648e613226e18897231ab5e42ffc29e63fa3365","https://git.kernel.org/stable/c/772d5729b5ff0df0d37b32db600ce635b2172f80","https://git.kernel.org/stable/c/b397a0ab8582c533ec0c6b732392f141fc364f87","https://git.kernel.org/stable/c/c0809c128dad4c3413818384eb06a341633db973"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38547
|
Medium |
fixed |
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries
The allocation failure of mycs->yuv_scaler_binary in load_video_binaries()
is followed with a dereference of mycs->yuv_scaler_binary after the
following call chain:
sh_css_pipe_load_binaries()
|-> load_video_binaries(mycs->yuv_scaler_binary == NULL)
|
|-> sh_css_pipe_unload_binaries()
|-> unload_video_binaries()
In unload_video_binaries(), it calls to ia_css_binary_unload with argument
&pipe->pipe_settings.video.yuv_scaler_binary[i], which refers to the
same memory slot as mycs->yuv_scaler_binary. Thus, a null-pointer
dereference is triggered. |
["https://git.kernel.org/stable/c/3b621e9e9e148c0928ab109ac3d4b81487469acb","https://git.kernel.org/stable/c/4b68b861b514a5c09220d622ac3784c0ebac6c80","https://git.kernel.org/stable/c/6482c433863b257b0b9b687c28ce80b89d5f89f0","https://git.kernel.org/stable/c/69b27ff82f87379afeaaea4b2f339032fdd8486e","https://git.kernel.org/stable/c/82c2c85aead3ea3cbceef4be077cf459c5df2272","https://git.kernel.org/stable/c/a1ab99dcc8604afe7e3bccb01b10da03bdd7ea35","https://git.kernel.org/stable/c/cc20c87b04db86c8e3e810bcdca686b406206069","https://git.kernel.org/stable/c/3b621e9e9e148c0928ab109ac3d4b81487469acb","https://git.kernel.org/stable/c/4b68b861b514a5c09220d622ac3784c0ebac6c80","https://git.kernel.org/stable/c/6482c433863b257b0b9b687c28ce80b89d5f89f0","https://git.kernel.org/stable/c/69b27ff82f87379afeaaea4b2f339032fdd8486e","https://git.kernel.org/stable/c/82c2c85aead3ea3cbceef4be077cf459c5df2272","https://git.kernel.org/stable/c/a1ab99dcc8604afe7e3bccb01b10da03bdd7ea35","https://git.kernel.org/stable/c/cc20c87b04db86c8e3e810bcdca686b406206069"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38590
|
Medium |
fixed |
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Modify the print level of CQE error
Too much print may lead to a panic in kernel. Change ibdev_err() to
ibdev_err_ratelimited(), and change the printing level of cqe dump
to debug level. |
["https://git.kernel.org/stable/c/06cf121346bbd3d83a5eea05bb87666c6b279990","https://git.kernel.org/stable/c/17f3741c65c4a042ae8ba094068b07a4b77e213c","https://git.kernel.org/stable/c/349e859952285ab9689779fb46de163f13f18f43","https://git.kernel.org/stable/c/45b31be4dd22827903df15c548b97b416790139b","https://git.kernel.org/stable/c/6f541a89ced8305da459e3ab0006e7528cf7da7b","https://git.kernel.org/stable/c/817a10a6df9354e67561922d2b7fce48dfbebc55","https://git.kernel.org/stable/c/cc699b7eb2bc963c12ffcd37f80f45330d2924bd","https://git.kernel.org/stable/c/06cf121346bbd3d83a5eea05bb87666c6b279990","https://git.kernel.org/stable/c/17f3741c65c4a042ae8ba094068b07a4b77e213c","https://git.kernel.org/stable/c/349e859952285ab9689779fb46de163f13f18f43","https://git.kernel.org/stable/c/45b31be4dd22827903df15c548b97b416790139b","https://git.kernel.org/stable/c/6f541a89ced8305da459e3ab0006e7528cf7da7b","https://git.kernel.org/stable/c/817a10a6df9354e67561922d2b7fce48dfbebc55","https://git.kernel.org/stable/c/cc699b7eb2bc963c12ffcd37f80f45330d2924bd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38633
|
Medium |
fixed |
- 4.19.316
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.9.4
|
In the Linux kernel, the following vulnerability has been resolved:
serial: max3100: Update uart_driver_registered on driver removal
The removal of the last MAX3100 device triggers the removal of
the driver. However, code doesn't update the respective global
variable and after insmod — rmmod — insmod cycle the kernel
oopses:
max3100 spi-PRP0001:01: max3100_probe: adding port 0
BUG: kernel NULL pointer dereference, address: 0000000000000408
...
RIP: 0010:serial_core_register_port+0xa0/0x840
...
max3100_probe+0x1b6/0x280 [max3100]
spi_probe+0x8d/0xb0
Update the actual state so next time UART driver will be registered
again.
Hugo also noticed, that the error path in the probe also affected
by having the variable set, and not cleared. Instead of clearing it
move the assignment after the successfull uart_register_driver() call. |
["https://git.kernel.org/stable/c/21a61a7fbcfdd3493cede43ebc7c4dfae2147a8b","https://git.kernel.org/stable/c/361a92c9038e8c8c3996f8eeaa14522a8ad90752","https://git.kernel.org/stable/c/712a1fcb38dc7cac6da63ee79a88708fbf9c45ec","https://git.kernel.org/stable/c/9db4222ed8cd3e50b81c8b910ae74c26427a4003","https://git.kernel.org/stable/c/b6eb7aff23e05f362e8c9b560f6ac5e727b70e00","https://git.kernel.org/stable/c/e8a10089eddba40d4b2080c9d3fc2d2b2488f762","https://git.kernel.org/stable/c/e8e2a4339decad7e59425b594a98613402652d72","https://git.kernel.org/stable/c/fa84ca78b048dfb00df0ef446f5c35e0a98ca6a0","https://git.kernel.org/stable/c/21a61a7fbcfdd3493cede43ebc7c4dfae2147a8b","https://git.kernel.org/stable/c/361a92c9038e8c8c3996f8eeaa14522a8ad90752","https://git.kernel.org/stable/c/712a1fcb38dc7cac6da63ee79a88708fbf9c45ec","https://git.kernel.org/stable/c/9db4222ed8cd3e50b81c8b910ae74c26427a4003","https://git.kernel.org/stable/c/b6eb7aff23e05f362e8c9b560f6ac5e727b70e00","https://git.kernel.org/stable/c/e8a10089eddba40d4b2080c9d3fc2d2b2488f762","https://git.kernel.org/stable/c/e8e2a4339decad7e59425b594a98613402652d72","https://git.kernel.org/stable/c/fa84ca78b048dfb00df0ef446f5c35e0a98ca6a0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39475
|
Medium |
fixed |
- 4.19.316
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.94
- 6.6.34
- 6.9.5
|
In the Linux kernel, the following vulnerability has been resolved:
fbdev: savage: Handle err return when savagefb_check_var failed
The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero")
checks the value of pixclock to avoid divide-by-zero error. However
the function savagefb_probe doesn't handle the error return of
savagefb_check_var. When pixclock is 0, it will cause divide-by-zero error. |
["https://git.kernel.org/stable/c/32f92b0078ebf79dbe4827288e0acb50d89d3d5b","https://git.kernel.org/stable/c/4b2c67e30b4e1d2ae19dba8b8e8f3b5fd3cf8089","https://git.kernel.org/stable/c/5f446859bfa46df0ffb34149499f48a2c2d8cd95","https://git.kernel.org/stable/c/6ad959b6703e2c4c5d7af03b4cfd5ff608036339","https://git.kernel.org/stable/c/86435f39c18967cdd937d7a49ba539cdea7fb547","https://git.kernel.org/stable/c/b8385ff814ca4cb7e63789841e6ec2a14c73e1e8","https://git.kernel.org/stable/c/be754cbd77eaf2932408a4e18532e4945274a5c7","https://git.kernel.org/stable/c/edaa57480b876e8203b51df7c3d14a51ea6b09e3","https://git.kernel.org/stable/c/32f92b0078ebf79dbe4827288e0acb50d89d3d5b","https://git.kernel.org/stable/c/4b2c67e30b4e1d2ae19dba8b8e8f3b5fd3cf8089","https://git.kernel.org/stable/c/5f446859bfa46df0ffb34149499f48a2c2d8cd95","https://git.kernel.org/stable/c/6ad959b6703e2c4c5d7af03b4cfd5ff608036339","https://git.kernel.org/stable/c/86435f39c18967cdd937d7a49ba539cdea7fb547","https://git.kernel.org/stable/c/b8385ff814ca4cb7e63789841e6ec2a14c73e1e8","https://git.kernel.org/stable/c/be754cbd77eaf2932408a4e18532e4945274a5c7","https://git.kernel.org/stable/c/edaa57480b876e8203b51df7c3d14a51ea6b09e3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39482
|
Medium |
fixed |
- 5.10.221
- 5.15.162
- 6.1.94
- 6.6.34
- 6.9.5
|
In the Linux kernel, the following vulnerability has been resolved:
bcache: fix variable length array abuse in btree_iter
btree_iter is used in two ways: either allocated on the stack with a
fixed size MAX_BSETS, or from a mempool with a dynamic size based on the
specific cache set. Previously, the struct had a fixed-length array of
size MAX_BSETS which was indexed out-of-bounds for the dynamically-sized
iterators, which causes UBSAN to complain.
This patch uses the same approach as in bcachefs's sort_iter and splits
the iterator into a btree_iter with a flexible array member and a
btree_iter_stack which embeds a btree_iter as well as a fixed-length
data array. |
["https://git.kernel.org/stable/c/0c31344e22dd8d6b1394c6e4c41d639015bdc671","https://git.kernel.org/stable/c/2c3d7b03b658dc8bfa6112b194b67b92a87e081b","https://git.kernel.org/stable/c/3a861560ccb35f2a4f0a4b8207fa7c2a35fc7f31","https://git.kernel.org/stable/c/5a1922adc5798b7ec894cd3f197afb6f9591b023","https://git.kernel.org/stable/c/6479b9f41583b013041943c4602e1ad61cec8148","https://git.kernel.org/stable/c/934e1e4331859183a861f396d7dfaf33cb5afb02","https://git.kernel.org/stable/c/0c31344e22dd8d6b1394c6e4c41d639015bdc671","https://git.kernel.org/stable/c/2c3d7b03b658dc8bfa6112b194b67b92a87e081b","https://git.kernel.org/stable/c/3a861560ccb35f2a4f0a4b8207fa7c2a35fc7f31","https://git.kernel.org/stable/c/5a1922adc5798b7ec894cd3f197afb6f9591b023","https://git.kernel.org/stable/c/6479b9f41583b013041943c4602e1ad61cec8148","https://git.kernel.org/stable/c/934e1e4331859183a861f396d7dfaf33cb5afb02"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39489
|
Medium |
fixed |
- 4.19.316
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.9.4
|
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: fix memleak in seg6_hmac_init_algo
seg6_hmac_init_algo returns without cleaning up the previous allocations
if one fails, so it's going to leak all that memory and the crypto tfms.
Update seg6_hmac_exit to only free the memory when allocated, so we can
reuse the code directly. |
["https://git.kernel.org/stable/c/0e44d6cbe8de983470c3d2f978649783384fdcb6","https://git.kernel.org/stable/c/4a3fcf53725b70010d1cf869a2ba549fed6b8fb3","https://git.kernel.org/stable/c/599a5654215092ac22bfc453f4fd3959c55ea821","https://git.kernel.org/stable/c/61d31ac85b4572d11f8071855c0ccb4f32d76c0c","https://git.kernel.org/stable/c/afd5730969aec960a2fee4e5ee839a6014643976","https://git.kernel.org/stable/c/daf341e0a2318b813427d5a78788c86f4a7f02be","https://git.kernel.org/stable/c/efb9f4f19f8e37fde43dfecebc80292d179f56c6","https://git.kernel.org/stable/c/f6a99ef4e056c20a138a95cc51332b2b96c8f383","https://git.kernel.org/stable/c/0e44d6cbe8de983470c3d2f978649783384fdcb6","https://git.kernel.org/stable/c/4a3fcf53725b70010d1cf869a2ba549fed6b8fb3","https://git.kernel.org/stable/c/599a5654215092ac22bfc453f4fd3959c55ea821","https://git.kernel.org/stable/c/61d31ac85b4572d11f8071855c0ccb4f32d76c0c","https://git.kernel.org/stable/c/afd5730969aec960a2fee4e5ee839a6014643976","https://git.kernel.org/stable/c/daf341e0a2318b813427d5a78788c86f4a7f02be","https://git.kernel.org/stable/c/efb9f4f19f8e37fde43dfecebc80292d179f56c6","https://git.kernel.org/stable/c/f6a99ef4e056c20a138a95cc51332b2b96c8f383"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39506
|
Medium |
fixed |
- 4.19.317
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.95
- 6.6.35
- 6.9.6
|
In the Linux kernel, the following vulnerability has been resolved:
liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet
In lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value,
but then it is unconditionally passed to skb_add_rx_frag() which looks
strange and could lead to null pointer dereference.
lio_vf_rep_copy_packet() call trace looks like:
octeon_droq_process_packets
octeon_droq_fast_process_packets
octeon_droq_dispatch_pkt
octeon_create_recv_info
...search in the dispatch_list...
->disp_fn(rdisp->rinfo, ...)
lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...)
In this path there is no code which sets pg_info->page to NULL.
So this check looks unneeded and doesn't solve potential problem.
But I guess the author had reason to add a check and I have no such card
and can't do real test.
In addition, the code in the function liquidio_push_packet() in
liquidio/lio_core.c does exactly the same.
Based on this, I consider the most acceptable compromise solution to
adjust this issue by moving skb_add_rx_frag() into conditional scope.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/87d6bdc006f0cbf297a3b2ad6e40ede4c3ee5dc2","https://git.kernel.org/stable/c/a6f4d0ec170a46b5f453cacf55dff5989b42bbfa","https://git.kernel.org/stable/c/a86490a3712cc513113440a606a0e77130abd47c","https://git.kernel.org/stable/c/c44711b78608c98a3e6b49ce91678cd0917d5349","https://git.kernel.org/stable/c/cbf18d8128a753cb632bef39470d19befd9c7347","https://git.kernel.org/stable/c/dcc7440f32c7a26b067aff6e7d931ec593024a79","https://git.kernel.org/stable/c/f1ab15a09492a5ae8ab1e2c35ba2cf9e150d25ee","https://git.kernel.org/stable/c/fd2b613bc4c508e55c1221c6595bb889812a4fea","https://git.kernel.org/stable/c/87d6bdc006f0cbf297a3b2ad6e40ede4c3ee5dc2","https://git.kernel.org/stable/c/a6f4d0ec170a46b5f453cacf55dff5989b42bbfa","https://git.kernel.org/stable/c/a86490a3712cc513113440a606a0e77130abd47c","https://git.kernel.org/stable/c/c44711b78608c98a3e6b49ce91678cd0917d5349","https://git.kernel.org/stable/c/cbf18d8128a753cb632bef39470d19befd9c7347","https://git.kernel.org/stable/c/dcc7440f32c7a26b067aff6e7d931ec593024a79","https://git.kernel.org/stable/c/f1ab15a09492a5ae8ab1e2c35ba2cf9e150d25ee","https://git.kernel.org/stable/c/fd2b613bc4c508e55c1221c6595bb889812a4fea"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40945
|
Medium |
fixed |
- 5.4.279
- 5.10.221
- 5.15.162
- 6.6.35
- 6.9.6
|
In the Linux kernel, the following vulnerability has been resolved:
iommu: Return right value in iommu_sva_bind_device()
iommu_sva_bind_device() should return either a sva bond handle or an
ERR_PTR value in error cases. Existing drivers (idxd and uacce) only
check the return value with IS_ERR(). This could potentially lead to
a kernel NULL pointer dereference issue if the function returns NULL
instead of an error pointer.
In reality, this doesn't cause any problems because iommu_sva_bind_device()
only returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA.
In this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will
return an error, and the device drivers won't call iommu_sva_bind_device()
at all. |
["https://git.kernel.org/stable/c/2973b8e7d127754de9013177c41c0b5547406998","https://git.kernel.org/stable/c/61a96da9649a6b6a1a5d5bde9374b045fdb5c12e","https://git.kernel.org/stable/c/6325eab6c108fed27f60ff51852e3eac0ba23f3f","https://git.kernel.org/stable/c/700f564758882db7c039dfba9443fe762561a3f8","https://git.kernel.org/stable/c/7388ae6f26c0ba95f70cc96bf9c5d5cb06c908b6","https://git.kernel.org/stable/c/89e8a2366e3bce584b6c01549d5019c5cda1205e","https://git.kernel.org/stable/c/cf34f8f66982a36e5cba0d05781b21ec9606b91e","https://git.kernel.org/stable/c/2973b8e7d127754de9013177c41c0b5547406998","https://git.kernel.org/stable/c/61a96da9649a6b6a1a5d5bde9374b045fdb5c12e","https://git.kernel.org/stable/c/700f564758882db7c039dfba9443fe762561a3f8","https://git.kernel.org/stable/c/7388ae6f26c0ba95f70cc96bf9c5d5cb06c908b6","https://git.kernel.org/stable/c/89e8a2366e3bce584b6c01549d5019c5cda1205e","https://git.kernel.org/stable/c/cf34f8f66982a36e5cba0d05781b21ec9606b91e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41077
|
Medium |
fixed |
- 5.10.223
- 5.15.164
- 6.1.101
- 6.6.42
- 6.9.11
|
In the Linux kernel, the following vulnerability has been resolved:
null_blk: fix validation of block size
Block size should be between 512 and PAGE_SIZE and be a power of 2. The current
check does not validate this, so update the check.
Without this patch, null_blk would Oops due to a null pointer deref when
loaded with bs=1536 [1].
[axboe: remove unnecessary braces and != 0 check] |
["https://git.kernel.org/stable/c/08f03186b96e25e3154916a2e70732557c770ea7","https://git.kernel.org/stable/c/2772ed2fc075eef7df3789906fc9dae01e4e132e","https://git.kernel.org/stable/c/9625afe1dd4a158a14bb50f81af9e2dac634c0b1","https://git.kernel.org/stable/c/9b873bdaae64bddade9d8c6df23c8a31948d47d0","https://git.kernel.org/stable/c/c462ecd659b5fce731f1d592285832fd6ad54053","https://git.kernel.org/stable/c/f92409a9da02f27d05d713bff5f865e386cef9b3","https://git.kernel.org/stable/c/08f03186b96e25e3154916a2e70732557c770ea7","https://git.kernel.org/stable/c/2772ed2fc075eef7df3789906fc9dae01e4e132e","https://git.kernel.org/stable/c/9625afe1dd4a158a14bb50f81af9e2dac634c0b1","https://git.kernel.org/stable/c/9b873bdaae64bddade9d8c6df23c8a31948d47d0","https://git.kernel.org/stable/c/c462ecd659b5fce731f1d592285832fd6ad54053","https://git.kernel.org/stable/c/f92409a9da02f27d05d713bff5f865e386cef9b3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42101
|
Medium |
fixed |
- 4.19.318
- 5.4.280
- 5.10.222
- 5.15.163
- 6.1.98
- 6.6.39
- 6.9.9
|
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: fix null pointer dereference in nouveau_connector_get_modes
In nouveau_connector_get_modes(), the return value of drm_mode_duplicate()
is assigned to mode, which will lead to a possible NULL pointer
dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. |
["https://git.kernel.org/stable/c/1f32535238493008587a8c5cb17eb2ca097592ef","https://git.kernel.org/stable/c/274cba8d2d1b48c72d8bd90e76c9e2dc1aa0a81d","https://git.kernel.org/stable/c/744b229f09134ccd091427a6f9ea6d97302cfdd9","https://git.kernel.org/stable/c/7db5411c5d0bd9c29b8c2ad93c36b5c16ea46c9e","https://git.kernel.org/stable/c/80bec6825b19d95ccdfd3393cf8ec15ff2a749b4","https://git.kernel.org/stable/c/9baf60323efa992b7c915094529f0a1882c34e7e","https://git.kernel.org/stable/c/e36364f5f3785d054a94e57e971385284886d41a","https://git.kernel.org/stable/c/f48dd3f19614022f2e1b794fbd169d2b4c398c07","https://git.kernel.org/stable/c/1f32535238493008587a8c5cb17eb2ca097592ef","https://git.kernel.org/stable/c/274cba8d2d1b48c72d8bd90e76c9e2dc1aa0a81d","https://git.kernel.org/stable/c/744b229f09134ccd091427a6f9ea6d97302cfdd9","https://git.kernel.org/stable/c/7db5411c5d0bd9c29b8c2ad93c36b5c16ea46c9e","https://git.kernel.org/stable/c/80bec6825b19d95ccdfd3393cf8ec15ff2a749b4","https://git.kernel.org/stable/c/9baf60323efa992b7c915094529f0a1882c34e7e","https://git.kernel.org/stable/c/e36364f5f3785d054a94e57e971385284886d41a","https://git.kernel.org/stable/c/f48dd3f19614022f2e1b794fbd169d2b4c398c07"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42106
|
Medium |
fixed |
- 4.19.318
- 5.4.280
- 5.10.222
- 5.15.163
- 6.1.98
- 6.6.39
- 6.9.9
|
In the Linux kernel, the following vulnerability has been resolved:
inet_diag: Initialize pad field in struct inet_diag_req_v2
KMSAN reported uninit-value access in raw_lookup() [1]. Diag for raw
sockets uses the pad field in struct inet_diag_req_v2 for the
underlying protocol. This field corresponds to the sdiag_raw_protocol
field in struct inet_diag_req_raw.
inet_diag_get_exact_compat() converts inet_diag_req to
inet_diag_req_v2, but leaves the pad field uninitialized. So the issue
occurs when raw_lookup() accesses the sdiag_raw_protocol field.
Fix this by initializing the pad field in
inet_diag_get_exact_compat(). Also, do the same fix in
inet_diag_dump_compat() to avoid the similar issue in the future.
[1]
BUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline]
BUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71
raw_lookup net/ipv4/raw_diag.c:49 [inline]
raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71
raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99
inet_diag_cmd_exact+0x7d9/0x980
inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]
inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426
sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564
sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297
netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361
netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x332/0x3d0 net/socket.c:745
____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585
___sys_sendmsg+0x271/0x3b0 net/socket.c:2639
__sys_sendmsg net/socket.c:2668 [inline]
__do_sys_sendmsg net/socket.c:2677 [inline]
__se_sys_sendmsg net/socket.c:2675 [inline]
__x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675
x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was stored to memory at:
raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71
raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99
inet_diag_cmd_exact+0x7d9/0x980
inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]
inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426
sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564
sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297
netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361
netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x332/0x3d0 net/socket.c:745
____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585
___sys_sendmsg+0x271/0x3b0 net/socket.c:2639
__sys_sendmsg net/socket.c:2668 [inline]
__do_sys_sendmsg net/socket.c:2677 [inline]
__se_sys_sendmsg net/socket.c:2675 [inline]
__x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675
x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Local variable req.i created at:
inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline]
inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426
sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 |
["https://git.kernel.org/stable/c/0184bf0a349f4cf9e663abbe862ff280e8e4dfa2","https://git.kernel.org/stable/c/61cf1c739f08190a4cbf047b9fbb192a94d87e3f","https://git.kernel.org/stable/c/7094a5fd20ab66028f1da7f06e0f2692d70346f9","https://git.kernel.org/stable/c/76965648fe6858db7c5f3c700fef7aa5f124ca1c","https://git.kernel.org/stable/c/7ef519c8efde152e0d632337f2994f6921e0b7e4","https://git.kernel.org/stable/c/8366720519ea8d322a20780debdfd23d9fc0904a","https://git.kernel.org/stable/c/d6f487e0704de2f2d15f8dd5d7d723210f2b2fdb","https://git.kernel.org/stable/c/f9b2010e8af49fac9d9562146fb81744d8a9b051","https://git.kernel.org/stable/c/0184bf0a349f4cf9e663abbe862ff280e8e4dfa2","https://git.kernel.org/stable/c/61cf1c739f08190a4cbf047b9fbb192a94d87e3f","https://git.kernel.org/stable/c/7094a5fd20ab66028f1da7f06e0f2692d70346f9","https://git.kernel.org/stable/c/76965648fe6858db7c5f3c700fef7aa5f124ca1c","https://git.kernel.org/stable/c/7ef519c8efde152e0d632337f2994f6921e0b7e4","https://git.kernel.org/stable/c/8366720519ea8d322a20780debdfd23d9fc0904a","https://git.kernel.org/stable/c/d6f487e0704de2f2d15f8dd5d7d723210f2b2fdb","https://git.kernel.org/stable/c/f9b2010e8af49fac9d9562146fb81744d8a9b051"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35947
|
Medium |
fixed |
- 4.19.314
- 5.4.276
- 5.10.217
- 5.15.159
- 6.1.91
- 6.6.31
- 6.8..10
|
In the Linux kernel, the following vulnerability has been resolved:
dyndbg: fix old BUG_ON in >control parser
Fix a BUG_ON from 2009. Even if it looks "unreachable" (I didn't
really look), lets make sure by removing it, doing pr_err and return
-EINVAL instead. |
["https://git.kernel.org/stable/c/00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c","https://git.kernel.org/stable/c/343081c21e56bd6690d342e2f5ae8c00183bf081","https://git.kernel.org/stable/c/3c718bddddca9cbef177ac475b94c5c91147fb38","https://git.kernel.org/stable/c/41d8ac238ab1cab01a8c71798d61903304f4e79b","https://git.kernel.org/stable/c/529e1852785599160415e964ca322ee7add7aef0","https://git.kernel.org/stable/c/a66c869b17c4c4dcf81d273b02cb0efe88e127ab","https://git.kernel.org/stable/c/a69e1bdd777ce51061111dc419801e8a2fd241cc","https://git.kernel.org/stable/c/ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561","https://git.kernel.org/stable/c/00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c","https://git.kernel.org/stable/c/343081c21e56bd6690d342e2f5ae8c00183bf081","https://git.kernel.org/stable/c/3c718bddddca9cbef177ac475b94c5c91147fb38","https://git.kernel.org/stable/c/41d8ac238ab1cab01a8c71798d61903304f4e79b","https://git.kernel.org/stable/c/529e1852785599160415e964ca322ee7add7aef0","https://git.kernel.org/stable/c/a66c869b17c4c4dcf81d273b02cb0efe88e127ab","https://git.kernel.org/stable/c/a69e1bdd777ce51061111dc419801e8a2fd241cc","https://git.kernel.org/stable/c/ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561","https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OTB4HWU2PTVW5NEYHHLOCXDKG3PYA534/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35247
|
Medium |
fixed |
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.9.4
|
In the Linux kernel, the following vulnerability has been resolved:
fpga: region: add owner module and take its refcount
The current implementation of the fpga region assumes that the low-level
module registers a driver for the parent device and uses its owner pointer
to take the module's refcount. This approach is problematic since it can
lead to a null pointer dereference while attempting to get the region
during programming if the parent device does not have a driver.
To address this problem, add a module owner pointer to the fpga_region
struct and use it to take the module's refcount. Modify the functions for
registering a region to take an additional owner module parameter and
rename them to avoid conflicts. Use the old function names for helper
macros that automatically set the module that registers the region as the
owner. This ensures compatibility with existing low-level control modules
and reduces the chances of registering a region without setting the owner.
Also, update the documentation to keep it consistent with the new interface
for registering an fpga region. |
["https://git.kernel.org/stable/c/2279c09c36165ccded4d506d11a7714e13b56019","https://git.kernel.org/stable/c/26e6e25d742e29885cf44274fcf6b744366c4702","https://git.kernel.org/stable/c/4d7d12b643c00e7eea51b49a60a2ead182633ec8","https://git.kernel.org/stable/c/75a001914a8d2ccdcbe4b8cc7e94ac71d0e66093","https://git.kernel.org/stable/c/9b4eee8572dcf82b2ed17d9a328c7fb87df2f0e8","https://git.kernel.org/stable/c/b7c0e1ecee403a43abc89eb3e75672b01ff2ece9","https://git.kernel.org/stable/c/2279c09c36165ccded4d506d11a7714e13b56019","https://git.kernel.org/stable/c/26e6e25d742e29885cf44274fcf6b744366c4702","https://git.kernel.org/stable/c/4d7d12b643c00e7eea51b49a60a2ead182633ec8","https://git.kernel.org/stable/c/75a001914a8d2ccdcbe4b8cc7e94ac71d0e66093","https://git.kernel.org/stable/c/9b4eee8572dcf82b2ed17d9a328c7fb87df2f0e8","https://git.kernel.org/stable/c/b7c0e1ecee403a43abc89eb3e75672b01ff2ece9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27015
|
Medium |
fixed |
- 5.15.157
- 6.1.88
- 6.6.29
- 6.8.8
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: flowtable: incorrect pppoe tuple
pppoe traffic reaching ingress path does not match the flowtable entry
because the pppoe header is expected to be at the network header offset.
This bug causes a mismatch in the flow table lookup, so pppoe packets
enter the classical forwarding path. |
["https://git.kernel.org/stable/c/4ed82dd368ad883dc4284292937b882f044e625d","https://git.kernel.org/stable/c/6db5dc7b351b9569940cd1cf445e237c42cd6d27","https://git.kernel.org/stable/c/e3f078103421642fcd5f05c5e70777feb10f000d","https://git.kernel.org/stable/c/e719b52d0c56989b0f3475a03a6d64f182c85b56","https://git.kernel.org/stable/c/f1c3c61701a0b12f4906152c1626a5de580ea3d2","https://git.kernel.org/stable/c/4ed82dd368ad883dc4284292937b882f044e625d","https://git.kernel.org/stable/c/6db5dc7b351b9569940cd1cf445e237c42cd6d27","https://git.kernel.org/stable/c/e3f078103421642fcd5f05c5e70777feb10f000d","https://git.kernel.org/stable/c/e719b52d0c56989b0f3475a03a6d64f182c85b56","https://git.kernel.org/stable/c/f1c3c61701a0b12f4906152c1626a5de580ea3d2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27016
|
Medium |
fixed |
- 5.15.157
- 6.1.88
- 6.6.29
- 6.8.8
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: flowtable: validate pppoe header
Ensure there is sufficient room to access the protocol field of the
PPPoe header. Validate it once before the flowtable lookup, then use a
helper function to access protocol field. |
["https://git.kernel.org/stable/c/87b3593bed1868b2d9fe096c01bcdf0ea86cbebf","https://git.kernel.org/stable/c/8bf7c76a2a207ca2b4cfda0a279192adf27678d7","https://git.kernel.org/stable/c/a2471d271042ea18e8a6babc132a8716bb2f08b9","https://git.kernel.org/stable/c/cf366ee3bc1b7d1c76a882640ba3b3f8f1039163","https://git.kernel.org/stable/c/d06977b9a4109f8738bb276125eb6a0b772bc433","https://git.kernel.org/stable/c/87b3593bed1868b2d9fe096c01bcdf0ea86cbebf","https://git.kernel.org/stable/c/8bf7c76a2a207ca2b4cfda0a279192adf27678d7","https://git.kernel.org/stable/c/a2471d271042ea18e8a6babc132a8716bb2f08b9","https://git.kernel.org/stable/c/cf366ee3bc1b7d1c76a882640ba3b3f8f1039163","https://git.kernel.org/stable/c/d06977b9a4109f8738bb276125eb6a0b772bc433"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48843
|
Medium |
fixed |
- 5.4.186
- 5.10.107
- 5.15.30
- 5.16.16
|
In the Linux kernel, the following vulnerability has been resolved:
drm/vrr: Set VRR capable prop only if it is attached to connector
VRR capable property is not attached by default to the connector
It is attached only if VRR is supported.
So if the driver tries to call drm core set prop function without
it being attached that causes NULL dereference. |
["https://git.kernel.org/stable/c/0ba557d330946c23559aaea2d51ea649fdeca98a","https://git.kernel.org/stable/c/3534c5c005ef99a1804ed50b8a72cdae254cabb5","https://git.kernel.org/stable/c/62929726ef0ec72cbbe9440c5d125d4278b99894","https://git.kernel.org/stable/c/85271e92ae4f13aa679acaa6cf76b3c36bcb7bab","https://git.kernel.org/stable/c/941e8bcd2b2ba95490738e33dfeca27168452779","https://git.kernel.org/stable/c/0ba557d330946c23559aaea2d51ea649fdeca98a","https://git.kernel.org/stable/c/3534c5c005ef99a1804ed50b8a72cdae254cabb5","https://git.kernel.org/stable/c/62929726ef0ec72cbbe9440c5d125d4278b99894","https://git.kernel.org/stable/c/85271e92ae4f13aa679acaa6cf76b3c36bcb7bab","https://git.kernel.org/stable/c/941e8bcd2b2ba95490738e33dfeca27168452779"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52815
|
Medium |
fixed |
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/vkms: fix a possible null pointer dereference
In amdgpu_vkms_conn_get_modes(), the return value of drm_cvt_mode()
is assigned to mode, which will lead to a NULL pointer dereference
on failure of drm_cvt_mode(). Add a check to avoid null pointer
dereference. |
["https://git.kernel.org/stable/c/33fb1a555354bd593f785935ddcb5d9dd4d3847f","https://git.kernel.org/stable/c/70f831f21155c692bb336c434936fd6f24f3f81a","https://git.kernel.org/stable/c/8c6c85a073768df68c1a3fea143d013a38c66d34","https://git.kernel.org/stable/c/cd90511557fdfb394bb4ac4c3b539b007383914c","https://git.kernel.org/stable/c/eaa03ea366c85ae3cb69c8d4bbc67c8bc2167a27","https://git.kernel.org/stable/c/33fb1a555354bd593f785935ddcb5d9dd4d3847f","https://git.kernel.org/stable/c/70f831f21155c692bb336c434936fd6f24f3f81a","https://git.kernel.org/stable/c/8c6c85a073768df68c1a3fea143d013a38c66d34","https://git.kernel.org/stable/c/cd90511557fdfb394bb4ac4c3b539b007383914c","https://git.kernel.org/stable/c/eaa03ea366c85ae3cb69c8d4bbc67c8bc2167a27"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36897
|
Medium |
fixed |
- 5.15.159
- 6.1.91
- 6.6.31
- 6.8.10
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Atom Integrated System Info v2_2 for DCN35
New request from KMD/VBIOS in order to support new UMA carveout
model. This fixes a null dereference from accessing
Ctx->dc_bios->integrated_info while it was NULL.
DAL parses through the BIOS and extracts the necessary
integrated_info but was missing a case for the new BIOS
version 2.3. |
["https://git.kernel.org/stable/c/02f5300f6827206f6e48a77f51e6264993695e5c","https://git.kernel.org/stable/c/3c7013a87124bab54216d9b99f77e8b6de6fbc1a","https://git.kernel.org/stable/c/7e3030774431eb093165a31baff040d35446fb8b","https://git.kernel.org/stable/c/9a35d205f466501dcfe5625ca313d944d0ac2d60","https://git.kernel.org/stable/c/c2797ec16d9072327e7578d09ee05bcab52fffd0","https://git.kernel.org/stable/c/02f5300f6827206f6e48a77f51e6264993695e5c","https://git.kernel.org/stable/c/3c7013a87124bab54216d9b99f77e8b6de6fbc1a","https://git.kernel.org/stable/c/7e3030774431eb093165a31baff040d35446fb8b","https://git.kernel.org/stable/c/9a35d205f466501dcfe5625ca313d944d0ac2d60","https://git.kernel.org/stable/c/c2797ec16d9072327e7578d09ee05bcab52fffd0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41093
|
Medium |
fixed |
- 5.15.162
- 6.1.97
- 6.6.37
- 6.9.8
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: avoid using null object of framebuffer
Instead of using state->fb->obj[0] directly, get object from framebuffer
by calling drm_gem_fb_get_obj() and return error code when object is
null to avoid using null object of framebuffer. |
["https://git.kernel.org/stable/c/330c8c1453848c04d335bad81371a66710210800","https://git.kernel.org/stable/c/6ce0544cabaa608018d5922ab404dc656a9d8447","https://git.kernel.org/stable/c/7f35e01cb0ea4d295f5c067bb5c67dfcddaf05bc","https://git.kernel.org/stable/c/bcfa48ff785bd121316592b131ff6531e3e696bb","https://git.kernel.org/stable/c/dd9ec0ea4cdde0fc48116e63969fc83e81d7ef46","https://git.kernel.org/stable/c/330c8c1453848c04d335bad81371a66710210800","https://git.kernel.org/stable/c/6ce0544cabaa608018d5922ab404dc656a9d8447","https://git.kernel.org/stable/c/7f35e01cb0ea4d295f5c067bb5c67dfcddaf05bc","https://git.kernel.org/stable/c/bcfa48ff785bd121316592b131ff6531e3e696bb","https://git.kernel.org/stable/c/dd9ec0ea4cdde0fc48116e63969fc83e81d7ef46"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49400
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
md: Don't set mddev private to NULL in raid0 pers->free
In normal stop process, it does like this:
do_md_stop
|
__md_stop (pers->free(); mddev->private=NULL)
|
md_free (free mddev)
__md_stop sets mddev->private to NULL after pers->free. The raid device
will be stopped and mddev memory is free. But in reshape, it doesn't
free the mddev and mddev will still be used in new raid.
In reshape, it first sets mddev->private to new_pers and then runs
old_pers->free(). Now raid0 sets mddev->private to NULL in raid0_free.
The new raid can't work anymore. It will panic when dereference
mddev->private because of NULL pointer dereference.
It can panic like this:
[63010.814972] kernel BUG at drivers/md/raid10.c:928!
[63010.819778] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[63010.825011] CPU: 3 PID: 44437 Comm: md0_resync Kdump: loaded Not tainted 5.14.0-86.el9.x86_64 #1
[63010.833789] Hardware name: Dell Inc. PowerEdge R6415/07YXFK, BIOS 1.15.0 09/11/2020
[63010.841440] RIP: 0010:raise_barrier+0x161/0x170 [raid10]
[63010.865508] RSP: 0018:ffffc312408bbc10 EFLAGS: 00010246
[63010.870734] RAX: 0000000000000000 RBX: ffffa00bf7d39800 RCX: 0000000000000000
[63010.877866] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffa00bf7d39800
[63010.884999] RBP: 0000000000000000 R08: fffffa4945e74400 R09: 0000000000000000
[63010.892132] R10: ffffa00eed02f798 R11: 0000000000000000 R12: ffffa00bbc435200
[63010.899266] R13: ffffa00bf7d39800 R14: 0000000000000400 R15: 0000000000000003
[63010.906399] FS: 0000000000000000(0000) GS:ffffa00eed000000(0000) knlGS:0000000000000000
[63010.914485] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[63010.920229] CR2: 00007f5cfbe99828 CR3: 0000000105efe000 CR4: 00000000003506e0
[63010.927363] Call Trace:
[63010.929822] ? bio_reset+0xe/0x40
[63010.933144] ? raid10_alloc_init_r10buf+0x60/0xa0 [raid10]
[63010.938629] raid10_sync_request+0x756/0x1610 [raid10]
[63010.943770] md_do_sync.cold+0x3e4/0x94c
[63010.947698] md_thread+0xab/0x160
[63010.951024] ? md_write_inc+0x50/0x50
[63010.954688] kthread+0x149/0x170
[63010.957923] ? set_kthread_struct+0x40/0x40
[63010.962107] ret_from_fork+0x22/0x30
Removing the code that sets mddev->private to NULL in raid0 can fix
problem. |
["https://git.kernel.org/stable/c/0f2571ad7a30ff6b33cde142439f9378669f8b4f","https://git.kernel.org/stable/c/7da3454a65f8a56e65dfb44fa0ccac08cbc2f5a1","https://git.kernel.org/stable/c/b7a51df785031cc49caf1c59766ca89cfa97b54b","https://git.kernel.org/stable/c/f63fd1e0e0fc158023cc67ea6a07e278019061ba"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52846
|
High |
fixed |
- 5.10.201
- 5.15.139
- 6.1.63
- 6.5.12
- 6.6.2
|
In the Linux kernel, the following vulnerability has been resolved:
hsr: Prevent use after free in prp_create_tagged_frame()
The prp_fill_rct() function can fail. In that situation, it frees the
skb and returns NULL. Meanwhile on the success path, it returns the
original skb. So it's straight forward to fix bug by using the returned
value. |
["https://git.kernel.org/stable/c/1787b9f0729d318d67cf7c5a95f0c3dba9a7cc18","https://git.kernel.org/stable/c/6086258bd5ea7b5c706ff62da42b8e271b2401db","https://git.kernel.org/stable/c/876f8ab52363f649bcc74072157dfd7adfbabc0d","https://git.kernel.org/stable/c/a1a485e45d24b1cd8fe834fd6f1b06e2903827da","https://git.kernel.org/stable/c/d103fb6726904e353b4773188ee3d3acb4078363","https://git.kernel.org/stable/c/ddf4e04e946aaa6c458b8b6829617cc44af2bffd","https://git.kernel.org/stable/c/1787b9f0729d318d67cf7c5a95f0c3dba9a7cc18","https://git.kernel.org/stable/c/6086258bd5ea7b5c706ff62da42b8e271b2401db","https://git.kernel.org/stable/c/876f8ab52363f649bcc74072157dfd7adfbabc0d","https://git.kernel.org/stable/c/a1a485e45d24b1cd8fe834fd6f1b06e2903827da","https://git.kernel.org/stable/c/d103fb6726904e353b4773188ee3d3acb4078363","https://git.kernel.org/stable/c/ddf4e04e946aaa6c458b8b6829617cc44af2bffd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52854
|
High |
fixed |
- 3.17
- 4.5
- 4.10
- 4.15
- 4.20
- 5.5
- 5.10.201
- 5.15.139
- 6.1.63
- 6.5.12
- 6.6.2
|
In the Linux kernel, the following vulnerability has been resolved:
padata: Fix refcnt handling in padata_free_shell()
In a high-load arm64 environment, the pcrypt_aead01 test in LTP can lead
to system UAF (Use-After-Free) issues. Due to the lengthy analysis of
the pcrypt_aead01 function call, I'll describe the problem scenario
using a simplified model:
Suppose there's a user of padata named `user_function` that adheres to
the padata requirement of calling `padata_free_shell` after `serial()`
has been invoked, as demonstrated in the following code:
```c
struct request {
struct padata_priv padata;
struct completion *done;
};
void parallel(struct padata_priv *padata) {
do_something();
}
void serial(struct padata_priv *padata) {
struct request *request = container_of(padata,
struct request,
padata);
complete(request->done);
}
void user_function() {
DECLARE_COMPLETION(done)
padata->parallel = parallel;
padata->serial = serial;
padata_do_parallel();
wait_for_completion(&done);
padata_free_shell();
}
```
In the corresponding padata.c file, there's the following code:
```c
static void padata_serial_worker(struct work_struct *serial_work) {
...
cnt = 0;
while (!list_empty(&local_list)) {
...
padata->serial(padata);
cnt++;
}
local_bh_enable();
if (refcount_sub_and_test(cnt, &pd->refcnt))
padata_free_pd(pd);
}
```
Because of the high system load and the accumulation of unexecuted
softirq at this moment, `local_bh_enable()` in padata takes longer
to execute than usual. Subsequently, when accessing `pd->refcnt`,
`pd` has already been released by `padata_free_shell()`, resulting
in a UAF issue with `pd->refcnt`.
The fix is straightforward: add `refcount_dec_and_test` before calling
`padata_free_pd` in `padata_free_shell`. |
["https://git.kernel.org/stable/c/0dd34a7ad395dbcf6ae60e48e9786050e25b9bc5","https://git.kernel.org/stable/c/1734a79e951914f1db2c65e635012a35db1c674b","https://git.kernel.org/stable/c/1e901bcb8af19416b65f5063a4af7996e5a51d7f","https://git.kernel.org/stable/c/41aad9d6953984d134fc50f631f24ef476875d4d","https://git.kernel.org/stable/c/7ddc21e317b360c3444de3023bcc83b85fabae2f","https://git.kernel.org/stable/c/c7c26d0ef5d20f00dbb2ae3befcabbe0efa77275","https://git.kernel.org/stable/c/0dd34a7ad395dbcf6ae60e48e9786050e25b9bc5","https://git.kernel.org/stable/c/1734a79e951914f1db2c65e635012a35db1c674b","https://git.kernel.org/stable/c/1e901bcb8af19416b65f5063a4af7996e5a51d7f","https://git.kernel.org/stable/c/41aad9d6953984d134fc50f631f24ef476875d4d","https://git.kernel.org/stable/c/7ddc21e317b360c3444de3023bcc83b85fabae2f","https://git.kernel.org/stable/c/c7c26d0ef5d20f00dbb2ae3befcabbe0efa77275"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38555
|
High |
fixed |
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Discard command completions in internal error
Fix use after free when FW completion arrives while device is in
internal error state. Avoid calling completion handler in this case,
since the device will flush the command interface and trigger all
completions manually.
Kernel log:
------------[ cut here ]------------
refcount_t: underflow; use-after-free.
...
RIP: 0010:refcount_warn_saturate+0xd8/0xe0
...
Call Trace:
<IRQ>
? __warn+0x79/0x120
? refcount_warn_saturate+0xd8/0xe0
? report_bug+0x17c/0x190
? handle_bug+0x3c/0x60
? exc_invalid_op+0x14/0x70
? asm_exc_invalid_op+0x16/0x20
? refcount_warn_saturate+0xd8/0xe0
cmd_ent_put+0x13b/0x160 [mlx5_core]
mlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core]
cmd_comp_notifier+0x1f/0x30 [mlx5_core]
notifier_call_chain+0x35/0xb0
atomic_notifier_call_chain+0x16/0x20
mlx5_eq_async_int+0xf6/0x290 [mlx5_core]
notifier_call_chain+0x35/0xb0
atomic_notifier_call_chain+0x16/0x20
irq_int_handler+0x19/0x30 [mlx5_core]
__handle_irq_event_percpu+0x4b/0x160
handle_irq_event+0x2e/0x80
handle_edge_irq+0x98/0x230
__common_interrupt+0x3b/0xa0
common_interrupt+0x7b/0xa0
</IRQ>
<TASK>
asm_common_interrupt+0x22/0x40 |
["https://git.kernel.org/stable/c/1337ec94bc5a9eed250e33f5f5c89a28a6bfabdb","https://git.kernel.org/stable/c/1d5dce5e92a70274de67a59e1e674c3267f94cd7","https://git.kernel.org/stable/c/3cb92b0ad73d3f1734e812054e698d655e9581b0","https://git.kernel.org/stable/c/7ac4c69c34240c6de820492c0a28a0bd1494265a","https://git.kernel.org/stable/c/bf8aaf0ae01c27ae3c06aa8610caf91e50393396","https://git.kernel.org/stable/c/db9b31aa9bc56ff0d15b78f7e827d61c4a096e40","https://git.kernel.org/stable/c/f6fbb8535e990f844371086ab2c1221f71f993d3","https://git.kernel.org/stable/c/1337ec94bc5a9eed250e33f5f5c89a28a6bfabdb","https://git.kernel.org/stable/c/1d5dce5e92a70274de67a59e1e674c3267f94cd7","https://git.kernel.org/stable/c/3cb92b0ad73d3f1734e812054e698d655e9581b0","https://git.kernel.org/stable/c/7ac4c69c34240c6de820492c0a28a0bd1494265a","https://git.kernel.org/stable/c/bf8aaf0ae01c27ae3c06aa8610caf91e50393396","https://git.kernel.org/stable/c/db9b31aa9bc56ff0d15b78f7e827d61c4a096e40","https://git.kernel.org/stable/c/f6fbb8535e990f844371086ab2c1221f71f993d3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38627
|
High |
fixed |
- 4.19.316
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.9.4
|
In the Linux kernel, the following vulnerability has been resolved:
stm class: Fix a double free in stm_register_device()
The put_device(&stm->dev) call will trigger stm_device_release() which
frees "stm" so the vfree(stm) on the next line is a double free. |
["https://git.kernel.org/stable/c/370c480410f60b90ba3e96abe73ead21ec827b20","https://git.kernel.org/stable/c/3df463865ba42b8f88a590326f4c9ea17a1ce459","https://git.kernel.org/stable/c/4bfd48bb6e62512b9c392c5002c11e1e3b18d247","https://git.kernel.org/stable/c/6cc30ef8eb6d8f8d6df43152264bbf8835d99931","https://git.kernel.org/stable/c/713fc00c571dde4af3db2dbd5d1b0eadc327817b","https://git.kernel.org/stable/c/7419df1acffbcc90037f6b5a2823e81389659b36","https://git.kernel.org/stable/c/a0450d3f38e7c6c0a7c0afd4182976ee15573695","https://git.kernel.org/stable/c/d782a2db8f7ac49c33b9ca3e835500a28667d1be","https://git.kernel.org/stable/c/370c480410f60b90ba3e96abe73ead21ec827b20","https://git.kernel.org/stable/c/3df463865ba42b8f88a590326f4c9ea17a1ce459","https://git.kernel.org/stable/c/4bfd48bb6e62512b9c392c5002c11e1e3b18d247","https://git.kernel.org/stable/c/6cc30ef8eb6d8f8d6df43152264bbf8835d99931","https://git.kernel.org/stable/c/713fc00c571dde4af3db2dbd5d1b0eadc327817b","https://git.kernel.org/stable/c/7419df1acffbcc90037f6b5a2823e81389659b36","https://git.kernel.org/stable/c/a0450d3f38e7c6c0a7c0afd4182976ee15573695","https://git.kernel.org/stable/c/d782a2db8f7ac49c33b9ca3e835500a28667d1be"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41011
|
High |
fixed |
- 5.4.283
- 5.10.225
- 5.15.166
- 6.1.91
- 6.8.10
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: don't allow mapping the MMIO HDP page with large pages
We don't get the right offset in that case. The GPU has
an unused 4K area of the register BAR space into which you can
remap registers. We remap the HDP flush registers into this
space to allow userspace (CPU or GPU) to flush the HDP when it
updates VRAM. However, on systems with >4K pages, we end up
exposing PAGE_SIZE of MMIO space. |
["https://git.kernel.org/stable/c/009c4d78bcf07c4ac2e3dd9f275b4eaa72b4f884","https://git.kernel.org/stable/c/4b4cff994a27ebf7bd3fb9a798a1cdfa8d01b724","https://git.kernel.org/stable/c/6186c93560889265bfe0914609c274eff40bbeb5","https://git.kernel.org/stable/c/89fffbdf535ce659c1a26b51ad62070566e33b28","https://git.kernel.org/stable/c/8ad4838040e5515939c071a0f511ce2661a0889d","https://git.kernel.org/stable/c/be4a2a81b6b90d1a47eaeaace4cc8e2cb57b96c7","https://git.kernel.org/stable/c/f7276cdc1912325b64c33fcb1361952c06e55f63","https://git.kernel.org/stable/c/4b4cff994a27ebf7bd3fb9a798a1cdfa8d01b724","https://git.kernel.org/stable/c/6186c93560889265bfe0914609c274eff40bbeb5","https://git.kernel.org/stable/c/89fffbdf535ce659c1a26b51ad62070566e33b28","https://git.kernel.org/stable/c/be4a2a81b6b90d1a47eaeaace4cc8e2cb57b96c7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41046
|
High |
fixed |
- 4.19.318
- 5.4.280
- 5.10.222
- 5.15.163
- 6.1.100
- 6.6.41
- 6.9.10
|
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: lantiq_etop: fix double free in detach
The number of the currently released descriptor is never incremented
which results in the same skb being released multiple times. |
["https://git.kernel.org/stable/c/1a2db00a554cfda57c397cce79b2804bf9633fec","https://git.kernel.org/stable/c/22b16618a80858b3a9d607708444426948cc4ae1","https://git.kernel.org/stable/c/69ad5fa0ce7c548262e0770fc2b726fe7ab4f156","https://git.kernel.org/stable/c/84aaaa796a19195fc59290154fef9aeb1fba964f","https://git.kernel.org/stable/c/907443174e76b854d28024bd079f0e53b94dc9a1","https://git.kernel.org/stable/c/9d23909ae041761cb2aa0c3cb1748598d8b6bc54","https://git.kernel.org/stable/c/c2b66e2b3939af63699e4a4bd25a8ac4a9b1d1b3","https://git.kernel.org/stable/c/e1533b6319ab9c3a97dad314dd88b3783bc41b69","https://git.kernel.org/stable/c/1a2db00a554cfda57c397cce79b2804bf9633fec","https://git.kernel.org/stable/c/22b16618a80858b3a9d607708444426948cc4ae1","https://git.kernel.org/stable/c/69ad5fa0ce7c548262e0770fc2b726fe7ab4f156","https://git.kernel.org/stable/c/84aaaa796a19195fc59290154fef9aeb1fba964f","https://git.kernel.org/stable/c/907443174e76b854d28024bd079f0e53b94dc9a1","https://git.kernel.org/stable/c/9d23909ae041761cb2aa0c3cb1748598d8b6bc54","https://git.kernel.org/stable/c/c2b66e2b3939af63699e4a4bd25a8ac4a9b1d1b3","https://git.kernel.org/stable/c/e1533b6319ab9c3a97dad314dd88b3783bc41b69"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42148
|
High |
fixed |
- 4.19.318
- 5.4.280
- 5.10.222
- 5.15.163
- 6.1.98
- 6.6.39
- 6.9.9
|
In the Linux kernel, the following vulnerability has been resolved:
bnx2x: Fix multiple UBSAN array-index-out-of-bounds
Fix UBSAN warnings that occur when using a system with 32 physical
cpu cores or more, or when the user defines a number of Ethernet
queues greater than or equal to FP_SB_MAX_E1x using the num_queues
module parameter.
Currently there is a read/write out of bounds that occurs on the array
"struct stats_query_entry query" present inside the "bnx2x_fw_stats_req"
struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h".
Looking at the definition of the "struct stats_query_entry query" array:
struct stats_query_entry query[FP_SB_MAX_E1x+
BNX2X_FIRST_QUEUE_QUERY_IDX];
FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and
has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3
meaning the array has a total size of 19.
Since accesses to "struct stats_query_entry query" are offset-ted by
BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet
queues should not exceed FP_SB_MAX_E1x (16). However one of these queues
is reserved for FCOE and thus the number of Ethernet queues should be set
to [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if
it is not.
This is also described in a comment in the source code in
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition
of FP_SB_MAX_E1x. Below is the part of this explanation that it important
for this patch
/*
* The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is
* control by the number of fast-path status blocks supported by the
* device (HW/FW). Each fast-path status block (FP-SB) aka non-default
* status block represents an independent interrupts context that can
* serve a regular L2 networking queue. However special L2 queues such
* as the FCoE queue do not require a FP-SB and other components like
* the CNIC may consume FP-SB reducing the number of possible L2 queues
*
* If the maximum number of FP-SB available is X then:
* a. If CNIC is supported it consumes 1 FP-SB thus the max number of
* regular L2 queues is Y=X-1
* b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor)
* c. If the FCoE L2 queue is supported the actual number of L2 queues
* is Y+1
* d. The number of irqs (MSIX vectors) is either Y+1 (one extra for
* slow-path interrupts) or Y+2 if CNIC is supported (one additional
* FP interrupt context for the CNIC).
* e. The number of HW context (CID count) is always X or X+1 if FCoE
* L2 queue is supported. The cid for the FCoE L2 queue is always X.
*/
However this driver also supports NICs that use the E2 controller which can
handle more queues due to having more FP-SB represented by FP_SB_MAX_E2.
Looking at the commits when the E2 support was added, it was originally
using the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support").
Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver
was later updated to take full advantage of the E2 instead of having it be
limited to the capabilities of the E1x. But as far as we can tell, the
array "stats_query_entry query" was still limited to using the FP-SB
available to the E1x cards as part of an oversignt when the driver was
updated to take full advantage of the E2, and now with the driver being
aware of the greater queue size supported by E2 NICs, it causes the UBSAN
warnings seen in the stack traces below.
This patch increases the size of the "stats_query_entry query" array by
replacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle
both types of NICs.
Stack traces:
UBSAN: array-index-out-of-bounds in
drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11
index 20 is out of range for type 'stats_query_entry [19]'
CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic
#202405052133
Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360
---truncated--- |
["https://git.kernel.org/stable/c/0edae06b4c227bcfaf3ce21208d49191e1009d3b","https://git.kernel.org/stable/c/134061163ee5ca4759de5c24ca3bd71608891ba7","https://git.kernel.org/stable/c/8b17cec33892a66bbd71f8d9a70a45e2072ae84f","https://git.kernel.org/stable/c/9504a1550686f53b0bab4cab31d435383b1ee2ce","https://git.kernel.org/stable/c/b9ea38e767459111a511ed4fb74abc37db95a59d","https://git.kernel.org/stable/c/cbe53087026ad929cd3950508397e8892a6a2a0f","https://git.kernel.org/stable/c/cfb04472ce33bee2579caf4dc9f4242522f6e26e","https://git.kernel.org/stable/c/f1313ea92f82451923e28ab45a4aaa0e70e80b98","https://git.kernel.org/stable/c/0edae06b4c227bcfaf3ce21208d49191e1009d3b","https://git.kernel.org/stable/c/134061163ee5ca4759de5c24ca3bd71608891ba7","https://git.kernel.org/stable/c/8b17cec33892a66bbd71f8d9a70a45e2072ae84f","https://git.kernel.org/stable/c/9504a1550686f53b0bab4cab31d435383b1ee2ce","https://git.kernel.org/stable/c/b9ea38e767459111a511ed4fb74abc37db95a59d","https://git.kernel.org/stable/c/cbe53087026ad929cd3950508397e8892a6a2a0f","https://git.kernel.org/stable/c/cfb04472ce33bee2579caf4dc9f4242522f6e26e","https://git.kernel.org/stable/c/f1313ea92f82451923e28ab45a4aaa0e70e80b98"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48637
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bnxt: prevent skb UAF after handing over to PTP worker
When reading the timestamp is required bnxt_tx_int() hands
over the ownership of the completed skb to the PTP worker.
The skb should not be used afterwards, as the worker may
run before the rest of our code and free the skb, leading
to a use-after-free.
Since dev_kfree_skb_any() accepts NULL make the loss of
ownership more obvious and set skb to NULL. |
["https://git.kernel.org/stable/c/08483e4c0c83b221b8891434a04cec405dee94a6","https://git.kernel.org/stable/c/32afa1f23e42cc635ccf4c39f24514d03d1e8338","https://git.kernel.org/stable/c/c31f26c8f69f776759cbbdfb38e40ea91aa0dd65","https://git.kernel.org/stable/c/08483e4c0c83b221b8891434a04cec405dee94a6","https://git.kernel.org/stable/c/32afa1f23e42cc635ccf4c39f24514d03d1e8338","https://git.kernel.org/stable/c/c31f26c8f69f776759cbbdfb38e40ea91aa0dd65"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52751
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free in smb2_query_info_compound()
The following UAF was triggered when running fstests generic/072 with
KASAN enabled against Windows Server 2022 and mount options
'multichannel,max_channels=2,vers=3.1.1,mfsymlinks,noperm'
BUG: KASAN: slab-use-after-free in smb2_query_info_compound+0x423/0x6d0 [cifs]
Read of size 8 at addr ffff888014941048 by task xfs_io/27534
CPU: 0 PID: 27534 Comm: xfs_io Not tainted 6.6.0-rc7 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
Call Trace:
dump_stack_lvl+0x4a/0x80
print_report+0xcf/0x650
? srso_alias_return_thunk+0x5/0x7f
? srso_alias_return_thunk+0x5/0x7f
? __phys_addr+0x46/0x90
kasan_report+0xda/0x110
? smb2_query_info_compound+0x423/0x6d0 [cifs]
? smb2_query_info_compound+0x423/0x6d0 [cifs]
smb2_query_info_compound+0x423/0x6d0 [cifs]
? __pfx_smb2_query_info_compound+0x10/0x10 [cifs]
? srso_alias_return_thunk+0x5/0x7f
? __stack_depot_save+0x39/0x480
? kasan_save_stack+0x33/0x60
? kasan_set_track+0x25/0x30
? ____kasan_slab_free+0x126/0x170
smb2_queryfs+0xc2/0x2c0 [cifs]
? __pfx_smb2_queryfs+0x10/0x10 [cifs]
? __pfx___lock_acquire+0x10/0x10
smb311_queryfs+0x210/0x220 [cifs]
? __pfx_smb311_queryfs+0x10/0x10 [cifs]
? srso_alias_return_thunk+0x5/0x7f
? __lock_acquire+0x480/0x26c0
? lock_release+0x1ed/0x640
? srso_alias_return_thunk+0x5/0x7f
? do_raw_spin_unlock+0x9b/0x100
cifs_statfs+0x18c/0x4b0 [cifs]
statfs_by_dentry+0x9b/0xf0
fd_statfs+0x4e/0xb0
__do_sys_fstatfs+0x7f/0xe0
? __pfx___do_sys_fstatfs+0x10/0x10
? srso_alias_return_thunk+0x5/0x7f
? lockdep_hardirqs_on_prepare+0x136/0x200
? srso_alias_return_thunk+0x5/0x7f
do_syscall_64+0x3f/0x90
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Allocated by task 27534:
kasan_save_stack+0x33/0x60
kasan_set_track+0x25/0x30
__kasan_kmalloc+0x8f/0xa0
open_cached_dir+0x71b/0x1240 [cifs]
smb2_query_info_compound+0x5c3/0x6d0 [cifs]
smb2_queryfs+0xc2/0x2c0 [cifs]
smb311_queryfs+0x210/0x220 [cifs]
cifs_statfs+0x18c/0x4b0 [cifs]
statfs_by_dentry+0x9b/0xf0
fd_statfs+0x4e/0xb0
__do_sys_fstatfs+0x7f/0xe0
do_syscall_64+0x3f/0x90
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Freed by task 27534:
kasan_save_stack+0x33/0x60
kasan_set_track+0x25/0x30
kasan_save_free_info+0x2b/0x50
____kasan_slab_free+0x126/0x170
slab_free_freelist_hook+0xd0/0x1e0
__kmem_cache_free+0x9d/0x1b0
open_cached_dir+0xff5/0x1240 [cifs]
smb2_query_info_compound+0x5c3/0x6d0 [cifs]
smb2_queryfs+0xc2/0x2c0 [cifs]
This is a race between open_cached_dir() and cached_dir_lease_break()
where the cache entry for the open directory handle receives a lease
break while creating it. And before returning from open_cached_dir(),
we put the last reference of the new @cfid because of
!@cfid->has_lease.
Besides the UAF, while running xfstests a lot of missed lease breaks
have been noticed in tests that run several concurrent statfs(2) calls
on those cached fids
CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame...
CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1...
CIFS: VFS: \\w22-root1.gandalf.test smb buf 00000000715bfe83 len 108
CIFS: VFS: Dump pending requests:
CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame...
CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1...
CIFS: VFS: \\w22-root1.gandalf.test smb buf 000000005aa7316e len 108
...
To fix both, in open_cached_dir() ensure that @cfid->has_lease is set
right before sending out compounded request so that any potential
lease break will be get processed by demultiplex thread while we're
still caching @cfid. And, if open failed for some reason, re-check
@cfid->has_lease to decide whether or not put lease reference. |
["https://git.kernel.org/stable/c/5c86919455c1edec99ebd3338ad213b59271a71b","https://git.kernel.org/stable/c/6db94d08359c43f2c8fe372811cdee04564a41b9","https://git.kernel.org/stable/c/93877b9afc2994c89362007aac480a7b150f386f","https://git.kernel.org/stable/c/5c86919455c1edec99ebd3338ad213b59271a71b","https://git.kernel.org/stable/c/6db94d08359c43f2c8fe372811cdee04564a41b9","https://git.kernel.org/stable/c/93877b9afc2994c89362007aac480a7b150f386f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35887
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ax25: fix use-after-free bugs caused by ax25_ds_del_timer
When the ax25 device is detaching, the ax25_dev_device_down()
calls ax25_ds_del_timer() to cleanup the slave_timer. When
the timer handler is running, the ax25_ds_del_timer() that
calls del_timer() in it will return directly. As a result,
the use-after-free bugs could happen, one of the scenarios
is shown below:
(Thread 1) | (Thread 2)
| ax25_ds_timeout()
ax25_dev_device_down() |
ax25_ds_del_timer() |
del_timer() |
ax25_dev_put() //FREE |
| ax25_dev-> //USE
In order to mitigate bugs, when the device is detaching, use
timer_shutdown_sync() to stop the timer. |
["https://git.kernel.org/stable/c/74204bf9050f7627aead9875fe4e07ba125cb19b","https://git.kernel.org/stable/c/c6a368f9c7af4c14b14d390c2543af8001c9bdb9","https://git.kernel.org/stable/c/fd819ad3ecf6f3c232a06b27423ce9ed8c20da89","https://git.kernel.org/stable/c/74204bf9050f7627aead9875fe4e07ba125cb19b","https://git.kernel.org/stable/c/c6a368f9c7af4c14b14d390c2543af8001c9bdb9","https://git.kernel.org/stable/c/fd819ad3ecf6f3c232a06b27423ce9ed8c20da89"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38630
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger
When the cpu5wdt module is removing, the origin code uses del_timer() to
de-activate the timer. If the timer handler is running, del_timer() could
not stop it and will return directly. If the port region is released by
release_region() and then the timer handler cpu5wdt_trigger() calls outb()
to write into the region that is released, the use-after-free bug will
happen.
Change del_timer() to timer_shutdown_sync() in order that the timer handler
could be finished before the port region is released. |
["https://git.kernel.org/stable/c/573601521277119f2e2ba5f28ae6e87fc594f4d4","https://git.kernel.org/stable/c/9b1c063ffc075abf56f63e55d70b9778ff534314","https://git.kernel.org/stable/c/f19686d616500cd0d47b30cee82392b53f7f784a","https://git.kernel.org/stable/c/573601521277119f2e2ba5f28ae6e87fc594f4d4","https://git.kernel.org/stable/c/9b1c063ffc075abf56f63e55d70b9778ff534314","https://git.kernel.org/stable/c/f19686d616500cd0d47b30cee82392b53f7f784a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42313
|
High |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
media: venus: fix use after free in vdec_close
There appears to be a possible use after free with vdec_close().
The firmware will add buffer release work to the work queue through
HFI callbacks as a normal part of decoding. Randomly closing the
decoder device from userspace during normal decoding can incur
a read after free for inst.
Fix it by cancelling the work in vdec_close. |
["https://git.kernel.org/stable/c/4c9d235630d35db762b85a4149bbb0be9d504c36","https://git.kernel.org/stable/c/66fa52edd32cdbb675f0803b3c4da10ea19b6635","https://git.kernel.org/stable/c/6a96041659e834dc0b172dda4b2df512d63920c2","https://git.kernel.org/stable/c/72aff311194c8ceda934f24fd6f250b8827d7567","https://git.kernel.org/stable/c/a0157b5aa34eb43ec4c5510f9c260bbb03be937e","https://git.kernel.org/stable/c/ad8cf035baf29467158e0550c7a42b7bb43d1db6","https://git.kernel.org/stable/c/da55685247f409bf7f976cc66ba2104df75d8dad","https://git.kernel.org/stable/c/f8e9a63b982a8345470c225679af4ba86e4a7282"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44934
|
High |
fixed |
- 5.15.165
- 6.1.105
- 6.6.46
- 6.10.5
|
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: mcast: wait for previous gc cycles when removing port
syzbot hit a use-after-free[1] which is caused because the bridge doesn't
make sure that all previous garbage has been collected when removing a
port. What happens is:
CPU 1 CPU 2
start gc cycle remove port
acquire gc lock first
wait for lock
call br_multicasg_gc() directly
acquire lock now but free port
the port can be freed
while grp timers still
running
Make sure all previous gc cycles have finished by using flush_work before
freeing the port.
[1]
BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861
Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699
CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114
print_address_description mm/kasan/report.c:377 [inline]
print_report+0xc3/0x620 mm/kasan/report.c:488
kasan_report+0xd9/0x110 mm/kasan/report.c:601
br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861
call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792
expire_timers kernel/time/timer.c:1843 [inline]
__run_timers+0x74b/0xaf0 kernel/time/timer.c:2417
__run_timer_base kernel/time/timer.c:2428 [inline]
__run_timer_base kernel/time/timer.c:2421 [inline]
run_timer_base+0x111/0x190 kernel/time/timer.c:2437 |
["https://git.kernel.org/stable/c/0d8b26e10e680c01522d7cc14abe04c3265a928f","https://git.kernel.org/stable/c/1e16828020c674b3be85f52685e8b80f9008f50f","https://git.kernel.org/stable/c/92c4ee25208d0f35dafc3213cdf355fbe449e078","https://git.kernel.org/stable/c/b2f794b168cf560682ff976b255aa6d29d14a658","https://git.kernel.org/stable/c/e3145ca904fa8dbfd1a5bf0187905bc117b0efce"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48956
|
High |
fixed |
- 4.14.302
- 4.19.269
- 5.4.227
- 5.10.159
- 5.15.83
- 6.0.13
|
In the Linux kernel, the following vulnerability has been resolved:
ipv6: avoid use-after-free in ip6_fragment()
Blamed commit claimed rcu_read_lock() was held by ip6_fragment() callers.
It seems to not be always true, at least for UDP stack.
syzbot reported:
BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:245 [inline]
BUG: KASAN: use-after-free in ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951
Read of size 8 at addr ffff88801d403e80 by task syz-executor.3/7618
CPU: 1 PID: 7618 Comm: syz-executor.3 Not tainted 6.1.0-rc6-syzkaller-00012-g4312098baf37 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:284 [inline]
print_report+0x15e/0x45d mm/kasan/report.c:395
kasan_report+0xbf/0x1f0 mm/kasan/report.c:495
ip6_dst_idev include/net/ip6_fib.h:245 [inline]
ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951
__ip6_finish_output net/ipv6/ip6_output.c:193 [inline]
ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206
NF_HOOK_COND include/linux/netfilter.h:291 [inline]
ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227
dst_output include/net/dst.h:445 [inline]
ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161
ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966
udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286
udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313
udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606
inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg+0xd3/0x120 net/socket.c:734
sock_write_iter+0x295/0x3d0 net/socket.c:1108
call_write_iter include/linux/fs.h:2191 [inline]
new_sync_write fs/read_write.c:491 [inline]
vfs_write+0x9ed/0xdd0 fs/read_write.c:584
ksys_write+0x1ec/0x250 fs/read_write.c:637
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fde3588c0d9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fde365b6168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007fde359ac050 RCX: 00007fde3588c0d9
RDX: 000000000000ffdc RSI: 00000000200000c0 RDI: 000000000000000a
RBP: 00007fde358e7ae9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fde35acfb1f R14: 00007fde365b6300 R15: 0000000000022000
</TASK>
Allocated by task 7618:
kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
kasan_set_track+0x25/0x30 mm/kasan/common.c:52
__kasan_slab_alloc+0x82/0x90 mm/kasan/common.c:325
kasan_slab_alloc include/linux/kasan.h:201 [inline]
slab_post_alloc_hook mm/slab.h:737 [inline]
slab_alloc_node mm/slub.c:3398 [inline]
slab_alloc mm/slub.c:3406 [inline]
__kmem_cache_alloc_lru mm/slub.c:3413 [inline]
kmem_cache_alloc+0x2b4/0x3d0 mm/slub.c:3422
dst_alloc+0x14a/0x1f0 net/core/dst.c:92
ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344
ip6_rt_pcpu_alloc net/ipv6/route.c:1369 [inline]
rt6_make_pcpu_route net/ipv6/route.c:1417 [inline]
ip6_pol_route+0x901/0x1190 net/ipv6/route.c:2254
pol_lookup_func include/net/ip6_fib.h:582 [inline]
fib6_rule_lookup+0x52e/0x6f0 net/ipv6/fib6_rules.c:121
ip6_route_output_flags_noref+0x2e6/0x380 net/ipv6/route.c:2625
ip6_route_output_flags+0x76/0x320 net/ipv6/route.c:2638
ip6_route_output include/net/ip6_route.h:98 [inline]
ip6_dst_lookup_tail+0x5ab/0x1620 net/ipv6/ip6_output.c:1092
ip6_dst_lookup_flow+0x90/0x1d0 net/ipv6/ip6_output.c:1222
ip6_sk_dst_lookup_flow+0x553/0x980 net/ipv6/ip6_output.c:1260
udpv6_sendmsg+0x151d/0x2c80 net/ipv6/udp.c:1554
inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665
sock_sendmsg_nosec n
---truncated--- |
["https://git.kernel.org/stable/c/6b6d3be3661bff2746cab26147bd629aa034e094","https://git.kernel.org/stable/c/7390c70bd431cbfa6951477e2c80a301643e284b","https://git.kernel.org/stable/c/7e0dcd5f3ade221a6126278aca60c8ab4cc3bce9","https://git.kernel.org/stable/c/803e84867de59a1e5d126666d25eb4860cfd2ebe","https://git.kernel.org/stable/c/8208d7e56b1e579320b9ff3712739ad2e63e1f86","https://git.kernel.org/stable/c/9b1a468a455d8319041528778d0e684a4c062792","https://git.kernel.org/stable/c/b3d7ff8c04a83279fb7641fc4d5aa82a602df7c0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26982
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
Squashfs: check the inode number is not the invalid value of zero
Syskiller has produced an out of bounds access in fill_meta_index().
That out of bounds access is ultimately caused because the inode
has an inode number with the invalid value of zero, which was not checked.
The reason this causes the out of bounds access is due to following
sequence of events:
1. Fill_meta_index() is called to allocate (via empty_meta_index())
and fill a metadata index. It however suffers a data read error
and aborts, invalidating the newly returned empty metadata index.
It does this by setting the inode number of the index to zero,
which means unused (zero is not a valid inode number).
2. When fill_meta_index() is subsequently called again on another
read operation, locate_meta_index() returns the previous index
because it matches the inode number of 0. Because this index
has been returned it is expected to have been filled, and because
it hasn't been, an out of bounds access is performed.
This patch adds a sanity check which checks that the inode number
is not zero when the inode is created and returns -EINVAL if it is.
[phillip@squashfs.org.uk: whitespace fix] |
["https://git.kernel.org/stable/c/32c114a58236fe67141634774559f21f1dc96fd7","https://git.kernel.org/stable/c/4a1b6f89825e267e156ccaeba3d235edcac77f94","https://git.kernel.org/stable/c/5b99dea79650b50909c50aba24fbae00f203f013","https://git.kernel.org/stable/c/7def00ebc9f2d6a581ddf46ce4541f84a10680e5","https://git.kernel.org/stable/c/9253c54e01b6505d348afbc02abaa4d9f8a01395","https://git.kernel.org/stable/c/be383effaee3d89034f0828038f95065b518772e","https://git.kernel.org/stable/c/cf46f88b92cfc0e32bd8a21ba1273cff13b8745f","https://git.kernel.org/stable/c/7def00ebc9f2d6a581ddf46ce4541f84a10680e5","https://git.kernel.org/stable/c/9253c54e01b6505d348afbc02abaa4d9f8a01395","https://git.kernel.org/stable/c/be383effaee3d89034f0828038f95065b518772e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35937
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: check A-MSDU format more carefully
If it looks like there's another subframe in the A-MSDU
but the header isn't fully there, we can end up reading
data out of bounds, only to discard later. Make this a
bit more careful and check if the subframe header can
even be present. |
["https://git.kernel.org/stable/c/16da1e1dac23be45ef6e23c41b1508c400e6c544","https://git.kernel.org/stable/c/5d7a8585fbb31e88fb2a0f581b70667d3300d1e9","https://git.kernel.org/stable/c/9ad7974856926129f190ffbe3beea78460b3b7cc","https://git.kernel.org/stable/c/9eb3bc0973d084423a6df21cf2c74692ff05647e","https://git.kernel.org/stable/c/16da1e1dac23be45ef6e23c41b1508c400e6c544","https://git.kernel.org/stable/c/5d7a8585fbb31e88fb2a0f581b70667d3300d1e9","https://git.kernel.org/stable/c/9ad7974856926129f190ffbe3beea78460b3b7cc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43882
|
High |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.106
- 6.6.47
- 6.10.6
|
In the Linux kernel, the following vulnerability has been resolved:
exec: Fix ToCToU between perm check and set-uid/gid usage
When opening a file for exec via do_filp_open(), permission checking is
done against the file's metadata at that moment, and on success, a file
pointer is passed back. Much later in the execve() code path, the file
metadata (specifically mode, uid, and gid) is used to determine if/how
to set the uid and gid. However, those values may have changed since the
permissions check, meaning the execution may gain unintended privileges.
For example, if a file could change permissions from executable and not
set-id:
---------x 1 root root 16048 Aug 7 13:16 target
to set-id and non-executable:
---S------ 1 root root 16048 Aug 7 13:16 target
it is possible to gain root privileges when execution should have been
disallowed.
While this race condition is rare in real-world scenarios, it has been
observed (and proven exploitable) when package managers are updating
the setuid bits of installed programs. Such files start with being
world-executable but then are adjusted to be group-exec with a set-uid
bit. For example, "chmod o-x,u+s target" makes "target" executable only
by uid "root" and gid "cdrom", while also becoming setuid-root:
-rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target
becomes:
-rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target
But racing the chmod means users without group "cdrom" membership can
get the permission to execute "target" just before the chmod, and when
the chmod finishes, the exec reaches brpm_fill_uid(), and performs the
setuid to root, violating the expressed authorization of "only cdrom
group members can setuid to root".
Re-check that we still have execute permissions in case the metadata
has changed. It would be better to keep a copy from the perm-check time,
but until we can do that refactoring, the least-bad option is to do a
full inode_permission() call (under inode lock). It is understood that
this is safe against dead-locks, but hardly optimal. |
["https://git.kernel.org/stable/c/15469d46ba34559bfe7e3de6659115778c624759","https://git.kernel.org/stable/c/368f6985d46657b8b466a421dddcacd4051f7ada","https://git.kernel.org/stable/c/90dfbba89ad4f0d9c9744ecbb1adac4aa2ff4f3e","https://git.kernel.org/stable/c/9b424c5d4130d56312e2a3be17efb0928fec4d64","https://git.kernel.org/stable/c/d2a2a4714d80d09b0f8eb6438ab4224690b7121e","https://git.kernel.org/stable/c/d5c3c7e26275a2d83b894d30f7582a42853a958f","https://git.kernel.org/stable/c/f50733b45d865f91db90919f8311e2127ce5a0cb","https://git.kernel.org/stable/c/f6cfc6bcfd5e1cf76115b6450516ea4c99897ae1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43904
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add null checks for 'stream' and 'plane' before dereferencing
This commit adds null checks for the 'stream' and 'plane' variables in
the dcn30_apply_idle_power_optimizations function. These variables were
previously assumed to be null at line 922, but they were used later in
the code without checking if they were null. This could potentially lead
to a null pointer dereference, which would cause a crash.
The null checks ensure that 'stream' and 'plane' are not null before
they are used, preventing potential crashes.
Fixes the below static smatch checker:
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:938 dcn30_apply_idle_power_optimizations() error: we previously assumed 'stream' could be null (see line 922)
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:940 dcn30_apply_idle_power_optimizations() error: we previously assumed 'plane' could be null (see line 922) |
["https://git.kernel.org/stable/c/10c20d79d59cadfe572480d98cec271a89ffb024","https://git.kernel.org/stable/c/15c2990e0f0108b9c3752d7072a97d45d4283aea","https://git.kernel.org/stable/c/16a8a2a839d19c4cf7253642b493ffb8eee1d857","https://git.kernel.org/stable/c/5e84eda48ffb2363437db44bbd0235594f8a58f9","https://git.kernel.org/stable/c/fcf9d6a9f30ea414b6b84a6e901cebd44e146847"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2020-1749
|
High |
|
N/A
|
A flaw was found in the Linux kernel's implementation of some networking protocols in IPsec, such as VXLAN and GENEVE tunnels over IPv6. When an encrypted tunnel is created between two hosts, the kernel isn't correctly routing tunneled data over the encrypted link; rather sending the data unencrypted. This would allow anyone in between the two endpoints to read the traffic unencrypted. The main threat from this vulnerability is to data confidentiality. |
["https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-1749","https://security.netapp.com/advisory/ntap-20201222-0001/","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-1749","https://security.netapp.com/advisory/ntap-20201222-0001/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3523
|
Medium |
|
N/A
|
A vulnerability was found in Linux Kernel. It has been classified as problematic. Affected is an unknown function of the file mm/memory.c of the component Driver Handler. The manipulation leads to use after free. It is possible to launch the attack remotely. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211020. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=16ce101db85db694a91380aa4c89b25530871d33","https://vuldb.com/?id.211020","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=16ce101db85db694a91380aa4c89b25530871d33","https://vuldb.com/?id.211020"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48878
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_qca: Fix driver shutdown on closed serdev
The driver shutdown callback (which sends EDL_SOC_RESET to the device
over serdev) should not be invoked when HCI device is not open (e.g. if
hci_dev_open_sync() failed), because the serdev and its TTY are not open
either. Also skip this step if device is powered off
(qca_power_shutdown()).
The shutdown callback causes use-after-free during system reboot with
Qualcomm Atheros Bluetooth:
Unable to handle kernel paging request at virtual address
0072662f67726fd7
...
CPU: 6 PID: 1 Comm: systemd-shutdow Tainted: G W
6.1.0-rt5-00325-g8a5f56bcfcca #8
Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
Call trace:
tty_driver_flush_buffer+0x4/0x30
serdev_device_write_flush+0x24/0x34
qca_serdev_shutdown+0x80/0x130 [hci_uart]
device_shutdown+0x15c/0x260
kernel_restart+0x48/0xac
KASAN report:
BUG: KASAN: use-after-free in tty_driver_flush_buffer+0x1c/0x50
Read of size 8 at addr ffff16270c2e0018 by task systemd-shutdow/1
CPU: 7 PID: 1 Comm: systemd-shutdow Not tainted
6.1.0-next-20221220-00014-gb85aaf97fb01-dirty #28
Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
Call trace:
dump_backtrace.part.0+0xdc/0xf0
show_stack+0x18/0x30
dump_stack_lvl+0x68/0x84
print_report+0x188/0x488
kasan_report+0xa4/0xf0
__asan_load8+0x80/0xac
tty_driver_flush_buffer+0x1c/0x50
ttyport_write_flush+0x34/0x44
serdev_device_write_flush+0x48/0x60
qca_serdev_shutdown+0x124/0x274
device_shutdown+0x1e8/0x350
kernel_restart+0x48/0xb0
__do_sys_reboot+0x244/0x2d0
__arm64_sys_reboot+0x54/0x70
invoke_syscall+0x60/0x190
el0_svc_common.constprop.0+0x7c/0x160
do_el0_svc+0x44/0xf0
el0_svc+0x2c/0x6c
el0t_64_sync_handler+0xbc/0x140
el0t_64_sync+0x190/0x194 |
["https://git.kernel.org/stable/c/272970be3dabd24cbe50e393ffee8f04aec3b9a8","https://git.kernel.org/stable/c/908d1742b6e694e84ead5c62e4b7c1bfbb8b46a3","https://git.kernel.org/stable/c/e84ec6e25df9bb0968599e92eacedaf3a0a5b587","https://git.kernel.org/stable/c/ea3ebda47dd56f6e1c62f2e0e1b6e1b0a973e447"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49085
|
High |
fixed |
- 4.9.311
- 4.14.276
- 4.19.238
- 5.4.189
- 5.10.111
- 5.15.34
- 5.16.20
- 5.17.3
|
In the Linux kernel, the following vulnerability has been resolved:
drbd: Fix five use after free bugs in get_initial_state
In get_initial_state, it calls notify_initial_state_done(skb,..) if
cb->args[5]==1. If genlmsg_put() failed in notify_initial_state_done(),
the skb will be freed by nlmsg_free(skb).
Then get_initial_state will goto out and the freed skb will be used by
return value skb->len, which is a uaf bug.
What's worse, the same problem goes even further: skb can also be
freed in the notify_*_state_change -> notify_*_state calls below.
Thus 4 additional uaf bugs happened.
My patch lets the problem callee functions: notify_initial_state_done
and notify_*_state_change return an error code if errors happen.
So that the error codes could be propagated and the uaf bugs can be avoid.
v2 reports a compilation warning. This v3 fixed this warning and built
successfully in my local environment with no additional warnings.
v2: https://lore.kernel.org/patchwork/patch/1435218/ |
["https://git.kernel.org/stable/c/0489700bfeb1e53eb2039c2291c67e71b0b40103","https://git.kernel.org/stable/c/188fe6b26765edbad4055611c0f788b6870f4024","https://git.kernel.org/stable/c/226e993c39405292781bfcf4b039a8db56aab362","https://git.kernel.org/stable/c/594205b4936771a250f9d141e7e0fff21c3dd2d9","https://git.kernel.org/stable/c/a972c768723359ec995579902473028fe3cd64b1","https://git.kernel.org/stable/c/aadb22ba2f656581b2f733deb3a467c48cc618f6","https://git.kernel.org/stable/c/b6a4055036eed1f5e239ce3d8b0db1ce38bba447","https://git.kernel.org/stable/c/dcf6be17b5c53b741898d2223b23e66d682de300","https://git.kernel.org/stable/c/de63e74da2333b4068bb79983e632db730fea97e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49114
|
High |
fixed |
- 4.9.311
- 4.14.276
- 4.19.238
- 5.4.189
- 5.10.111
- 5.15.34
- 5.16.20
- 5.17.3
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: libfc: Fix use after free in fc_exch_abts_resp()
fc_exch_release(ep) will decrease the ep's reference count. When the
reference count reaches zero, it is freed. But ep is still used in the
following code, which will lead to a use after free.
Return after the fc_exch_release() call to avoid use after free. |
["https://git.kernel.org/stable/c/1d7effe5fff9d28e45e18ac3a564067c7ddfe898","https://git.kernel.org/stable/c/271add11994ba1a334859069367e04d2be2ebdd4","https://git.kernel.org/stable/c/412dd8299b02e4410fe77b8396953c1a8dde183a","https://git.kernel.org/stable/c/499d198494e77b6533251b9b909baf5c101129cb","https://git.kernel.org/stable/c/4a131d4ea8b581ac9b01d3a72754db4848be3232","https://git.kernel.org/stable/c/5cf2ce8967b0d98c8cfa4dc42ef4fcf080f5c836","https://git.kernel.org/stable/c/6044ad64f41c87382cfeeca281573d1886d80cbe","https://git.kernel.org/stable/c/87909291762d08fdb60d19069d7a89b5b308d0ef","https://git.kernel.org/stable/c/f581df412bc45c95176e3c808ee2839c05b2ab0c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35866
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in cifs_dump_full_key()
Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF. |
["https://git.kernel.org/stable/c/10e17ca4000ec34737bde002a13435c38ace2682","https://git.kernel.org/stable/c/3103163ccd3be4adcfa37e15608fb497be044113","https://git.kernel.org/stable/c/58acd1f497162e7d282077f816faa519487be045","https://git.kernel.org/stable/c/d798fd98e3563027c5162259ead517057d6fa794","https://git.kernel.org/stable/c/f4a60d360d9114b5085701a3702a0102b0d6d846","https://git.kernel.org/stable/c/10e17ca4000ec34737bde002a13435c38ace2682","https://git.kernel.org/stable/c/3103163ccd3be4adcfa37e15608fb497be044113","https://git.kernel.org/stable/c/58acd1f497162e7d282077f816faa519487be045"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46738
|
High |
fixed |
- 4.19.322
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
VMCI: Fix use-after-free when removing resource in vmci_resource_remove()
When removing a resource from vmci_resource_table in
vmci_resource_remove(), the search is performed using the resource
handle by comparing context and resource fields.
It is possible though to create two resources with different types
but same handle (same context and resource fields).
When trying to remove one of the resources, vmci_resource_remove()
may not remove the intended one, but the object will still be freed
as in the case of the datagram type in vmci_datagram_destroy_handle().
vmci_resource_table will still hold a pointer to this freed resource
leading to a use-after-free vulnerability.
BUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]
BUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147
Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106
print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239
__kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425
kasan_report+0x38/0x51 mm/kasan/report.c:442
vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]
vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147
vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182
ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444
kref_put include/linux/kref.h:65 [inline]
vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline]
vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195
vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143
__fput+0x261/0xa34 fs/file_table.c:282
task_work_run+0xf0/0x194 kernel/task_work.c:164
tracehook_notify_resume include/linux/tracehook.h:189 [inline]
exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187
exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220
__syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline]
syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313
do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86
entry_SYSCALL_64_after_hwframe+0x6e/0x0
This change ensures the type is also checked when removing
the resource from vmci_resource_table in vmci_resource_remove(). |
["https://git.kernel.org/stable/c/00fe5292f081f8d773e572df8e03bf6e1855fe49","https://git.kernel.org/stable/c/39e7e593418ccdbd151f2925fa6be1a616d16c96","https://git.kernel.org/stable/c/48b9a8dabcc3cf5f961b2ebcd8933bf9204babb7","https://git.kernel.org/stable/c/6c563a29857aa8053b67ee141191f69757f27f6e","https://git.kernel.org/stable/c/b243d52b5f6f59f9d39e69b191fb3d58b94a43b1","https://git.kernel.org/stable/c/b9efdf333174468651be40390cbc79c9f55d9cce","https://git.kernel.org/stable/c/ef5f4d0c5ee22d4f873116fec844ff6edaf3fa7d","https://git.kernel.org/stable/c/f6365931bf7c07b2b397dbb06a4f6573cc9fae73"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40994
|
High |
fixed |
- 5.15.162
- 6.1.96
- 6.6.36
- 6.9.7
|
In the Linux kernel, the following vulnerability has been resolved:
ptp: fix integer overflow in max_vclocks_store
On 32bit systems, the "4 * max" multiply can overflow. Use kcalloc()
to do the allocation to prevent this. |
["https://git.kernel.org/stable/c/4b03da87d0b7074c93d9662c6e1a8939f9b8b86e","https://git.kernel.org/stable/c/666e934d749e50a37f3796caaf843a605f115b6f","https://git.kernel.org/stable/c/81d23d2a24012e448f651e007fac2cfd20a45ce0","https://git.kernel.org/stable/c/d50d62d5e6ee6aa03c00bddb91745d0b632d3b0f","https://git.kernel.org/stable/c/e1fccfb4638ee6188377867f6015d0ce35764a8e","https://git.kernel.org/stable/c/4b03da87d0b7074c93d9662c6e1a8939f9b8b86e","https://git.kernel.org/stable/c/666e934d749e50a37f3796caaf843a605f115b6f","https://git.kernel.org/stable/c/81d23d2a24012e448f651e007fac2cfd20a45ce0","https://git.kernel.org/stable/c/d50d62d5e6ee6aa03c00bddb91745d0b632d3b0f","https://git.kernel.org/stable/c/e1fccfb4638ee6188377867f6015d0ce35764a8e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52799
|
High |
fixed |
- 4.14.331
- 4.19.300
- 5.4.262
- 5.10.202
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix array-index-out-of-bounds in dbFindLeaf
Currently while searching for dmtree_t for sufficient free blocks there
is an array out of bounds while getting element in tp->dm_stree. To add
the required check for out of bound we first need to determine the type
of dmtree. Thus added an extra parameter to dbFindLeaf so that the type
of tree can be determined and the required check can be applied. |
["https://git.kernel.org/stable/c/20f9310a18e3e99fc031e036fcbed67105ae1859","https://git.kernel.org/stable/c/22cad8bc1d36547cdae0eef316c47d917ce3147c","https://git.kernel.org/stable/c/81aa58cd8495b8c3b527f58ccbe19478d8087f61","https://git.kernel.org/stable/c/86df90f3fea7c5591f05c8a0010871d435e83046","https://git.kernel.org/stable/c/87c681ab49e99039ff2dd3e71852417381b13878","https://git.kernel.org/stable/c/88b7894a8f8705bf4e7ea90b10229376abf14514","https://git.kernel.org/stable/c/a50b796d36719757526ee094c703378895ab5e67","https://git.kernel.org/stable/c/da3da5e1e6f71c21d8e6149d7076d936ef5d4cb9","https://git.kernel.org/stable/c/ecfb47f13b08b02cf28b7b50d4941eefa21954d2","https://git.kernel.org/stable/c/20f9310a18e3e99fc031e036fcbed67105ae1859","https://git.kernel.org/stable/c/22cad8bc1d36547cdae0eef316c47d917ce3147c","https://git.kernel.org/stable/c/81aa58cd8495b8c3b527f58ccbe19478d8087f61","https://git.kernel.org/stable/c/86df90f3fea7c5591f05c8a0010871d435e83046","https://git.kernel.org/stable/c/87c681ab49e99039ff2dd3e71852417381b13878","https://git.kernel.org/stable/c/88b7894a8f8705bf4e7ea90b10229376abf14514","https://git.kernel.org/stable/c/a50b796d36719757526ee094c703378895ab5e67","https://git.kernel.org/stable/c/da3da5e1e6f71c21d8e6149d7076d936ef5d4cb9","https://git.kernel.org/stable/c/ecfb47f13b08b02cf28b7b50d4941eefa21954d2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52805
|
High |
fixed |
- 4.14.331
- 4.19.300
- 5.4.262
- 5.10.202
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix array-index-out-of-bounds in diAlloc
Currently there is not check against the agno of the iag while
allocating new inodes to avoid fragmentation problem. Added the check
which is required. |
["https://git.kernel.org/stable/c/05d9ea1ceb62a55af6727a69269a4fd310edf483","https://git.kernel.org/stable/c/1708d0a9917fea579cc9da3d87b154285abd2cd8","https://git.kernel.org/stable/c/1ba7df5457dc1c1071c5f92ac11323533a6430e1","https://git.kernel.org/stable/c/2308d0fb0dc32446b4e6ca37cd09c30374bb64e9","https://git.kernel.org/stable/c/64f062baf202b82f54987a3f614a6c8f3e466641","https://git.kernel.org/stable/c/665b44e55c2767a4f899c3b18f49e9e1c9983777","https://git.kernel.org/stable/c/7467ca10a5ff09b0e87edf6c4d2a4bfdee69cf2c","https://git.kernel.org/stable/c/8c68af2af697ba2ba3b138be0c6d72e2ce3a3d6d","https://git.kernel.org/stable/c/cf7e3e84df36a9953796c737f080712f631d7083","https://git.kernel.org/stable/c/05d9ea1ceb62a55af6727a69269a4fd310edf483","https://git.kernel.org/stable/c/1708d0a9917fea579cc9da3d87b154285abd2cd8","https://git.kernel.org/stable/c/1ba7df5457dc1c1071c5f92ac11323533a6430e1","https://git.kernel.org/stable/c/2308d0fb0dc32446b4e6ca37cd09c30374bb64e9","https://git.kernel.org/stable/c/64f062baf202b82f54987a3f614a6c8f3e466641","https://git.kernel.org/stable/c/665b44e55c2767a4f899c3b18f49e9e1c9983777","https://git.kernel.org/stable/c/7467ca10a5ff09b0e87edf6c4d2a4bfdee69cf2c","https://git.kernel.org/stable/c/8c68af2af697ba2ba3b138be0c6d72e2ce3a3d6d","https://git.kernel.org/stable/c/cf7e3e84df36a9953796c737f080712f631d7083"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26957
|
High |
fixed |
- 4.19.312
- 5.4.274
- 5.10.215
- 5.15.154
- 6.1.84
- 6.6.24
- 6.7.12
- 6.8.3
|
In the Linux kernel, the following vulnerability has been resolved:
s390/zcrypt: fix reference counting on zcrypt card objects
Tests with hot-plugging crytpo cards on KVM guests with debug
kernel build revealed an use after free for the load field of
the struct zcrypt_card. The reason was an incorrect reference
handling of the zcrypt card object which could lead to a free
of the zcrypt card object while it was still in use.
This is an example of the slab message:
kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b
kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43
kernel: kmalloc_trace+0x3f2/0x470
kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt]
kernel: zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4]
kernel: ap_device_probe+0x15c/0x290
kernel: really_probe+0xd2/0x468
kernel: driver_probe_device+0x40/0xf0
kernel: __device_attach_driver+0xc0/0x140
kernel: bus_for_each_drv+0x8c/0xd0
kernel: __device_attach+0x114/0x198
kernel: bus_probe_device+0xb4/0xc8
kernel: device_add+0x4d2/0x6e0
kernel: ap_scan_adapter+0x3d0/0x7c0
kernel: ap_scan_bus+0x5a/0x3b0
kernel: ap_scan_bus_wq_callback+0x40/0x60
kernel: process_one_work+0x26e/0x620
kernel: worker_thread+0x21c/0x440
kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43
kernel: kfree+0x37e/0x418
kernel: zcrypt_card_put+0x54/0x80 [zcrypt]
kernel: ap_device_remove+0x4c/0xe0
kernel: device_release_driver_internal+0x1c4/0x270
kernel: bus_remove_device+0x100/0x188
kernel: device_del+0x164/0x3c0
kernel: device_unregister+0x30/0x90
kernel: ap_scan_adapter+0xc8/0x7c0
kernel: ap_scan_bus+0x5a/0x3b0
kernel: ap_scan_bus_wq_callback+0x40/0x60
kernel: process_one_work+0x26e/0x620
kernel: worker_thread+0x21c/0x440
kernel: kthread+0x150/0x168
kernel: __ret_from_fork+0x3c/0x58
kernel: ret_from_fork+0xa/0x30
kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff)
kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88
kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........
kernel: Object 00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkkhKkkk.
kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb ........
kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ
kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2
kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux)
kernel: Call Trace:
kernel: [<00000000ca5ab5b8>] dump_stack_lvl+0x90/0x120
kernel: [<00000000c99d78bc>] check_bytes_and_report+0x114/0x140
kernel: [<00000000c99d53cc>] check_object+0x334/0x3f8
kernel: [<00000000c99d820c>] alloc_debug_processing+0xc4/0x1f8
kernel: [<00000000c99d852e>] get_partial_node.part.0+0x1ee/0x3e0
kernel: [<00000000c99d94ec>] ___slab_alloc+0xaf4/0x13c8
kernel: [<00000000c99d9e38>] __slab_alloc.constprop.0+0x78/0xb8
kernel: [<00000000c99dc8dc>] __kmalloc+0x434/0x590
kernel: [<00000000c9b4c0ce>] ext4_htree_store_dirent+0x4e/0x1c0
kernel: [<00000000c9b908a2>] htree_dirblock_to_tree+0x17a/0x3f0
kernel:
---truncated--- |
["https://git.kernel.org/stable/c/394b6d8bbdf9ddee6d5bcf3e1f3e9f23eecd6484","https://git.kernel.org/stable/c/50ed48c80fecbe17218afed4f8bed005c802976c","https://git.kernel.org/stable/c/6470078ab3d8f222115e11c4ec67351f3031b3dd","https://git.kernel.org/stable/c/7e500849fa558879a1cde43f80c7c048c2437058","https://git.kernel.org/stable/c/9daddee03de3f231012014dab8ab2b277a116a55","https://git.kernel.org/stable/c/a55677878b93e9ebc31f66d0e2fb93be5e7836a6","https://git.kernel.org/stable/c/a64ab862e84e3e698cd351a87cdb504c7fc575ca","https://git.kernel.org/stable/c/b7f6c3630eb3f103115ab0d7613588064f665d0d","https://git.kernel.org/stable/c/befb7f889594d23e1b475720cf93efd2f77df000","https://git.kernel.org/stable/c/394b6d8bbdf9ddee6d5bcf3e1f3e9f23eecd6484","https://git.kernel.org/stable/c/50ed48c80fecbe17218afed4f8bed005c802976c","https://git.kernel.org/stable/c/6470078ab3d8f222115e11c4ec67351f3031b3dd","https://git.kernel.org/stable/c/7e500849fa558879a1cde43f80c7c048c2437058","https://git.kernel.org/stable/c/9daddee03de3f231012014dab8ab2b277a116a55","https://git.kernel.org/stable/c/a55677878b93e9ebc31f66d0e2fb93be5e7836a6","https://git.kernel.org/stable/c/a64ab862e84e3e698cd351a87cdb504c7fc575ca","https://git.kernel.org/stable/c/b7f6c3630eb3f103115ab0d7613588064f665d0d","https://git.kernel.org/stable/c/befb7f889594d23e1b475720cf93efd2f77df000","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27395
|
High |
fixed |
- 4.19.313
- 5.4.275
- 5.10.216
- 5.15.158
- 6.1.90
- 6.6.30
- 6.8.9
|
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: Fix Use-After-Free in ovs_ct_exit
Since kfree_rcu, which is called in the hlist_for_each_entry_rcu traversal
of ovs_ct_limit_exit, is not part of the RCU read critical section, it
is possible that the RCU grace period will pass during the traversal and
the key will be free.
To prevent this, it should be changed to hlist_for_each_entry_safe. |
["https://git.kernel.org/stable/c/2db9a8c0a01fa1c762c1e61a13c212c492752994","https://git.kernel.org/stable/c/35880c3fa6f8fe281a19975d2992644588ca33d3","https://git.kernel.org/stable/c/589523cf0b384164e445dd5db8d5b1bf97982424","https://git.kernel.org/stable/c/5ea7b72d4fac2fdbc0425cd8f2ea33abe95235b2","https://git.kernel.org/stable/c/9048616553c65e750d43846f225843ed745ec0d4","https://git.kernel.org/stable/c/bca6fa2d9a9f560e6b89fd5190b05cc2f5d422c1","https://git.kernel.org/stable/c/eaa5e164a2110d2fb9e16c8a29e4501882235137","https://git.kernel.org/stable/c/edee0758747d7c219e29db9ed1d4eb33e8d32865","https://git.kernel.org/stable/c/2db9a8c0a01fa1c762c1e61a13c212c492752994","https://git.kernel.org/stable/c/35880c3fa6f8fe281a19975d2992644588ca33d3","https://git.kernel.org/stable/c/589523cf0b384164e445dd5db8d5b1bf97982424","https://git.kernel.org/stable/c/5ea7b72d4fac2fdbc0425cd8f2ea33abe95235b2","https://git.kernel.org/stable/c/9048616553c65e750d43846f225843ed745ec0d4","https://git.kernel.org/stable/c/bca6fa2d9a9f560e6b89fd5190b05cc2f5d422c1","https://git.kernel.org/stable/c/eaa5e164a2110d2fb9e16c8a29e4501882235137","https://git.kernel.org/stable/c/edee0758747d7c219e29db9ed1d4eb33e8d32865","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27396
|
High |
fixed |
- 4.15
- 4.19.313
- 5.4.275
- 5.10.216
- 5.15.158
- 6.1.90
- 6.6.30
- 6.8.9
|
In the Linux kernel, the following vulnerability has been resolved:
net: gtp: Fix Use-After-Free in gtp_dellink
Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal
of gtp_dellink, is not part of the RCU read critical section, it
is possible that the RCU grace period will pass during the traversal and
the key will be free.
To prevent this, it should be changed to hlist_for_each_entry_safe. |
["https://git.kernel.org/stable/c/07b20d0a3dc13fb1adff10b60021a4924498da58","https://git.kernel.org/stable/c/0caff3e6390f840666b8dc1ecebf985c2ef3f1dd","https://git.kernel.org/stable/c/25a1c2d4b1fcf938356a9688a96a6456abd44b29","https://git.kernel.org/stable/c/2aacd4de45477582993f8a8abb9505a06426bfb6","https://git.kernel.org/stable/c/2e74b3fd6bf542349758f283676dff3660327c07","https://git.kernel.org/stable/c/718df1bc226c383dd803397d7f5d95557eb81ac7","https://git.kernel.org/stable/c/cd957d1716ec979d8f5bf38fc659aeb9fdaa2474","https://git.kernel.org/stable/c/f2a904107ee2b647bb7794a1a82b67740d7c8a64","https://git.kernel.org/stable/c/07b20d0a3dc13fb1adff10b60021a4924498da58","https://git.kernel.org/stable/c/0caff3e6390f840666b8dc1ecebf985c2ef3f1dd","https://git.kernel.org/stable/c/25a1c2d4b1fcf938356a9688a96a6456abd44b29","https://git.kernel.org/stable/c/2aacd4de45477582993f8a8abb9505a06426bfb6","https://git.kernel.org/stable/c/2e74b3fd6bf542349758f283676dff3660327c07","https://git.kernel.org/stable/c/718df1bc226c383dd803397d7f5d95557eb81ac7","https://git.kernel.org/stable/c/cd957d1716ec979d8f5bf38fc659aeb9fdaa2474","https://git.kernel.org/stable/c/f2a904107ee2b647bb7794a1a82b67740d7c8a64","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35847
|
High |
fixed |
- 4.19.313
- 5.4.275
- 5.10.216
- 5.15.158
- 6.1.90
- 6.6.30
- 6.8.9
|
In the Linux kernel, the following vulnerability has been resolved:
irqchip/gic-v3-its: Prevent double free on error
The error handling path in its_vpe_irq_domain_alloc() causes a double free
when its_vpe_init() fails after successfully allocating at least one
interrupt. This happens because its_vpe_irq_domain_free() frees the
interrupts along with the area bitmap and the vprop_page and
its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the
vprop_page again.
Fix this by unconditionally invoking its_vpe_irq_domain_free() which
handles all cases correctly and by removing the bitmap/vprop_page freeing
from its_vpe_irq_domain_alloc().
[ tglx: Massaged change log ] |
["https://git.kernel.org/stable/c/03170e657f62c26834172742492a8cb8077ef792","https://git.kernel.org/stable/c/5b012f77abde89bf0be8a0547636184fea618137","https://git.kernel.org/stable/c/5dbdbe1133911ca7d8466bb86885adec32ad9438","https://git.kernel.org/stable/c/aa44d21574751a7d6bca892eb8e0e9ac68372e52","https://git.kernel.org/stable/c/b72d2b1448b682844f995e660b77f2a1fabc1662","https://git.kernel.org/stable/c/c26591afd33adce296c022e3480dea4282b7ef91","https://git.kernel.org/stable/c/dd681710ab77c8beafe2e263064cb1bd0e2d6ca9","https://git.kernel.org/stable/c/f5417ff561b8ac9a7e53c747b8627a7ab58378ae","https://git.kernel.org/stable/c/03170e657f62c26834172742492a8cb8077ef792","https://git.kernel.org/stable/c/5b012f77abde89bf0be8a0547636184fea618137","https://git.kernel.org/stable/c/5dbdbe1133911ca7d8466bb86885adec32ad9438","https://git.kernel.org/stable/c/aa44d21574751a7d6bca892eb8e0e9ac68372e52","https://git.kernel.org/stable/c/b72d2b1448b682844f995e660b77f2a1fabc1662","https://git.kernel.org/stable/c/c26591afd33adce296c022e3480dea4282b7ef91","https://git.kernel.org/stable/c/dd681710ab77c8beafe2e263064cb1bd0e2d6ca9","https://git.kernel.org/stable/c/f5417ff561b8ac9a7e53c747b8627a7ab58378ae","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48701
|
High |
fixed |
- 4.9.328
- 4.14.293
- 4.19.258
- 5.4.213
- 5.10.143
- 5.15.68
- 5.19.9
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Fix an out-of-bounds bug in __snd_usb_parse_audio_interface()
There may be a bad USB audio device with a USB ID of (0x04fa, 0x4201) and
the number of it's interfaces less than 4, an out-of-bounds read bug occurs
when parsing the interface descriptor for this device.
Fix this by checking the number of interfaces. |
["https://git.kernel.org/stable/c/0492798bf8dfcc09c9337a1ba065da1d1ca68712","https://git.kernel.org/stable/c/2a308e415d247a23d4d64c964c02e782eede2936","https://git.kernel.org/stable/c/6123bec8480d23369e2ee0b2208611619f269faf","https://git.kernel.org/stable/c/8293e61bbf908b18ff9935238d4fc2ad359e3fe0","https://git.kernel.org/stable/c/91904870370fd986c29719846ed76d559de43251","https://git.kernel.org/stable/c/98e8e67395cc6d0cdf3a771f86ea42d0ee6e59dd","https://git.kernel.org/stable/c/b970518014f2f0f6c493fb86c1e092b936899061","https://git.kernel.org/stable/c/e53f47f6c1a56d2af728909f1cb894da6b43d9bf","https://git.kernel.org/stable/c/0492798bf8dfcc09c9337a1ba065da1d1ca68712","https://git.kernel.org/stable/c/2a308e415d247a23d4d64c964c02e782eede2936","https://git.kernel.org/stable/c/6123bec8480d23369e2ee0b2208611619f269faf","https://git.kernel.org/stable/c/8293e61bbf908b18ff9935238d4fc2ad359e3fe0","https://git.kernel.org/stable/c/91904870370fd986c29719846ed76d559de43251","https://git.kernel.org/stable/c/98e8e67395cc6d0cdf3a771f86ea42d0ee6e59dd","https://git.kernel.org/stable/c/b970518014f2f0f6c493fb86c1e092b936899061","https://git.kernel.org/stable/c/e53f47f6c1a56d2af728909f1cb894da6b43d9bf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-38429
|
Critical |
fixed |
|
An issue was discovered in the Linux kernel before 6.3.4. fs/ksmbd/connection.c in ksmbd has an off-by-one error in memory allocation (because of ksmbd_smb2_check_message) that may lead to out-of-bounds access. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/ksmbd?id=443d61d1fa9faa60ef925513d83742902390100f","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/ksmbd?id=443d61d1fa9faa60ef925513d83742902390100f","https://security.netapp.com/advisory/ntap-20250103-0009/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2020-16119
|
High |
|
N/A
|
Use-after-free vulnerability in the Linux kernel exploitable by a local attacker due to reuse of a DCCP socket with an attached dccps_hc_tx_ccid object as a listener after being released. Fixed in Ubuntu Linux kernel 5.4.0-51.56, 5.3.0-68.63, 4.15.0-121.123, 4.4.0-193.224, 3.13.0.182.191 and 3.2.0-149.196. |
["https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/commit/?id=01872cb896c76cedeabe93a08456976ab55ad695","https://launchpad.net/bugs/1883840","https://lists.debian.org/debian-lts-announce/2021/10/msg00010.html","https://lists.debian.org/debian-lts-announce/2021/12/msg00012.html","https://lore.kernel.org/netdev/20201013171849.236025-1-kleber.souza%40canonical.com/T/","https://security.netapp.com/advisory/ntap-20210304-0006/","https://ubuntu.com/USN-4576-1","https://ubuntu.com/USN-4577-1","https://ubuntu.com/USN-4578-1","https://ubuntu.com/USN-4579-1","https://ubuntu.com/USN-4580-1","https://www.debian.org/security/2021/dsa-4978","https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/commit/?id=01872cb896c76cedeabe93a08456976ab55ad695","https://launchpad.net/bugs/1883840","https://lists.debian.org/debian-lts-announce/2021/10/msg00010.html","https://lists.debian.org/debian-lts-announce/2021/12/msg00012.html","https://lore.kernel.org/netdev/20201013171849.236025-1-kleber.souza%40canonical.com/T/","https://security.netapp.com/advisory/ntap-20210304-0006/","https://ubuntu.com/USN-4576-1","https://ubuntu.com/USN-4577-1","https://ubuntu.com/USN-4578-1","https://ubuntu.com/USN-4579-1","https://ubuntu.com/USN-4580-1","https://www.debian.org/security/2021/dsa-4978"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36901
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent NULL dereference in ip6_output()
According to syzbot, there is a chance that ip6_dst_idev()
returns NULL in ip6_output(). Most places in IPv6 stack
deal with a NULL idev just fine, but not here.
syzbot reported:
general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]
CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237
Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff
RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202
RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000
RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48
RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad
R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0
R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000
FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
NF_HOOK include/linux/netfilter.h:314 [inline]
ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358
sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248
sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653
sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783
sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline]
sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212
sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]
sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169
sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73
__sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234
sctp_connect net/sctp/socket.c:4819 [inline]
sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834
__sys_connect_file net/socket.c:2048 [inline]
__sys_connect+0x2df/0x310 net/socket.c:2065
__do_sys_connect net/socket.c:2075 [inline]
__se_sys_connect net/socket.c:2072 [inline]
__x64_sys_connect+0x7a/0x90 net/socket.c:2072
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f |
["https://git.kernel.org/stable/c/2272e2db38f2e85929278146d7c770f22f528579","https://git.kernel.org/stable/c/4db783d68b9b39a411a96096c10828ff5dfada7a","https://git.kernel.org/stable/c/55f7eb4001ef2a3b48cf039cf263f9ed0ec5a488","https://git.kernel.org/stable/c/9df3b2474a627994433a87cbf325a562555b17de","https://git.kernel.org/stable/c/e31b25cc2066d3f2b6c38579253882008d4469b0","https://git.kernel.org/stable/c/ea0cb87402f774b0e1214ffba0f57028b27cf155","https://git.kernel.org/stable/c/2272e2db38f2e85929278146d7c770f22f528579","https://git.kernel.org/stable/c/4db783d68b9b39a411a96096c10828ff5dfada7a","https://git.kernel.org/stable/c/55f7eb4001ef2a3b48cf039cf263f9ed0ec5a488","https://git.kernel.org/stable/c/9df3b2474a627994433a87cbf325a562555b17de","https://git.kernel.org/stable/c/e31b25cc2066d3f2b6c38579253882008d4469b0","https://git.kernel.org/stable/c/ea0cb87402f774b0e1214ffba0f57028b27cf155"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42259
|
Medium |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.106
- 6.6.46
- 6.10.5
|
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gem: Fix Virtual Memory mapping boundaries calculation
Calculating the size of the mapped area as the lesser value
between the requested size and the actual size does not consider
the partial mapping offset. This can cause page fault access.
Fix the calculation of the starting and ending addresses, the
total size is now deduced from the difference between the end and
start addresses.
Additionally, the calculations have been rewritten in a clearer
and more understandable form.
[Joonas: Add Requires: tag]
Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset")
(cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417) |
["https://git.kernel.org/stable/c/3e06073d24807f04b4694108a8474decb7b99e60","https://git.kernel.org/stable/c/4b09513ce93b3dcb590baaaff2ce96f2d098312d","https://git.kernel.org/stable/c/50111a8098fb9ade621eeff82228a997d42732ab","https://git.kernel.org/stable/c/8bdd9ef7e9b1b2a73e394712b72b22055e0e26c3","https://git.kernel.org/stable/c/911f8055f175c82775d0fd8cedcd0b75413f4ba7","https://git.kernel.org/stable/c/a256d019eaf044864c7e50312f0a65b323c24f39","https://git.kernel.org/stable/c/e8a68aa842d3f8dd04a46b9d632e5f67fde1da9b","https://git.kernel.org/stable/c/ead9289a51ea82eb5b27029fcf4c34b2dd60cf06","https://project-zero.issues.chromium.org/issues/42451707"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43824
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: pci-epf-test: Make use of cached 'epc_features' in pci_epf_test_core_init()
Instead of getting the epc_features from pci_epc_get_features() API, use
the cached pci_epf_test::epc_features value to avoid the NULL check. Since
the NULL check is already performed in pci_epf_test_bind(), having one more
check in pci_epf_test_core_init() is redundant and it is not possible to
hit the NULL pointer dereference.
Also with commit a01e7214bef9 ("PCI: endpoint: Remove "core_init_notifier"
flag"), 'epc_features' got dereferenced without the NULL check, leading to
the following false positive Smatch warning:
drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed 'epc_features' could be null (see line 747)
Thus, remove the redundant NULL check and also use the epc_features::
{msix_capable/msi_capable} flags directly to avoid local variables.
[kwilczynski: commit log] |
["https://git.kernel.org/stable/c/5a5095a8bd1bd349cce1c879e5e44407a34dda8a","https://git.kernel.org/stable/c/af4ad016abb1632ff7ee598a6037952b495e5b80"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46739
|
Medium |
fixed |
- 4.19.322
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
uio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescind
For primary VM Bus channels, primary_channel pointer is always NULL. This
pointer is valid only for the secondary channels. Also, rescind callback
is meant for primary channels only.
Fix NULL pointer dereference by retrieving the device_obj from the parent
for the primary channel. |
["https://git.kernel.org/stable/c/1d8e020e51ab07e40f9dd00b52f1da7d96fec04c","https://git.kernel.org/stable/c/2be373469be1774bbe03b0fa7e2854e65005b1cc","https://git.kernel.org/stable/c/3005091cd537ef8cdb7530dcb2ecfba8d2ef475c","https://git.kernel.org/stable/c/3d414b64ecf6fd717d7510ffb893c6f23acbf50e","https://git.kernel.org/stable/c/928e399e84f4e80307dce44e89415115c473275b","https://git.kernel.org/stable/c/de6946be9c8bc7d2279123433495af7c21011b99","https://git.kernel.org/stable/c/f38f46da80a2ab7d1b2f8fcb444c916034a2dac4","https://git.kernel.org/stable/c/fb1adbd7e50f3d2de56d0a2bb0700e2e819a329e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48912
|
High |
fixed |
- 4.14.270
- 4.19.233
- 5.4.183
- 5.10.104
- 5.15.27
- 5.16.13
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: fix use-after-free in __nf_register_net_hook()
We must not dereference @new_hooks after nf_hook_mutex has been released,
because other threads might have freed our allocated hooks already.
BUG: KASAN: use-after-free in nf_hook_entries_get_hook_ops include/linux/netfilter.h:130 [inline]
BUG: KASAN: use-after-free in hooks_validate net/netfilter/core.c:171 [inline]
BUG: KASAN: use-after-free in __nf_register_net_hook+0x77a/0x820 net/netfilter/core.c:438
Read of size 2 at addr ffff88801c1a8000 by task syz-executor237/4430
CPU: 1 PID: 4430 Comm: syz-executor237 Not tainted 5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description.constprop.0.cold+0x8d/0x336 mm/kasan/report.c:255
__kasan_report mm/kasan/report.c:442 [inline]
kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
nf_hook_entries_get_hook_ops include/linux/netfilter.h:130 [inline]
hooks_validate net/netfilter/core.c:171 [inline]
__nf_register_net_hook+0x77a/0x820 net/netfilter/core.c:438
nf_register_net_hook+0x114/0x170 net/netfilter/core.c:571
nf_register_net_hooks+0x59/0xc0 net/netfilter/core.c:587
nf_synproxy_ipv6_init+0x85/0xe0 net/netfilter/nf_synproxy_core.c:1218
synproxy_tg6_check+0x30d/0x560 net/ipv6/netfilter/ip6t_SYNPROXY.c:81
xt_check_target+0x26c/0x9e0 net/netfilter/x_tables.c:1038
check_target net/ipv6/netfilter/ip6_tables.c:530 [inline]
find_check_entry.constprop.0+0x7f1/0x9e0 net/ipv6/netfilter/ip6_tables.c:573
translate_table+0xc8b/0x1750 net/ipv6/netfilter/ip6_tables.c:735
do_replace net/ipv6/netfilter/ip6_tables.c:1153 [inline]
do_ip6t_set_ctl+0x56e/0xb90 net/ipv6/netfilter/ip6_tables.c:1639
nf_setsockopt+0x83/0xe0 net/netfilter/nf_sockopt.c:101
ipv6_setsockopt+0x122/0x180 net/ipv6/ipv6_sockglue.c:1024
rawv6_setsockopt+0xd3/0x6a0 net/ipv6/raw.c:1084
__sys_setsockopt+0x2db/0x610 net/socket.c:2180
__do_sys_setsockopt net/socket.c:2191 [inline]
__se_sys_setsockopt net/socket.c:2188 [inline]
__x64_sys_setsockopt+0xba/0x150 net/socket.c:2188
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f65a1ace7d9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 71 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f65a1a7f308 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00007f65a1ace7d9
RDX: 0000000000000040 RSI: 0000000000000029 RDI: 0000000000000003
RBP: 00007f65a1b574c8 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000020000000 R11: 0000000000000246 R12: 00007f65a1b55130
R13: 00007f65a1b574c0 R14: 00007f65a1b24090 R15: 0000000000022000
</TASK>
The buggy address belongs to the page:
page:ffffea0000706a00 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1c1a8
flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000000000 ffffea0001c1b108 ffffea000046dd08 0000000000000000
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as freed
page last allocated via order 2, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 4430, ts 1061781545818, free_ts 1061791488993
prep_new_page mm/page_alloc.c:2434 [inline]
get_page_from_freelist+0xa72/0x2f50 mm/page_alloc.c:4165
__alloc_pages+0x1b2/0x500 mm/page_alloc.c:5389
__alloc_pages_node include/linux/gfp.h:572 [inline]
alloc_pages_node include/linux/gfp.h:595 [inline]
kmalloc_large_node+0x62/0x130 mm/slub.c:4438
__kmalloc_node+0x35a/0x4a0 mm/slub.
---truncated--- |
["https://git.kernel.org/stable/c/05f7927b25d2635e87267ff6c79db79fb46cf313","https://git.kernel.org/stable/c/49c24579cec41e32f13d57b337fd28fb208d4a5b","https://git.kernel.org/stable/c/56763f12b0f02706576a088e85ef856deacc98a0","https://git.kernel.org/stable/c/5a8076e98dde17224dd47283b894a8b1dbe1bc72","https://git.kernel.org/stable/c/8b0142c4143c1ca297dcf2c0cdd045d65dae2344","https://git.kernel.org/stable/c/bd61f192a339b1095dfd6d56073a5265934c2979","https://git.kernel.org/stable/c/bdd8fc1b826e6f23963f5bef3f7431c6188ec954"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42271
|
High |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.104
- 6.6.45
- 6.10.4
|
In the Linux kernel, the following vulnerability has been resolved:
net/iucv: fix use after free in iucv_sock_close()
iucv_sever_path() is called from process context and from bh context.
iucv->path is used as indicator whether somebody else is taking care of
severing the path (or it is already removed / never existed).
This needs to be done with atomic compare and swap, otherwise there is a
small window where iucv_sock_close() will try to work with a path that has
already been severed and freed by iucv_callback_connrej() called by
iucv_tasklet_fn().
Example:
[452744.123844] Call Trace:
[452744.123845] ([<0000001e87f03880>] 0x1e87f03880)
[452744.123966] [<00000000d593001e>] iucv_path_sever+0x96/0x138
[452744.124330] [<000003ff801ddbca>] iucv_sever_path+0xc2/0xd0 [af_iucv]
[452744.124336] [<000003ff801e01b6>] iucv_sock_close+0xa6/0x310 [af_iucv]
[452744.124341] [<000003ff801e08cc>] iucv_sock_release+0x3c/0xd0 [af_iucv]
[452744.124345] [<00000000d574794e>] __sock_release+0x5e/0xe8
[452744.124815] [<00000000d5747a0c>] sock_close+0x34/0x48
[452744.124820] [<00000000d5421642>] __fput+0xba/0x268
[452744.124826] [<00000000d51b382c>] task_work_run+0xbc/0xf0
[452744.124832] [<00000000d5145710>] do_notify_resume+0x88/0x90
[452744.124841] [<00000000d5978096>] system_call+0xe2/0x2c8
[452744.125319] Last Breaking-Event-Address:
[452744.125321] [<00000000d5930018>] iucv_path_sever+0x90/0x138
[452744.125324]
[452744.125325] Kernel panic - not syncing: Fatal exception in interrupt
Note that bh_lock_sock() is not serializing the tasklet context against
process context, because the check for sock_owned_by_user() and
corresponding handling is missing.
Ideas for a future clean-up patch:
A) Correct usage of bh_lock_sock() in tasklet context, as described in
Re-enqueue, if needed. This may require adding return values to the
tasklet functions and thus changes to all users of iucv.
B) Change iucv tasklet into worker and use only lock_sock() in af_iucv. |
["https://git.kernel.org/stable/c/01437282fd3904810603f3dc98d2cac6b8b6fc84","https://git.kernel.org/stable/c/37652fbef9809411cea55ea5fa1a170e299efcd0","https://git.kernel.org/stable/c/69620522c48ce8215e5eb55ffbab8cafee8f407d","https://git.kernel.org/stable/c/84f40b46787ecb67c7ad08a5bb1376141fa10c01","https://git.kernel.org/stable/c/8b424c9e44111c5a76f41c6b741f8d4c4179d876","https://git.kernel.org/stable/c/ac758e1f663fe9bc64f6b47212a2aa18697524f5","https://git.kernel.org/stable/c/c65f72eec60a34ace031426e04e9aff8e5f04895","https://git.kernel.org/stable/c/f558120cd709682b739207b48cf7479fd9568431"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41092
|
High |
fixed |
- 5.10.221
- 5.15.162
- 6.1.97
- 6.6.37
- 6.9.8
|
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gt: Fix potential UAF by revoke of fence registers
CI has been sporadically reporting the following issue triggered by
igt@i915_selftest@live@hangcheck on ADL-P and similar machines:
<6> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence
...
<6> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
<6> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled
<3> [414.070354] Unable to pin Y-tiled fence; err:-4
<3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active))
...
<4>[ 609.603992] ------------[ cut here ]------------
<2>[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!
<4>[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
<4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1
<4>[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023
<4>[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915]
<4>[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]
...
<4>[ 609.604271] Call Trace:
<4>[ 609.604273] <TASK>
...
<4>[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915]
<4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915]
<4>[ 609.604977] force_unbind+0x24/0xa0 [i915]
<4>[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915]
<4>[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915]
<4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]
<4>[ 609.605440] process_scheduled_works+0x351/0x690
...
In the past, there were similar failures reported by CI from other IGT
tests, observed on other platforms.
Before commit 63baf4f3d587 ("drm/i915/gt: Only wait for GPU activity
before unbinding a GGTT fence"), i915_vma_revoke_fence() was waiting for
idleness of vma->active via fence_update(). That commit introduced
vma->fence->active in order for the fence_update() to be able to wait
selectively on that one instead of vma->active since only idleness of
fence registers was needed. But then, another commit 0d86ee35097a
("drm/i915/gt: Make fence revocation unequivocal") replaced the call to
fence_update() in i915_vma_revoke_fence() with only fence_write(), and
also added that GEM_BUG_ON(!i915_active_is_idle(&fence->active)) in front.
No justification was provided on why we might then expect idleness of
vma->fence->active without first waiting on it.
The issue can be potentially caused by a race among revocation of fence
registers on one side and sequential execution of signal callbacks invoked
on completion of a request that was using them on the other, still
processed in parallel to revocation of those fence registers. Fix it by
waiting for idleness of vma->fence->active in i915_vma_revoke_fence().
(cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1) |
["https://git.kernel.org/stable/c/06dec31a0a5112a91f49085e8a8fa1a82296d5c7","https://git.kernel.org/stable/c/29c0fdf49078ab161570d3d1c6e13d66f182717d","https://git.kernel.org/stable/c/414f4a31f7a811008fd9a33b06216b060bad18fc","https://git.kernel.org/stable/c/996c3412a06578e9d779a16b9e79ace18125ab50","https://git.kernel.org/stable/c/ca0fabd365a27a94a36e68a7a02df8ff3c13dac6","https://git.kernel.org/stable/c/f771b91f21c46ad1217328d05e72a2c7e3add535","https://git.kernel.org/stable/c/06dec31a0a5112a91f49085e8a8fa1a82296d5c7","https://git.kernel.org/stable/c/29c0fdf49078ab161570d3d1c6e13d66f182717d","https://git.kernel.org/stable/c/414f4a31f7a811008fd9a33b06216b060bad18fc","https://git.kernel.org/stable/c/996c3412a06578e9d779a16b9e79ace18125ab50","https://git.kernel.org/stable/c/ca0fabd365a27a94a36e68a7a02df8ff3c13dac6","https://git.kernel.org/stable/c/f771b91f21c46ad1217328d05e72a2c7e3add535"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49667
|
High |
fixed |
- 4.9.322
- 4.14.287
- 4.19.251
- 5.4.204
- 5.10.129
- 5.15.53
- 5.18.10
|
In the Linux kernel, the following vulnerability has been resolved:
net: bonding: fix use-after-free after 802.3ad slave unbind
commit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection"),
resolve case, when there is several aggregation groups in the same bond.
bond_3ad_unbind_slave will invalidate (clear) aggregator when
__agg_active_ports return zero. So, ad_clear_agg can be executed even, when
num_of_ports!=0. Than bond_3ad_unbind_slave can be executed again for,
previously cleared aggregator. NOTE: at this time bond_3ad_unbind_slave
will not update slave ports list, because lag_ports==NULL. So, here we
got slave ports, pointing to freed aggregator memory.
Fix with checking actual number of ports in group (as was before
commit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection") ),
before ad_clear_agg().
The KASAN logs are as follows:
[ 767.617392] ==================================================================
[ 767.630776] BUG: KASAN: use-after-free in bond_3ad_state_machine_handler+0x13dc/0x1470
[ 767.638764] Read of size 2 at addr ffff00011ba9d430 by task kworker/u8:7/767
[ 767.647361] CPU: 3 PID: 767 Comm: kworker/u8:7 Tainted: G O 5.15.11 #15
[ 767.655329] Hardware name: DNI AmazonGo1 A7040 board (DT)
[ 767.660760] Workqueue: lacp_1 bond_3ad_state_machine_handler
[ 767.666468] Call trace:
[ 767.668930] dump_backtrace+0x0/0x2d0
[ 767.672625] show_stack+0x24/0x30
[ 767.675965] dump_stack_lvl+0x68/0x84
[ 767.679659] print_address_description.constprop.0+0x74/0x2b8
[ 767.685451] kasan_report+0x1f0/0x260
[ 767.689148] __asan_load2+0x94/0xd0
[ 767.692667] bond_3ad_state_machine_handler+0x13dc/0x1470 |
["https://git.kernel.org/stable/c/050133e1aa2cb49bb17be847d48a4431598ef562","https://git.kernel.org/stable/c/2765749def4765c5052a4c66445cf4c96fcccdbc","https://git.kernel.org/stable/c/63b2fe509f69b90168a75e04e14573dccf7984e6","https://git.kernel.org/stable/c/893825289ba840afd86bfffcb6f7f363c73efff8","https://git.kernel.org/stable/c/a853b7a3a9fd1d74a4ccdd9cd73512b7dace2f1e","https://git.kernel.org/stable/c/b90ac60303063a43e17dd4aec159067599d255e6","https://git.kernel.org/stable/c/ef0af7d08d26c5333ff4944a559279464edf6f15","https://git.kernel.org/stable/c/f162f7c348fa2a5555bafdb5cc890b89b221e69c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57850
|
High |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
jffs2: Prevent rtime decompress memory corruption
The rtime decompression routine does not fully check bounds during the
entirety of the decompression pass and can corrupt memory outside the
decompression buffer if the compressed data is corrupted. This adds the
required check to prevent this failure mode. |
["https://git.kernel.org/stable/c/421f9e9f0fae9f8e721ffa07f22d9765fa1214d5","https://git.kernel.org/stable/c/47c9a7f81027a78afea9d2e9a54bfd8fabb6b3d0","https://git.kernel.org/stable/c/6808a1812a3419542223e7fe9e2de577e99e45d1","https://git.kernel.org/stable/c/bd384b04ad1995441b18fe6c1366d02de8c5d5eb","https://git.kernel.org/stable/c/dc39b08fcc3831b0bc46add91ba93cd2aab50716","https://git.kernel.org/stable/c/f6fc251baefc3cdc4f41f2f5a47940d7d4a67332","https://git.kernel.org/stable/c/fe051552f5078fa02d593847529a3884305a6ffe"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52679
|
High |
fixed |
- 4.19.306
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
of: Fix double free in of_parse_phandle_with_args_map
In of_parse_phandle_with_args_map() the inner loop that
iterates through the map entries calls of_node_put(new)
to free the reference acquired by the previous iteration
of the inner loop. This assumes that the value of "new" is
NULL on the first iteration of the inner loop.
Make sure that this is true in all iterations of the outer
loop by setting "new" to NULL after its value is assigned to "cur".
Extend the unittest to detect the double free and add an additional
test case that actually triggers this path. |
["https://git.kernel.org/stable/c/26b4d702c44f9e5cf3c5c001ae619a4a001889db","https://git.kernel.org/stable/c/4541004084527ce9e95a818ebbc4e6b293ffca21","https://git.kernel.org/stable/c/4dde83569832f9377362e50f7748463340c5db6b","https://git.kernel.org/stable/c/a0a061151a6200c13149dbcdb6c065203c8425d2","https://git.kernel.org/stable/c/b64d09a4e8596f76d27f4b4a90a1cf6baf6a82f8","https://git.kernel.org/stable/c/b9d760dae5b10e73369b769073525acd7b3be2bd","https://git.kernel.org/stable/c/cafa992134124e785609a406da4ff2b54052aff7","https://git.kernel.org/stable/c/d5f490343c77e6708b6c4aa7dbbfbcbb9546adea","https://git.kernel.org/stable/c/26b4d702c44f9e5cf3c5c001ae619a4a001889db","https://git.kernel.org/stable/c/4541004084527ce9e95a818ebbc4e6b293ffca21","https://git.kernel.org/stable/c/4dde83569832f9377362e50f7748463340c5db6b","https://git.kernel.org/stable/c/a0a061151a6200c13149dbcdb6c065203c8425d2","https://git.kernel.org/stable/c/b64d09a4e8596f76d27f4b4a90a1cf6baf6a82f8","https://git.kernel.org/stable/c/b9d760dae5b10e73369b769073525acd7b3be2bd","https://git.kernel.org/stable/c/cafa992134124e785609a406da4ff2b54052aff7","https://git.kernel.org/stable/c/d5f490343c77e6708b6c4aa7dbbfbcbb9546adea","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26981
|
High |
fixed |
- 4.19.313
- 5.4.275
- 5.10.216
- 5.15.157
- 6.1.88
- 6.6.29
- 6.8.8
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix OOB in nilfs_set_de_type
The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is
defined as "S_IFMT >> S_SHIFT", but the nilfs_set_de_type() function,
which uses this array, specifies the index to read from the array in the
same way as "(mode & S_IFMT) >> S_SHIFT".
static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode
*inode)
{
umode_t mode = inode->i_mode;
de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob
}
However, when the index is determined this way, an out-of-bounds (OOB)
error occurs by referring to an index that is 1 larger than the array size
when the condition "mode & S_IFMT == S_IFMT" is satisfied. Therefore, a
patch to resize the nilfs_type_by_mode array should be applied to prevent
OOB errors. |
["https://git.kernel.org/stable/c/054f29e9ca05be3906544c5f2a2c7321c30a4243","https://git.kernel.org/stable/c/2382eae66b196c31893984a538908c3eb7506ff9","https://git.kernel.org/stable/c/7061c7efbb9e8f11ce92d6b4646405ea2b0b4de1","https://git.kernel.org/stable/c/897ac5306bbeb83e90c437326f7044c79a17c611","https://git.kernel.org/stable/c/90823f8d9ecca3d5fa6b102c8e464c62f416975f","https://git.kernel.org/stable/c/90f43980ea6be4ad903e389be9a27a2a0018f1c8","https://git.kernel.org/stable/c/bdbe483da21f852c93b22557b146bc4d989260f0","https://git.kernel.org/stable/c/c4a7dc9523b59b3e73fd522c73e95e072f876b16","https://git.kernel.org/stable/c/054f29e9ca05be3906544c5f2a2c7321c30a4243","https://git.kernel.org/stable/c/2382eae66b196c31893984a538908c3eb7506ff9","https://git.kernel.org/stable/c/7061c7efbb9e8f11ce92d6b4646405ea2b0b4de1","https://git.kernel.org/stable/c/897ac5306bbeb83e90c437326f7044c79a17c611","https://git.kernel.org/stable/c/90823f8d9ecca3d5fa6b102c8e464c62f416975f","https://git.kernel.org/stable/c/90f43980ea6be4ad903e389be9a27a2a0018f1c8","https://git.kernel.org/stable/c/bdbe483da21f852c93b22557b146bc4d989260f0","https://git.kernel.org/stable/c/c4a7dc9523b59b3e73fd522c73e95e072f876b16","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36940
|
High |
fixed |
- 4.19.314
- 5.4.276
- 5.10.217
- 5.15.159
- 6.1.91
- 6.6.31
- 6.8.10
|
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: core: delete incorrect free in pinctrl_enable()
The "pctldev" struct is allocated in devm_pinctrl_register_and_init().
It's a devm_ managed pointer that is freed by devm_pinctrl_dev_release(),
so freeing it in pinctrl_enable() will lead to a double free.
The devm_pinctrl_dev_release() function frees the pindescs and destroys
the mutex as well. |
["https://git.kernel.org/stable/c/288bc4aa75f150d6f1ee82dd43c6da1b438b6068","https://git.kernel.org/stable/c/41f88ef8ba387a12f4a2b8c400b6c9e8e54b2cca","https://git.kernel.org/stable/c/5038a66dad0199de60e5671603ea6623eb9e5c79","https://git.kernel.org/stable/c/558c8039fdf596a584a92c171cbf3298919c448c","https://git.kernel.org/stable/c/735f4c6b6771eafe336404c157ca683ad72a040d","https://git.kernel.org/stable/c/ac7d65795827dc0cf7662384ed27caf4066bd72e","https://git.kernel.org/stable/c/cdaa171473d98962ae86f2a663d398fda2fbeefd","https://git.kernel.org/stable/c/f9f1e321d53e4c5b666b66e5b43da29841fb55ba","https://git.kernel.org/stable/c/288bc4aa75f150d6f1ee82dd43c6da1b438b6068","https://git.kernel.org/stable/c/41f88ef8ba387a12f4a2b8c400b6c9e8e54b2cca","https://git.kernel.org/stable/c/5038a66dad0199de60e5671603ea6623eb9e5c79","https://git.kernel.org/stable/c/558c8039fdf596a584a92c171cbf3298919c448c","https://git.kernel.org/stable/c/735f4c6b6771eafe336404c157ca683ad72a040d","https://git.kernel.org/stable/c/ac7d65795827dc0cf7662384ed27caf4066bd72e","https://git.kernel.org/stable/c/cdaa171473d98962ae86f2a663d398fda2fbeefd","https://git.kernel.org/stable/c/f9f1e321d53e4c5b666b66e5b43da29841fb55ba","https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38583
|
High |
fixed |
- 4.19.316
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.94
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix use-after-free of timer for log writer thread
Patch series "nilfs2: fix log writer related issues".
This bug fix series covers three nilfs2 log writer-related issues,
including a timer use-after-free issue and potential deadlock issue on
unmount, and a potential freeze issue in event synchronization found
during their analysis. Details are described in each commit log.
This patch (of 3):
A use-after-free issue has been reported regarding the timer sc_timer on
the nilfs_sc_info structure.
The problem is that even though it is used to wake up a sleeping log
writer thread, sc_timer is not shut down until the nilfs_sc_info structure
is about to be freed, and is used regardless of the thread's lifetime.
Fix this issue by limiting the use of sc_timer only while the log writer
thread is alive. |
["https://git.kernel.org/stable/c/2f12b2c03c5dae1a0de0a9e5853177e3d6eee3c6","https://git.kernel.org/stable/c/67fa90d4a2ccd9ebb0e1e168c7d0b5d0cf3c7148","https://git.kernel.org/stable/c/68e738be5c518fc3c4e9146b66f67c8fee0135fb","https://git.kernel.org/stable/c/822ae5a8eac30478578a75f7e064f0584931bf2d","https://git.kernel.org/stable/c/82933c84f188dcfe89eb26b0b48ab5d1ca99d164","https://git.kernel.org/stable/c/86a30d6302deddb9fb97ba6fc4b04d0e870b582a","https://git.kernel.org/stable/c/e65ccf3a4de4f0c763d94789615b83e11f204438","https://git.kernel.org/stable/c/f5d4e04634c9cf68bdf23de08ada0bb92e8befe7","https://git.kernel.org/stable/c/f9186bba4ea282b07293c1c892441df3a5441cb0","https://git.kernel.org/stable/c/2f12b2c03c5dae1a0de0a9e5853177e3d6eee3c6","https://git.kernel.org/stable/c/67fa90d4a2ccd9ebb0e1e168c7d0b5d0cf3c7148","https://git.kernel.org/stable/c/68e738be5c518fc3c4e9146b66f67c8fee0135fb","https://git.kernel.org/stable/c/822ae5a8eac30478578a75f7e064f0584931bf2d","https://git.kernel.org/stable/c/82933c84f188dcfe89eb26b0b48ab5d1ca99d164","https://git.kernel.org/stable/c/86a30d6302deddb9fb97ba6fc4b04d0e870b582a","https://git.kernel.org/stable/c/e65ccf3a4de4f0c763d94789615b83e11f204438","https://git.kernel.org/stable/c/f5d4e04634c9cf68bdf23de08ada0bb92e8befe7","https://git.kernel.org/stable/c/f9186bba4ea282b07293c1c892441df3a5441cb0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1670
|
High |
fixed |
- 4.14.312
- 4.19.280
- 5.4.240
- 5.10.177
- 5.15.105
- 6.1.22
- 6.2.9
|
A flaw use after free in the Linux kernel Xircom 16-bit PCMCIA (PC-card) Ethernet driver was found.A local user could use this flaw to crash the system or potentially escalate their privileges on the system. |
["https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20230316161526.1568982-1-zyytlz.wz%40163.com/","https://security.netapp.com/advisory/ntap-20230526-0010/","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20230316161526.1568982-1-zyytlz.wz%40163.com/","https://security.netapp.com/advisory/ntap-20230526-0010/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42280
|
High |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
mISDN: Fix a use after free in hfcmulti_tx()
Don't dereference *sp after calling dev_kfree_skb(*sp). |
["https://git.kernel.org/stable/c/4d8b642985ae24f4b3656438eb8489834a17bb80","https://git.kernel.org/stable/c/61ab751451f5ebd0b98e02276a44e23a10110402","https://git.kernel.org/stable/c/70db2c84631f50e02e6b32b543700699dd395803","https://git.kernel.org/stable/c/7e4a539bca7d8d20f2c5d93c18cce8ef77cd78e0","https://git.kernel.org/stable/c/8f4030277dfb9dbe04fd78566b19931097c9d629","https://git.kernel.org/stable/c/9460ac3dd1ae033bc2b021a458fb535a0c36ddb2","https://git.kernel.org/stable/c/d3e4d4a98c5629ccdcb762a0ff6c82ba9738a0c3","https://git.kernel.org/stable/c/ddc79556641ee070d36be0de4a1f0a16a71f1fc7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42285
|
High |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/iwcm: Fix a use-after-free related to destroying CM IDs
iw_conn_req_handler() associates a new struct rdma_id_private (conn_id) with
an existing struct iw_cm_id (cm_id) as follows:
conn_id->cm_id.iw = cm_id;
cm_id->context = conn_id;
cm_id->cm_handler = cma_iw_handler;
rdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Make
sure that cm_work_handler() does not trigger a use-after-free by only
freeing of the struct rdma_id_private after all pending work has finished. |
["https://git.kernel.org/stable/c/557d035fe88d78dd51664f4dc0e1896c04c97cf6","https://git.kernel.org/stable/c/7f25f296fc9bd0435be14e89bf657cd615a23574","https://git.kernel.org/stable/c/94ee7ff99b87435ec63211f632918dc7f44dac79","https://git.kernel.org/stable/c/aee2424246f9f1dadc33faa78990c1e2eb7826e4","https://git.kernel.org/stable/c/d91d253c87fd1efece521ff2612078a35af673c6","https://git.kernel.org/stable/c/dc8074b8901caabb97c2d353abd6b4e7fa5a59a5","https://git.kernel.org/stable/c/ee39384ee787e86e9db4efb843818ef0ea9cb8ae","https://git.kernel.org/stable/c/ff5bbbdee08287d75d72e65b72a2b76d9637892a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44985
|
High |
fixed |
- 5.15.166
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent possible UAF in ip6_xmit()
If skb_expand_head() returns NULL, skb has been freed
and the associated dst/idev could also have been freed.
We must use rcu_read_lock() to prevent a possible UAF. |
["https://git.kernel.org/stable/c/124b428fe28064c809e4237b0b38e97200a8a4a8","https://git.kernel.org/stable/c/2d5ff7e339d04622d8282661df36151906d0e1c7","https://git.kernel.org/stable/c/38a21c026ed2cc7232414cb166efc1923f34af17","https://git.kernel.org/stable/c/975f764e96f71616b530e300c1bb2ac0ce0c2596","https://git.kernel.org/stable/c/b3a3d5333c13a1be57499581eab4a8fc94d57f36","https://git.kernel.org/stable/c/c47e022011719fc5727bca661d662303180535ba","https://git.kernel.org/stable/c/fc88d6c1f2895a5775795d82ec581afdff7661d1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44987
|
High |
fixed |
- 4.19.321
- 5.4.283
- 5.10.225
- 5.15.166
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent UAF in ip6_send_skb()
syzbot reported an UAF in ip6_send_skb() [1]
After ip6_local_out() has returned, we no longer can safely
dereference rt, unless we hold rcu_read_lock().
A similar issue has been fixed in commit
a688caa34beb ("ipv6: take rcu lock in rawv6_send_hdrinc()")
Another potential issue in ip6_finish_output2() is handled in a
separate patch.
[1]
BUG: KASAN: slab-use-after-free in ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964
Read of size 8 at addr ffff88806dde4858 by task syz.1.380/6530
CPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 Not tainted 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:93 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x169/0x550 mm/kasan/report.c:488
kasan_report+0x143/0x180 mm/kasan/report.c:601
ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964
rawv6_push_pending_frames+0x75c/0x9e0 net/ipv6/raw.c:588
rawv6_sendmsg+0x19c7/0x23c0 net/ipv6/raw.c:926
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x1a6/0x270 net/socket.c:745
sock_write_iter+0x2dd/0x400 net/socket.c:1160
do_iter_readv_writev+0x60a/0x890
vfs_writev+0x37c/0xbb0 fs/read_write.c:971
do_writev+0x1b1/0x350 fs/read_write.c:1018
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f936bf79e79
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f936cd7f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00007f936c115f80 RCX: 00007f936bf79e79
RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000004
RBP: 00007f936bfe7916 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f936c115f80 R15: 00007fff2860a7a8
</TASK>
Allocated by task 6530:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
unpoison_slab_object mm/kasan/common.c:312 [inline]
__kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338
kasan_slab_alloc include/linux/kasan.h:201 [inline]
slab_post_alloc_hook mm/slub.c:3988 [inline]
slab_alloc_node mm/slub.c:4037 [inline]
kmem_cache_alloc_noprof+0x135/0x2a0 mm/slub.c:4044
dst_alloc+0x12b/0x190 net/core/dst.c:89
ip6_blackhole_route+0x59/0x340 net/ipv6/route.c:2670
make_blackhole net/xfrm/xfrm_policy.c:3120 [inline]
xfrm_lookup_route+0xd1/0x1c0 net/xfrm/xfrm_policy.c:3313
ip6_dst_lookup_flow+0x13e/0x180 net/ipv6/ip6_output.c:1257
rawv6_sendmsg+0x1283/0x23c0 net/ipv6/raw.c:898
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x1a6/0x270 net/socket.c:745
____sys_sendmsg+0x525/0x7d0 net/socket.c:2597
___sys_sendmsg net/socket.c:2651 [inline]
__sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 45:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
poison_slab_object+0xe0/0x150 mm/kasan/common.c:240
__kasan_slab_free+0x37/0x60 mm/kasan/common.c:256
kasan_slab_free include/linux/kasan.h:184 [inline]
slab_free_hook mm/slub.c:2252 [inline]
slab_free mm/slub.c:4473 [inline]
kmem_cache_free+0x145/0x350 mm/slub.c:4548
dst_destroy+0x2ac/0x460 net/core/dst.c:124
rcu_do_batch kernel/rcu/tree.c:2569 [inline]
rcu_core+0xafd/0x1830 kernel/rcu/tree.
---truncated--- |
["https://git.kernel.org/stable/c/24e93695b1239fbe4c31e224372be77f82dab69a","https://git.kernel.org/stable/c/571567e0277008459750f0728f246086b2659429","https://git.kernel.org/stable/c/9a3e55afa95ed4ac9eda112d4f918af645d72f25","https://git.kernel.org/stable/c/af1dde074ee2ed7dd5bdca4e7e8ba17f44e7b011","https://git.kernel.org/stable/c/cb5880a0de12c7f618d2bdd84e2d985f1e06ed7e","https://git.kernel.org/stable/c/ce2f6cfab2c637d0bd9762104023a15d0ab7c0a8","https://git.kernel.org/stable/c/e44bd76dd072756e674f45c5be00153f4ded68b2","https://git.kernel.org/stable/c/faa389b2fbaaec7fd27a390b4896139f9da662e3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35867
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in cifs_stats_proc_show()
Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF. |
["https://git.kernel.org/stable/c/0865ffefea197b437ba78b5dd8d8e256253efd65","https://git.kernel.org/stable/c/16b7d785775eb03929766819415055e367398f49","https://git.kernel.org/stable/c/1e12f0d5c66f07c934041621351973a116fa13c7","https://git.kernel.org/stable/c/838ec01ea8d3deb5d123e8ed9022e8162dc3f503","https://git.kernel.org/stable/c/bb6570085826291dc392005f9fec16ea5da3c8ad","https://git.kernel.org/stable/c/c3cf8b74c57924c0985e49a1fdf02d3395111f39","http://www.openwall.com/lists/oss-security/2024/05/29/2","http://www.openwall.com/lists/oss-security/2024/05/30/1","http://www.openwall.com/lists/oss-security/2024/05/30/2","https://git.kernel.org/stable/c/0865ffefea197b437ba78b5dd8d8e256253efd65","https://git.kernel.org/stable/c/16b7d785775eb03929766819415055e367398f49","https://git.kernel.org/stable/c/1e12f0d5c66f07c934041621351973a116fa13c7","https://git.kernel.org/stable/c/c3cf8b74c57924c0985e49a1fdf02d3395111f39"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41000
|
High |
fixed |
- 5.10.221
- 5.15.162
- 6.1.96
- 6.6.36
- 6.9.7
|
In the Linux kernel, the following vulnerability has been resolved:
block/ioctl: prefer different overflow check
Running syzkaller with the newly reintroduced signed integer overflow
sanitizer shows this report:
[ 62.982337] ------------[ cut here ]------------
[ 62.985692] cgroup: Invalid name
[ 62.986211] UBSAN: signed-integer-overflow in ../block/ioctl.c:36:46
[ 62.989370] 9pnet_fd: p9_fd_create_tcp (7343): problem connecting socket to 127.0.0.1
[ 62.992992] 9223372036854775807 + 4095 cannot be represented in type 'long long'
[ 62.997827] 9pnet_fd: p9_fd_create_tcp (7345): problem connecting socket to 127.0.0.1
[ 62.999369] random: crng reseeded on system resumption
[ 63.000634] GUP no longer grows the stack in syz-executor.2 (7353): 20002000-20003000 (20001000)
[ 63.000668] CPU: 0 PID: 7353 Comm: syz-executor.2 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1
[ 63.000677] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 63.000682] Call Trace:
[ 63.000686] <TASK>
[ 63.000731] dump_stack_lvl+0x93/0xd0
[ 63.000919] __get_user_pages+0x903/0xd30
[ 63.001030] __gup_longterm_locked+0x153e/0x1ba0
[ 63.001041] ? _raw_read_unlock_irqrestore+0x17/0x50
[ 63.001072] ? try_get_folio+0x29c/0x2d0
[ 63.001083] internal_get_user_pages_fast+0x1119/0x1530
[ 63.001109] iov_iter_extract_pages+0x23b/0x580
[ 63.001206] bio_iov_iter_get_pages+0x4de/0x1220
[ 63.001235] iomap_dio_bio_iter+0x9b6/0x1410
[ 63.001297] __iomap_dio_rw+0xab4/0x1810
[ 63.001316] iomap_dio_rw+0x45/0xa0
[ 63.001328] ext4_file_write_iter+0xdde/0x1390
[ 63.001372] vfs_write+0x599/0xbd0
[ 63.001394] ksys_write+0xc8/0x190
[ 63.001403] do_syscall_64+0xd4/0x1b0
[ 63.001421] ? arch_exit_to_user_mode_prepare+0x3a/0x60
[ 63.001479] entry_SYSCALL_64_after_hwframe+0x6f/0x77
[ 63.001535] RIP: 0033:0x7f7fd3ebf539
[ 63.001551] Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
[ 63.001562] RSP: 002b:00007f7fd32570c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 63.001584] RAX: ffffffffffffffda RBX: 00007f7fd3ff3f80 RCX: 00007f7fd3ebf539
[ 63.001590] RDX: 4db6d1e4f7e43360 RSI: 0000000020000000 RDI: 0000000000000004
[ 63.001595] RBP: 00007f7fd3f1e496 R08: 0000000000000000 R09: 0000000000000000
[ 63.001599] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[ 63.001604] R13: 0000000000000006 R14: 00007f7fd3ff3f80 R15: 00007ffd415ad2b8
...
[ 63.018142] ---[ end trace ]---
Historically, the signed integer overflow sanitizer did not work in the
kernel due to its interaction with `-fwrapv` but this has since been
changed [1] in the newest version of Clang; It was re-enabled in the
kernel with Commit 557f8c582a9ba8ab ("ubsan: Reintroduce signed overflow
sanitizer").
Let's rework this overflow checking logic to not actually perform an
overflow during the check itself, thus avoiding the UBSAN splat.
[1]: https://github.com/llvm/llvm-project/pull/82432 |
["https://git.kernel.org/stable/c/3220c90f4dbdc6d20d0608b164d964434a810d66","https://git.kernel.org/stable/c/54160fb1db2de367485f21e30196c42f7ee0be4e","https://git.kernel.org/stable/c/58706e482bf45c4db48b0c53aba2468c97adda24","https://git.kernel.org/stable/c/61ec76ec930709b7bcd69029ef1fe90491f20cf9","https://git.kernel.org/stable/c/ccb326b5f9e623eb7f130fbbf2505ec0e2dcaff9","https://git.kernel.org/stable/c/fd841ee01fb4a79cb7f5cc424b5c96c3a73b2d1e","https://git.kernel.org/stable/c/3220c90f4dbdc6d20d0608b164d964434a810d66","https://git.kernel.org/stable/c/54160fb1db2de367485f21e30196c42f7ee0be4e","https://git.kernel.org/stable/c/58706e482bf45c4db48b0c53aba2468c97adda24","https://git.kernel.org/stable/c/61ec76ec930709b7bcd69029ef1fe90491f20cf9","https://git.kernel.org/stable/c/ccb326b5f9e623eb7f130fbbf2505ec0e2dcaff9","https://git.kernel.org/stable/c/fd841ee01fb4a79cb7f5cc424b5c96c3a73b2d1e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39487
|
High |
fixed |
- 4.19.318
- 5.4.280
- 5.10.222
- 5.15.163
- 6.1.98
- 6.6.39
- 6.9.9
|
In the Linux kernel, the following vulnerability has been resolved:
bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()
In function bond_option_arp_ip_targets_set(), if newval->string is an
empty string, newval->string+1 will point to the byte after the
string, causing an out-of-bound read.
BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418
Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107
CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:364 [inline]
print_report+0xc1/0x5e0 mm/kasan/report.c:475
kasan_report+0xbe/0xf0 mm/kasan/report.c:588
strlen+0x7d/0xa0 lib/string.c:418
__fortify_strlen include/linux/fortify-string.h:210 [inline]
in4_pton+0xa3/0x3f0 net/core/utils.c:130
bond_option_arp_ip_targets_set+0xc2/0x910
drivers/net/bonding/bond_options.c:1201
__bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767
__bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792
bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817
bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156
dev_attr_store+0x54/0x80 drivers/base/core.c:2366
sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136
kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334
call_write_iter include/linux/fs.h:2020 [inline]
new_sync_write fs/read_write.c:491 [inline]
vfs_write+0x96a/0xd80 fs/read_write.c:584
ksys_write+0x122/0x250 fs/read_write.c:637
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
---[ end trace ]---
Fix it by adding a check of string length before using it. |
["https://git.kernel.org/stable/c/6a8a4fd082c439e19fede027e80c79bc4c84bb8e","https://git.kernel.org/stable/c/6b21346b399fd1336fe59233a17eb5ce73041ee1","https://git.kernel.org/stable/c/707c85ba3527ad6aa25552033576b0f1ff835d7b","https://git.kernel.org/stable/c/9f835e48bd4c75fdf6a9cff3f0b806a7abde78da","https://git.kernel.org/stable/c/b75e33eae8667084bd4a63e67657c6a5a0f8d1e8","https://git.kernel.org/stable/c/bfd14e5915c2669f292a31d028e75dcd82f1e7e9","https://git.kernel.org/stable/c/c8eb8ab9a44ff0e73492d0a12a643c449f641a9f","https://git.kernel.org/stable/c/e271ff53807e8f2c628758290f0e499dbe51cb3d","https://git.kernel.org/stable/c/6a8a4fd082c439e19fede027e80c79bc4c84bb8e","https://git.kernel.org/stable/c/6b21346b399fd1336fe59233a17eb5ce73041ee1","https://git.kernel.org/stable/c/707c85ba3527ad6aa25552033576b0f1ff835d7b","https://git.kernel.org/stable/c/9f835e48bd4c75fdf6a9cff3f0b806a7abde78da","https://git.kernel.org/stable/c/b75e33eae8667084bd4a63e67657c6a5a0f8d1e8","https://git.kernel.org/stable/c/bfd14e5915c2669f292a31d028e75dcd82f1e7e9","https://git.kernel.org/stable/c/c8eb8ab9a44ff0e73492d0a12a643c449f641a9f","https://git.kernel.org/stable/c/e271ff53807e8f2c628758290f0e499dbe51cb3d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-0330
|
High |
fixed |
|
A random memory access flaw was found in the Linux kernel's GPU i915 kernel driver functionality in the way a user may run malicious code on the GPU. This flaw allows a local user to crash the system or escalate their privileges on the system. |
["http://www.openwall.com/lists/oss-security/2022/11/30/1","https://bugzilla.redhat.com/show_bug.cgi?id=2042404","https://security.netapp.com/advisory/ntap-20220526-0001/","https://www.openwall.com/lists/oss-security/2022/01/25/12","http://www.openwall.com/lists/oss-security/2022/11/30/1","https://bugzilla.redhat.com/show_bug.cgi?id=2042404","https://security.netapp.com/advisory/ntap-20220526-0001/","https://www.openwall.com/lists/oss-security/2022/01/25/12"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-34027
|
High |
fixed |
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.9.4
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock
It needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock
to avoid racing with checkpoint, otherwise, filesystem metadata including
blkaddr in dnode, inode fields and .total_valid_block_count may be
corrupted after SPO case. |
["https://git.kernel.org/stable/c/0a4ed2d97cb6d044196cc3e726b6699222b41019","https://git.kernel.org/stable/c/329edb7c9e3b6ca27e6ca67ab1cdda1740fb3a2b","https://git.kernel.org/stable/c/5d47d63883735718825ca2efc4fca6915469774f","https://git.kernel.org/stable/c/69136304fd144144a4828c7b7b149d0f80321ba4","https://git.kernel.org/stable/c/a6e1f7744e9b84f86a629a76024bba8468aa153b","https://git.kernel.org/stable/c/b5bac43875aa27ec032dbbb86173baae6dce6182","https://git.kernel.org/stable/c/0a4ed2d97cb6d044196cc3e726b6699222b41019","https://git.kernel.org/stable/c/329edb7c9e3b6ca27e6ca67ab1cdda1740fb3a2b","https://git.kernel.org/stable/c/5d47d63883735718825ca2efc4fca6915469774f","https://git.kernel.org/stable/c/69136304fd144144a4828c7b7b149d0f80321ba4","https://git.kernel.org/stable/c/a6e1f7744e9b84f86a629a76024bba8468aa153b","https://git.kernel.org/stable/c/b5bac43875aa27ec032dbbb86173baae6dce6182"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41040
|
High |
fixed |
- 5.10.222
- 5.13
- 5.15.163
- 6.1.100
- 6.6.41
- 6.9.10
|
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Fix UAF when resolving a clash
KASAN reports the following UAF:
BUG: KASAN: slab-use-after-free in tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct]
Read of size 1 at addr ffff888c07603600 by task handler130/6469
Call Trace:
<IRQ>
dump_stack_lvl+0x48/0x70
print_address_description.constprop.0+0x33/0x3d0
print_report+0xc0/0x2b0
kasan_report+0xd0/0x120
__asan_load1+0x6c/0x80
tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct]
tcf_ct_act+0x886/0x1350 [act_ct]
tcf_action_exec+0xf8/0x1f0
fl_classify+0x355/0x360 [cls_flower]
__tcf_classify+0x1fd/0x330
tcf_classify+0x21c/0x3c0
sch_handle_ingress.constprop.0+0x2c5/0x500
__netif_receive_skb_core.constprop.0+0xb25/0x1510
__netif_receive_skb_list_core+0x220/0x4c0
netif_receive_skb_list_internal+0x446/0x620
napi_complete_done+0x157/0x3d0
gro_cell_poll+0xcf/0x100
__napi_poll+0x65/0x310
net_rx_action+0x30c/0x5c0
__do_softirq+0x14f/0x491
__irq_exit_rcu+0x82/0xc0
irq_exit_rcu+0xe/0x20
common_interrupt+0xa1/0xb0
</IRQ>
<TASK>
asm_common_interrupt+0x27/0x40
Allocated by task 6469:
kasan_save_stack+0x38/0x70
kasan_set_track+0x25/0x40
kasan_save_alloc_info+0x1e/0x40
__kasan_krealloc+0x133/0x190
krealloc+0xaa/0x130
nf_ct_ext_add+0xed/0x230 [nf_conntrack]
tcf_ct_act+0x1095/0x1350 [act_ct]
tcf_action_exec+0xf8/0x1f0
fl_classify+0x355/0x360 [cls_flower]
__tcf_classify+0x1fd/0x330
tcf_classify+0x21c/0x3c0
sch_handle_ingress.constprop.0+0x2c5/0x500
__netif_receive_skb_core.constprop.0+0xb25/0x1510
__netif_receive_skb_list_core+0x220/0x4c0
netif_receive_skb_list_internal+0x446/0x620
napi_complete_done+0x157/0x3d0
gro_cell_poll+0xcf/0x100
__napi_poll+0x65/0x310
net_rx_action+0x30c/0x5c0
__do_softirq+0x14f/0x491
Freed by task 6469:
kasan_save_stack+0x38/0x70
kasan_set_track+0x25/0x40
kasan_save_free_info+0x2b/0x60
____kasan_slab_free+0x180/0x1f0
__kasan_slab_free+0x12/0x30
slab_free_freelist_hook+0xd2/0x1a0
__kmem_cache_free+0x1a2/0x2f0
kfree+0x78/0x120
nf_conntrack_free+0x74/0x130 [nf_conntrack]
nf_ct_destroy+0xb2/0x140 [nf_conntrack]
__nf_ct_resolve_clash+0x529/0x5d0 [nf_conntrack]
nf_ct_resolve_clash+0xf6/0x490 [nf_conntrack]
__nf_conntrack_confirm+0x2c6/0x770 [nf_conntrack]
tcf_ct_act+0x12ad/0x1350 [act_ct]
tcf_action_exec+0xf8/0x1f0
fl_classify+0x355/0x360 [cls_flower]
__tcf_classify+0x1fd/0x330
tcf_classify+0x21c/0x3c0
sch_handle_ingress.constprop.0+0x2c5/0x500
__netif_receive_skb_core.constprop.0+0xb25/0x1510
__netif_receive_skb_list_core+0x220/0x4c0
netif_receive_skb_list_internal+0x446/0x620
napi_complete_done+0x157/0x3d0
gro_cell_poll+0xcf/0x100
__napi_poll+0x65/0x310
net_rx_action+0x30c/0x5c0
__do_softirq+0x14f/0x491
The ct may be dropped if a clash has been resolved but is still passed to
the tcf_ct_flow_table_process_conn function for further usage. This issue
can be fixed by retrieving ct from skb again after confirming conntrack. |
["https://git.kernel.org/stable/c/26488172b0292bed837b95a006a3f3431d1898c3","https://git.kernel.org/stable/c/2b4d68df3f57ea746c430941ba9c03d7d8b5a23f","https://git.kernel.org/stable/c/4e71b10a100861fb27d9c5755dfd68f615629fae","https://git.kernel.org/stable/c/799a34901b634008db4a7ece3900e2b971d4c932","https://git.kernel.org/stable/c/b81a523d54ea689414f67c9fb81a5b917a41ed55","https://git.kernel.org/stable/c/ef472cc6693b16b202a916482df72f35d94bd69e","https://git.kernel.org/stable/c/26488172b0292bed837b95a006a3f3431d1898c3","https://git.kernel.org/stable/c/2b4d68df3f57ea746c430941ba9c03d7d8b5a23f","https://git.kernel.org/stable/c/4e71b10a100861fb27d9c5755dfd68f615629fae","https://git.kernel.org/stable/c/799a34901b634008db4a7ece3900e2b971d4c932","https://git.kernel.org/stable/c/b81a523d54ea689414f67c9fb81a5b917a41ed55","https://git.kernel.org/stable/c/ef472cc6693b16b202a916482df72f35d94bd69e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48674
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
erofs: fix pcluster use-after-free on UP platforms
During stress testing with CONFIG_SMP disabled, KASAN reports as below:
==================================================================
BUG: KASAN: use-after-free in __mutex_lock+0xe5/0xc30
Read of size 8 at addr ffff8881094223f8 by task stress/7789
CPU: 0 PID: 7789 Comm: stress Not tainted 6.0.0-rc1-00002-g0d53d2e882f9 #3
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
Call Trace:
<TASK>
..
__mutex_lock+0xe5/0xc30
..
z_erofs_do_read_page+0x8ce/0x1560
..
z_erofs_readahead+0x31c/0x580
..
Freed by task 7787
kasan_save_stack+0x1e/0x40
kasan_set_track+0x20/0x30
kasan_set_free_info+0x20/0x40
__kasan_slab_free+0x10c/0x190
kmem_cache_free+0xed/0x380
rcu_core+0x3d5/0xc90
__do_softirq+0x12d/0x389
Last potentially related work creation:
kasan_save_stack+0x1e/0x40
__kasan_record_aux_stack+0x97/0xb0
call_rcu+0x3d/0x3f0
erofs_shrink_workstation+0x11f/0x210
erofs_shrink_scan+0xdc/0x170
shrink_slab.constprop.0+0x296/0x530
drop_slab+0x1c/0x70
drop_caches_sysctl_handler+0x70/0x80
proc_sys_call_handler+0x20a/0x2f0
vfs_write+0x555/0x6c0
ksys_write+0xbe/0x160
do_syscall_64+0x3b/0x90
The root cause is that erofs_workgroup_unfreeze() doesn't reset to
orig_val thus it causes a race that the pcluster reuses unexpectedly
before freeing.
Since UP platforms are quite rare now, such path becomes unnecessary.
Let's drop such specific-designed path directly instead. |
["https://git.kernel.org/stable/c/2f44013e39984c127c6efedf70e6b5f4e9dcf315","https://git.kernel.org/stable/c/8ddd001cef5e82d19192e6861068463ecca5f556","https://git.kernel.org/stable/c/94c34faaafe7b55adc2d8d881db195b646959b9e","https://git.kernel.org/stable/c/2f44013e39984c127c6efedf70e6b5f4e9dcf315","https://git.kernel.org/stable/c/8ddd001cef5e82d19192e6861068463ecca5f556","https://git.kernel.org/stable/c/94c34faaafe7b55adc2d8d881db195b646959b9e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48988
|
High |
fixed |
- 4.14.302
- 4.19.269
- 5.4.227
- 5.10.159
- 5.15.83
- 6.0.13
|
In the Linux kernel, the following vulnerability has been resolved:
memcg: fix possible use-after-free in memcg_write_event_control()
memcg_write_event_control() accesses the dentry->d_name of the specified
control fd to route the write call. As a cgroup interface file can't be
renamed, it's safe to access d_name as long as the specified file is a
regular cgroup file. Also, as these cgroup interface files can't be
removed before the directory, it's safe to access the parent too.
Prior to 347c4a874710 ("memcg: remove cgroup_event->cft"), there was a
call to __file_cft() which verified that the specified file is a regular
cgroupfs file before further accesses. The cftype pointer returned from
__file_cft() was no longer necessary and the commit inadvertently dropped
the file type check with it allowing any file to slip through. With the
invarients broken, the d_name and parent accesses can now race against
renames and removals of arbitrary files and cause use-after-free's.
Fix the bug by resurrecting the file type check in __file_cft(). Now that
cgroupfs is implemented through kernfs, checking the file operations needs
to go through a layer of indirection. Instead, let's check the superblock
and dentry type. |
["https://git.kernel.org/stable/c/0ed074317b835caa6c03bcfa8f133365324673dc","https://git.kernel.org/stable/c/35963b31821920908e397146502066f6b032c917","https://git.kernel.org/stable/c/4a7ba45b1a435e7097ca0f79a847d0949d0eb088","https://git.kernel.org/stable/c/aad8bbd17a1d586005feb9226c2e9cfce1432e13","https://git.kernel.org/stable/c/b77600e26fd48727a95ffd50ba1e937efb548125","https://git.kernel.org/stable/c/e1ae97624ecf400ea56c238bff23e5cd139df0b8","https://git.kernel.org/stable/c/f1f7f36cf682fa59db15e2089039a2eeb58ff2ad"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27013
|
Medium |
fixed |
- 4.19.313
- 5.4.275
- 5.10.216
- 5.15.157
- 6.1.88
- 6.6.29
- 6.8.8
|
In the Linux kernel, the following vulnerability has been resolved:
tun: limit printing rate when illegal packet received by tun dev
vhost_worker will call tun call backs to receive packets. If too many
illegal packets arrives, tun_do_read will keep dumping packet contents.
When console is enabled, it will costs much more cpu time to dump
packet and soft lockup will be detected.
net_ratelimit mechanism can be used to limit the dumping rate.
PID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: "vhost-32980"
#0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253
#1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3
#2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e
#3 [fffffe00003fced0] do_nmi at ffffffff8922660d
#4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663
[exception RIP: io_serial_in+20]
RIP: ffffffff89792594 RSP: ffffa655314979e8 RFLAGS: 00000002
RAX: ffffffff89792500 RBX: ffffffff8af428a0 RCX: 0000000000000000
RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff8af428a0
RBP: 0000000000002710 R8: 0000000000000004 R9: 000000000000000f
R10: 0000000000000000 R11: ffffffff8acbf64f R12: 0000000000000020
R13: ffffffff8acbf698 R14: 0000000000000058 R15: 0000000000000000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#5 [ffffa655314979e8] io_serial_in at ffffffff89792594
#6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470
#7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6
#8 [ffffa65531497a20] uart_console_write at ffffffff8978b605
#9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558
#10 [ffffa65531497ac8] console_unlock at ffffffff89316124
#11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07
#12 [ffffa65531497b68] printk at ffffffff89318306
#13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765
#14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun]
#15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun]
#16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net]
#17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost]
#18 [ffffa65531497f10] kthread at ffffffff892d2e72
#19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f |
["https://git.kernel.org/stable/c/14cdb43dbc827e18ac7d5b30c5b4c676219f1421","https://git.kernel.org/stable/c/40f4ced305c6c47487d3cd8da54676e2acc1a6ad","https://git.kernel.org/stable/c/4b0dcae5c4797bf31c63011ed62917210d3fdac3","https://git.kernel.org/stable/c/52854101180beccdb9dc2077a3bea31b6ad48dfa","https://git.kernel.org/stable/c/62e27ef18eb4f0d33bbae8e9ef56b99696a74713","https://git.kernel.org/stable/c/68459b8e3ee554ce71878af9eb69659b9462c588","https://git.kernel.org/stable/c/a50dbeca28acf7051dfa92786b85f704c75db6eb","https://git.kernel.org/stable/c/f8bbc07ac535593139c875ffa19af924b1084540","https://git.kernel.org/stable/c/14cdb43dbc827e18ac7d5b30c5b4c676219f1421","https://git.kernel.org/stable/c/40f4ced305c6c47487d3cd8da54676e2acc1a6ad","https://git.kernel.org/stable/c/4b0dcae5c4797bf31c63011ed62917210d3fdac3","https://git.kernel.org/stable/c/52854101180beccdb9dc2077a3bea31b6ad48dfa","https://git.kernel.org/stable/c/62e27ef18eb4f0d33bbae8e9ef56b99696a74713","https://git.kernel.org/stable/c/68459b8e3ee554ce71878af9eb69659b9462c588","https://git.kernel.org/stable/c/a50dbeca28acf7051dfa92786b85f704c75db6eb","https://git.kernel.org/stable/c/f8bbc07ac535593139c875ffa19af924b1084540","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36941
|
Medium |
fixed |
- 4.19.314
- 5.4.276
- 5.10.217
- 5.15.159
- 6.1.91
- 6.6.31
- 6.8.10
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: nl80211: don't free NULL coalescing rule
If the parsing fails, we can dereference a NULL pointer here. |
["https://git.kernel.org/stable/c/244822c09b4f9aedfb5977f03c0deeb39da8ec7d","https://git.kernel.org/stable/c/327382dc0f16b268950b96e0052595efd80f7b0a","https://git.kernel.org/stable/c/5a730a161ac2290d46d49be76b2b1aee8d2eb307","https://git.kernel.org/stable/c/801ea33ae82d6a9d954074fbcf8ea9d18f1543a7","https://git.kernel.org/stable/c/97792d0611ae2e6fe3ccefb0a94a1d802317c457","https://git.kernel.org/stable/c/ad12c74e953b68ad85c78adc6408ed8435c64af4","https://git.kernel.org/stable/c/b0db4caa10f2e4e811cf88744fbf0d074b67ec1f","https://git.kernel.org/stable/c/f92772a642485394db5c9a17bd0ee73fc6902383","https://git.kernel.org/stable/c/244822c09b4f9aedfb5977f03c0deeb39da8ec7d","https://git.kernel.org/stable/c/327382dc0f16b268950b96e0052595efd80f7b0a","https://git.kernel.org/stable/c/5a730a161ac2290d46d49be76b2b1aee8d2eb307","https://git.kernel.org/stable/c/801ea33ae82d6a9d954074fbcf8ea9d18f1543a7","https://git.kernel.org/stable/c/97792d0611ae2e6fe3ccefb0a94a1d802317c457","https://git.kernel.org/stable/c/ad12c74e953b68ad85c78adc6408ed8435c64af4","https://git.kernel.org/stable/c/b0db4caa10f2e4e811cf88744fbf0d074b67ec1f","https://git.kernel.org/stable/c/f92772a642485394db5c9a17bd0ee73fc6902383","https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36954
|
Medium |
fixed |
- 4.5
- 4.10
- 4.15
- 4.19.314
- 5.4.276
- 5.10.217
- 5.15.159
- 6.1.91
- 6.6.31
- 6.8.10
|
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix a possible memleak in tipc_buf_append
__skb_linearize() doesn't free the skb when it fails, so move
'*buf = NULL' after __skb_linearize(), so that the skb can be
freed on the err path. |
["https://git.kernel.org/stable/c/01cd1b7b685751ee422d00d050292a3d277652d6","https://git.kernel.org/stable/c/2f87fd9476cf9725d774e6dcb7d17859c6a6d1ae","https://git.kernel.org/stable/c/3210d34fda4caff212cb53729e6bd46de604d565","https://git.kernel.org/stable/c/42c8471b0566c7539e7dd584b4d0ebd3cec8cb2c","https://git.kernel.org/stable/c/614c5a5ae45a921595952117b2e2bd4d4bf9b574","https://git.kernel.org/stable/c/97bf6f81b29a8efaf5d0983251a7450e5794370d","https://git.kernel.org/stable/c/adbce6d20da6254c86425a8d4359b221b5ccbccd","https://git.kernel.org/stable/c/d03a82f4f8144befdc10518e732e2a60b34c870e","https://git.kernel.org/stable/c/01cd1b7b685751ee422d00d050292a3d277652d6","https://git.kernel.org/stable/c/2f87fd9476cf9725d774e6dcb7d17859c6a6d1ae","https://git.kernel.org/stable/c/3210d34fda4caff212cb53729e6bd46de604d565","https://git.kernel.org/stable/c/42c8471b0566c7539e7dd584b4d0ebd3cec8cb2c","https://git.kernel.org/stable/c/614c5a5ae45a921595952117b2e2bd4d4bf9b574","https://git.kernel.org/stable/c/97bf6f81b29a8efaf5d0983251a7450e5794370d","https://git.kernel.org/stable/c/adbce6d20da6254c86425a8d4359b221b5ccbccd","https://git.kernel.org/stable/c/d03a82f4f8144befdc10518e732e2a60b34c870e","https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38549
|
Medium |
fixed |
- 4.19.316
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Add 0 size check to mtk_drm_gem_obj
Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object
of 0 bytes. Currently, no such check exists and the kernel will panic if
a userspace application attempts to allocate a 0x0 GBM buffer.
Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and
verifying that we now return EINVAL. |
["https://git.kernel.org/stable/c/0e3b6f9123726858cac299e1654e3d20424cabe4","https://git.kernel.org/stable/c/13562c2d48c9ee330de1077d00146742be368f05","https://git.kernel.org/stable/c/1e4350095e8ab2577ee05f8c3b044e661b5af9a0","https://git.kernel.org/stable/c/79078880795478d551a05acc41f957700030d364","https://git.kernel.org/stable/c/9489951e3ae505534c4013db4e76b1b5a3151ac7","https://git.kernel.org/stable/c/af26ea99019caee1500bf7e60c861136c0bf8594","https://git.kernel.org/stable/c/be34a1b351ea7faeb15dde8c44fe89de3980ae67","https://git.kernel.org/stable/c/d17b75ee9c2e44d3a3682c4ea5ab713ea6073350","https://git.kernel.org/stable/c/fb4aabdb1b48c25d9e1ee28f89440fd2ce556405","https://git.kernel.org/stable/c/0e3b6f9123726858cac299e1654e3d20424cabe4","https://git.kernel.org/stable/c/13562c2d48c9ee330de1077d00146742be368f05","https://git.kernel.org/stable/c/1e4350095e8ab2577ee05f8c3b044e661b5af9a0","https://git.kernel.org/stable/c/79078880795478d551a05acc41f957700030d364","https://git.kernel.org/stable/c/9489951e3ae505534c4013db4e76b1b5a3151ac7","https://git.kernel.org/stable/c/af26ea99019caee1500bf7e60c861136c0bf8594","https://git.kernel.org/stable/c/be34a1b351ea7faeb15dde8c44fe89de3980ae67","https://git.kernel.org/stable/c/d17b75ee9c2e44d3a3682c4ea5ab713ea6073350","https://git.kernel.org/stable/c/fb4aabdb1b48c25d9e1ee28f89440fd2ce556405"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42244
|
Medium |
fixed |
- 5.10.222
- 5.15.163
- 6.1.100
- 6.6.41
- 6.9.10
|
In the Linux kernel, the following vulnerability has been resolved:
USB: serial: mos7840: fix crash on resume
Since commit c49cfa917025 ("USB: serial: use generic method if no
alternative is provided in usb serial layer"), USB serial core calls the
generic resume implementation when the driver has not provided one.
This can trigger a crash on resume with mos7840 since support for
multiple read URBs was added back in 2011. Specifically, both port read
URBs are now submitted on resume for open ports, but the context pointer
of the second URB is left set to the core rather than mos7840 port
structure.
Fix this by implementing dedicated suspend and resume functions for
mos7840.
Tested with Delock 87414 USB 2.0 to 4x serial adapter.
[ johan: analyse crash and rewrite commit message; set busy flag on
resume; drop bulk-in check; drop unnecessary usb_kill_urb() ] |
["https://git.kernel.org/stable/c/1094ed500987e67a9d18b0f95e1812f1cc720856","https://git.kernel.org/stable/c/553e67dec846323b5575e78a776cf594c13f98c4","https://git.kernel.org/stable/c/5ae6a64f18211851c8df6b4221381c438b9a7348","https://git.kernel.org/stable/c/932a86a711c722b45ed47ba2103adca34d225b33","https://git.kernel.org/stable/c/b14aa5673e0a8077ff4b74f0bb260735e7d5e6a4","https://git.kernel.org/stable/c/c15a688e49987385baa8804bf65d570e362f8576"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52889
|
Medium |
fixed |
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
apparmor: Fix null pointer deref when receiving skb during sock creation
The panic below is observed when receiving ICMP packets with secmark set
while an ICMP raw socket is being created. SK_CTX(sk)->label is updated
in apparmor_socket_post_create(), but the packet is delivered to the
socket before that, causing the null pointer dereference.
Drop the packet if label context is not set.
BUG: kernel NULL pointer dereference, address: 000000000000004c
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020
RIP: 0010:aa_label_next_confined+0xb/0x40
Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 <8b> 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2
RSP: 0018:ffffa92940003b08 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e
RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002
R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400
R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000
FS: 00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0
PKRU: 55555554
Call Trace:
<IRQ>
? __die+0x23/0x70
? page_fault_oops+0x171/0x4e0
? exc_page_fault+0x7f/0x180
? asm_exc_page_fault+0x26/0x30
? aa_label_next_confined+0xb/0x40
apparmor_secmark_check+0xec/0x330
security_sock_rcv_skb+0x35/0x50
sk_filter_trim_cap+0x47/0x250
sock_queue_rcv_skb_reason+0x20/0x60
raw_rcv+0x13c/0x210
raw_local_deliver+0x1f3/0x250
ip_protocol_deliver_rcu+0x4f/0x2f0
ip_local_deliver_finish+0x76/0xa0
__netif_receive_skb_one_core+0x89/0xa0
netif_receive_skb+0x119/0x170
? __netdev_alloc_skb+0x3d/0x140
vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]
vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]
__napi_poll+0x28/0x1b0
net_rx_action+0x2a4/0x380
__do_softirq+0xd1/0x2c8
__irq_exit_rcu+0xbb/0xf0
common_interrupt+0x86/0xa0
</IRQ>
<TASK>
asm_common_interrupt+0x26/0x40
RIP: 0010:apparmor_socket_post_create+0xb/0x200
Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 <55> 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48
RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286
RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001
RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003
R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748
? __pfx_apparmor_socket_post_create+0x10/0x10
security_socket_post_create+0x4b/0x80
__sock_create+0x176/0x1f0
__sys_socket+0x89/0x100
__x64_sys_socket+0x17/0x20
do_syscall_64+0x5d/0x90
? do_syscall_64+0x6c/0x90
? do_syscall_64+0x6c/0x90
? do_syscall_64+0x6c/0x90
entry_SYSCALL_64_after_hwframe+0x72/0xdc |
["https://git.kernel.org/stable/c/0abe35bc48d4ec80424b1f4b3560c0e082cbd5c1","https://git.kernel.org/stable/c/290a6b88e8c19b6636ed1acc733d1458206f7697","https://git.kernel.org/stable/c/347dcb84a4874b5fb375092c08d8cc4069b94f81","https://git.kernel.org/stable/c/46c17ead5b7389e22e7dc9903fd0ba865d05bda2","https://git.kernel.org/stable/c/6c920754f62cefc63fccdc38a062c7c3452e2961","https://git.kernel.org/stable/c/ead2ad1d9f045f26fdce3ef1644913b3a6cd38f2","https://git.kernel.org/stable/c/fce09ea314505a52f2436397608fa0a5d0934fb1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42283
|
Medium |
fixed |
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
net: nexthop: Initialize all fields in dumped nexthops
struct nexthop_grp contains two reserved fields that are not initialized by
nla_put_nh_group(), and carry garbage. This can be observed e.g. with
strace (edited for clarity):
# ip nexthop add id 1 dev lo
# ip nexthop add id 101 group 1
# strace -e recvmsg ip nexthop get id 101
...
recvmsg(... [{nla_len=12, nla_type=NHA_GROUP},
[{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52
The fields are reserved and therefore not currently used. But as they are, they
leak kernel memory, and the fact they are not just zero complicates repurposing
of the fields for new ends. Initialize the full structure. |
["https://git.kernel.org/stable/c/1377de719652d868f5317ba8398b7e74c5f0430b","https://git.kernel.org/stable/c/5cc4d71dda2dd4f1520f40e634a527022e48ccd8","https://git.kernel.org/stable/c/6d745cd0e9720282cd291d36b9db528aea18add2","https://git.kernel.org/stable/c/7704460acd7f5d35eb07c52500987dc9b95313fb","https://git.kernel.org/stable/c/9e8f558a3afe99ce51a642ce0d3637ddc2b5d5d0","https://git.kernel.org/stable/c/a13d3864b76ac87085ec530b2ff8e37482a63a96","https://git.kernel.org/stable/c/fd06cb4a5fc7bda3dea31712618a62af72a1c6cb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43835
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
virtio_net: Fix napi_skb_cache_put warning
After the commit bdacf3e34945 ("net: Use nested-BH locking for
napi_alloc_cache.") was merged, the following warning began to appear:
WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0
__warn+0x12f/0x340
napi_skb_cache_put+0x82/0x4b0
napi_skb_cache_put+0x82/0x4b0
report_bug+0x165/0x370
handle_bug+0x3d/0x80
exc_invalid_op+0x1a/0x50
asm_exc_invalid_op+0x1a/0x20
__free_old_xmit+0x1c8/0x510
napi_skb_cache_put+0x82/0x4b0
__free_old_xmit+0x1c8/0x510
__free_old_xmit+0x1c8/0x510
__pfx___free_old_xmit+0x10/0x10
The issue arises because virtio is assuming it's running in NAPI context
even when it's not, such as in the netpoll case.
To resolve this, modify virtnet_poll_tx() to only set NAPI when budget
is available. Same for virtnet_poll_cleantx(), which always assumed that
it was in a NAPI context. |
["https://git.kernel.org/stable/c/19ac6f29bf64304ef04630c8ab56ecd2059d7aa1","https://git.kernel.org/stable/c/468a729b78895893d0e580ceea49bed8ada2a2bd","https://git.kernel.org/stable/c/6b5325f2457521bbece29499970c0117a648c620","https://git.kernel.org/stable/c/842a97b5e44f0c8a9fc356fe976e0e13ddcf7783","https://git.kernel.org/stable/c/cc7340f18e45886121c131227985d64ef666012f","https://git.kernel.org/stable/c/d3af435e8ace119e58d8e21d3d2d6a4e7c4a4baa","https://git.kernel.org/stable/c/f5e9a22d19bb98a7e86034db85eb295e94187caa","https://git.kernel.org/stable/c/f8321fa75102246d7415a6af441872f6637c93ab"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43861
|
Medium |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.105
- 6.6.46
- 6.10.5
|
In the Linux kernel, the following vulnerability has been resolved:
net: usb: qmi_wwan: fix memory leak for not ip packets
Free the unused skb when not ip packets arrive. |
["https://git.kernel.org/stable/c/37c093449704017870604994ba9b813cdb9475a4","https://git.kernel.org/stable/c/3c90a69533b5bba73401ef884d033ea49ee99662","https://git.kernel.org/stable/c/7ab107544b777c3bd7feb9fe447367d8edd5b202","https://git.kernel.org/stable/c/c4251a3deccad852b27e60625f31fba6cc14372f","https://git.kernel.org/stable/c/c6c5b91424fafc0f83852d961c10c7e43a001882","https://git.kernel.org/stable/c/da518cc9b64df391795d9952aed551e0f782e446","https://git.kernel.org/stable/c/e87f52225e04a7001bf55bbd7a330fa4252327b5","https://git.kernel.org/stable/c/f2c353227de14b0289298ffc3ba92058c4768384"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43871
|
Medium |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
devres: Fix memory leakage caused by driver API devm_free_percpu()
It will cause memory leakage when use driver API devm_free_percpu()
to free memory allocated by devm_alloc_percpu(), fixed by using
devres_release() instead of devres_destroy() within devm_free_percpu(). |
["https://git.kernel.org/stable/c/3047f99caec240a88ccd06197af2868da1af6a96","https://git.kernel.org/stable/c/3dcd0673e47664bc6c719ad47dadac6d55d5950d","https://git.kernel.org/stable/c/700e8abd65b10792b2f179ce4e858f2ca2880f85","https://git.kernel.org/stable/c/95065edb8ebb27771d5f1e898eef6ab43dc6c87c","https://git.kernel.org/stable/c/b044588a16a978cd891cb3d665dd7ae06850d5bf","https://git.kernel.org/stable/c/b67552d7c61f52f1271031adfa7834545ae99701","https://git.kernel.org/stable/c/bd50a974097bb82d52a458bd3ee39fb723129a0c","https://git.kernel.org/stable/c/ef56dcdca8f2a53abc3a83d388b8336447533d85"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43889
|
Medium |
fixed |
- 5.10.224
- 5.15.165
- 6.1.105
- 6.6.46
- 6.10.5
|
In the Linux kernel, the following vulnerability has been resolved:
padata: Fix possible divide-by-0 panic in padata_mt_helper()
We are hit with a not easily reproducible divide-by-0 panic in padata.c at
bootup time.
[ 10.017908] Oops: divide error: 0000 1 PREEMPT SMP NOPTI
[ 10.017908] CPU: 26 PID: 2627 Comm: kworker/u1666:1 Not tainted 6.10.0-15.el10.x86_64 #1
[ 10.017908] Hardware name: Lenovo ThinkSystem SR950 [7X12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021
[ 10.017908] Workqueue: events_unbound padata_mt_helper
[ 10.017908] RIP: 0010:padata_mt_helper+0x39/0xb0
:
[ 10.017963] Call Trace:
[ 10.017968] <TASK>
[ 10.018004] ? padata_mt_helper+0x39/0xb0
[ 10.018084] process_one_work+0x174/0x330
[ 10.018093] worker_thread+0x266/0x3a0
[ 10.018111] kthread+0xcf/0x100
[ 10.018124] ret_from_fork+0x31/0x50
[ 10.018138] ret_from_fork_asm+0x1a/0x30
[ 10.018147] </TASK>
Looking at the padata_mt_helper() function, the only way a divide-by-0
panic can happen is when ps->chunk_size is 0. The way that chunk_size is
initialized in padata_do_multithreaded(), chunk_size can be 0 when the
min_chunk in the passed-in padata_mt_job structure is 0.
Fix this divide-by-0 panic by making sure that chunk_size will be at least
1 no matter what the input parameters are. |
["https://git.kernel.org/stable/c/6d45e1c948a8b7ed6ceddb14319af69424db730c","https://git.kernel.org/stable/c/8f5ffd2af7274853ff91d6cd62541191d9fbd10d","https://git.kernel.org/stable/c/924f788c906dccaca30acab86c7124371e1d6f2c","https://git.kernel.org/stable/c/a29cfcb848c31f22b4de6a531c3e1d68c9bfe09f","https://git.kernel.org/stable/c/ab8b397d5997d8c37610252528edc54bebf9f6d3","https://git.kernel.org/stable/c/da0ffe84fcc1627a7dff82c80b823b94236af905"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43890
|
Medium |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.105
- 6.6.46
- 6.10.5
|
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix overflow in get_free_elt()
"tracing_map->next_elt" in get_free_elt() is at risk of overflowing.
Once it overflows, new elements can still be inserted into the tracing_map
even though the maximum number of elements (`max_elts`) has been reached.
Continuing to insert elements after the overflow could result in the
tracing_map containing "tracing_map->max_size" elements, leaving no empty
entries.
If any attempt is made to insert an element into a full tracing_map using
`__tracing_map_insert()`, it will cause an infinite loop with preemption
disabled, leading to a CPU hang problem.
Fix this by preventing any further increments to "tracing_map->next_elt"
once it reaches "tracing_map->max_elt". |
["https://git.kernel.org/stable/c/236bb4690773ab6869b40bedc7bc8d889e36f9d6","https://git.kernel.org/stable/c/302ceb625d7b990db205a15e371f9a71238de91c","https://git.kernel.org/stable/c/788ea62499b3c18541fd6d621964d8fafbc4aec5","https://git.kernel.org/stable/c/a172c7b22bc2feaf489cfc6d6865f7237134fdf8","https://git.kernel.org/stable/c/bcf86c01ca4676316557dd482c8416ece8c2e143","https://git.kernel.org/stable/c/cd10d186a5409a1fe6e976df82858e9773a698da","https://git.kernel.org/stable/c/d3e4dbc2858fe85d1dbd2e72a9fc5dea988b5c18","https://git.kernel.org/stable/c/eb223bf01e688dfe37e813c8988ee11c8c9f8d0a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44935
|
Medium |
fixed |
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.105
- 6.6.46
- 6.10.5
|
In the Linux kernel, the following vulnerability has been resolved:
sctp: Fix null-ptr-deref in reuseport_add_sock().
syzbot reported a null-ptr-deref while accessing sk2->sk_reuseport_cb in
reuseport_add_sock(). [0]
The repro first creates a listener with SO_REUSEPORT. Then, it creates
another listener on the same port and concurrently closes the first
listener.
The second listen() calls reuseport_add_sock() with the first listener as
sk2, where sk2->sk_reuseport_cb is not expected to be cleared concurrently,
but the close() does clear it by reuseport_detach_sock().
The problem is SCTP does not properly synchronise reuseport_alloc(),
reuseport_add_sock(), and reuseport_detach_sock().
The caller of reuseport_alloc() and reuseport_{add,detach}_sock() must
provide synchronisation for sockets that are classified into the same
reuseport group.
Otherwise, such sockets form multiple identical reuseport groups, and
all groups except one would be silently dead.
1. Two sockets call listen() concurrently
2. No socket in the same group found in sctp_ep_hashtable[]
3. Two sockets call reuseport_alloc() and form two reuseport groups
4. Only one group hit first in __sctp_rcv_lookup_endpoint() receives
incoming packets
Also, the reported null-ptr-deref could occur.
TCP/UDP guarantees that would not happen by holding the hash bucket lock.
Let's apply the locking strategy to __sctp_hash_endpoint() and
__sctp_unhash_endpoint().
[0]:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
CPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024
RIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/sock_reuseport.c:350
Code: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14
RSP: 0018:ffffc9000b947c98 EFLAGS: 00010202
RAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012
RBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385
R10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0
R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000
FS: 00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
__sctp_hash_endpoint net/sctp/input.c:762 [inline]
sctp_hash_endpoint+0x52a/0x600 net/sctp/input.c:790
sctp_listen_start net/sctp/socket.c:8570 [inline]
sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625
__sys_listen_socket net/socket.c:1883 [inline]
__sys_listen+0x1b7/0x230 net/socket.c:1894
__do_sys_listen net/socket.c:1902 [inline]
__se_sys_listen net/socket.c:1900 [inline]
__x64_sys_listen+0x5a/0x70 net/socket.c:1900
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f24e46039b9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032
RAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: 00007f24e46039b9
RDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004
RBP: 00007f24e468e420 R08: 00007f24e45b96c0 R09: 00007f24e45b96c0
R10: 00007f24e45b96c0 R11: 0000000000000246 R12: 00007f24e468e42c
R13:
---truncated--- |
["https://git.kernel.org/stable/c/05e4a0fa248240efd99a539853e844f0f0a9e6a5","https://git.kernel.org/stable/c/1407be30fc17eff918a98e0a990c0e988f11dc84","https://git.kernel.org/stable/c/52319d9d2f522ed939af31af70f8c3a0f0f67e6c","https://git.kernel.org/stable/c/54b303d8f9702b8ab618c5032fae886b16356928","https://git.kernel.org/stable/c/9ab0faa7f9ffe31296dbb9bbe6f76c72c14eea18","https://git.kernel.org/stable/c/c9b3fc4f157867e858734e31022ebee8a24f0de7","https://git.kernel.org/stable/c/e809a84c802377ef61525a298a1ec1728759b913"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44965
|
Medium |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.105
- 6.6.46
- 6.10.5
|
In the Linux kernel, the following vulnerability has been resolved:
x86/mm: Fix pti_clone_pgtable() alignment assumption
Guenter reported dodgy crashes on an i386-nosmp build using GCC-11
that had the form of endless traps until entry stack exhaust and then
#DF from the stack guard.
It turned out that pti_clone_pgtable() had alignment assumptions on
the start address, notably it hard assumes start is PMD aligned. This
is true on x86_64, but very much not true on i386.
These assumptions can cause the end condition to malfunction, leading
to a 'short' clone. Guess what happens when the user mapping has a
short copy of the entry text?
Use the correct increment form for addr to avoid alignment
assumptions. |
["https://git.kernel.org/stable/c/18da1b27ce16a14a9b636af9232acb4fb24f4c9e","https://git.kernel.org/stable/c/25a727233a40a9b33370eec9f0cad67d8fd312f8","https://git.kernel.org/stable/c/41e71dbb0e0a0fe214545fe64af031303a08524c","https://git.kernel.org/stable/c/4d143ae782009b43b4f366402e5c37f59d4e4346","https://git.kernel.org/stable/c/5c580c1050bcbc15c3e78090859d798dcf8c9763","https://git.kernel.org/stable/c/ca07aab70dd3b5e7fddb62d7a6ecd7a7d6d0b2ed","https://git.kernel.org/stable/c/d00c9b4bbc442d99e1dafbdfdab848bc1ead73f6","https://git.kernel.org/stable/c/df3eecb5496f87263d171b254ca6e2758ab3c35c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44971
|
Medium |
fixed |
- 5.10.224
- 5.15.165
- 6.1.105
- 6.6.46
- 6.10.5
|
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register()
bcm_sf2_mdio_register() calls of_phy_find_device() and then
phy_device_remove() in a loop to remove existing PHY devices.
of_phy_find_device() eventually calls bus_find_device(), which calls
get_device() on the returned struct device * to increment the refcount.
The current implementation does not decrement the refcount, which causes
memory leak.
This commit adds the missing phy_device_free() call to decrement the
refcount via put_device() to balance the refcount. |
["https://git.kernel.org/stable/c/7feef10768ea71d468d9bbc1e0d14c461876768c","https://git.kernel.org/stable/c/a7d2808d67570e6acae45c2a96e0d59986888e4c","https://git.kernel.org/stable/c/b7b8d9f5e679af60c94251fd6728dde34be69a71","https://git.kernel.org/stable/c/c05516c072903f6fb9134b8e7e1ad4bffcdc4819","https://git.kernel.org/stable/c/e3862093ee93fcfbdadcb7957f5f8974fffa806a","https://git.kernel.org/stable/c/f3d5efe18a11f94150fee8b3fda9d62079af640a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44989
|
Medium |
fixed |
- 5.10.225
- 5.15.166
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
bonding: fix xfrm real_dev null pointer dereference
We shouldn't set real_dev to NULL because packets can be in transit and
xfrm might call xdo_dev_offload_ok() in parallel. All callbacks assume
real_dev is set.
Example trace:
kernel: BUG: unable to handle page fault for address: 0000000000001030
kernel: bond0: (slave eni0np1): making interface the new active one
kernel: #PF: supervisor write access in kernel mode
kernel: #PF: error_code(0x0002) - not-present page
kernel: PGD 0 P4D 0
kernel: Oops: 0002 [#1] PREEMPT SMP
kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12
kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014
kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]
kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA
kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 <83> 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f
kernel: bond0: (slave eni0np1): making interface the new active one
kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246
kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA
kernel:
kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60
kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00
kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014
kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000
kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000
kernel: FS: 00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0
kernel: bond0: (slave eni0np1): making interface the new active one
kernel: Call Trace:
kernel: <TASK>
kernel: ? __die+0x1f/0x60
kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA
kernel: ? page_fault_oops+0x142/0x4c0
kernel: ? do_user_addr_fault+0x65/0x670
kernel: ? kvm_read_and_reset_apf_flags+0x3b/0x50
kernel: bond0: (slave eni0np1): making interface the new active one
kernel: ? exc_page_fault+0x7b/0x180
kernel: ? asm_exc_page_fault+0x22/0x30
kernel: ? nsim_bpf_uninit+0x50/0x50 [netdevsim]
kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA
kernel: ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]
kernel: bond0: (slave eni0np1): making interface the new active one
kernel: bond_ipsec_offload_ok+0x7b/0x90 [bonding]
kernel: xfrm_output+0x61/0x3b0
kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA
kernel: ip_push_pending_frames+0x56/0x80 |
["https://git.kernel.org/stable/c/21816b696c172c19d53a30d45ee005cce246ed21","https://git.kernel.org/stable/c/2f72c6a66bcd7e0187ec085237fee5db27145294","https://git.kernel.org/stable/c/4582d4ff413a07d4ed8a4823c652dc5207760548","https://git.kernel.org/stable/c/7fa9243391ad2afe798ef4ea2e2851947b95754f","https://git.kernel.org/stable/c/89fc1dca79db5c3e7a2d589ecbf8a3661c65f436","https://git.kernel.org/stable/c/f8cde9805981c50d0c029063dc7d82821806fc44"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44990
|
Medium |
fixed |
- 5.10.225
- 5.15.166
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
bonding: fix null pointer deref in bond_ipsec_offload_ok
We must check if there is an active slave before dereferencing the pointer. |
["https://git.kernel.org/stable/c/0707260a18312bbcd2a5668584e3692d0a29e3f6","https://git.kernel.org/stable/c/2f5bdd68c1ce64bda6bef4d361a3de23b04ccd59","https://git.kernel.org/stable/c/32a0173600c63aadaf2103bf02f074982e8602ab","https://git.kernel.org/stable/c/81216b9352be43f8958092d379f6dec85443c309","https://git.kernel.org/stable/c/95c90e4ad89d493a7a14fa200082e466e2548f9d","https://git.kernel.org/stable/c/b70b0ddfed31fc92c8dc722d0afafc8e14cb550c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-45006
|
Medium |
fixed |
- 4.19.321
- 5.4.283
- 5.10.225
- 5.15.166
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration
re-enumerating full-speed devices after a failed address device command
can trigger a NULL pointer dereference.
Full-speed devices may need to reconfigure the endpoint 0 Max Packet Size
value during enumeration. Usb core calls usb_ep0_reinit() in this case,
which ends up calling xhci_configure_endpoint().
On Panther point xHC the xhci_configure_endpoint() function will
additionally check and reserve bandwidth in software. Other hosts do
this in hardware
If xHC address device command fails then a new xhci_virt_device structure
is allocated as part of re-enabling the slot, but the bandwidth table
pointers are not set up properly here.
This triggers the NULL pointer dereference the next time usb_ep0_reinit()
is called and xhci_configure_endpoint() tries to check and reserve
bandwidth
[46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd
[46710.713699] usb 3-1: Device not responding to setup address.
[46710.917684] usb 3-1: Device not responding to setup address.
[46711.125536] usb 3-1: device not accepting address 5, error -71
[46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008
[46711.125600] #PF: supervisor read access in kernel mode
[46711.125603] #PF: error_code(0x0000) - not-present page
[46711.125606] PGD 0 P4D 0
[46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI
[46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1
[46711.125620] Hardware name: Gigabyte Technology Co., Ltd.
[46711.125623] Workqueue: usb_hub_wq hub_event [usbcore]
[46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c
Fix this by making sure bandwidth table pointers are set up correctly
after a failed address device command, and additionally by avoiding
checking for bandwidth in cases like this where no actual endpoints are
added or removed, i.e. only context for default control endpoint 0 is
evaluated. |
["https://git.kernel.org/stable/c/0f0654318e25b2c185e245ba4a591e42fabb5e59","https://git.kernel.org/stable/c/365ef7c4277fdd781a695c3553fa157d622d805d","https://git.kernel.org/stable/c/5ad898ae82412f8a689d59829804bff2999dd0ea","https://git.kernel.org/stable/c/6b99de301d78e1f5249e57ef2c32e1dec3df2bb1","https://git.kernel.org/stable/c/8fb9d412ebe2f245f13481e4624b40e651570cbd","https://git.kernel.org/stable/c/a57b0ebabe6862dce0a2e0f13e17941ad72fc56b","https://git.kernel.org/stable/c/af8e119f52e9c13e556be9e03f27957554a84656","https://git.kernel.org/stable/c/ef0a0e616b2789bb804a0ce5e161db03170a85b6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43829
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/qxl: Add check for drm_cvt_mode
Add check for the return value of drm_cvt_mode() and return the error if
it fails in order to avoid NULL pointer dereference. |
["https://git.kernel.org/stable/c/3efe34f95b1ac8c138a46b14ce75956db0d6ee7c","https://git.kernel.org/stable/c/4b1f303bdeceac049e56e4b20eb5280bd9e02f4f","https://git.kernel.org/stable/c/4e87f592a46bb804d8f833da6ce702ae4b55053f","https://git.kernel.org/stable/c/62ef8d7816c8e4a6088275553818b9afc0ffaa03","https://git.kernel.org/stable/c/7bd09a2db0f617377027a2bb0b9179e6959edff3","https://git.kernel.org/stable/c/d4c57354a06cb4a77998ff8aa40af89eee30e07b","https://git.kernel.org/stable/c/f28b353c0c6c7831a70ccca881bf2db5e6785cdd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43846
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
lib: objagg: Fix general protection fault
The library supports aggregation of objects into other objects only if
the parent object does not have a parent itself. That is, nesting is not
supported.
Aggregation happens in two cases: Without and with hints, where hints
are a pre-computed recommendation on how to aggregate the provided
objects.
Nesting is not possible in the first case due to a check that prevents
it, but in the second case there is no check because the assumption is
that nesting cannot happen when creating objects based on hints. The
violation of this assumption leads to various warnings and eventually to
a general protection fault [1].
Before fixing the root cause, error out when nesting happens and warn.
[1]
general protection fault, probably for non-canonical address 0xdead000000000d90: 0000 [#1] PREEMPT SMP PTI
CPU: 1 PID: 1083 Comm: kworker/1:9 Tainted: G W 6.9.0-rc6-custom-gd9b4f1cca7fb #7
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
RIP: 0010:mlxsw_sp_acl_erp_bf_insert+0x25/0x80
[...]
Call Trace:
<TASK>
mlxsw_sp_acl_atcam_entry_add+0x256/0x3c0
mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0
mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270
mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510
process_one_work+0x151/0x370
worker_thread+0x2cb/0x3e0
kthread+0xd0/0x100
ret_from_fork+0x34/0x50
ret_from_fork_asm+0x1a/0x30
</TASK> |
["https://git.kernel.org/stable/c/1936fa05a180834c3b52e0439a6bddc07814d3eb","https://git.kernel.org/stable/c/22ae17a267f4812861f0c644186c3421ff97dbfc","https://git.kernel.org/stable/c/499f742fed42e74f1321f4b12ca196a66a2b49fc","https://git.kernel.org/stable/c/565213e005557eb6cc4e42189d26eb300e02f170","https://git.kernel.org/stable/c/5adc61d29bbb461d7f7c2b48dceaa90ecd182eb7","https://git.kernel.org/stable/c/8161263362154cbebfbf4808097b956a6a8cb98a","https://git.kernel.org/stable/c/b4a3a89fffcdf09702b1f161b914e52abca1894d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43911
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix NULL dereference at band check in starting tx ba session
In MLD connection, link_data/link_conf are dynamically allocated. They
don't point to vif->bss_conf. So, there will be no chanreq assigned to
vif->bss_conf and then the chan will be NULL. Tweak the code to check
ht_supported/vht_supported/has_he/has_eht on sta deflink.
Crash log (with rtw89 version under MLO development):
[ 9890.526087] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 9890.526102] #PF: supervisor read access in kernel mode
[ 9890.526105] #PF: error_code(0x0000) - not-present page
[ 9890.526109] PGD 0 P4D 0
[ 9890.526114] Oops: 0000 [#1] PREEMPT SMP PTI
[ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: loaded Tainted: G OE 6.9.0 #1
[ 9890.526123] Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018
[ 9890.526126] Workqueue: phy2 rtw89_core_ba_work [rtw89_core]
[ 9890.526203] RIP: 0010:ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211
[ 9890.526279] Code: f7 e8 d5 93 3e ea 48 83 c4 28 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 49 8b 84 24 e0 f1 ff ff 48 8b 80 90 1b 00 00 <83> 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3
All code
========
0: f7 e8 imul %eax
2: d5 (bad)
3: 93 xchg %eax,%ebx
4: 3e ea ds (bad)
6: 48 83 c4 28 add $0x28,%rsp
a: 89 d8 mov %ebx,%eax
c: 5b pop %rbx
d: 41 5c pop %r12
f: 41 5d pop %r13
11: 41 5e pop %r14
13: 41 5f pop %r15
15: 5d pop %rbp
16: c3 retq
17: cc int3
18: cc int3
19: cc int3
1a: cc int3
1b: 49 8b 84 24 e0 f1 ff mov -0xe20(%r12),%rax
22: ff
23: 48 8b 80 90 1b 00 00 mov 0x1b90(%rax),%rax
2a:* 83 38 03 cmpl $0x3,(%rax) <-- trapping instruction
2d: 0f 84 37 fe ff ff je 0xfffffffffffffe6a
33: bb ea ff ff ff mov $0xffffffea,%ebx
38: eb cc jmp 0x6
3a: 49 rex.WB
3b: 8b .byte 0x8b
3c: 84 24 10 test %ah,(%rax,%rdx,1)
3f: f3 repz
Code starting with the faulting instruction
===========================================
0: 83 38 03 cmpl $0x3,(%rax)
3: 0f 84 37 fe ff ff je 0xfffffffffffffe40
9: bb ea ff ff ff mov $0xffffffea,%ebx
e: eb cc jmp 0xffffffffffffffdc
10: 49 rex.WB
11: 8b .byte 0x8b
12: 84 24 10 test %ah,(%rax,%rdx,1)
15: f3 repz
[ 9890.526285] RSP: 0018:ffffb8db09013d68 EFLAGS: 00010246
[ 9890.526291] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9308e0d656c8
[ 9890.526295] RDX: 0000000000000000 RSI: ffffffffab99460b RDI: ffffffffab9a7685
[ 9890.526300] RBP: ffffb8db09013db8 R08: 0000000000000000 R09: 0000000000000873
[ 9890.526304] R10: ffff9308e0d64800 R11: 0000000000000002 R12: ffff9308e5ff6e70
[ 9890.526308] R13: ffff930952500e20 R14: ffff9309192a8c00 R15: 0000000000000000
[ 9890.526313] FS: 0000000000000000(0000) GS:ffff930b4e700000(0000) knlGS:0000000000000000
[ 9890.526316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 9890.526318] CR2: 0000000000000000 CR3: 0000000391c58005 CR4: 00000000001706f0
[ 9890.526321] Call Trace:
[ 9890.526324] <TASK>
[ 9890.526327] ? show_regs (arch/x86/kernel/dumpstack.c:479)
[ 9890.526335] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)
[ 9890.526340] ? page_fault_oops (arch/x86/mm/fault.c:713)
[ 9890.526347] ? search_module_extables (kernel/module/main.c:3256 (discriminator
---truncated--- |
["https://git.kernel.org/stable/c/021d53a3d87eeb9dbba524ac515651242a2a7e3b","https://git.kernel.org/stable/c/0acaf4a5025d6dafb7da787d2d4c47ed95e46ed6","https://git.kernel.org/stable/c/a53c2d847627b790fb3bd8b00e02c247941b17e0","https://git.kernel.org/stable/c/a5594c1e03b0df3908b1e1202a1ba34422eed0f6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43902
|
Medium |
fixed |
- 5.15.165
- 6.1.105
- 6.6.46
- 6.10.5
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add null checker before passing variables
Checks null pointer before passing variables to functions.
This fixes 3 NULL_RETURNS issues reported by Coverity. |
["https://git.kernel.org/stable/c/1686675405d07f35eae7ff3d13a530034b899df2","https://git.kernel.org/stable/c/4cc2a94d96caeb3c975acdae7351c2f997c32175","https://git.kernel.org/stable/c/8092aa3ab8f7b737a34b71f91492c676a843043a","https://git.kernel.org/stable/c/83c7f509ef087041604e9572938f82e18b724c9d","https://git.kernel.org/stable/c/d0b8b23b9c2ebec693a36fea518d8f13493ad655"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43909
|
Medium |
fixed |
- 5.15.165
- 6.1.105
- 6.6.46
- 6.10.5
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/pm: Fix the null pointer dereference for smu7
optimize the code to avoid pass a null pointer (hwmgr->backend)
to function smu7_update_edc_leakage_table. |
["https://git.kernel.org/stable/c/09544cd95c688d3041328a4253bd7514972399bb","https://git.kernel.org/stable/c/1b8aa82b80bd947b68a8ab051d960a0c7935e22d","https://git.kernel.org/stable/c/37b9df457cbcf095963d18f17d6cb7dfa0a03fce","https://git.kernel.org/stable/c/7f56f050f02c27ed89cce1ea0c04b34abce32751","https://git.kernel.org/stable/c/c02c1960c93eede587576625a1221205a68a904f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38570
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix potential glock use-after-free on unmount
When a DLM lockspace is released and there ares still locks in that
lockspace, DLM will unlock those locks automatically. Commit
fb6791d100d1b started exploiting this behavior to speed up filesystem
unmount: gfs2 would simply free glocks it didn't want to unlock and then
release the lockspace. This didn't take the bast callbacks for
asynchronous lock contention notifications into account, which remain
active until until a lock is unlocked or its lockspace is released.
To prevent those callbacks from accessing deallocated objects, put the
glocks that should not be unlocked on the sd_dead_glocks list, release
the lockspace, and only then free those glocks.
As an additional measure, ignore unexpected ast and bast callbacks if
the receiving glock is dead. |
["https://git.kernel.org/stable/c/0636b34b44589b142700ac137b5f69802cfe2e37","https://git.kernel.org/stable/c/501cd8fabf621d10bd4893e37f6ce6c20523c8ca","https://git.kernel.org/stable/c/d98779e687726d8f8860f1c54b5687eec5f63a73","https://git.kernel.org/stable/c/e42e8a24d7f02d28763d16ca7ec5fc6d1f142af0","https://git.kernel.org/stable/c/0636b34b44589b142700ac137b5f69802cfe2e37","https://git.kernel.org/stable/c/501cd8fabf621d10bd4893e37f6ce6c20523c8ca","https://git.kernel.org/stable/c/d98779e687726d8f8860f1c54b5687eec5f63a73","https://git.kernel.org/stable/c/e42e8a24d7f02d28763d16ca7ec5fc6d1f142af0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40954
|
High |
fixed |
- 5.15.162
- 6.1.96
- 6.6.36
- 6.9.7
|
In the Linux kernel, the following vulnerability has been resolved:
net: do not leave a dangling sk pointer, when socket creation fails
It is possible to trigger a use-after-free by:
* attaching an fentry probe to __sock_release() and the probe calling the
bpf_get_socket_cookie() helper
* running traceroute -I 1.1.1.1 on a freshly booted VM
A KASAN enabled kernel will log something like below (decoded and stripped):
==================================================================
BUG: KASAN: slab-use-after-free in __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29)
Read of size 8 at addr ffff888007110dd8 by task traceroute/299
CPU: 2 PID: 299 Comm: traceroute Tainted: G E 6.10.0-rc2+ #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl (lib/dump_stack.c:117 (discriminator 1))
print_report (mm/kasan/report.c:378 mm/kasan/report.c:488)
? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29)
kasan_report (mm/kasan/report.c:603)
? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29)
kasan_check_range (mm/kasan/generic.c:183 mm/kasan/generic.c:189)
__sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29)
bpf_get_socket_ptr_cookie (./arch/x86/include/asm/preempt.h:94 ./include/linux/sock_diag.h:42 net/core/filter.c:5094 net/core/filter.c:5092)
bpf_prog_875642cf11f1d139___sock_release+0x6e/0x8e
bpf_trampoline_6442506592+0x47/0xaf
__sock_release (net/socket.c:652)
__sock_create (net/socket.c:1601)
...
Allocated by task 299 on cpu 2 at 78.328492s:
kasan_save_stack (mm/kasan/common.c:48)
kasan_save_track (mm/kasan/common.c:68)
__kasan_slab_alloc (mm/kasan/common.c:312 mm/kasan/common.c:338)
kmem_cache_alloc_noprof (mm/slub.c:3941 mm/slub.c:4000 mm/slub.c:4007)
sk_prot_alloc (net/core/sock.c:2075)
sk_alloc (net/core/sock.c:2134)
inet_create (net/ipv4/af_inet.c:327 net/ipv4/af_inet.c:252)
__sock_create (net/socket.c:1572)
__sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706)
__x64_sys_socket (net/socket.c:1718)
do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
Freed by task 299 on cpu 2 at 78.328502s:
kasan_save_stack (mm/kasan/common.c:48)
kasan_save_track (mm/kasan/common.c:68)
kasan_save_free_info (mm/kasan/generic.c:582)
poison_slab_object (mm/kasan/common.c:242)
__kasan_slab_free (mm/kasan/common.c:256)
kmem_cache_free (mm/slub.c:4437 mm/slub.c:4511)
__sk_destruct (net/core/sock.c:2117 net/core/sock.c:2208)
inet_create (net/ipv4/af_inet.c:397 net/ipv4/af_inet.c:252)
__sock_create (net/socket.c:1572)
__sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706)
__x64_sys_socket (net/socket.c:1718)
do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
Fix this by clearing the struct socket reference in sk_common_release() to cover
all protocol families create functions, which may already attached the
reference to the sk object with sock_init_data(). |
["https://git.kernel.org/stable/c/454c454ed645fed051216b79622f7cb69c1638f5","https://git.kernel.org/stable/c/5dfe2408fd7dc4d2e7ac38a116ff0a37b1cfd3b9","https://git.kernel.org/stable/c/6cd4a78d962bebbaf8beb7d2ead3f34120e3f7b2","https://git.kernel.org/stable/c/78e4aa528a7b1204219d808310524344f627d069","https://git.kernel.org/stable/c/893eeba94c40d513cd0fe6539330ebdaea208c0e","https://git.kernel.org/stable/c/454c454ed645fed051216b79622f7cb69c1638f5","https://git.kernel.org/stable/c/5dfe2408fd7dc4d2e7ac38a116ff0a37b1cfd3b9","https://git.kernel.org/stable/c/6cd4a78d962bebbaf8beb7d2ead3f34120e3f7b2","https://git.kernel.org/stable/c/78e4aa528a7b1204219d808310524344f627d069","https://git.kernel.org/stable/c/893eeba94c40d513cd0fe6539330ebdaea208c0e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38667
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
riscv: prevent pt_regs corruption for secondary idle threads
Top of the kernel thread stack should be reserved for pt_regs. However
this is not the case for the idle threads of the secondary boot harts.
Their stacks overlap with their pt_regs, so both may get corrupted.
Similar issue has been fixed for the primary hart, see c7cdd96eca28
("riscv: prevent stack corruption by reserving task_pt_regs(p) early").
However that fix was not propagated to the secondary harts. The problem
has been noticed in some CPU hotplug tests with V enabled. The function
smp_callin stored several registers on stack, corrupting top of pt_regs
structure including status field. As a result, kernel attempted to save
or restore inexistent V context. |
["https://git.kernel.org/stable/c/0c1f28c32a194303da630fca89481334b9547b80","https://git.kernel.org/stable/c/3090c06d50eaa91317f84bf3eac4c265e6cb8d44","https://git.kernel.org/stable/c/a638b0461b58aa3205cd9d5f14d6f703d795b4af","https://git.kernel.org/stable/c/ea22d4195cca13d5fdbc4d6555a2dfb8a7867a9e","https://git.kernel.org/stable/c/0c1f28c32a194303da630fca89481334b9547b80","https://git.kernel.org/stable/c/3090c06d50eaa91317f84bf3eac4c265e6cb8d44","https://git.kernel.org/stable/c/a638b0461b58aa3205cd9d5f14d6f703d795b4af","https://git.kernel.org/stable/c/ea22d4195cca13d5fdbc4d6555a2dfb8a7867a9e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44974
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mptcp: pm: avoid possible UaF when selecting endp
select_local_address() and select_signal_address() both select an
endpoint entry from the list inside an RCU protected section, but return
a reference to it, to be read later on. If the entry is dereferenced
after the RCU unlock, reading info could cause a Use-after-Free.
A simple solution is to copy the required info while inside the RCU
protected section to avoid any risk of UaF later. The address ID might
need to be modified later to handle the ID0 case later, so a copy seems
OK to deal with. |
["https://git.kernel.org/stable/c/0201d65d9806d287a00e0ba96f0321835631f63f","https://git.kernel.org/stable/c/2b4f46f9503633dade75cb796dd1949d0e6581a1","https://git.kernel.org/stable/c/48e50dcbcbaaf713d82bf2da5c16aeced94ad07d","https://git.kernel.org/stable/c/9a9afbbc3fbfca4975eea4aa5b18556db5a0c0b8","https://git.kernel.org/stable/c/ddee5b4b6a1cc03c1e9921cf34382e094c2009f1","https://git.kernel.org/stable/c/f2c865e9e3ca44fc06b5f73b29a954775e4dbb38"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50217
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids()
Mounting btrfs from two images (which have the same one fsid and two
different dev_uuids) in certain executing order may trigger an UAF for
variable 'device->bdev_file' in __btrfs_free_extra_devids(). And
following are the details:
1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs
devices by ioctl(BTRFS_IOC_SCAN_DEV):
/ btrfs_device_1 → loop0
fs_device
\ btrfs_device_2 → loop1
2. mount /dev/loop0 /mnt
btrfs_open_devices
btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0)
btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1)
btrfs_fill_super
open_ctree
fail: btrfs_close_devices // -ENOMEM
btrfs_close_bdev(btrfs_device_1)
fput(btrfs_device_1->bdev_file)
// btrfs_device_1->bdev_file is freed
btrfs_close_bdev(btrfs_device_2)
fput(btrfs_device_2->bdev_file)
3. mount /dev/loop1 /mnt
btrfs_open_devices
btrfs_get_bdev_and_sb(&bdev_file)
// EIO, btrfs_device_1->bdev_file is not assigned,
// which points to a freed memory area
btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1)
btrfs_fill_super
open_ctree
btrfs_free_extra_devids
if (btrfs_device_1->bdev_file)
fput(btrfs_device_1->bdev_file) // UAF !
Fix it by setting 'device->bdev_file' as 'NULL' after closing the
btrfs_device in btrfs_close_one_device(). |
["https://git.kernel.org/stable/c/47a83f8df39545f3f552bb6a1b6d9c30e37621dd","https://git.kernel.org/stable/c/aec8e6bf839101784f3ef037dcdb9432c3f32343","http://www.openwall.com/lists/oss-security/2025/04/10/4","http://www.openwall.com/lists/oss-security/2025/04/10/5","http://www.openwall.com/lists/oss-security/2025/04/10/6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3623
|
High |
fixed |
- 5.4.228
- 5.10.159
- 5.15.78
- 5.19.17
- 6.0.3
|
A vulnerability was found in Linux Kernel. It has been declared as problematic. Affected by this vulnerability is the function follow_page_pte of the file mm/gup.c of the component BPF. The manipulation leads to race condition. The attack can be launched remotely. It is recommended to apply a patch to fix this issue. The identifier VDB-211921 was assigned to this vulnerability. |
["https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=fac35ba763ed07ba93154c95ffc0c4a55023707f","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://vuldb.com/?id.211921","https://www.debian.org/security/2023/dsa-5324","https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=fac35ba763ed07ba93154c95ffc0c4a55023707f","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://vuldb.com/?id.211921","https://www.debian.org/security/2023/dsa-5324"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48660
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
gpiolib: cdev: Set lineevent_state::irq after IRQ register successfully
When running gpio test on nxp-ls1028 platform with below command
gpiomon --num-events=3 --rising-edge gpiochip1 25
There will be a warning trace as below:
Call trace:
free_irq+0x204/0x360
lineevent_free+0x64/0x70
gpio_ioctl+0x598/0x6a0
__arm64_sys_ioctl+0xb4/0x100
invoke_syscall+0x5c/0x130
......
el0t_64_sync+0x1a0/0x1a4
The reason of this issue is that calling request_threaded_irq()
function failed, and then lineevent_free() is invoked to release
the resource. Since the lineevent_state::irq was already set, so
the subsequent invocation of free_irq() would trigger the above
warning call trace. To fix this issue, set the lineevent_state::irq
after the IRQ register successfully. |
["https://git.kernel.org/stable/c/657803b918e097e47d99d1489da83a603c36bcdd","https://git.kernel.org/stable/c/69bef19d6b9700e96285f4b4e28691cda3dcd0d1","https://git.kernel.org/stable/c/97da736cd11ae73bdf2f5e21e24446b8349e0168","https://git.kernel.org/stable/c/b1489043d3b9004dd8d5a0357b08b5f0e6691c43","https://git.kernel.org/stable/c/657803b918e097e47d99d1489da83a603c36bcdd","https://git.kernel.org/stable/c/69bef19d6b9700e96285f4b4e28691cda3dcd0d1","https://git.kernel.org/stable/c/97da736cd11ae73bdf2f5e21e24446b8349e0168","https://git.kernel.org/stable/c/b1489043d3b9004dd8d5a0357b08b5f0e6691c43"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43853
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
cgroup/cpuset: Prevent UAF in proc_cpuset_show()
An UAF can happen when /proc/cpuset is read as reported in [1].
This can be reproduced by the following methods:
1.add an mdelay(1000) before acquiring the cgroup_lock In the
cgroup_path_ns function.
2.$cat /proc/<pid>/cpuset repeatly.
3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/
$umount /sys/fs/cgroup/cpuset/ repeatly.
The race that cause this bug can be shown as below:
(umount) | (cat /proc/<pid>/cpuset)
css_release | proc_cpuset_show
css_release_work_fn | css = task_get_css(tsk, cpuset_cgrp_id);
css_free_rwork_fn | cgroup_path_ns(css->cgroup, ...);
cgroup_destroy_root | mutex_lock(&cgroup_mutex);
rebind_subsystems |
cgroup_free_root |
| // cgrp was freed, UAF
| cgroup_path_ns_locked(cgrp,..);
When the cpuset is initialized, the root node top_cpuset.css.cgrp
will point to &cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will
allocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated
&cgroup_root.cgrp. When the umount operation is executed,
top_cpuset.css.cgrp will be rebound to &cgrp_dfl_root.cgrp.
The problem is that when rebinding to cgrp_dfl_root, there are cases
where the cgroup_root allocated by setting up the root for cgroup v1
is cached. This could lead to a Use-After-Free (UAF) if it is
subsequently freed. The descendant cgroups of cgroup v1 can only be
freed after the css is released. However, the css of the root will never
be released, yet the cgroup_root should be freed when it is unmounted.
This means that obtaining a reference to the css of the root does
not guarantee that css.cgrp->root will not be freed.
Fix this problem by using rcu_read_lock in proc_cpuset_show().
As cgroup_root is kfree_rcu after commit d23b5c577715
("cgroup: Make operations on the cgroup root_list RCU safe"),
css->cgroup won't be freed during the critical section.
To call cgroup_path_ns_locked, css_set_lock is needed, so it is safe to
replace task_get_css with task_css.
[1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd |
["https://git.kernel.org/stable/c/10aeaa47e4aa2432f29b3e5376df96d7dac5537a","https://git.kernel.org/stable/c/1be59c97c83ccd67a519d8a49486b3a8a73ca28a","https://git.kernel.org/stable/c/27d6dbdc6485d68075a0ebf8544d6425c1ed84bb","https://git.kernel.org/stable/c/29a8d4e02fd4840028c38ceb1536cc8f82a257d4","https://git.kernel.org/stable/c/29ac1d238b3bf126af36037df80d7ecc4822341e","https://git.kernel.org/stable/c/4e8d6ac8fc9f843e940ab7389db8136634e07989","https://git.kernel.org/stable/c/688325078a8b5badd6e07ae22b27cd04e9947aec","https://git.kernel.org/stable/c/96226fbed566f3f686f53a489a29846f2d538080"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35940
|
Medium |
fixed |
- 5.10.215
- 5.15.155
- 6.1.86
- 6.6.27
- 6.8.6
|
In the Linux kernel, the following vulnerability has been resolved:
pstore/zone: Add a null pointer check to the psz_kmsg_read
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity. |
["https://git.kernel.org/stable/c/0ff96ec22a84d80a18d7ae8ca7eb111c34ee33bb","https://git.kernel.org/stable/c/635594cca59f9d7a8e96187600c34facb8bc0682","https://git.kernel.org/stable/c/6f9f2e498eae7897ba5d3e33908917f68ff4abcc","https://git.kernel.org/stable/c/98bc7e26e14fbb26a6abf97603d59532475e97f8","https://git.kernel.org/stable/c/98e2b97acb875d65bdfc75fc408e67975cef3041","https://git.kernel.org/stable/c/ec7256887d072f98c42cdbef4dcc80ddf84c7a70","https://git.kernel.org/stable/c/0ff96ec22a84d80a18d7ae8ca7eb111c34ee33bb","https://git.kernel.org/stable/c/635594cca59f9d7a8e96187600c34facb8bc0682","https://git.kernel.org/stable/c/6f9f2e498eae7897ba5d3e33908917f68ff4abcc","https://git.kernel.org/stable/c/98bc7e26e14fbb26a6abf97603d59532475e97f8","https://git.kernel.org/stable/c/98e2b97acb875d65bdfc75fc408e67975cef3041","https://git.kernel.org/stable/c/ec7256887d072f98c42cdbef4dcc80ddf84c7a70","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40905
|
Medium |
fixed |
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.95
- 6.6.35
- 6.9.6
|
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix possible race in __fib6_drop_pcpu_from()
syzbot found a race in __fib6_drop_pcpu_from() [1]
If compiler reads more than once (*ppcpu_rt),
second read could read NULL, if another cpu clears
the value in rt6_get_pcpu_route().
Add a READ_ONCE() to prevent this race.
Also add rcu_read_lock()/rcu_read_unlock() because
we rely on RCU protection while dereferencing pcpu_rt.
[1]
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]
CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Workqueue: netns cleanup_net
RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984
Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48
RSP: 0018:ffffc900040df070 EFLAGS: 00010206
RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16
RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091
RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007
R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8
R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
__fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline]
fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline]
fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038
fib6_del_route net/ipv6/ip6_fib.c:1998 [inline]
fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043
fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205
fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127
fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175
fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255
__fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271
rt6_sync_down_dev net/ipv6/route.c:4906 [inline]
rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911
addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855
addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778
notifier_call_chain+0xb9/0x410 kernel/notifier.c:93
call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992
call_netdevice_notifiers_extack net/core/dev.c:2030 [inline]
call_netdevice_notifiers net/core/dev.c:2044 [inline]
dev_close_many+0x333/0x6a0 net/core/dev.c:1585
unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193
unregister_netdevice_many net/core/dev.c:11276 [inline]
default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759
ops_exit_list+0x128/0x180 net/core/net_namespace.c:178
cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640
process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
process_scheduled_works kernel/workqueue.c:3312 [inline]
worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393
kthread+0x2c1/0x3a0 kernel/kthread.c:389
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 |
["https://git.kernel.org/stable/c/09e5a5a80e205922151136069e440477d6816914","https://git.kernel.org/stable/c/2498960dac9b6fc49b6d1574f7cd1a4872744adf","https://git.kernel.org/stable/c/7e796c3fefa8b17b30e7252886ae8cffacd2b9ef","https://git.kernel.org/stable/c/a0bc020592b54a8f3fa2b7f244b6e39e526c2e12","https://git.kernel.org/stable/c/b01e1c030770ff3b4fe37fc7cc6bca03f594133f","https://git.kernel.org/stable/c/c693698787660c97950bc1f93a8dd19d8307153d","https://git.kernel.org/stable/c/c90af1cced2f669a7b2304584be4ada495eaa0e5","https://git.kernel.org/stable/c/09e5a5a80e205922151136069e440477d6816914","https://git.kernel.org/stable/c/2498960dac9b6fc49b6d1574f7cd1a4872744adf","https://git.kernel.org/stable/c/7e796c3fefa8b17b30e7252886ae8cffacd2b9ef","https://git.kernel.org/stable/c/a0bc020592b54a8f3fa2b7f244b6e39e526c2e12","https://git.kernel.org/stable/c/b01e1c030770ff3b4fe37fc7cc6bca03f594133f","https://git.kernel.org/stable/c/c693698787660c97950bc1f93a8dd19d8307153d","https://git.kernel.org/stable/c/c90af1cced2f669a7b2304584be4ada495eaa0e5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42152
|
Medium |
fixed |
- 5.10.222
- 5.15.163
- 6.1.98
- 6.6.39
- 6.9.9
|
In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix a possible leak when destroy a ctrl during qp establishment
In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we
know that a ctrl was allocated (in the admin connect request handler)
and we need to release pending AERs, clear ctrl->sqs and sq->ctrl
(for nvme-loop primarily), and drop the final reference on the ctrl.
However, a small window is possible where nvmet_sq_destroy starts (as
a result of the client giving up and disconnecting) concurrently with
the nvme admin connect cmd (which may be in an early stage). But *before*
kill_and_confirm of sq->ref (i.e. the admin connect managed to get an sq
live reference). In this case, sq->ctrl was allocated however after it was
captured in a local variable in nvmet_sq_destroy.
This prevented the final reference drop on the ctrl.
Solve this by re-capturing the sq->ctrl after all inflight request has
completed, where for sure sq->ctrl reference is final, and move forward
based on that.
This issue was observed in an environment with many hosts connecting
multiple ctrls simoutanuosly, creating a delay in allocating a ctrl
leading up to this race window. |
["https://git.kernel.org/stable/c/2f3c22b1d3d7e86712253244797a651998c141fa","https://git.kernel.org/stable/c/5502c1f1d0d7472706cc1f201aecf1c935d302d1","https://git.kernel.org/stable/c/818004f2a380420c19872171be716174d4985e33","https://git.kernel.org/stable/c/940a71f08ef153ef807f751310b0648d1fa5d0da","https://git.kernel.org/stable/c/b4fed1443a6571d49c6ffe7d97af3bbe5ee6dff5","https://git.kernel.org/stable/c/c758b77d4a0a0ed3a1292b3fd7a2aeccd1a169a4","https://git.kernel.org/stable/c/2f3c22b1d3d7e86712253244797a651998c141fa","https://git.kernel.org/stable/c/5502c1f1d0d7472706cc1f201aecf1c935d302d1","https://git.kernel.org/stable/c/818004f2a380420c19872171be716174d4985e33","https://git.kernel.org/stable/c/940a71f08ef153ef807f751310b0648d1fa5d0da","https://git.kernel.org/stable/c/b4fed1443a6571d49c6ffe7d97af3bbe5ee6dff5","https://git.kernel.org/stable/c/c758b77d4a0a0ed3a1292b3fd7a2aeccd1a169a4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3435
|
Medium |
|
N/A
|
A vulnerability classified as problematic has been found in Linux Kernel. This affects the function fib_nh_match of the file net/ipv4/fib_semantics.c of the component IPv4 Handler. The manipulation leads to out-of-bounds read. It is possible to initiate the attack remotely. It is recommended to apply a patch to fix this issue. The identifier VDB-210357 was assigned to this vulnerability. |
["https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://lore.kernel.org/netdev/20221005181257.8897-1-dsahern%40kernel.org/T/#u","https://vuldb.com/?id.210357","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://lore.kernel.org/netdev/20221005181257.8897-1-dsahern%40kernel.org/T/#u","https://vuldb.com/?id.210357"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35855
|
High |
fixed |
- 5.4.275
- 5.10.216
- 5.15.158
- 6.1.90
- 6.6.30
- 6.8.9
|
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update
The rule activity update delayed work periodically traverses the list of
configured rules and queries their activity from the device.
As part of this task it accesses the entry pointed by 'ventry->entry',
but this entry can be changed concurrently by the rehash delayed work,
leading to a use-after-free [1].
Fix by closing the race and perform the activity query under the
'vregion->lock' mutex.
[1]
BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140
Read of size 8 at addr ffff8881054ed808 by task kworker/0:18/181
CPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_work
Call Trace:
<TASK>
dump_stack_lvl+0xc6/0x120
print_report+0xce/0x670
kasan_report+0xd7/0x110
mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140
mlxsw_sp_acl_rule_activity_update_work+0x219/0x400
process_one_work+0x8eb/0x19b0
worker_thread+0x6c9/0xf70
kthread+0x2c9/0x3b0
ret_from_fork+0x4d/0x80
ret_from_fork_asm+0x1a/0x30
</TASK>
Allocated by task 1039:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
__kasan_kmalloc+0x8f/0xa0
__kmalloc+0x19c/0x360
mlxsw_sp_acl_tcam_entry_create+0x7b/0x1f0
mlxsw_sp_acl_tcam_vchunk_migrate_all+0x30d/0xb50
mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300
process_one_work+0x8eb/0x19b0
worker_thread+0x6c9/0xf70
kthread+0x2c9/0x3b0
ret_from_fork+0x4d/0x80
ret_from_fork_asm+0x1a/0x30
Freed by task 1039:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x60
poison_slab_object+0x102/0x170
__kasan_slab_free+0x14/0x30
kfree+0xc1/0x290
mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3d7/0xb50
mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300
process_one_work+0x8eb/0x19b0
worker_thread+0x6c9/0xf70
kthread+0x2c9/0x3b0
ret_from_fork+0x4d/0x80
ret_from_fork_asm+0x1a/0x30 |
["https://git.kernel.org/stable/c/1b73f6e4ea770410a937a8db98f77e52594d23a0","https://git.kernel.org/stable/c/79b5b4b18bc85b19d3a518483f9abbbe6d7b3ba4","https://git.kernel.org/stable/c/b183b915beef818a25e3154d719ca015a1ae0770","https://git.kernel.org/stable/c/b996e8699da810e4c915841d6aaef761007f933a","https://git.kernel.org/stable/c/c17976b42d546ee118ca300db559630ee96fb758","https://git.kernel.org/stable/c/e24d2487424779c02760ff50cd9021b8676e19ef","https://git.kernel.org/stable/c/feabdac2057e863d0e140a2adf3d232eb4882db4","https://git.kernel.org/stable/c/1b73f6e4ea770410a937a8db98f77e52594d23a0","https://git.kernel.org/stable/c/79b5b4b18bc85b19d3a518483f9abbbe6d7b3ba4","https://git.kernel.org/stable/c/b183b915beef818a25e3154d719ca015a1ae0770","https://git.kernel.org/stable/c/b996e8699da810e4c915841d6aaef761007f933a","https://git.kernel.org/stable/c/c17976b42d546ee118ca300db559630ee96fb758","https://git.kernel.org/stable/c/e24d2487424779c02760ff50cd9021b8676e19ef","https://git.kernel.org/stable/c/feabdac2057e863d0e140a2adf3d232eb4882db4","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27024
|
High |
fixed |
- 3.19
- 4.2
- 4.5
- 4.10
- 4.19.310
- 5.4.272
- 5.10.213
- 5.15.152
- 6.1.82
- 6.6.22
- 6.7.10
|
In the Linux kernel, the following vulnerability has been resolved:
net/rds: fix WARNING in rds_conn_connect_if_down
If connection isn't established yet, get_mr() will fail, trigger connection after
get_mr(). |
["https://git.kernel.org/stable/c/2b505d05280739ce31d5708da840f42df827cb85","https://git.kernel.org/stable/c/786854141057751bc08eb26f1b02e97c1631c8f4","https://git.kernel.org/stable/c/907761307469adecb02461a14120e9a1812a5fb1","https://git.kernel.org/stable/c/997efea2bf3a4adb96c306b9ad6a91442237bf5b","https://git.kernel.org/stable/c/998fd719e6d6468b930ac0c44552ea9ff8b07b80","https://git.kernel.org/stable/c/9dfc15a10dfd44f8ff7f27488651cb5be6af83c2","https://git.kernel.org/stable/c/b562ebe21ed9adcf42242797dd6cb75beef12bf0","https://git.kernel.org/stable/c/c055fc00c07be1f0df7375ab0036cebd1106ed38","https://git.kernel.org/stable/c/2b505d05280739ce31d5708da840f42df827cb85","https://git.kernel.org/stable/c/786854141057751bc08eb26f1b02e97c1631c8f4","https://git.kernel.org/stable/c/907761307469adecb02461a14120e9a1812a5fb1","https://git.kernel.org/stable/c/997efea2bf3a4adb96c306b9ad6a91442237bf5b","https://git.kernel.org/stable/c/998fd719e6d6468b930ac0c44552ea9ff8b07b80","https://git.kernel.org/stable/c/9dfc15a10dfd44f8ff7f27488651cb5be6af83c2","https://git.kernel.org/stable/c/b562ebe21ed9adcf42242797dd6cb75beef12bf0","https://git.kernel.org/stable/c/c055fc00c07be1f0df7375ab0036cebd1106ed38","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46800
|
High |
fixed |
- 4.19.322
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
sch/netem: fix use after free in netem_dequeue
If netem_dequeue() enqueues packet to inner qdisc and that qdisc
returns __NET_XMIT_STOLEN. The packet is dropped but
qdisc_tree_reduce_backlog() is not called to update the parent's
q.qlen, leading to the similar use-after-free as Commit
e04991a48dbaf382 ("netem: fix return value if duplicate enqueue
fails")
Commands to trigger KASAN UaF:
ip link add type dummy
ip link set lo up
ip link set dummy0 up
tc qdisc add dev lo parent root handle 1: drr
tc filter add dev lo parent 1: basic classid 1:1
tc class add dev lo classid 1:1 drr
tc qdisc add dev lo parent 1:1 handle 2: netem
tc qdisc add dev lo parent 2: handle 3: drr
tc filter add dev lo parent 3: basic classid 3:1 action mirred egress
redirect dev dummy0
tc class add dev lo classid 3:1 drr
ping -c1 -W0.01 localhost # Trigger bug
tc class del dev lo classid 1:1
tc class add dev lo classid 1:1 drr
ping -c1 -W0.01 localhost # UaF |
["https://git.kernel.org/stable/c/14f91ab8d391f249b845916820a56f42cf747241","https://git.kernel.org/stable/c/295ad5afd9efc5f67b86c64fce28fb94e26dc4c9","https://git.kernel.org/stable/c/32008ab989ddcff1a485fa2b4906234c25dc5cd6","https://git.kernel.org/stable/c/3b3a2a9c6349e25a025d2330f479bc33a6ccb54a","https://git.kernel.org/stable/c/98c75d76187944296068d685dfd8a1e9fd8c4fdc","https://git.kernel.org/stable/c/db2c235682913a63054e741fe4e19645fdf2d68e","https://git.kernel.org/stable/c/dde33a9d0b80aae0c69594d1f462515d7ff1cb3d","https://git.kernel.org/stable/c/f0bddb4de043399f16d1969dad5ee5b984a64e7b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46853
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
spi: nxp-fspi: fix the KASAN report out-of-bounds bug
Change the memcpy length to fix the out-of-bounds issue when writing the
data that is not 4 byte aligned to TX FIFO.
To reproduce the issue, write 3 bytes data to NOR chip.
dd if=3b of=/dev/mtd0
[ 36.926103] ==================================================================
[ 36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838
[ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455
[ 36.946721]
[ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070
[ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT)
[ 36.961260] Call trace:
[ 36.963723] dump_backtrace+0x90/0xe8
[ 36.967414] show_stack+0x18/0x24
[ 36.970749] dump_stack_lvl+0x78/0x90
[ 36.974451] print_report+0x114/0x5cc
[ 36.978151] kasan_report+0xa4/0xf0
[ 36.981670] __asan_report_load_n_noabort+0x1c/0x28
[ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838
[ 36.990800] spi_mem_exec_op+0x8ec/0xd30
[ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0
[ 36.999323] spi_mem_dirmap_write+0x238/0x32c
[ 37.003710] spi_nor_write_data+0x220/0x374
[ 37.007932] spi_nor_write+0x110/0x2e8
[ 37.011711] mtd_write_oob_std+0x154/0x1f0
[ 37.015838] mtd_write_oob+0x104/0x1d0
[ 37.019617] mtd_write+0xb8/0x12c
[ 37.022953] mtdchar_write+0x224/0x47c
[ 37.026732] vfs_write+0x1e4/0x8c8
[ 37.030163] ksys_write+0xec/0x1d0
[ 37.033586] __arm64_sys_write+0x6c/0x9c
[ 37.037539] invoke_syscall+0x6c/0x258
[ 37.041327] el0_svc_common.constprop.0+0x160/0x22c
[ 37.046244] do_el0_svc+0x44/0x5c
[ 37.049589] el0_svc+0x38/0x78
[ 37.052681] el0t_64_sync_handler+0x13c/0x158
[ 37.057077] el0t_64_sync+0x190/0x194
[ 37.060775]
[ 37.062274] Allocated by task 455:
[ 37.065701] kasan_save_stack+0x2c/0x54
[ 37.069570] kasan_save_track+0x20/0x3c
[ 37.073438] kasan_save_alloc_info+0x40/0x54
[ 37.077736] __kasan_kmalloc+0xa0/0xb8
[ 37.081515] __kmalloc_noprof+0x158/0x2f8
[ 37.085563] mtd_kmalloc_up_to+0x120/0x154
[ 37.089690] mtdchar_write+0x130/0x47c
[ 37.093469] vfs_write+0x1e4/0x8c8
[ 37.096901] ksys_write+0xec/0x1d0
[ 37.100332] __arm64_sys_write+0x6c/0x9c
[ 37.104287] invoke_syscall+0x6c/0x258
[ 37.108064] el0_svc_common.constprop.0+0x160/0x22c
[ 37.112972] do_el0_svc+0x44/0x5c
[ 37.116319] el0_svc+0x38/0x78
[ 37.119401] el0t_64_sync_handler+0x13c/0x158
[ 37.123788] el0t_64_sync+0x190/0x194
[ 37.127474]
[ 37.128977] The buggy address belongs to the object at ffff00081037c2a0
[ 37.128977] which belongs to the cache kmalloc-8 of size 8
[ 37.141177] The buggy address is located 0 bytes inside of
[ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3)
[ 37.153465]
[ 37.154971] The buggy address belongs to the physical page:
[ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c
[ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff)
[ 37.175149] page_type: 0xfdffffff(slab)
[ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000
[ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000
[ 37.194553] page dumped because: kasan: bad access detected
[ 37.200144]
[ 37.201647] Memory state around the buggy address:
[ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc
[ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc
[ 37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc
[ 37.228186] ^
[ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 37.246962] ==============================================================
---truncated--- |
["https://git.kernel.org/stable/c/09af8b0ba70072be831f3ec459f4063d570f9e24","https://git.kernel.org/stable/c/2a8787c1cdc7be24fdd8953ecd1a8743a1006235","https://git.kernel.org/stable/c/491f9646f7ac31af5fca71be1a3e5eb8aa7663ad","https://git.kernel.org/stable/c/609260542cf86b459c57618b8cdec8020394b7ad","https://git.kernel.org/stable/c/aa05db44db5f409f6d91c27b5737efb49fb45d9f","https://git.kernel.org/stable/c/af9ca9ca3e44f48b2a191e100d452fbf850c3d87","https://git.kernel.org/stable/c/d1a1dfcec77c57b1181da93d11a3db1bc4eefa97"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40958
|
High |
fixed |
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.96
- 6.6.36
- 6.9.7
|
In the Linux kernel, the following vulnerability has been resolved:
netns: Make get_net_ns() handle zero refcount net
Syzkaller hit a warning:
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 3 PID: 7890 at lib/refcount.c:25 refcount_warn_saturate+0xdf/0x1d0
Modules linked in:
CPU: 3 PID: 7890 Comm: tun Not tainted 6.10.0-rc3-00100-gcaa4f9578aba-dirty #310
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:refcount_warn_saturate+0xdf/0x1d0
Code: 41 49 04 31 ff 89 de e8 9f 1e cd fe 84 db 75 9c e8 76 26 cd fe c6 05 b6 41 49 04 01 90 48 c7 c7 b8 8e 25 86 e8 d2 05 b5 fe 90 <0f> 0b 90 90 e9 79 ff ff ff e8 53 26 cd fe 0f b6 1
RSP: 0018:ffff8881067b7da0 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c72ac
RDX: ffff8881026a2140 RSI: ffffffff811c72b5 RDI: 0000000000000001
RBP: ffff8881067b7db0 R08: 0000000000000000 R09: 205b5d3730353139
R10: 0000000000000000 R11: 205d303938375420 R12: ffff8881086500c4
R13: ffff8881086500c4 R14: ffff8881086500b0 R15: ffff888108650040
FS: 00007f5b2961a4c0(0000) GS:ffff88823bd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055d7ed36fd18 CR3: 00000001482f6000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
? show_regs+0xa3/0xc0
? __warn+0xa5/0x1c0
? refcount_warn_saturate+0xdf/0x1d0
? report_bug+0x1fc/0x2d0
? refcount_warn_saturate+0xdf/0x1d0
? handle_bug+0xa1/0x110
? exc_invalid_op+0x3c/0xb0
? asm_exc_invalid_op+0x1f/0x30
? __warn_printk+0xcc/0x140
? __warn_printk+0xd5/0x140
? refcount_warn_saturate+0xdf/0x1d0
get_net_ns+0xa4/0xc0
? __pfx_get_net_ns+0x10/0x10
open_related_ns+0x5a/0x130
__tun_chr_ioctl+0x1616/0x2370
? __sanitizer_cov_trace_switch+0x58/0xa0
? __sanitizer_cov_trace_const_cmp2+0x1c/0x30
? __pfx_tun_chr_ioctl+0x10/0x10
tun_chr_ioctl+0x2f/0x40
__x64_sys_ioctl+0x11b/0x160
x64_sys_call+0x1211/0x20d0
do_syscall_64+0x9e/0x1d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f5b28f165d7
Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 8
RSP: 002b:00007ffc2b59c5e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5b28f165d7
RDX: 0000000000000000 RSI: 00000000000054e3 RDI: 0000000000000003
RBP: 00007ffc2b59c650 R08: 00007f5b291ed8c0 R09: 00007f5b2961a4c0
R10: 0000000029690010 R11: 0000000000000246 R12: 0000000000400730
R13: 00007ffc2b59cf40 R14: 0000000000000000 R15: 0000000000000000
</TASK>
Kernel panic - not syncing: kernel: panic_on_warn set ...
This is trigger as below:
ns0 ns1
tun_set_iff() //dev is tun0
tun->dev = dev
//ip link set tun0 netns ns1
put_net() //ref is 0
__tun_chr_ioctl() //TUNGETDEVNETNS
net = dev_net(tun->dev);
open_related_ns(&net->ns, get_net_ns); //ns1
get_net_ns()
get_net() //addition on 0
Use maybe_get_net() in get_net_ns in case net's ref is zero to fix this |
["https://git.kernel.org/stable/c/1b631bffcb2c09551888f3c723f4365c91fe05ef","https://git.kernel.org/stable/c/2b82028a1f5ee3a8e04090776b10c534144ae77b","https://git.kernel.org/stable/c/3a6cd326ead7c8bb1f64486789a01974a9f1ad55","https://git.kernel.org/stable/c/3af28df0d883e8c89a29ac31bc65f9023485743b","https://git.kernel.org/stable/c/cb7f811f638a14590ff98f53c6dd1fb54627d940","https://git.kernel.org/stable/c/ef0394ca25953ea0eddcc82feae1f750451f1876","https://git.kernel.org/stable/c/ff960f9d3edbe08a736b5a224d91a305ccc946b0","https://git.kernel.org/stable/c/1b631bffcb2c09551888f3c723f4365c91fe05ef","https://git.kernel.org/stable/c/2b82028a1f5ee3a8e04090776b10c534144ae77b","https://git.kernel.org/stable/c/3a6cd326ead7c8bb1f64486789a01974a9f1ad55","https://git.kernel.org/stable/c/3af28df0d883e8c89a29ac31bc65f9023485743b","https://git.kernel.org/stable/c/cb7f811f638a14590ff98f53c6dd1fb54627d940","https://git.kernel.org/stable/c/ef0394ca25953ea0eddcc82feae1f750451f1876","https://git.kernel.org/stable/c/ff960f9d3edbe08a736b5a224d91a305ccc946b0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38546
|
Medium |
fixed |
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm: vc4: Fix possible null pointer dereference
In vc4_hdmi_audio_init() of_get_address() may return
NULL which is later dereferenced. Fix this bug by adding NULL check.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/2a345fe928c21de6f3c3c7230ff509d715153a31","https://git.kernel.org/stable/c/2d9adecc88ab678785b581ab021f039372c324cb","https://git.kernel.org/stable/c/42c22b63056cea259d5313bf138a834840af85a5","https://git.kernel.org/stable/c/6cf1874aec42058a5ad621a23b5b2f248def0e96","https://git.kernel.org/stable/c/80431ea3634efb47a3004305d76486db9dd8ed49","https://git.kernel.org/stable/c/bd7827d46d403f8cdb43d16744cb1114e4726b21","https://git.kernel.org/stable/c/c534b63bede6cb987c2946ed4d0b0013a52c5ba7","https://git.kernel.org/stable/c/2a345fe928c21de6f3c3c7230ff509d715153a31","https://git.kernel.org/stable/c/2d9adecc88ab678785b581ab021f039372c324cb","https://git.kernel.org/stable/c/42c22b63056cea259d5313bf138a834840af85a5","https://git.kernel.org/stable/c/6cf1874aec42058a5ad621a23b5b2f248def0e96","https://git.kernel.org/stable/c/80431ea3634efb47a3004305d76486db9dd8ed49","https://git.kernel.org/stable/c/bd7827d46d403f8cdb43d16744cb1114e4726b21","https://git.kernel.org/stable/c/c534b63bede6cb987c2946ed4d0b0013a52c5ba7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38548
|
Medium |
fixed |
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference
In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is
assigned to mhdp_state->current_mode, and there is a dereference of it in
drm_mode_set_name(), which will lead to a NULL pointer dereference on
failure of drm_mode_duplicate().
Fix this bug add a check of mhdp_state->current_mode. |
["https://git.kernel.org/stable/c/32fb2ef124c3301656ac6c789a2ef35ef69a66da","https://git.kernel.org/stable/c/47889711da20be9b43e1e136e5cb68df37cbcc79","https://git.kernel.org/stable/c/85d1a27402f81f2e04b0e67d20f749c2a14edbb3","https://git.kernel.org/stable/c/89788cd9824c28ffcdea40232c458233353d1896","https://git.kernel.org/stable/c/935a92a1c400285545198ca2800a4c6c519c650a","https://git.kernel.org/stable/c/ca53b7efd4ba6ae92fd2b3085cb099c745e96965","https://git.kernel.org/stable/c/dcf53e6103b26e7458be71491d0641f49fbd5840","https://git.kernel.org/stable/c/32fb2ef124c3301656ac6c789a2ef35ef69a66da","https://git.kernel.org/stable/c/47889711da20be9b43e1e136e5cb68df37cbcc79","https://git.kernel.org/stable/c/85d1a27402f81f2e04b0e67d20f749c2a14edbb3","https://git.kernel.org/stable/c/89788cd9824c28ffcdea40232c458233353d1896","https://git.kernel.org/stable/c/935a92a1c400285545198ca2800a4c6c519c650a","https://git.kernel.org/stable/c/ca53b7efd4ba6ae92fd2b3085cb099c745e96965","https://git.kernel.org/stable/c/dcf53e6103b26e7458be71491d0641f49fbd5840"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42122
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add NULL pointer check for kzalloc
[Why & How]
Check return pointer of kzalloc before using it. |
["https://git.kernel.org/stable/c/062edd612fcd300f0f79a36fca5b8b6a5e2fce70","https://git.kernel.org/stable/c/552e7938b4d7fe548fbf29b9950a14c6149d0470","https://git.kernel.org/stable/c/8e65a1b7118acf6af96449e1e66b7adbc9396912","https://git.kernel.org/stable/c/cd1e565a5b7fa60c349ca8a16db1e61715fe8230","https://git.kernel.org/stable/c/062edd612fcd300f0f79a36fca5b8b6a5e2fce70","https://git.kernel.org/stable/c/8e65a1b7118acf6af96449e1e66b7adbc9396912"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39507
|
Medium |
fixed |
- 5.15.162
- 6.1.95
- 6.6.35
- 6.9.6
|
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix kernel crash problem in concurrent scenario
When link status change, the nic driver need to notify the roce
driver to handle this event, but at this time, the roce driver
may uninit, then cause kernel crash.
To fix the problem, when link status change, need to check
whether the roce registered, and when uninit, need to wait link
update finish. |
["https://git.kernel.org/stable/c/12cda920212a49fa22d9e8b9492ac4ea013310a4","https://git.kernel.org/stable/c/62b5dfb67bfa8bd0301bf3442004563495f9ee48","https://git.kernel.org/stable/c/689de7c3bfc7d47e0eacc641c4ce4a0f579aeefa","https://git.kernel.org/stable/c/6d0007f7b69d684879a0f598a042e40244d3cf63","https://git.kernel.org/stable/c/b2c5024b771cd1dd8175d5f6949accfadbab7edd","https://git.kernel.org/stable/c/12cda920212a49fa22d9e8b9492ac4ea013310a4","https://git.kernel.org/stable/c/62b5dfb67bfa8bd0301bf3442004563495f9ee48","https://git.kernel.org/stable/c/689de7c3bfc7d47e0eacc641c4ce4a0f579aeefa","https://git.kernel.org/stable/c/6d0007f7b69d684879a0f598a042e40244d3cf63","https://git.kernel.org/stable/c/b2c5024b771cd1dd8175d5f6949accfadbab7edd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40957
|
Medium |
fixed |
- 5.15.162
- 6.1.96
- 6.6.36
- 6.9.7
|
In the Linux kernel, the following vulnerability has been resolved:
seg6: fix parameter passing when calling NF_HOOK() in End.DX4 and End.DX6 behaviors
input_action_end_dx4() and input_action_end_dx6() are called NF_HOOK() for
PREROUTING hook, in PREROUTING hook, we should passing a valid indev,
and a NULL outdev to NF_HOOK(), otherwise may trigger a NULL pointer
dereference, as below:
[74830.647293] BUG: kernel NULL pointer dereference, address: 0000000000000090
[74830.655633] #PF: supervisor read access in kernel mode
[74830.657888] #PF: error_code(0x0000) - not-present page
[74830.659500] PGD 0 P4D 0
[74830.660450] Oops: 0000 [#1] PREEMPT SMP PTI
...
[74830.664953] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
[74830.666569] RIP: 0010:rpfilter_mt+0x44/0x15e [ipt_rpfilter]
...
[74830.689725] Call Trace:
[74830.690402] <IRQ>
[74830.690953] ? show_trace_log_lvl+0x1c4/0x2df
[74830.692020] ? show_trace_log_lvl+0x1c4/0x2df
[74830.693095] ? ipt_do_table+0x286/0x710 [ip_tables]
[74830.694275] ? __die_body.cold+0x8/0xd
[74830.695205] ? page_fault_oops+0xac/0x140
[74830.696244] ? exc_page_fault+0x62/0x150
[74830.697225] ? asm_exc_page_fault+0x22/0x30
[74830.698344] ? rpfilter_mt+0x44/0x15e [ipt_rpfilter]
[74830.699540] ipt_do_table+0x286/0x710 [ip_tables]
[74830.700758] ? ip6_route_input+0x19d/0x240
[74830.701752] nf_hook_slow+0x3f/0xb0
[74830.702678] input_action_end_dx4+0x19b/0x1e0
[74830.703735] ? input_action_end_t+0xe0/0xe0
[74830.704734] seg6_local_input_core+0x2d/0x60
[74830.705782] lwtunnel_input+0x5b/0xb0
[74830.706690] __netif_receive_skb_one_core+0x63/0xa0
[74830.707825] process_backlog+0x99/0x140
[74830.709538] __napi_poll+0x2c/0x160
[74830.710673] net_rx_action+0x296/0x350
[74830.711860] __do_softirq+0xcb/0x2ac
[74830.713049] do_softirq+0x63/0x90
input_action_end_dx4() passing a NULL indev to NF_HOOK(), and finally
trigger a NULL dereference in rpfilter_mt()->rpfilter_is_loopback():
static bool
rpfilter_is_loopback(const struct sk_buff *skb,
const struct net_device *in)
{
// in is NULL
return skb->pkt_type == PACKET_LOOPBACK ||
in->flags & IFF_LOOPBACK;
} |
["https://git.kernel.org/stable/c/561475d53aa7e4511ee7cdba8728ded81cf1db1c","https://git.kernel.org/stable/c/9a3bc8d16e0aacd65c31aaf23a2bced3288a7779","https://git.kernel.org/stable/c/af90e3d73dc45778767b2fb6e7edd57ebe34380d","https://git.kernel.org/stable/c/d62df86c172033679d744f07d89e93e367dd11f6","https://git.kernel.org/stable/c/ec4d970b597ee5e17b0d8d73b7875197ce9a04d4","https://git.kernel.org/stable/c/561475d53aa7e4511ee7cdba8728ded81cf1db1c","https://git.kernel.org/stable/c/9a3bc8d16e0aacd65c31aaf23a2bced3288a7779","https://git.kernel.org/stable/c/af90e3d73dc45778767b2fb6e7edd57ebe34380d","https://git.kernel.org/stable/c/d62df86c172033679d744f07d89e93e367dd11f6","https://git.kernel.org/stable/c/ec4d970b597ee5e17b0d8d73b7875197ce9a04d4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43817
|
Medium |
fixed |
- 5.15.165
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
net: missing check virtio
Two missing check in virtio_net_hdr_to_skb() allowed syzbot
to crash kernels again
1. After the skb_segment function the buffer may become non-linear
(nr_frags != 0), but since the SKBTX_SHARED_FRAG flag is not set anywhere
the __skb_linearize function will not be executed, then the buffer will
remain non-linear. Then the condition (offset >= skb_headlen(skb))
becomes true, which causes WARN_ON_ONCE in skb_checksum_help.
2. The struct sk_buff and struct virtio_net_hdr members must be
mathematically related.
(gso_size) must be greater than (needed) otherwise WARN_ON_ONCE.
(remainder) must be greater than (needed) otherwise WARN_ON_ONCE.
(remainder) may be 0 if division is without remainder.
offset+2 (4191) > skb_headlen() (1116)
WARNING: CPU: 1 PID: 5084 at net/core/dev.c:3303 skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303
Modules linked in:
CPU: 1 PID: 5084 Comm: syz-executor336 Not tainted 6.7.0-rc3-syzkaller-00014-gdf60cee26a2e #0
Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
RIP: 0010:skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303
Code: 89 e8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 52 01 00 00 44 89 e2 2b 53 74 4c 89 ee 48 c7 c7 40 57 e9 8b e8 af 8f dd f8 90 <0f> 0b 90 90 e9 87 fe ff ff e8 40 0f 6e f9 e9 4b fa ff ff 48 89 ef
RSP: 0018:ffffc90003a9f338 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff888025125780 RCX: ffffffff814db209
RDX: ffff888015393b80 RSI: ffffffff814db216 RDI: 0000000000000001
RBP: ffff8880251257f4 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000045c
R13: 000000000000105f R14: ffff8880251257f0 R15: 000000000000105d
FS: 0000555555c24380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000002000f000 CR3: 0000000023151000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
ip_do_fragment+0xa1b/0x18b0 net/ipv4/ip_output.c:777
ip_fragment.constprop.0+0x161/0x230 net/ipv4/ip_output.c:584
ip_finish_output_gso net/ipv4/ip_output.c:286 [inline]
__ip_finish_output net/ipv4/ip_output.c:308 [inline]
__ip_finish_output+0x49c/0x650 net/ipv4/ip_output.c:295
ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
ip_output+0x13b/0x2a0 net/ipv4/ip_output.c:433
dst_output include/net/dst.h:451 [inline]
ip_local_out+0xaf/0x1a0 net/ipv4/ip_output.c:129
iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82
ipip6_tunnel_xmit net/ipv6/sit.c:1034 [inline]
sit_tunnel_xmit+0xed2/0x28f0 net/ipv6/sit.c:1076
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
xmit_one net/core/dev.c:3545 [inline]
dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3561
__dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4346
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
packet_xmit+0x257/0x380 net/packet/af_packet.c:276
packet_snd net/packet/af_packet.c:3087 [inline]
packet_sendmsg+0x24ca/0x5240 net/packet/af_packet.c:3119
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0xd5/0x180 net/socket.c:745
__sys_sendto+0x255/0x340 net/socket.c:2190
__do_sys_sendto net/socket.c:2202 [inline]
__se_sys_sendto net/socket.c:2198 [inline]
__x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Found by Linux Verification Center (linuxtesting.org) with Syzkaller |
["https://git.kernel.org/stable/c/27874ca77bd2b05a3779c7b3a5c75d8dd7f0b40f","https://git.kernel.org/stable/c/5b1997487a3f3373b0f580c8a20b56c1b64b0775","https://git.kernel.org/stable/c/90d41ebe0cd4635f6410471efc1dd71b33e894cf","https://git.kernel.org/stable/c/e269d79c7d35aa3808b1f3c1737d63dab504ddc8","https://git.kernel.org/stable/c/e9164903b8b303c34723177b02fe91e49e3c4cd7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50304
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()
The per-netns IP tunnel hash table is protected by the RTNL mutex and
ip_tunnel_find() is only called from the control path where the mutex is
taken.
Add a lockdep expression to hlist_for_each_entry_rcu() in
ip_tunnel_find() in order to validate that the mutex is held and to
silence the suspicious RCU usage warning [1].
[1]
WARNING: suspicious RCU usage
6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted
-----------------------------
net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by ip/362:
#0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60
stack backtrace:
CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Call Trace:
<TASK>
dump_stack_lvl+0xba/0x110
lockdep_rcu_suspicious.cold+0x4f/0xd6
ip_tunnel_find+0x435/0x4d0
ip_tunnel_newlink+0x517/0x7a0
ipgre_newlink+0x14c/0x170
__rtnl_newlink+0x1173/0x19c0
rtnl_newlink+0x6c/0xa0
rtnetlink_rcv_msg+0x3cc/0xf60
netlink_rcv_skb+0x171/0x450
netlink_unicast+0x539/0x7f0
netlink_sendmsg+0x8c1/0xd80
____sys_sendmsg+0x8f9/0xc20
___sys_sendmsg+0x197/0x1e0
__sys_sendmsg+0x122/0x1f0
do_syscall_64+0xbb/0x1d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f |
["https://git.kernel.org/stable/c/31bd7378c6fe100a8af0e996ea0b5dafd3579df6","https://git.kernel.org/stable/c/6ac5dfa575136da8dd8a9e7c1437c41f3a593993","https://git.kernel.org/stable/c/90e0569dd3d32f4f4d2ca691d3fa5a8a14a13c12","https://git.kernel.org/stable/c/ce11424026cbf87d5861b09e5e33565ff7f2ec8d","https://git.kernel.org/stable/c/e0500e4373cd3d5eace1f1712444ab830b82c114","https://git.kernel.org/stable/c/f20fe2cfe06ca1b008b09da4f2b4e0c5547ccef6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36902
|
Medium |
fixed |
- 4.19.314
- 5.4.276
- 5.10.217
- 6.1.91
- 6.6.31
- 6.8.10
|
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()
syzbot is able to trigger the following crash [1],
caused by unsafe ip6_dst_idev() use.
Indeed ip6_dst_idev() can return NULL, and must always be checked.
[1]
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline]
RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267
Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c
RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700
RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760
RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd
R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000
R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00
FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317
fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108
ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline]
ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649
ip6_route_output include/net/ip6_route.h:93 [inline]
ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120
ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250
sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326
sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455
sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662
sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099
__sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197
sctp_connect net/sctp/socket.c:4819 [inline]
sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834
__sys_connect_file net/socket.c:2048 [inline]
__sys_connect+0x2df/0x310 net/socket.c:2065
__do_sys_connect net/socket.c:2075 [inline]
__se_sys_connect net/socket.c:2072 [inline]
__x64_sys_connect+0x7a/0x90 net/socket.c:2072
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f |
["https://git.kernel.org/stable/c/1876881c9a49613b5249fb400cbf53412d90cb09","https://git.kernel.org/stable/c/35297fc68de36826087e976f86a5b1f94fd0bf95","https://git.kernel.org/stable/c/4a5a573387da6a6b23a4cc62147453ff1bc32afa","https://git.kernel.org/stable/c/674c951ab8a23f7aff9b4c3f2f865901bc76a290","https://git.kernel.org/stable/c/7e3242c139c38e60844638e394c2877b16b396b0","https://git.kernel.org/stable/c/8745a8d74ba17dafe72b6ab461fa6c007d879747","https://git.kernel.org/stable/c/d101291b2681e5ab938554e3e323f7a7ee33e3aa","https://git.kernel.org/stable/c/ddec23f206a944c73bcc2724358b85388837daff","https://git.kernel.org/stable/c/1876881c9a49613b5249fb400cbf53412d90cb09","https://git.kernel.org/stable/c/35297fc68de36826087e976f86a5b1f94fd0bf95","https://git.kernel.org/stable/c/4a5a573387da6a6b23a4cc62147453ff1bc32afa","https://git.kernel.org/stable/c/674c951ab8a23f7aff9b4c3f2f865901bc76a290","https://git.kernel.org/stable/c/7e3242c139c38e60844638e394c2877b16b396b0","https://git.kernel.org/stable/c/8745a8d74ba17dafe72b6ab461fa6c007d879747","https://git.kernel.org/stable/c/d101291b2681e5ab938554e3e323f7a7ee33e3aa","https://git.kernel.org/stable/c/ddec23f206a944c73bcc2724358b85388837daff","https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://security.netapp.com/advisory/ntap-20240926-0002/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36960
|
High |
fixed |
- 4.19.314
- 5.4.276
- 5.10.217
- 5.15.159
- 6.1.91
- 6.6.31
- 6.8.10
|
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix invalid reads in fence signaled events
Correctly set the length of the drm_event to the size of the structure
that's actually used.
The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads. |
["https://git.kernel.org/stable/c/0dbfc73670b357456196130551e586345ca48e1b","https://git.kernel.org/stable/c/2f527e3efd37c7c5e85e8aa86308856b619fa59f","https://git.kernel.org/stable/c/3cd682357c6167f636aec8ac0efaa8ba61144d36","https://git.kernel.org/stable/c/7b5fd3af4a250dd0a2a558e07b43478748eb5d22","https://git.kernel.org/stable/c/a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c","https://git.kernel.org/stable/c/b7bab33c4623c66e3398d5253870d4e88c52dfc0","https://git.kernel.org/stable/c/cef0962f2d3e5fd0660c8efb72321083a1b531a9","https://git.kernel.org/stable/c/deab66596dfad14f1c54eeefdb72428340d72a77","https://git.kernel.org/stable/c/0dbfc73670b357456196130551e586345ca48e1b","https://git.kernel.org/stable/c/2f527e3efd37c7c5e85e8aa86308856b619fa59f","https://git.kernel.org/stable/c/3cd682357c6167f636aec8ac0efaa8ba61144d36","https://git.kernel.org/stable/c/7b5fd3af4a250dd0a2a558e07b43478748eb5d22","https://git.kernel.org/stable/c/a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c","https://git.kernel.org/stable/c/b7bab33c4623c66e3398d5253870d4e88c52dfc0","https://git.kernel.org/stable/c/cef0962f2d3e5fd0660c8efb72321083a1b531a9","https://git.kernel.org/stable/c/deab66596dfad14f1c54eeefdb72428340d72a77","https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-38430
|
Critical |
fixed |
|
An issue was discovered in the Linux kernel before 6.3.9. ksmbd does not validate the SMB request protocol ID, leading to an out-of-bounds read. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.9","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=1c1bcf2d3ea061613119b534f57507c377df20f9","https://security.netapp.com/advisory/ntap-20230831-0003/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.9","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=1c1bcf2d3ea061613119b534f57507c377df20f9","https://security.netapp.com/advisory/ntap-20230831-0003/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-38431
|
Critical |
fixed |
|
An issue was discovered in the Linux kernel before 6.3.8. fs/smb/server/connection.c in ksmbd does not validate the relationship between the NetBIOS header's length field and the SMB header sizes, via pdu_size in ksmbd_conn_handler_loop, leading to an out-of-bounds read. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.8","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=368ba06881c395f1c9a7ba22203cf8d78b4addc0","https://security.netapp.com/advisory/ntap-20230824-0011/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.8","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=368ba06881c395f1c9a7ba22203cf8d78b4addc0","https://security.netapp.com/advisory/ntap-20230824-0011/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-42895
|
Medium |
|
N/A
|
There is an infoleak vulnerability in the Linux kernel's net/bluetooth/l2cap_core.c's l2cap_parse_conf_req function which can be used to leak kernel pointers remotely.
We recommend upgrading past commit https://github.com/torvalds/linux/commit/b1a2cd50c0357f243b7435a732b4e62ba3157a2e https://www.google.com/url |
["https://github.com/torvalds/linux/commit/b1a2cd50c0357f243b7435a732b4e62ba3157a2e","https://kernel.dance/#b1a2cd50c0357f243b7435a732b4e62ba3157a2e","https://github.com/torvalds/linux/commit/b1a2cd50c0357f243b7435a732b4e62ba3157a2e","https://kernel.dance/#b1a2cd50c0357f243b7435a732b4e62ba3157a2e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46808
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add missing NULL pointer check within dpcd_extend_address_range
[Why & How]
ASSERT if return NULL from kcalloc. |
["https://git.kernel.org/stable/c/5524fa301ba649f8cf00848f91468e0ba7e4f24c","https://git.kernel.org/stable/c/ca0b0b0a22306f2e51105ac48f4a09c2fbbb504e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40904
|
Medium |
fixed |
- 4.19.317
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.95
- 6.6.35
- 6.9.6
|
In the Linux kernel, the following vulnerability has been resolved:
USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages
The syzbot fuzzer found that the interrupt-URB completion callback in
the cdc-wdm driver was taking too long, and the driver's immediate
resubmission of interrupt URBs with -EPROTO status combined with the
dummy-hcd emulation to cause a CPU lockup:
cdc_wdm 1-1:1.0: nonzero urb status received: -71
cdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes
watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]
CPU#0 Utilization every 4s during lockup:
#1: 98% system, 0% softirq, 3% hardirq, 0% idle
#2: 98% system, 0% softirq, 3% hardirq, 0% idle
#3: 98% system, 0% softirq, 3% hardirq, 0% idle
#4: 98% system, 0% softirq, 3% hardirq, 0% idle
#5: 98% system, 1% softirq, 3% hardirq, 0% idle
Modules linked in:
irq event stamp: 73096
hardirqs last enabled at (73095): [<ffff80008037bc00>] console_emit_next_record kernel/printk/printk.c:2935 [inline]
hardirqs last enabled at (73095): [<ffff80008037bc00>] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994
hardirqs last disabled at (73096): [<ffff80008af10b00>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
hardirqs last disabled at (73096): [<ffff80008af10b00>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
softirqs last enabled at (73048): [<ffff8000801ea530>] softirq_handle_end kernel/softirq.c:400 [inline]
softirqs last enabled at (73048): [<ffff8000801ea530>] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582
softirqs last disabled at (73043): [<ffff800080020de8>] __do_softirq+0x14/0x20 kernel/softirq.c:588
CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G W 6.10.0-rc2-syzkaller-g8867bbd4a056 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Testing showed that the problem did not occur if the two error
messages -- the first two lines above -- were removed; apparently adding
material to the kernel log takes a surprisingly large amount of time.
In any case, the best approach for preventing these lockups and to
avoid spamming the log with thousands of error messages per second is
to ratelimit the two dev_err() calls. Therefore we replace them with
dev_err_ratelimited(). |
["https://git.kernel.org/stable/c/02a4c0499fc3a02e992b4c69a9809912af372d94","https://git.kernel.org/stable/c/05b2cd6d33f700597e6f081b53c668a226a96d28","https://git.kernel.org/stable/c/217d1f44fff560b3995a685a60aa66e55a7f0f56","https://git.kernel.org/stable/c/22f00812862564b314784167a89f27b444f82a46","https://git.kernel.org/stable/c/53250b54c92fe087fd4b0c48f85529efe1ebd879","https://git.kernel.org/stable/c/72a3fe36cf9f0d030865e571f45a40f9c1e07e8a","https://git.kernel.org/stable/c/82075aff7ffccb1e72b0ac8aa349e473624d857c","https://git.kernel.org/stable/c/c0747d76eb05542b5d49f67069b64ef5ff732c6c","https://git.kernel.org/stable/c/02a4c0499fc3a02e992b4c69a9809912af372d94","https://git.kernel.org/stable/c/05b2cd6d33f700597e6f081b53c668a226a96d28","https://git.kernel.org/stable/c/217d1f44fff560b3995a685a60aa66e55a7f0f56","https://git.kernel.org/stable/c/22f00812862564b314784167a89f27b444f82a46","https://git.kernel.org/stable/c/53250b54c92fe087fd4b0c48f85529efe1ebd879","https://git.kernel.org/stable/c/72a3fe36cf9f0d030865e571f45a40f9c1e07e8a","https://git.kernel.org/stable/c/82075aff7ffccb1e72b0ac8aa349e473624d857c","https://git.kernel.org/stable/c/c0747d76eb05542b5d49f67069b64ef5ff732c6c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40961
|
Medium |
fixed |
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.96
- 6.6.36
- 6.9.7
|
In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent possible NULL deref in fib6_nh_init()
syzbot reminds us that in6_dev_get() can return NULL.
fib6_nh_init()
ip6_validate_gw( &idev )
ip6_route_check_nh( idev )
*idev = in6_dev_get(dev); // can be NULL
Oops: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]
CPU: 0 PID: 11237 Comm: syz-executor.3 Not tainted 6.10.0-rc2-syzkaller-00249-gbe27b8965297 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024
RIP: 0010:fib6_nh_init+0x640/0x2160 net/ipv6/route.c:3606
Code: 00 00 fc ff df 4c 8b 64 24 58 48 8b 44 24 28 4c 8b 74 24 30 48 89 c1 48 89 44 24 28 48 8d 98 e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 0f 85 b3 17 00 00 8b 1b 31 ff 89 de e8 b8 8b
RSP: 0018:ffffc900032775a0 EFLAGS: 00010202
RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000000000
RDX: 0000000000000010 RSI: ffffc90003277a54 RDI: ffff88802b3a08d8
RBP: ffffc900032778b0 R08: 00000000000002fc R09: 0000000000000000
R10: 00000000000002fc R11: 0000000000000000 R12: ffff88802b3a08b8
R13: 1ffff9200064eec8 R14: ffffc90003277a00 R15: dffffc0000000000
FS: 00007f940feb06c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000245e8000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
ip6_route_info_create+0x99e/0x12b0 net/ipv6/route.c:3809
ip6_route_add+0x28/0x160 net/ipv6/route.c:3853
ipv6_route_ioctl+0x588/0x870 net/ipv6/route.c:4483
inet6_ioctl+0x21a/0x280 net/ipv6/af_inet6.c:579
sock_do_ioctl+0x158/0x460 net/socket.c:1222
sock_ioctl+0x629/0x8e0 net/socket.c:1341
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f940f07cea9 |
["https://git.kernel.org/stable/c/2eab4543a2204092c3a7af81d7d6c506e59a03a6","https://git.kernel.org/stable/c/3200ffeec4d59aad5bc9ca75d2c1fae47c0aeade","https://git.kernel.org/stable/c/4cdfe813015d5a24586bd0a84fa0fa6eb0a1f668","https://git.kernel.org/stable/c/88b9a55e2e35ea846d41f4efdc29d23345bd1aa4","https://git.kernel.org/stable/c/ae8d3d39efe366c2198f530e01e4bf07830bf403","https://git.kernel.org/stable/c/b6947723c9eabcab58cfb33cdb0a565a6aee6727","https://git.kernel.org/stable/c/de5ad4d45cd0128a2a37555f48ab69aa19d78adc","https://git.kernel.org/stable/c/2eab4543a2204092c3a7af81d7d6c506e59a03a6","https://git.kernel.org/stable/c/3200ffeec4d59aad5bc9ca75d2c1fae47c0aeade","https://git.kernel.org/stable/c/4cdfe813015d5a24586bd0a84fa0fa6eb0a1f668","https://git.kernel.org/stable/c/88b9a55e2e35ea846d41f4efdc29d23345bd1aa4","https://git.kernel.org/stable/c/ae8d3d39efe366c2198f530e01e4bf07830bf403","https://git.kernel.org/stable/c/b6947723c9eabcab58cfb33cdb0a565a6aee6727","https://git.kernel.org/stable/c/de5ad4d45cd0128a2a37555f48ab69aa19d78adc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40984
|
Medium |
fixed |
- 4.19.317
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.96
- 6.6.36
- 6.9.7
|
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine."
Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid
"Info: mapping multiple BARs. Your kernel is fine.""). The initial
purpose of this commit was to stop memory mappings for operation
regions from overlapping page boundaries, as it can trigger warnings
if different page attributes are present.
However, it was found that when this situation arises, mapping
continues until the boundary's end, but there is still an attempt to
read/write the entire length of the map, leading to a NULL pointer
deference. For example, if a four-byte mapping request is made but
only one byte is mapped because it hits the current page boundary's
end, a four-byte read/write attempt is still made, resulting in a NULL
pointer deference.
Instead, map the entire length, as the ACPI specification does not
mandate that it must be within the same page boundary. It is
permissible for it to be mapped across different regions. |
["https://git.kernel.org/stable/c/434c6b924e1f4c219aab2d9e05fe79c5364e37d3","https://git.kernel.org/stable/c/435ecc978c3d5d0c4e172ec5b956dc1904061d98","https://git.kernel.org/stable/c/6eca23100e9030725f69c1babacd58803f29ec8d","https://git.kernel.org/stable/c/a83e1385b780d41307433ddbc86e3c528db031f0","https://git.kernel.org/stable/c/ae465109d82f4fb03c5adbe85f2d6a6a3d59124c","https://git.kernel.org/stable/c/dc5017c57f5eee80020c73ff8b67ba7f9fd08b1f","https://git.kernel.org/stable/c/ddc1f5f124479360a1fd43f73be950781d172239","https://git.kernel.org/stable/c/e21a4c9129c72fa54dd00f5ebf71219b41d43c04","https://git.kernel.org/stable/c/434c6b924e1f4c219aab2d9e05fe79c5364e37d3","https://git.kernel.org/stable/c/435ecc978c3d5d0c4e172ec5b956dc1904061d98","https://git.kernel.org/stable/c/6eca23100e9030725f69c1babacd58803f29ec8d","https://git.kernel.org/stable/c/a83e1385b780d41307433ddbc86e3c528db031f0","https://git.kernel.org/stable/c/ae465109d82f4fb03c5adbe85f2d6a6a3d59124c","https://git.kernel.org/stable/c/dc5017c57f5eee80020c73ff8b67ba7f9fd08b1f","https://git.kernel.org/stable/c/ddc1f5f124479360a1fd43f73be950781d172239","https://git.kernel.org/stable/c/e21a4c9129c72fa54dd00f5ebf71219b41d43c04"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-45016
|
Medium |
fixed |
- 5.4.283
- 5.10.225
- 5.15.166
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
netem: fix return value if duplicate enqueue fails
There is a bug in netem_enqueue() introduced by
commit 5845f706388a ("net: netem: fix skb length BUG_ON in __skb_to_sgvec")
that can lead to a use-after-free.
This commit made netem_enqueue() always return NET_XMIT_SUCCESS
when a packet is duplicated, which can cause the parent qdisc's q.qlen
to be mistakenly incremented. When this happens qlen_notify() may be
skipped on the parent during destruction, leaving a dangling pointer
for some classful qdiscs like DRR.
There are two ways for the bug happen:
- If the duplicated packet is dropped by rootq->enqueue() and then
the original packet is also dropped.
- If rootq->enqueue() sends the duplicated packet to a different qdisc
and the original packet is dropped.
In both cases NET_XMIT_SUCCESS is returned even though no packets
are enqueued at the netem qdisc.
The fix is to defer the enqueue of the duplicate packet until after
the original packet has been guaranteed to return NET_XMIT_SUCCESS. |
["https://git.kernel.org/stable/c/0486d31dd8198e22b63a4730244b38fffce6d469","https://git.kernel.org/stable/c/52d99a69f3d556c6426048c9d481b912205919d8","https://git.kernel.org/stable/c/577d6c0619467fe90f7e8e57e45cb5bd9d936014","https://git.kernel.org/stable/c/759e3e8c4a6a6b4e52ebc4547123a457f0ce90d4","https://git.kernel.org/stable/c/c07ff8592d57ed258afee5a5e04991a48dbaf382","https://git.kernel.org/stable/c/c414000da1c2ea1ba9a5e5bb1a4ba774e51e202d","https://git.kernel.org/stable/c/e5bb2988a310667abed66c7d3ffa28880cf0f883"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40911
|
Medium |
fixed |
- 5.15.162
- 6.1.95
- 6.6.35
- 6.9.6
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: Lock wiphy in cfg80211_get_station
Wiphy should be locked before calling rdev_get_station() (see lockdep
assert in ieee80211_get_station()).
This fixes the following kernel NULL dereference:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050
Mem abort info:
ESR = 0x0000000096000006
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x06: level 2 translation fault
Data abort info:
ISV = 0, ISS = 0x00000006
CM = 0, WnR = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=0000000003001000
[0000000000000050] pgd=0800000002dca003, p4d=0800000002dca003, pud=08000000028e9003, pmd=0000000000000000
Internal error: Oops: 0000000096000006 [#1] SMP
Modules linked in: netconsole dwc3_meson_g12a dwc3_of_simple dwc3 ip_gre gre ath10k_pci ath10k_core ath9k ath9k_common ath9k_hw ath
CPU: 0 PID: 1091 Comm: kworker/u8:0 Not tainted 6.4.0-02144-g565f9a3a7911-dirty #705
Hardware name: RPT (r1) (DT)
Workqueue: bat_events batadv_v_elp_throughput_metric_update
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : ath10k_sta_statistics+0x10/0x2dc [ath10k_core]
lr : sta_set_sinfo+0xcc/0xbd4
sp : ffff000007b43ad0
x29: ffff000007b43ad0 x28: ffff0000071fa900 x27: ffff00000294ca98
x26: ffff000006830880 x25: ffff000006830880 x24: ffff00000294c000
x23: 0000000000000001 x22: ffff000007b43c90 x21: ffff800008898acc
x20: ffff00000294c6e8 x19: ffff000007b43c90 x18: 0000000000000000
x17: 445946354d552d78 x16: 62661f7200000000 x15: 57464f445946354d
x14: 0000000000000000 x13: 00000000000000e3 x12: d5f0acbcebea978e
x11: 00000000000000e3 x10: 000000010048fe41 x9 : 0000000000000000
x8 : ffff000007b43d90 x7 : 000000007a1e2125 x6 : 0000000000000000
x5 : ffff0000024e0900 x4 : ffff800000a0250c x3 : ffff000007b43c90
x2 : ffff00000294ca98 x1 : ffff000006831920 x0 : 0000000000000000
Call trace:
ath10k_sta_statistics+0x10/0x2dc [ath10k_core]
sta_set_sinfo+0xcc/0xbd4
ieee80211_get_station+0x2c/0x44
cfg80211_get_station+0x80/0x154
batadv_v_elp_get_throughput+0x138/0x1fc
batadv_v_elp_throughput_metric_update+0x1c/0xa4
process_one_work+0x1ec/0x414
worker_thread+0x70/0x46c
kthread+0xdc/0xe0
ret_from_fork+0x10/0x20
Code: a9bb7bfd 910003fd a90153f3 f9411c40 (f9402814)
This happens because STA has time to disconnect and reconnect before
batadv_v_elp_throughput_metric_update() delayed work gets scheduled. In
this situation, ath10k_sta_state() can be in the middle of resetting
arsta data when the work queue get chance to be scheduled and ends up
accessing it. Locking wiphy prevents that. |
["https://git.kernel.org/stable/c/0ccc63958d8373e15a69f4f8069f3e78f7f3898a","https://git.kernel.org/stable/c/43e1eefb0b2094e2281150d87d09e8bc872b9fba","https://git.kernel.org/stable/c/642f89daa34567d02f312d03e41523a894906dae","https://git.kernel.org/stable/c/6d540b0317901535275020bd4ac44fac6439ca76","https://git.kernel.org/stable/c/dfd84ce41663be9ca3f69bd657c45f49b69344d9","https://git.kernel.org/stable/c/0ccc63958d8373e15a69f4f8069f3e78f7f3898a","https://git.kernel.org/stable/c/43e1eefb0b2094e2281150d87d09e8bc872b9fba","https://git.kernel.org/stable/c/642f89daa34567d02f312d03e41523a894906dae","https://git.kernel.org/stable/c/6d540b0317901535275020bd4ac44fac6439ca76","https://git.kernel.org/stable/c/dfd84ce41663be9ca3f69bd657c45f49b69344d9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44944
|
Medium |
fixed |
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: use helper function to calculate expect ID
Delete expectation path is missing a call to the nf_expect_get_id()
helper function to calculate the expectation ID, otherwise LSB of the
expectation object address is leaked to userspace. |
["https://git.kernel.org/stable/c/24f407042cf90b0872de667460230d8d50c06c39","https://git.kernel.org/stable/c/27662b46f2adaa52c1665a82af4b21c42c4337fd","https://git.kernel.org/stable/c/5e2c24f7b0911b15c29aefce760bcf770542fb61","https://git.kernel.org/stable/c/64c0b8e64be8368617ef08dfc59a3160563a1435","https://git.kernel.org/stable/c/66e7650dbbb8e236e781c670b167edc81e771450","https://git.kernel.org/stable/c/74de442b8e12a207c07953ee068009a7701aff8f","https://git.kernel.org/stable/c/782161895eb4ac45cf7cfa8db375bd4766cb8299","https://git.kernel.org/stable/c/eb4ca1a97e08ff5b920664ba292e576257e2d184","https://www.zerodayinitiative.com/advisories/ZDI-24-1182/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2020-8834
|
Medium |
|
N/A
|
KVM in the Linux kernel on Power8 processors has a conflicting use of HSTATE_HOST_R1 to store r1 state in kvmppc_hv_entry plus in kvmppc_{save,restore}_tm, leading to a stack corruption. Because of this, an attacker with the ability run code in kernel space of a guest VM can cause the host kernel to panic. There were two commits that, according to the reporter, introduced the vulnerability: f024ee098476 ("KVM: PPC: Book3S HV: Pull out TM state save/restore into separate procedures") 87a11bb6a7f7 ("KVM: PPC: Book3S HV: Work around XER[SO] bug in fake suspend mode") The former landed in 4.8, the latter in 4.17. This was fixed without realizing the impact in 4.18 with the following three commits, though it's believed the first is the only strictly necessary commit: 6f597c6b63b6 ("KVM: PPC: Book3S PR: Add guest MSR parameter for kvmppc_save_tm()/kvmppc_restore_tm()") 7b0e827c6970 ("KVM: PPC: Book3S HV: Factor fake-suspend handling out of kvmppc_save/restore_tm") 009c872a8bc4 ("KVM: PPC: Book3S PR: Move kvmppc_save_tm/kvmppc_restore_tm to separate file") |
["http://lists.opensuse.org/opensuse-security-announce/2020-04/msg00035.html","https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1867717","https://usn.ubuntu.com/4318-1/","https://usn.ubuntu.com/usn/usn-4318-1","https://www.openwall.com/lists/oss-security/2020/04/06/2","http://lists.opensuse.org/opensuse-security-announce/2020-04/msg00035.html","https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1867717","https://usn.ubuntu.com/4318-1/","https://usn.ubuntu.com/usn/usn-4318-1","https://www.openwall.com/lists/oss-security/2020/04/06/2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46740
|
High |
fixed |
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
binder: fix UAF caused by offsets overwrite
Binder objects are processed and copied individually into the target
buffer during transactions. Any raw data in-between these objects is
copied as well. However, this raw data copy lacks an out-of-bounds
check. If the raw data exceeds the data section size then the copy
overwrites the offsets section. This eventually triggers an error that
attempts to unwind the processed objects. However, at this point the
offsets used to index these objects are now corrupted.
Unwinding with corrupted offsets can result in decrements of arbitrary
nodes and lead to their premature release. Other users of such nodes are
left with a dangling pointer triggering a use-after-free. This issue is
made evident by the following KASAN report (trimmed):
==================================================================
BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x19c
Write of size 4 at addr ffff47fc91598f04 by task binder-util/743
CPU: 9 UID: 0 PID: 743 Comm: binder-util Not tainted 6.11.0-rc4 #1
Hardware name: linux,dummy-virt (DT)
Call trace:
_raw_spin_lock+0xe4/0x19c
binder_free_buf+0x128/0x434
binder_thread_write+0x8a4/0x3260
binder_ioctl+0x18f0/0x258c
[...]
Allocated by task 743:
__kmalloc_cache_noprof+0x110/0x270
binder_new_node+0x50/0x700
binder_transaction+0x413c/0x6da8
binder_thread_write+0x978/0x3260
binder_ioctl+0x18f0/0x258c
[...]
Freed by task 745:
kfree+0xbc/0x208
binder_thread_read+0x1c5c/0x37d4
binder_ioctl+0x16d8/0x258c
[...]
==================================================================
To avoid this issue, let's check that the raw data copy is within the
boundaries of the data section. |
["https://git.kernel.org/stable/c/109e845c1184c9f786d41516348ba3efd9112792","https://git.kernel.org/stable/c/1f33d9f1d9ac3f0129f8508925000900c2fe5bb0","https://git.kernel.org/stable/c/3a8154bb4ab4a01390a3abf1e6afac296e037da4","https://git.kernel.org/stable/c/4df153652cc46545722879415937582028c18af5","https://git.kernel.org/stable/c/4f79e0b80dc69bd5eaaed70f0df1b558728b4e59","https://git.kernel.org/stable/c/5a32bfd23022ffa7e152f273fa3fa29befb7d929","https://git.kernel.org/stable/c/eef79854a04feac5b861f94d7b19cbbe79874117"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49014
|
High |
fixed |
- 4.19.268
- 5.4.226
- 5.10.158
- 5.15.82
- 6.0.12
|
In the Linux kernel, the following vulnerability has been resolved:
net: tun: Fix use-after-free in tun_detach()
syzbot reported use-after-free in tun_detach() [1]. This causes call
trace like below:
==================================================================
BUG: KASAN: use-after-free in notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75
Read of size 8 at addr ffff88807324e2a8 by task syz-executor.0/3673
CPU: 0 PID: 3673 Comm: syz-executor.0 Not tainted 6.1.0-rc5-syzkaller-00044-gcc675d22e422 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:284 [inline]
print_report+0x15e/0x461 mm/kasan/report.c:395
kasan_report+0xbf/0x1f0 mm/kasan/report.c:495
notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75
call_netdevice_notifiers_info+0x86/0x130 net/core/dev.c:1942
call_netdevice_notifiers_extack net/core/dev.c:1983 [inline]
call_netdevice_notifiers net/core/dev.c:1997 [inline]
netdev_wait_allrefs_any net/core/dev.c:10237 [inline]
netdev_run_todo+0xbc6/0x1100 net/core/dev.c:10351
tun_detach drivers/net/tun.c:704 [inline]
tun_chr_close+0xe4/0x190 drivers/net/tun.c:3467
__fput+0x27c/0xa90 fs/file_table.c:320
task_work_run+0x16f/0x270 kernel/task_work.c:179
exit_task_work include/linux/task_work.h:38 [inline]
do_exit+0xb3d/0x2a30 kernel/exit.c:820
do_group_exit+0xd4/0x2a0 kernel/exit.c:950
get_signal+0x21b1/0x2440 kernel/signal.c:2858
arch_do_signal_or_restart+0x86/0x2300 arch/x86/kernel/signal.c:869
exit_to_user_mode_loop kernel/entry/common.c:168 [inline]
exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203
__syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296
do_syscall_64+0x46/0xb0 arch/x86/entry/common.c:86
entry_SYSCALL_64_after_hwframe+0x63/0xcd
The cause of the issue is that sock_put() from __tun_detach() drops
last reference count for struct net, and then notifier_call_chain()
from netdev_state_change() accesses that struct net.
This patch fixes the issue by calling sock_put() from tun_detach()
after all necessary accesses for the struct net has done. |
["https://git.kernel.org/stable/c/04b995e963229501401810dab89dc73e7f12d054","https://git.kernel.org/stable/c/16c244bc65d1175775325ec0489a5a5c830e02c7","https://git.kernel.org/stable/c/1f23f1890d91812c35d32eab1b49621b6d32dc7b","https://git.kernel.org/stable/c/4cde8da2d814a3b7b176db81922d4ddaad7c0f0e","https://git.kernel.org/stable/c/5daadc86f27ea4d691e2131c04310d0418c6cd12","https://git.kernel.org/stable/c/5f442e1d403e0496bacb74a58e2be7f500695e6f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48991
|
High |
fixed |
- 4.9.337
- 4.14.303
- 4.19.270
- 5.4.227
- 5.10.159
- 5.15.83
- 6.0.13
|
In the Linux kernel, the following vulnerability has been resolved:
mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths
Any codepath that zaps page table entries must invoke MMU notifiers to
ensure that secondary MMUs (like KVM) don't keep accessing pages which
aren't mapped anymore. Secondary MMUs don't hold their own references to
pages that are mirrored over, so failing to notify them can lead to page
use-after-free.
I'm marking this as addressing an issue introduced in commit f3f0e1d2150b
("khugepaged: add support of collapse for tmpfs/shmem pages"), but most of
the security impact of this only came in commit 27e1f8273113 ("khugepaged:
enable collapse pmd for pte-mapped THP"), which actually omitted flushes
for the removal of present PTEs, not just for the removal of empty page
tables. |
["https://git.kernel.org/stable/c/1a3f8c6cd29d9078cc81b29d39d0e9ae1d6a03c3","https://git.kernel.org/stable/c/275c626c131cfe141beeb6c575e31fa53d32da19","https://git.kernel.org/stable/c/5450535901d89a5dcca5fbbc59a24fe89caeb465","https://git.kernel.org/stable/c/5ffc2a75534d9d74d49760f983f8eb675fa63d69","https://git.kernel.org/stable/c/7f445ca2e0e59c7971d0b7b853465e50844ab596","https://git.kernel.org/stable/c/c23105673228c349739e958fa33955ed8faddcaf","https://git.kernel.org/stable/c/f268f6cf875f3220afc77bdd0bf1bb136eb54db9","https://git.kernel.org/stable/c/ff2a1a6f869650aec99e9d070b5ab625bfbc5bc3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49015
|
High |
fixed |
- 4.9.335
- 4.14.301
- 4.19.268
- 5.4.226
- 5.10.158
- 5.15.82
- 6.0.12
|
In the Linux kernel, the following vulnerability has been resolved:
net: hsr: Fix potential use-after-free
The skb is delivered to netif_rx() which may free it, after calling this,
dereferencing skb may trigger use-after-free. |
["https://git.kernel.org/stable/c/4b351609af4fdbc23f79ab2b12748f4403ea9af4","https://git.kernel.org/stable/c/53a62c5efe91665f7a41fad0f888a96f94dc59eb","https://git.kernel.org/stable/c/7ca81a161e406834a1fdc405fc83a572bd14b8d9","https://git.kernel.org/stable/c/7e177d32442b7ed08a9fa61b61724abc548cb248","https://git.kernel.org/stable/c/8393ce5040803666bfa26a3a7bf41e44fab0ace9","https://git.kernel.org/stable/c/b35d899854d5d5d58eb7d7e7c0f61afc60d3a9e9","https://git.kernel.org/stable/c/dca370e575d9b6c983f5015e8dc035e23e219ee6","https://git.kernel.org/stable/c/f3add2b8cf620966de3ebfa07679ca12d33ec26f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48689
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: TX zerocopy should not sense pfmemalloc status
We got a recent syzbot report [1] showing a possible misuse
of pfmemalloc page status in TCP zerocopy paths.
Indeed, for pages coming from user space or other layers,
using page_is_pfmemalloc() is moot, and possibly could give
false positives.
There has been attempts to make page_is_pfmemalloc() more robust,
but not using it in the first place in this context is probably better,
removing cpu cycles.
Note to stable teams :
You need to backport 84ce071e38a6 ("net: introduce
__skb_fill_page_desc_noacc") as a prereq.
Race is more probable after commit c07aea3ef4d4
("mm: add a signature in struct page") because page_is_pfmemalloc()
is now using low order bit from page->lru.next, which can change
more often than page->index.
Low order bit should never be set for lru.next (when used as an anchor
in LRU list), so KCSAN report is mostly a false positive.
Backporting to older kernel versions seems not necessary.
[1]
BUG: KCSAN: data-race in lru_add_fn / tcp_build_frag
write to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0:
__list_add include/linux/list.h:73 [inline]
list_add include/linux/list.h:88 [inline]
lruvec_add_folio include/linux/mm_inline.h:105 [inline]
lru_add_fn+0x440/0x520 mm/swap.c:228
folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246
folio_batch_add_and_move mm/swap.c:263 [inline]
folio_add_lru+0xf1/0x140 mm/swap.c:490
filemap_add_folio+0xf8/0x150 mm/filemap.c:948
__filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981
pagecache_get_page+0x26/0x190 mm/folio-compat.c:104
grab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116
ext4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988
generic_perform_write+0x1d4/0x3f0 mm/filemap.c:3738
ext4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270
ext4_file_write_iter+0x2e3/0x1210
call_write_iter include/linux/fs.h:2187 [inline]
new_sync_write fs/read_write.c:491 [inline]
vfs_write+0x468/0x760 fs/read_write.c:578
ksys_write+0xe8/0x1a0 fs/read_write.c:631
__do_sys_write fs/read_write.c:643 [inline]
__se_sys_write fs/read_write.c:640 [inline]
__x64_sys_write+0x3e/0x50 fs/read_write.c:640
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
read to 0xffffea0004a1d2c8 of 8 bytes by task 18611 on cpu 1:
page_is_pfmemalloc include/linux/mm.h:1740 [inline]
__skb_fill_page_desc include/linux/skbuff.h:2422 [inline]
skb_fill_page_desc include/linux/skbuff.h:2443 [inline]
tcp_build_frag+0x613/0xb20 net/ipv4/tcp.c:1018
do_tcp_sendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075
tcp_sendpage_locked net/ipv4/tcp.c:1140 [inline]
tcp_sendpage+0x89/0xb0 net/ipv4/tcp.c:1150
inet_sendpage+0x7f/0xc0 net/ipv4/af_inet.c:833
kernel_sendpage+0x184/0x300 net/socket.c:3561
sock_sendpage+0x5a/0x70 net/socket.c:1054
pipe_to_sendpage+0x128/0x160 fs/splice.c:361
splice_from_pipe_feed fs/splice.c:415 [inline]
__splice_from_pipe+0x222/0x4d0 fs/splice.c:559
splice_from_pipe fs/splice.c:594 [inline]
generic_splice_sendpage+0x89/0xc0 fs/splice.c:743
do_splice_from fs/splice.c:764 [inline]
direct_splice_actor+0x80/0xa0 fs/splice.c:931
splice_direct_to_actor+0x305/0x620 fs/splice.c:886
do_splice_direct+0xfb/0x180 fs/splice.c:974
do_sendfile+0x3bf/0x910 fs/read_write.c:1249
__do_sys_sendfile64 fs/read_write.c:1317 [inline]
__se_sys_sendfile64 fs/read_write.c:1303 [inline]
__x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1303
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
value changed: 0x0000000000000000 -> 0xffffea0004a1d288
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022 |
["https://git.kernel.org/stable/c/3261400639463a853ba2b3be8bd009c2a8089775","https://git.kernel.org/stable/c/6730c48ed6b0cd939fc9b30b2d621ce0b89bea83","https://git.kernel.org/stable/c/8527c9a6bf8e54fef0a8d3d7d8874a48c725c915","https://git.kernel.org/stable/c/3261400639463a853ba2b3be8bd009c2a8089775","https://git.kernel.org/stable/c/6730c48ed6b0cd939fc9b30b2d621ce0b89bea83","https://git.kernel.org/stable/c/8527c9a6bf8e54fef0a8d3d7d8874a48c725c915"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46858
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mptcp: pm: Fix uaf in __timer_delete_sync
There are two paths to access mptcp_pm_del_add_timer, result in a race
condition:
CPU1 CPU2
==== ====
net_rx_action
napi_poll netlink_sendmsg
__napi_poll netlink_unicast
process_backlog netlink_unicast_kernel
__netif_receive_skb genl_rcv
__netif_receive_skb_one_core netlink_rcv_skb
NF_HOOK genl_rcv_msg
ip_local_deliver_finish genl_family_rcv_msg
ip_protocol_deliver_rcu genl_family_rcv_msg_doit
tcp_v4_rcv mptcp_pm_nl_flush_addrs_doit
tcp_v4_do_rcv mptcp_nl_remove_addrs_list
tcp_rcv_established mptcp_pm_remove_addrs_and_subflows
tcp_data_queue remove_anno_list_by_saddr
mptcp_incoming_options mptcp_pm_del_add_timer
mptcp_pm_del_add_timer kfree(entry)
In remove_anno_list_by_saddr(running on CPU2), after leaving the critical
zone protected by "pm.lock", the entry will be released, which leads to the
occurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1).
Keeping a reference to add_timer inside the lock, and calling
sk_stop_timer_sync() with this reference, instead of "entry->add_timer".
Move list_del(&entry->list) to mptcp_pm_del_add_timer and inside the pm lock,
do not directly access any members of the entry outside the pm lock, which
can avoid similar "entry->x" uaf. |
["https://git.kernel.org/stable/c/12134a652b0a10064844ea235173e70246eba6dc","https://git.kernel.org/stable/c/3554482f4691571fc4b5490c17ae26896e62171c","https://git.kernel.org/stable/c/6452b162549c7f9ef54655d3fb9977b9192e6e5b","https://git.kernel.org/stable/c/67409b358500c71632116356a0b065f112d7b707","https://git.kernel.org/stable/c/b4cd80b0338945a94972ac3ed54f8338d2da2076"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26976
|
High |
fixed |
- 4.19.312
- 5.4.274
- 5.10.215
- 5.15.154
- 6.1.84
- 6.6.24
- 6.7.12
- 6.8.3
|
In the Linux kernel, the following vulnerability has been resolved:
KVM: Always flush async #PF workqueue when vCPU is being destroyed
Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its
completion queue, e.g. when a VM and all its vCPUs is being destroyed.
KVM must ensure that none of its workqueue callbacks is running when the
last reference to the KVM _module_ is put. Gifting a reference to the
associated VM prevents the workqueue callback from dereferencing freed
vCPU/VM memory, but does not prevent the KVM module from being unloaded
before the callback completes.
Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from
async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will
result in deadlock. async_pf_execute() can't return until kvm_put_kvm()
finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes:
WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm]
Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass
CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
Workqueue: events async_pf_execute [kvm]
RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm]
Call Trace:
<TASK>
async_pf_execute+0x198/0x260 [kvm]
process_one_work+0x145/0x2d0
worker_thread+0x27e/0x3a0
kthread+0xba/0xe0
ret_from_fork+0x2d/0x50
ret_from_fork_asm+0x11/0x20
</TASK>
---[ end trace 0000000000000000 ]---
INFO: task kworker/8:1:251 blocked for more than 120 seconds.
Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000
Workqueue: events async_pf_execute [kvm]
Call Trace:
<TASK>
__schedule+0x33f/0xa40
schedule+0x53/0xc0
schedule_timeout+0x12a/0x140
__wait_for_common+0x8d/0x1d0
__flush_work.isra.0+0x19f/0x2c0
kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm]
kvm_arch_destroy_vm+0x78/0x1b0 [kvm]
kvm_put_kvm+0x1c1/0x320 [kvm]
async_pf_execute+0x198/0x260 [kvm]
process_one_work+0x145/0x2d0
worker_thread+0x27e/0x3a0
kthread+0xba/0xe0
ret_from_fork+0x2d/0x50
ret_from_fork_asm+0x11/0x20
</TASK>
If kvm_clear_async_pf_completion_queue() actually flushes the workqueue,
then there's no need to gift async_pf_execute() a reference because all
invocations of async_pf_execute() will be forced to complete before the
vCPU and its VM are destroyed/freed. And that in turn fixes the module
unloading bug as __fput() won't do module_put() on the last vCPU reference
until the vCPU has been freed, e.g. if closing the vCPU file also puts the
last reference to the KVM module.
Note that kvm_check_async_pf_completion() may also take the work item off
the completion queue and so also needs to flush the work queue, as the
work will not be seen by kvm_clear_async_pf_completion_queue(). Waiting
on the workqueue could theoretically delay a vCPU due to waiting for the
work to complete, but that's a very, very small chance, and likely a very
small delay. kvm_arch_async_page_present_queued() unconditionally makes a
new request, i.e. will effectively delay entering the guest, so the
remaining work is really just:
trace_kvm_async_pf_completed(addr, cr2_or_gpa);
__kvm_vcpu_wake_up(vcpu);
mmput(mm);
and mmput() can't drop the last reference to the page tables if the vCPU is
still alive, i.e. the vCPU won't get stuck tearing down page tables.
Add a helper to do the flushing, specifically to deal with "wakeup all"
work items, as they aren't actually work items, i.e. are never placed in a
workqueue. Trying to flush a bogus workqueue entry rightly makes
__flush_work() complain (kudos to whoever added that sanity check).
Note, commit 5f6de5cbebee ("KVM: Prevent module exit until al
---truncated--- |
["https://git.kernel.org/stable/c/3d75b8aa5c29058a512db29da7cbee8052724157","https://git.kernel.org/stable/c/4f3a3bce428fb439c66a578adc447afce7b4a750","https://git.kernel.org/stable/c/82e25cc1c2e93c3023da98be282322fc08b61ffb","https://git.kernel.org/stable/c/83d3c5e309611ef593e2fcb78444fc8ceedf9bac","https://git.kernel.org/stable/c/a75afe480d4349c524d9c659b1a5a544dbc39a98","https://git.kernel.org/stable/c/ab2c2f5d9576112ad22cfd3798071cb74693b1f5","https://git.kernel.org/stable/c/b54478d20375874aeee257744dedfd3e413432ff","https://git.kernel.org/stable/c/caa9af2e27c275e089d702cfbaaece3b42bca31b","https://git.kernel.org/stable/c/f8730d6335e5f43d09151fca1f0f41922209a264","https://git.kernel.org/stable/c/3d75b8aa5c29058a512db29da7cbee8052724157","https://git.kernel.org/stable/c/4f3a3bce428fb439c66a578adc447afce7b4a750","https://git.kernel.org/stable/c/82e25cc1c2e93c3023da98be282322fc08b61ffb","https://git.kernel.org/stable/c/83d3c5e309611ef593e2fcb78444fc8ceedf9bac","https://git.kernel.org/stable/c/a75afe480d4349c524d9c659b1a5a544dbc39a98","https://git.kernel.org/stable/c/ab2c2f5d9576112ad22cfd3798071cb74693b1f5","https://git.kernel.org/stable/c/b54478d20375874aeee257744dedfd3e413432ff","https://git.kernel.org/stable/c/caa9af2e27c275e089d702cfbaaece3b42bca31b","https://git.kernel.org/stable/c/f8730d6335e5f43d09151fca1f0f41922209a264","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48639
|
Medium |
fixed |
- 5.4.215
- 5.10.146
- 5.15.71
- 5.19.12
|
In the Linux kernel, the following vulnerability has been resolved:
net: sched: fix possible refcount leak in tc_new_tfilter()
tfilter_put need to be called to put the refount got by tp->ops->get to
avoid possible refcount leak when chain->tmplt_ops != NULL and
chain->tmplt_ops != tp->ops. |
["https://git.kernel.org/stable/c/0559d91ee3a2cd81b15ad5cd507539d6da867f88","https://git.kernel.org/stable/c/8844c750eeb03452e2b3319c27a526f447b82596","https://git.kernel.org/stable/c/903f7d322c17d8e306d766404b4604e81653902a","https://git.kernel.org/stable/c/c2e1cfefcac35e0eea229e148c8284088ce437b5","https://git.kernel.org/stable/c/f8162aed962be8fa07445b2b5928e84ab40dd8d7","https://git.kernel.org/stable/c/0559d91ee3a2cd81b15ad5cd507539d6da867f88","https://git.kernel.org/stable/c/8844c750eeb03452e2b3319c27a526f447b82596","https://git.kernel.org/stable/c/903f7d322c17d8e306d766404b4604e81653902a","https://git.kernel.org/stable/c/c2e1cfefcac35e0eea229e148c8284088ce437b5","https://git.kernel.org/stable/c/f8162aed962be8fa07445b2b5928e84ab40dd8d7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52745
|
Medium |
fixed |
- 4.10
- 4.15
- 4.20
- 5.4.232
- 5.10.168
- 5.15.94
- 6.1
- 6.1.12
|
In the Linux kernel, the following vulnerability has been resolved:
IB/IPoIB: Fix legacy IPoIB due to wrong number of queues
The cited commit creates child PKEY interfaces over netlink will
multiple tx and rx queues, but some devices doesn't support more than 1
tx and 1 rx queues. This causes to a crash when traffic is sent over the
PKEY interface due to the parent having a single queue but the child
having multiple queues.
This patch fixes the number of queues to 1 for legacy IPoIB at the
earliest possible point in time.
BUG: kernel NULL pointer dereference, address: 000000000000036b
PGD 0 P4D 0
Oops: 0000 [#1] SMP
CPU: 4 PID: 209665 Comm: python3 Not tainted 6.1.0_for_upstream_min_debug_2022_12_12_17_02 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:kmem_cache_alloc+0xcb/0x450
Code: ce 7e 49 8b 50 08 49 83 78 10 00 4d 8b 28 0f 84 cb 02 00 00 4d 85 ed 0f 84 c2 02 00 00 41 8b 44 24 28 48 8d 4a
01 49 8b 3c 24 <49> 8b 5c 05 00 4c 89 e8 65 48 0f c7 0f 0f 94 c0 84 c0 74 b8 41 8b
RSP: 0018:ffff88822acbbab8 EFLAGS: 00010202
RAX: 0000000000000070 RBX: ffff8881c28e3e00 RCX: 00000000064f8dae
RDX: 00000000064f8dad RSI: 0000000000000a20 RDI: 0000000000030d00
RBP: 0000000000000a20 R08: ffff8882f5d30d00 R09: ffff888104032f40
R10: ffff88810fade828 R11: 736f6d6570736575 R12: ffff88810081c000
R13: 00000000000002fb R14: ffffffff817fc865 R15: 0000000000000000
FS: 00007f9324ff9700(0000) GS:ffff8882f5d00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000036b CR3: 00000001125af004 CR4: 0000000000370ea0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
skb_clone+0x55/0xd0
ip6_finish_output2+0x3fe/0x690
ip6_finish_output+0xfa/0x310
ip6_send_skb+0x1e/0x60
udp_v6_send_skb+0x1e5/0x420
udpv6_sendmsg+0xb3c/0xe60
? ip_mc_finish_output+0x180/0x180
? __switch_to_asm+0x3a/0x60
? __switch_to_asm+0x34/0x60
sock_sendmsg+0x33/0x40
__sys_sendto+0x103/0x160
? _copy_to_user+0x21/0x30
? kvm_clock_get_cycles+0xd/0x10
? ktime_get_ts64+0x49/0xe0
__x64_sys_sendto+0x25/0x30
do_syscall_64+0x3d/0x90
entry_SYSCALL_64_after_hwframe+0x46/0xb0
RIP: 0033:0x7f9374f1ed14
Code: 42 41 f8 ff 44 8b 4c 24 2c 4c 8b 44 24 20 89 c5 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b
7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 34 89 ef 48 89 44 24 08 e8 68 41 f8 ff 48 8b
RSP: 002b:00007f9324ff7bd0 EFLAGS: 00000293 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00007f9324ff7cc8 RCX: 00007f9374f1ed14
RDX: 00000000000002fb RSI: 00007f93000052f0 RDI: 0000000000000030
RBP: 0000000000000000 R08: 00007f9324ff7d40 R09: 000000000000001c
R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000
R13: 000000012a05f200 R14: 0000000000000001 R15: 00007f9374d57bdc
</TASK> |
["https://git.kernel.org/stable/c/1b4ef90cbcfa603b3bb536fbd6f261197012b6f6","https://git.kernel.org/stable/c/4a779187db39b2f32d048a752573e56e4e77807f","https://git.kernel.org/stable/c/7197460dcd43ff0e4a502ba855dd82d37c2848cc","https://git.kernel.org/stable/c/b1afb666c32931667c15ad1b58e7203f0119dcaf","https://git.kernel.org/stable/c/e632291a2dbce45a24cddeb5fe28fe71d724ba43","https://git.kernel.org/stable/c/1b4ef90cbcfa603b3bb536fbd6f261197012b6f6","https://git.kernel.org/stable/c/4a779187db39b2f32d048a752573e56e4e77807f","https://git.kernel.org/stable/c/7197460dcd43ff0e4a502ba855dd82d37c2848cc","https://git.kernel.org/stable/c/b1afb666c32931667c15ad1b58e7203f0119dcaf","https://git.kernel.org/stable/c/e632291a2dbce45a24cddeb5fe28fe71d724ba43"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44950
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
serial: sc16is7xx: fix invalid FIFO access with special register set
When enabling access to the special register set, Receiver time-out and
RHR interrupts can happen. In this case, the IRQ handler will try to read
from the FIFO thru the RHR register at address 0x00, but address 0x00 is
mapped to DLL register, resulting in erroneous FIFO reading.
Call graph example:
sc16is7xx_startup(): entry
sc16is7xx_ms_proc(): entry
sc16is7xx_set_termios(): entry
sc16is7xx_set_baud(): DLH/DLL = $009C --> access special register set
sc16is7xx_port_irq() entry --> IIR is 0x0C
sc16is7xx_handle_rx() entry
sc16is7xx_fifo_read(): --> unable to access FIFO (RHR) because it is
mapped to DLL (LCR=LCR_CONF_MODE_A)
sc16is7xx_set_baud(): exit --> Restore access to general register set
Fix the problem by claiming the efr_lock mutex when accessing the Special
register set. |
["https://git.kernel.org/stable/c/6a6730812220a9a5ce4003eb347da1ee5abd06b0","https://git.kernel.org/stable/c/7d3b793faaab1305994ce568b59d61927235f57b","https://git.kernel.org/stable/c/cc6a3f35bc9b3a8da1b195420a2e8d9fdadfa831","https://git.kernel.org/stable/c/dc5ead0e8fc5ef53b8553394d4aab60c277976b3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-29581
|
High |
fixed |
- 4.14.278
- 4.19.241
- 5.4.191
- 5.10.113
- 5.15.36
- 5.17.5
|
Improper Update of Reference Count vulnerability in net/sched of Linux Kernel allows local attacker to cause privilege escalation to root. This issue affects: Linux Kernel versions prior to 5.18; version 4.14 and later versions. |
["http://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html","http://packetstormsecurity.com/files/168191/Kernel-Live-Patch-Security-Notice-LSN-0089-1.html","http://www.openwall.com/lists/oss-security/2022/05/18/2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3db09e762dc79584a69c10d74a6b98f89a9979f8","https://kernel.dance/#3db09e762dc79584a69c10d74a6b98f89a9979f8","https://security.netapp.com/advisory/ntap-20220629-0005/","https://www.debian.org/security/2022/dsa-5173","http://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html","http://packetstormsecurity.com/files/168191/Kernel-Live-Patch-Security-Notice-LSN-0089-1.html","http://www.openwall.com/lists/oss-security/2022/05/18/2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3db09e762dc79584a69c10d74a6b98f89a9979f8","https://kernel.dance/#3db09e762dc79584a69c10d74a6b98f89a9979f8","https://security.netapp.com/advisory/ntap-20220629-0005/","https://www.debian.org/security/2022/dsa-5173"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44977
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Validate TA binary size
Add TA binary size validation to avoid OOB write.
(cherry picked from commit c0a04e3570d72aaf090962156ad085e37c62e442) |
["https://git.kernel.org/stable/c/50553ea7cbd3344fbf40afb065f6a2d38171c1ad","https://git.kernel.org/stable/c/5ab8793b9a6cc059f503cbe6fe596f80765e0f19","https://git.kernel.org/stable/c/c99769bceab4ecb6a067b9af11f9db281eea3e2a","https://git.kernel.org/stable/c/e562415248f402203e7fb6d8c38c1b32fa99220f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50257
|
High |
fixed |
- 5.15.171
- 6.1.116
- 6.6.60
- 6.11.7
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: Fix use-after-free in get_info()
ip6table_nat module unload has refcnt warning for UAF. call trace is:
WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80
Modules linked in: ip6table_nat(-)
CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:module_put+0x6f/0x80
Call Trace:
<TASK>
get_info+0x128/0x180
do_ip6t_get_ctl+0x6a/0x430
nf_getsockopt+0x46/0x80
ipv6_getsockopt+0xb9/0x100
rawv6_getsockopt+0x42/0x190
do_sock_getsockopt+0xaa/0x180
__sys_getsockopt+0x70/0xc0
__x64_sys_getsockopt+0x20/0x30
do_syscall_64+0xa2/0x1a0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Concurrent execution of module unload and get_info() trigered the warning.
The root cause is as follows:
cpu0 cpu1
module_exit
//mod->state = MODULE_STATE_GOING
ip6table_nat_exit
xt_unregister_template
kfree(t)
//removed from templ_list
getinfo()
t = xt_find_table_lock
list_for_each_entry(tmpl, &xt_templates[af]...)
if (strcmp(tmpl->name, name))
continue; //table not found
try_module_get
list_for_each_entry(t, &xt_net->tables[af]...)
return t; //not get refcnt
module_put(t->me) //uaf
unregister_pernet_subsys
//remove table from xt_net list
While xt_table module was going away and has been removed from
xt_templates list, we couldnt get refcnt of xt_table->me. Check
module in xt_net->tables list re-traversal to fix it. |
["https://git.kernel.org/stable/c/6a1f088f9807f5166f58902d26246d0b88da03a8","https://git.kernel.org/stable/c/ba22ea01348384df19cc1fabc7964be6e7189749","https://git.kernel.org/stable/c/bab3bb35c03b263c486833d50d50c081d9e9832b","https://git.kernel.org/stable/c/cb7c388b5967946f097afdb759b7c860305f2d96","https://git.kernel.org/stable/c/f48d258f0ac540f00fa617dac496c4c18b5dc2fa"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-2318
|
Medium |
fixed |
|
There are use-after-free vulnerabilities caused by timer handler in net/rose/rose_timer.c of linux that allow attackers to crash linux kernel without any privileges. |
["https://github.com/torvalds/linux/commit/9cc02ede696272c5271a401e4f27c262359bc2f6","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://security.netapp.com/advisory/ntap-20230120-0001/","https://www.debian.org/security/2022/dsa-5191","https://github.com/torvalds/linux/commit/9cc02ede696272c5271a401e4f27c262359bc2f6","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://security.netapp.com/advisory/ntap-20230120-0001/","https://www.debian.org/security/2022/dsa-5191"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35896
|
High |
fixed |
- 5.10.215
- 5.15.154
- 6.1.85
- 6.6.26
- 6.8.5
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: validate user input for expected length
I got multiple syzbot reports showing old bugs exposed
by BPF after commit 20f2505fb436 ("bpf: Try to avoid kzalloc
in cgroup/{s,g}etsockopt")
setsockopt() @optlen argument should be taken into account
before copying data.
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]
BUG: KASAN: slab-out-of-bounds in do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]
BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627
Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238
CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x169/0x550 mm/kasan/report.c:488
kasan_report+0x143/0x180 mm/kasan/report.c:601
kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
__asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105
copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
copy_from_sockptr include/linux/sockptr.h:55 [inline]
do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]
do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627
nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101
do_sock_setsockopt+0x3af/0x720 net/socket.c:2311
__sys_setsockopt+0x1ae/0x250 net/socket.c:2334
__do_sys_setsockopt net/socket.c:2343 [inline]
__se_sys_setsockopt net/socket.c:2340 [inline]
__x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
do_syscall_64+0xfb/0x240
entry_SYSCALL_64_after_hwframe+0x72/0x7a
RIP: 0033:0x7fd22067dde9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9
RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000
R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8
</TASK>
Allocated by task 7238:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
poison_kmalloc_redzone mm/kasan/common.c:370 [inline]
__kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387
kasan_kmalloc include/linux/kasan.h:211 [inline]
__do_kmalloc_node mm/slub.c:4069 [inline]
__kmalloc_noprof+0x200/0x410 mm/slub.c:4082
kmalloc_noprof include/linux/slab.h:664 [inline]
__cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869
do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293
__sys_setsockopt+0x1ae/0x250 net/socket.c:2334
__do_sys_setsockopt net/socket.c:2343 [inline]
__se_sys_setsockopt net/socket.c:2340 [inline]
__x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
do_syscall_64+0xfb/0x240
entry_SYSCALL_64_after_hwframe+0x72/0x7a
The buggy address belongs to the object at ffff88802cd73da0
which belongs to the cache kmalloc-8 of size 8
The buggy address is located 0 bytes inside of
allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1)
The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73
flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff)
page_type: 0xffffefff(slab)
raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122
raw: ffff88802cd73020 000000008080007f 00000001ffffefff 00
---truncated--- |
["https://git.kernel.org/stable/c/0c83842df40f86e529db6842231154772c20edcc","https://git.kernel.org/stable/c/0f038242b77ddfc505bf4163d4904c1abd2e74d6","https://git.kernel.org/stable/c/18aae2cb87e5faa9c5bd865260ceadac60d5a6c5","https://git.kernel.org/stable/c/440e948cf0eff32cfe322dcbca3f2525354b159b","https://git.kernel.org/stable/c/58f2bfb789e6bd3bc24a2c9c1580f3c67aec3018","https://git.kernel.org/stable/c/81d51b9b7c95e791ba3c1a2dd77920a9d3b3f525","https://git.kernel.org/stable/c/0c83842df40f86e529db6842231154772c20edcc","https://git.kernel.org/stable/c/0f038242b77ddfc505bf4163d4904c1abd2e74d6","https://git.kernel.org/stable/c/18aae2cb87e5faa9c5bd865260ceadac60d5a6c5","https://git.kernel.org/stable/c/440e948cf0eff32cfe322dcbca3f2525354b159b","https://git.kernel.org/stable/c/58f2bfb789e6bd3bc24a2c9c1580f3c67aec3018","https://git.kernel.org/stable/c/81d51b9b7c95e791ba3c1a2dd77920a9d3b3f525","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://security.netapp.com/advisory/ntap-20250321-0004/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-42722
|
Medium |
fixed |
|
In the Linux kernel 5.8 through 5.19.x before 5.19.16, local attackers able to inject WLAN frames into the mac80211 stack could cause a NULL pointer dereference denial-of-service attack against the beacon protection of P2P devices. |
["http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html","http://www.openwall.com/lists/oss-security/2022/10/13/5","https://bugzilla.suse.com/show_bug.cgi?id=1204125","https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=b2d03cabe2b2e150ff5a381731ea0355459be09f","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://security.netapp.com/advisory/ntap-20230203-0008/","https://www.debian.org/security/2022/dsa-5257","http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html","http://www.openwall.com/lists/oss-security/2022/10/13/5","https://bugzilla.suse.com/show_bug.cgi?id=1204125","https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=b2d03cabe2b2e150ff5a381731ea0355459be09f","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://security.netapp.com/advisory/ntap-20230203-0008/","https://www.debian.org/security/2022/dsa-5257"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36014
|
Medium |
fixed |
- 4.19.316
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/arm/malidp: fix a possible null pointer dereference
In malidp_mw_connector_reset, new memory is allocated with kzalloc, but
no check is performed. In order to prevent null pointer dereferencing,
ensure that mw_state is checked before calling
__drm_atomic_helper_connector_reset. |
["https://git.kernel.org/stable/c/335cc45ef2b81b68be63c698b4f867a530bdf7a5","https://git.kernel.org/stable/c/3e54d4e95120641216dfe91a6c49f116a9f68490","https://git.kernel.org/stable/c/565d9ad7e5a18eb69ed8b66a9e9bb3f45346520c","https://git.kernel.org/stable/c/93f76ec1eddce60dbb5885cbc0d7df54adee4639","https://git.kernel.org/stable/c/a1f95aede6285dba6dd036d907196f35ae3a11ea","https://git.kernel.org/stable/c/a5fa5b40a278a3ca978fed64707bd27614adb1eb","https://git.kernel.org/stable/c/b6cc5dd06336ed8bb3a7a1fc5aaf7d5e88bc0818","https://git.kernel.org/stable/c/b77620730f614059db2470e8ebab3e725280fc6d","https://git.kernel.org/stable/c/e4b52d49383306ef73fd1bd9102538beebb0fe07","https://git.kernel.org/stable/c/335cc45ef2b81b68be63c698b4f867a530bdf7a5","https://git.kernel.org/stable/c/3e54d4e95120641216dfe91a6c49f116a9f68490","https://git.kernel.org/stable/c/565d9ad7e5a18eb69ed8b66a9e9bb3f45346520c","https://git.kernel.org/stable/c/93f76ec1eddce60dbb5885cbc0d7df54adee4639","https://git.kernel.org/stable/c/a1f95aede6285dba6dd036d907196f35ae3a11ea","https://git.kernel.org/stable/c/a5fa5b40a278a3ca978fed64707bd27614adb1eb","https://git.kernel.org/stable/c/b6cc5dd06336ed8bb3a7a1fc5aaf7d5e88bc0818","https://git.kernel.org/stable/c/b77620730f614059db2470e8ebab3e725280fc6d","https://git.kernel.org/stable/c/e4b52d49383306ef73fd1bd9102538beebb0fe07"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42288
|
Medium |
fixed |
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix for possible memory corruption
Init Control Block is dereferenced incorrectly. Correctly dereference ICB |
["https://git.kernel.org/stable/c/2a15b59a2c5afac89696e44acf5bbfc0599c6c5e","https://git.kernel.org/stable/c/571d7f2a08836698c2fb0d792236424575b9829b","https://git.kernel.org/stable/c/8192c533e89d9fb69b2490398939236b78cda79b","https://git.kernel.org/stable/c/87db8d7b7520e99de71791260989f06f9c94953d","https://git.kernel.org/stable/c/b0302ffc74123b6a99d7d1896fcd9b2e4072d9ce","https://git.kernel.org/stable/c/c03d740152f78e86945a75b2ad541bf972fab92a","https://git.kernel.org/stable/c/dae67169cb35a37ecccf60cfcd6bf93a1f4f5efb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43894
|
Medium |
fixed |
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.105
- 6.6.46
- 6.10.5
|
In the Linux kernel, the following vulnerability has been resolved:
drm/client: fix null pointer dereference in drm_client_modeset_probe
In drm_client_modeset_probe(), the return value of drm_mode_duplicate() is
assigned to modeset->mode, which will lead to a possible NULL pointer
dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. |
["https://git.kernel.org/stable/c/113fd6372a5bb3689aba8ef5b8a265ed1529a78f","https://git.kernel.org/stable/c/24ddda932c43ffe156c7f3c568bed85131c63ae6","https://git.kernel.org/stable/c/5291d4f73452c91e8a11f71207617e3e234d418e","https://git.kernel.org/stable/c/612cae53e99ce32a58cb821b3b67199eb6e92dff","https://git.kernel.org/stable/c/c763dfe09425152b6bb0e348900a637c62c2ce52","https://git.kernel.org/stable/c/d64847c383100423aecb6ac5f18be5f4316d9d62","https://git.kernel.org/stable/c/d64fc94f7bb24fc2be0d6bd5df8df926da461a6d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2016-0774
|
Medium |
|
N/A
|
The (1) pipe_read and (2) pipe_write implementations in fs/pipe.c in a certain Linux kernel backport in the linux package before 3.2.73-2+deb7u3 on Debian wheezy and the kernel package before 3.10.0-229.26.2 on Red Hat Enterprise Linux (RHEL) 7.1 do not properly consider the side effects of failed __copy_to_user_inatomic and __copy_from_user_inatomic calls, which allows local users to cause a denial of service (system crash) or possibly gain privileges via a crafted application, aka an "I/O vector array overrun." NOTE: this vulnerability exists because of an incorrect fix for CVE-2015-1805. |
["http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00025.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00026.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00027.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00028.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00029.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00030.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00031.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00032.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00033.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00034.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00036.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00037.html","http://rhn.redhat.com/errata/RHSA-2016-0494.html","http://rhn.redhat.com/errata/RHSA-2016-0617.html","http://source.android.com/security/bulletin/2016-05-01.html","http://www.debian.org/security/2016/dsa-3503","http://www.oracle.com/technetwork/topics/security/linuxbulletinapr2016-2952096.html","http://www.securityfocus.com/bid/84126","http://www.ubuntu.com/usn/USN-2967-1","http://www.ubuntu.com/usn/USN-2967-2","http://www.ubuntu.com/usn/USN-2968-1","http://www.ubuntu.com/usn/USN-2968-2","https://bugzilla.redhat.com/show_bug.cgi?id=1303961","https://security-tracker.debian.org/tracker/CVE-2016-0774","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00025.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00026.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00027.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00028.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00029.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00030.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00031.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00032.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00033.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00034.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00036.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00037.html","http://rhn.redhat.com/errata/RHSA-2016-0494.html","http://rhn.redhat.com/errata/RHSA-2016-0617.html","http://source.android.com/security/bulletin/2016-05-01.html","http://www.debian.org/security/2016/dsa-3503","http://www.oracle.com/technetwork/topics/security/linuxbulletinapr2016-2952096.html","http://www.securityfocus.com/bid/84126","http://www.ubuntu.com/usn/USN-2967-1","http://www.ubuntu.com/usn/USN-2967-2","http://www.ubuntu.com/usn/USN-2968-1","http://www.ubuntu.com/usn/USN-2968-2","https://bugzilla.redhat.com/show_bug.cgi?id=1303961","https://security-tracker.debian.org/tracker/CVE-2016-0774"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35843
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Use device rbtree in iopf reporting path
The existing I/O page fault handler currently locates the PCI device by
calling pci_get_domain_bus_and_slot(). This function searches the list
of all PCI devices until the desired device is found. To improve lookup
efficiency, replace it with device_rbtree_find() to search the device
within the probed device rbtree.
The I/O page fault is initiated by the device, which does not have any
synchronization mechanism with the software to ensure that the device
stays in the probed device tree. Theoretically, a device could be released
by the IOMMU subsystem after device_rbtree_find() and before
iopf_get_dev_fault_param(), which would cause a use-after-free problem.
Add a mutex to synchronize the I/O page fault reporting path and the IOMMU
release device path. This lock doesn't introduce any performance overhead,
as the conflict between I/O page fault reporting and device releasing is
very rare. |
["https://git.kernel.org/stable/c/3d39238991e745c5df85785604f037f35d9d1b15","https://git.kernel.org/stable/c/def054b01a867822254e1dda13d587f5c7a99e2a","https://git.kernel.org/stable/c/3d39238991e745c5df85785604f037f35d9d1b15","https://git.kernel.org/stable/c/def054b01a867822254e1dda13d587f5c7a99e2a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-43750
|
Medium |
fixed |
- 4.9.331
- 4.14.296
- 4.19.262
- 5.4.218
- 5.10.148
- 5.15.73
- 5.19.15
- 6.0.1
|
drivers/usb/mon/mon_bin.c in usbmon in the Linux kernel before 5.19.15 and 6.x before 6.0.1 allows a user-space client to corrupt the monitor's internal memory. |
["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.15","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.0.1","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a659daf63d16aa883be42f3f34ff84235c302198","https://github.com/torvalds/linux/commit/a659daf63d16aa883be42f3f34ff84235c302198","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.15","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.0.1","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a659daf63d16aa883be42f3f34ff84235c302198","https://github.com/torvalds/linux/commit/a659daf63d16aa883be42f3f34ff84235c302198","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43892
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
memcg: protect concurrent access to mem_cgroup_idr
Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after
many small jobs") decoupled the memcg IDs from the CSS ID space to fix the
cgroup creation failures. It introduced IDR to maintain the memcg ID
space. The IDR depends on external synchronization mechanisms for
modifications. For the mem_cgroup_idr, the idr_alloc() and idr_replace()
happen within css callback and thus are protected through cgroup_mutex
from concurrent modifications. However idr_remove() for mem_cgroup_idr
was not protected against concurrency and can be run concurrently for
different memcgs when they hit their refcnt to zero. Fix that.
We have been seeing list_lru based kernel crashes at a low frequency in
our fleet for a long time. These crashes were in different part of
list_lru code including list_lru_add(), list_lru_del() and reparenting
code. Upon further inspection, it looked like for a given object (dentry
and inode), the super_block's list_lru didn't have list_lru_one for the
memcg of that object. The initial suspicions were either the object is
not allocated through kmem_cache_alloc_lru() or somehow
memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but
returned success. No evidence were found for these cases.
Looking more deeply, we started seeing situations where valid memcg's id
is not present in mem_cgroup_idr and in some cases multiple valid memcgs
have same id and mem_cgroup_idr is pointing to one of them. So, the most
reasonable explanation is that these situations can happen due to race
between multiple idr_remove() calls or race between
idr_alloc()/idr_replace() and idr_remove(). These races are causing
multiple memcgs to acquire the same ID and then offlining of one of them
would cleanup list_lrus on the system for all of them. Later access from
other memcgs to the list_lru cause crashes due to missing list_lru_one. |
["https://git.kernel.org/stable/c/37a060b64ae83b76600d187d76591ce488ab836b","https://git.kernel.org/stable/c/51c0b1bb7541f8893ec1accba59eb04361a70946","https://git.kernel.org/stable/c/56fd70f4aa8b82199dbe7e99366b1fd7a04d86fb","https://git.kernel.org/stable/c/912736a0435ef40e6a4ae78197ccb5553cb80b05","https://git.kernel.org/stable/c/9972605a238339b85bd16b084eed5f18414d22db","https://git.kernel.org/stable/c/e6cc9ff2ac0b5df9f25eb790934c3104f6710278"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52857
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Fix coverity issue with unintentional integer overflow
1. Instead of multiplying 2 variable of different types. Change to
assign a value of one variable and then multiply the other variable.
2. Add a int variable for multiplier calculation instead of calculating
different types multiplier with dma_addr_t variable directly. |
["https://git.kernel.org/stable/c/0d8a1df39d3fc34560e2cc663b5c340d06a25396","https://git.kernel.org/stable/c/96312a251d4dcee5d36e32edba3002bfde0ddd9c","https://git.kernel.org/stable/c/a12bd675100531f9fb4508fd4430dd1632325a0e","https://git.kernel.org/stable/c/b0b0d811eac6b4c52cb9ad632fa6384cf48869e7","https://git.kernel.org/stable/c/0d8a1df39d3fc34560e2cc663b5c340d06a25396","https://git.kernel.org/stable/c/96312a251d4dcee5d36e32edba3002bfde0ddd9c","https://git.kernel.org/stable/c/b0b0d811eac6b4c52cb9ad632fa6384cf48869e7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36923
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
fs/9p: fix uninitialized values during inode evict
If an iget fails due to not being able to retrieve information
from the server then the inode structure is only partially
initialized. When the inode gets evicted, references to
uninitialized structures (like fscache cookies) were being
made.
This patch checks for a bad_inode before doing anything other
than clearing the inode from the cache. Since the inode is
bad, it shouldn't have any state associated with it that needs
to be written back (and there really isn't a way to complete
those anyways). |
["https://git.kernel.org/stable/c/18cf7026355187b8d2b4cdfed61dbf873e9d29ff","https://git.kernel.org/stable/c/1b4cb6e91f19b81217ad98142ee53a1ab25893fd","https://git.kernel.org/stable/c/3a741b80b3457f079cf637e47800fb7bf8038ad6","https://git.kernel.org/stable/c/6630036b7c228f57c7893ee0403e92c2db2cd21d","https://git.kernel.org/stable/c/1b4cb6e91f19b81217ad98142ee53a1ab25893fd","https://git.kernel.org/stable/c/6630036b7c228f57c7893ee0403e92c2db2cd21d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40995
|
Medium |
fixed |
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.96
- 6.6.36
- 6.9.7
|
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()
syzbot found hanging tasks waiting on rtnl_lock [1]
A reproducer is available in the syzbot bug.
When a request to add multiple actions with the same index is sent, the
second request will block forever on the first request. This holds
rtnl_lock, and causes tasks to hang.
Return -EAGAIN to prevent infinite looping, while keeping documented
behavior.
[1]
INFO: task kworker/1:0:5088 blocked for more than 143 seconds.
Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000
Workqueue: events_power_efficient reg_check_chans_work
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5409 [inline]
__schedule+0xf15/0x5d00 kernel/sched/core.c:6746
__schedule_loop kernel/sched/core.c:6823 [inline]
schedule+0xe7/0x350 kernel/sched/core.c:6838
schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895
__mutex_lock_common kernel/locking/mutex.c:684 [inline]
__mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752
wiphy_lock include/net/cfg80211.h:5953 [inline]
reg_leave_invalid_chans net/wireless/reg.c:2466 [inline]
reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481 |
["https://git.kernel.org/stable/c/0d8a2d287c8a394c0d4653f0c6c7be4c688e5a74","https://git.kernel.org/stable/c/25987a97eec4d5f897cd04ee1b45170829c610da","https://git.kernel.org/stable/c/5f926aa96b08b6c47178fe1171e7ae331c695fc2","https://git.kernel.org/stable/c/6fc78d67f51aeb9a542d39a8714e16bc411582d4","https://git.kernel.org/stable/c/7a0e497b597df7c4cf2b63fc6e9188b6cabe5335","https://git.kernel.org/stable/c/c6a7da65a296745535a964be1019ec7691b0cb90","https://git.kernel.org/stable/c/d864319871b05fadd153e0aede4811ca7008f5d6","https://git.kernel.org/stable/c/0d8a2d287c8a394c0d4653f0c6c7be4c688e5a74","https://git.kernel.org/stable/c/25987a97eec4d5f897cd04ee1b45170829c610da","https://git.kernel.org/stable/c/5f926aa96b08b6c47178fe1171e7ae331c695fc2","https://git.kernel.org/stable/c/6fc78d67f51aeb9a542d39a8714e16bc411582d4","https://git.kernel.org/stable/c/7a0e497b597df7c4cf2b63fc6e9188b6cabe5335","https://git.kernel.org/stable/c/c6a7da65a296745535a964be1019ec7691b0cb90","https://git.kernel.org/stable/c/d864319871b05fadd153e0aede4811ca7008f5d6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48642
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: fix percpu memory leak at nf_tables_addchain()
It seems to me that percpu memory for chain stats started leaking since
commit 3bc158f8d0330f0a ("netfilter: nf_tables: map basechain priority to
hardware priority") when nft_chain_offload_priority() returned an error. |
["https://git.kernel.org/stable/c/08d7524f366a886b99b1630a24a27dd6e0d7f852","https://git.kernel.org/stable/c/985b031667c3177b9e7fb9787b989628e4271714","https://git.kernel.org/stable/c/9a4d6dd554b86e65581ef6b6638a39ae079b17ac","https://git.kernel.org/stable/c/b043a525a3f5520abb676a7cd8f6328fdf959e88","https://git.kernel.org/stable/c/08d7524f366a886b99b1630a24a27dd6e0d7f852","https://git.kernel.org/stable/c/985b031667c3177b9e7fb9787b989628e4271714","https://git.kernel.org/stable/c/9a4d6dd554b86e65581ef6b6638a39ae079b17ac","https://git.kernel.org/stable/c/b043a525a3f5520abb676a7cd8f6328fdf959e88"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52702
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix possible memory leak in ovs_meter_cmd_set()
old_meter needs to be free after it is detached regardless of whether
the new meter is successfully attached. |
["https://git.kernel.org/stable/c/1563e998a938f095548054ef09e277b562b79536","https://git.kernel.org/stable/c/2fa28f5c6fcbfc794340684f36d2581b4f2d20b5","https://git.kernel.org/stable/c/c0f65ee0a3329eb4b94beaef0268633696e2d0c6","https://git.kernel.org/stable/c/e336a9e08618203a456fb5367f1387b14554f55e","https://git.kernel.org/stable/c/1563e998a938f095548054ef09e277b562b79536","https://git.kernel.org/stable/c/2fa28f5c6fcbfc794340684f36d2581b4f2d20b5","https://git.kernel.org/stable/c/c0f65ee0a3329eb4b94beaef0268633696e2d0c6","https://git.kernel.org/stable/c/e336a9e08618203a456fb5367f1387b14554f55e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49013
|
Medium |
fixed |
- 5.4.226
- 5.10.158
- 5.15.82
- 6.0.12
|
In the Linux kernel, the following vulnerability has been resolved:
sctp: fix memory leak in sctp_stream_outq_migrate()
When sctp_stream_outq_migrate() is called to release stream out resources,
the memory pointed to by prio_head in stream out is not released.
The memory leak information is as follows:
unreferenced object 0xffff88801fe79f80 (size 64):
comm "sctp_repo", pid 7957, jiffies 4294951704 (age 36.480s)
hex dump (first 32 bytes):
80 9f e7 1f 80 88 ff ff 80 9f e7 1f 80 88 ff ff ................
90 9f e7 1f 80 88 ff ff 90 9f e7 1f 80 88 ff ff ................
backtrace:
[<ffffffff81b215c6>] kmalloc_trace+0x26/0x60
[<ffffffff88ae517c>] sctp_sched_prio_set+0x4cc/0x770
[<ffffffff88ad64f2>] sctp_stream_init_ext+0xd2/0x1b0
[<ffffffff88aa2604>] sctp_sendmsg_to_asoc+0x1614/0x1a30
[<ffffffff88ab7ff1>] sctp_sendmsg+0xda1/0x1ef0
[<ffffffff87f765ed>] inet_sendmsg+0x9d/0xe0
[<ffffffff8754b5b3>] sock_sendmsg+0xd3/0x120
[<ffffffff8755446a>] __sys_sendto+0x23a/0x340
[<ffffffff87554651>] __x64_sys_sendto+0xe1/0x1b0
[<ffffffff89978b49>] do_syscall_64+0x39/0xb0
[<ffffffff89a0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcd |
["https://git.kernel.org/stable/c/0dfb9a566327182387c90100ea54d8426cee8c67","https://git.kernel.org/stable/c/176ee6c673ccd118e9392fd2dbb165423bdb99ca","https://git.kernel.org/stable/c/9ed7bfc79542119ac0a9e1ce8a2a5285e43433e9","https://git.kernel.org/stable/c/a7555681e50bdebed2c40ff7404ee73c2e932993","https://git.kernel.org/stable/c/fa20f88271259d42ebe66f0a8c4c20199e888c99"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52618
|
Medium |
fixed |
- 5.10.210
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
block/rnbd-srv: Check for unlikely string overflow
Since "dev_search_path" can technically be as large as PATH_MAX,
there was a risk of truncation when copying it and a second string
into "full_path" since it was also PATH_MAX sized. The W=1 builds were
reporting this warning:
drivers/block/rnbd/rnbd-srv.c: In function 'process_msg_open.isra':
drivers/block/rnbd/rnbd-srv.c:616:51: warning: '%s' directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=]
616 | snprintf(full_path, PATH_MAX, "%s/%s",
| ^~
In function 'rnbd_srv_get_full_path',
inlined from 'process_msg_open.isra' at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: 'snprintf' output between 2 and 4351 bytes into a destination of size 4096
616 | snprintf(full_path, PATH_MAX, "%s/%s",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
617 | dev_search_path, dev_name);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
To fix this, unconditionally check for truncation (as was already done
for the case where "%SESSNAME%" was present). |
["https://git.kernel.org/stable/c/5b9ea86e662035a886ccb5c76d56793cba618827","https://git.kernel.org/stable/c/95bc866c11974d3e4a9d922275ea8127ff809cf7","https://git.kernel.org/stable/c/9e4bf6a08d1e127bcc4bd72557f2dfafc6bc7f41","https://git.kernel.org/stable/c/a2c6206f18104fba7f887bf4dbbfe4c41adc4339","https://git.kernel.org/stable/c/af7bbdac89739e2e7380387fda598848d3b7010f","https://git.kernel.org/stable/c/f6abd5e17da33eba15df2bddc93413e76c2b55f7","https://git.kernel.org/stable/c/5b9ea86e662035a886ccb5c76d56793cba618827","https://git.kernel.org/stable/c/95bc866c11974d3e4a9d922275ea8127ff809cf7","https://git.kernel.org/stable/c/9e4bf6a08d1e127bcc4bd72557f2dfafc6bc7f41","https://git.kernel.org/stable/c/a2c6206f18104fba7f887bf4dbbfe4c41adc4339","https://git.kernel.org/stable/c/af7bbdac89739e2e7380387fda598848d3b7010f","https://git.kernel.org/stable/c/f6abd5e17da33eba15df2bddc93413e76c2b55f7","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48638
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
cgroup: cgroup_get_from_id() must check the looked-up kn is a directory
cgroup has to be one kernfs dir, otherwise kernel panic is caused,
especially cgroup id is provide from userspace. |
["https://git.kernel.org/stable/c/1e9571887f97b17cf3ffe9aa4da89090ea60988b","https://git.kernel.org/stable/c/8484a356cee8ce3d6a8e6266ff99be326e9273ad","https://git.kernel.org/stable/c/df02452f3df069a59bc9e69c84435bf115cb6e37","https://git.kernel.org/stable/c/1e9571887f97b17cf3ffe9aa4da89090ea60988b","https://git.kernel.org/stable/c/8484a356cee8ce3d6a8e6266ff99be326e9273ad","https://git.kernel.org/stable/c/df02452f3df069a59bc9e69c84435bf115cb6e37"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26958
|
High |
fixed |
- 5.10.215
- 5.15.154
- 6.1.84
- 6.6.24
- 6.7.12
- 6.8.3
|
In the Linux kernel, the following vulnerability has been resolved:
nfs: fix UAF in direct writes
In production we have been hitting the following warning consistently
------------[ cut here ]------------
refcount_t: underflow; use-after-free.
WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0
Workqueue: nfsiod nfs_direct_write_schedule_work [nfs]
RIP: 0010:refcount_warn_saturate+0x9c/0xe0
PKRU: 55555554
Call Trace:
<TASK>
? __warn+0x9f/0x130
? refcount_warn_saturate+0x9c/0xe0
? report_bug+0xcc/0x150
? handle_bug+0x3d/0x70
? exc_invalid_op+0x16/0x40
? asm_exc_invalid_op+0x16/0x20
? refcount_warn_saturate+0x9c/0xe0
nfs_direct_write_schedule_work+0x237/0x250 [nfs]
process_one_work+0x12f/0x4a0
worker_thread+0x14e/0x3b0
? ZSTD_getCParams_internal+0x220/0x220
kthread+0xdc/0x120
? __btf_name_valid+0xa0/0xa0
ret_from_fork+0x1f/0x30
This is because we're completing the nfs_direct_request twice in a row.
The source of this is when we have our commit requests to submit, we
process them and send them off, and then in the completion path for the
commit requests we have
if (nfs_commit_end(cinfo.mds))
nfs_direct_write_complete(dreq);
However since we're submitting asynchronous requests we sometimes have
one that completes before we submit the next one, so we end up calling
complete on the nfs_direct_request twice.
The only other place we use nfs_generic_commit_list() is in
__nfs_commit_inode, which wraps this call in a
nfs_commit_begin();
nfs_commit_end();
Which is a common pattern for this style of completion handling, one
that is also repeated in the direct code with get_dreq()/put_dreq()
calls around where we process events as well as in the completion paths.
Fix this by using the same pattern for the commit requests.
Before with my 200 node rocksdb stress running this warning would pop
every 10ish minutes. With my patch the stress test has been running for
several hours without popping. |
["https://git.kernel.org/stable/c/17f46b803d4f23c66cacce81db35fef3adb8f2af","https://git.kernel.org/stable/c/1daf52b5ffb24870fbeda20b4967526d8f9e12ab","https://git.kernel.org/stable/c/3abc2d160ed8213948b147295d77d44a22c88fa3","https://git.kernel.org/stable/c/4595d90b5d2ea5fa4d318d13f59055aa4bf3e7f5","https://git.kernel.org/stable/c/80d24b308b7ee7037fc90d8ac99f6f78df0a256f","https://git.kernel.org/stable/c/cf54f66e1dd78990ec6b32177bca7e6ea2144a95","https://git.kernel.org/stable/c/e25447c35f8745337ea8bc0c9697fcac14df8605","https://git.kernel.org/stable/c/17f46b803d4f23c66cacce81db35fef3adb8f2af","https://git.kernel.org/stable/c/1daf52b5ffb24870fbeda20b4967526d8f9e12ab","https://git.kernel.org/stable/c/3abc2d160ed8213948b147295d77d44a22c88fa3","https://git.kernel.org/stable/c/4595d90b5d2ea5fa4d318d13f59055aa4bf3e7f5","https://git.kernel.org/stable/c/80d24b308b7ee7037fc90d8ac99f6f78df0a256f","https://git.kernel.org/stable/c/cf54f66e1dd78990ec6b32177bca7e6ea2144a95","https://git.kernel.org/stable/c/e25447c35f8745337ea8bc0c9697fcac14df8605","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35929
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
rcu/nocb: Fix WARN_ON_ONCE() in the rcu_nocb_bypass_lock()
For the kernels built with CONFIG_RCU_NOCB_CPU_DEFAULT_ALL=y and
CONFIG_RCU_LAZY=y, the following scenarios will trigger WARN_ON_ONCE()
in the rcu_nocb_bypass_lock() and rcu_nocb_wait_contended() functions:
CPU2 CPU11
kthread
rcu_nocb_cb_kthread ksys_write
rcu_do_batch vfs_write
rcu_torture_timer_cb proc_sys_write
__kmem_cache_free proc_sys_call_handler
kmemleak_free drop_caches_sysctl_handler
delete_object_full drop_slab
__delete_object shrink_slab
put_object lazy_rcu_shrink_scan
call_rcu rcu_nocb_flush_bypass
__call_rcu_commn rcu_nocb_bypass_lock
raw_spin_trylock(&rdp->nocb_bypass_lock) fail
atomic_inc(&rdp->nocb_lock_contended);
rcu_nocb_wait_contended WARN_ON_ONCE(smp_processor_id() != rdp->cpu);
WARN_ON_ONCE(atomic_read(&rdp->nocb_lock_contended)) |
|_ _ _ _ _ _ _ _ _ _same rdp and rdp->cpu != 11_ _ _ _ _ _ _ _ _ __|
Reproduce this bug with "echo 3 > /proc/sys/vm/drop_caches".
This commit therefore uses rcu_nocb_try_flush_bypass() instead of
rcu_nocb_flush_bypass() in lazy_rcu_shrink_scan(). If the nocb_bypass
queue is being flushed, then rcu_nocb_try_flush_bypass will return
directly. |
["https://git.kernel.org/stable/c/4d58c9fb45c70e62c19e8be3f3605889c47601bc","https://git.kernel.org/stable/c/927d1f4f77e4784ab3944a9df86ab14d1cd3185a","https://git.kernel.org/stable/c/dda98810b552fc6bf650f4270edeebdc2f28bd3f","https://git.kernel.org/stable/c/4d58c9fb45c70e62c19e8be3f3605889c47601bc","https://git.kernel.org/stable/c/927d1f4f77e4784ab3944a9df86ab14d1cd3185a","https://git.kernel.org/stable/c/dda98810b552fc6bf650f4270edeebdc2f28bd3f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36921
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: guard against invalid STA ID on removal
Guard against invalid station IDs in iwl_mvm_mld_rm_sta_id as that would
result in out-of-bounds array accesses. This prevents issues should the
driver get into a bad state during error handling. |
["https://git.kernel.org/stable/c/17f64517bf5c26af56b6c3566273aad6646c3c4f","https://git.kernel.org/stable/c/94f80a8ec15e238b78521f20f8afaed60521a294","https://git.kernel.org/stable/c/fab21d220017daa5fd8a3d788ff25ccfecfaae2f","https://git.kernel.org/stable/c/17f64517bf5c26af56b6c3566273aad6646c3c4f","https://git.kernel.org/stable/c/94f80a8ec15e238b78521f20f8afaed60521a294","https://git.kernel.org/stable/c/fab21d220017daa5fd8a3d788ff25ccfecfaae2f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42301
|
High |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
dev/parport: fix the array out-of-bounds risk
Fixed array out-of-bounds issues caused by sprintf
by replacing it with snprintf for safer data copying,
ensuring the destination buffer is not overflowed.
Below is the stack trace I encountered during the actual issue:
[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:
Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport]
[ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:
QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2
[ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp
[ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun
PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024
[ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:
[ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0
[ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20
[ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c
[ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc
[ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38
[ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport] |
["https://git.kernel.org/stable/c/166a0bddcc27de41fe13f861c8348e8e53e988c8","https://git.kernel.org/stable/c/47b3dce100778001cd76f7e9188944b5cb27a76d","https://git.kernel.org/stable/c/7789a1d6792af410aa9b39a1eb237ed24fa2170a","https://git.kernel.org/stable/c/7f4da759092a1a6ce35fb085182d02de8cc4cc84","https://git.kernel.org/stable/c/a44f88f7576bc1916d8d6293f5c62fbe7cbe03e0","https://git.kernel.org/stable/c/ab11dac93d2d568d151b1918d7b84c2d02bacbd5","https://git.kernel.org/stable/c/b579ea3516c371ecf59d073772bc45dfd28c8a0e","https://git.kernel.org/stable/c/c719b393374d3763e64900ee19aaed767d5a08d6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42302
|
High |
fixed |
- 5.10.224
- 5.15.165
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
PCI/DPC: Fix use-after-free on concurrent DPC and hot-removal
Keith reports a use-after-free when a DPC event occurs concurrently to
hot-removal of the same portion of the hierarchy:
The dpc_handler() awaits readiness of the secondary bus below the
Downstream Port where the DPC event occurred. To do so, it polls the
config space of the first child device on the secondary bus. If that
child device is concurrently removed, accesses to its struct pci_dev
cause the kernel to oops.
That's because pci_bridge_wait_for_secondary_bus() neglects to hold a
reference on the child device. Before v6.3, the function was only
called on resume from system sleep or on runtime resume. Holding a
reference wasn't necessary back then because the pciehp IRQ thread
could never run concurrently. (On resume from system sleep, IRQs are
not enabled until after the resume_noirq phase. And runtime resume is
always awaited before a PCI device is removed.)
However starting with v6.3, pci_bridge_wait_for_secondary_bus() is also
called on a DPC event. Commit 53b54ad074de ("PCI/DPC: Await readiness
of secondary bus after reset"), which introduced that, failed to
appreciate that pci_bridge_wait_for_secondary_bus() now needs to hold a
reference on the child device because dpc_handler() and pciehp may
indeed run concurrently. The commit was backported to v5.10+ stable
kernels, so that's the oldest one affected.
Add the missing reference acquisition.
Abridged stack trace:
BUG: unable to handle page fault for address: 00000000091400c0
CPU: 15 PID: 2464 Comm: irq/53-pcie-dpc 6.9.0
RIP: pci_bus_read_config_dword+0x17/0x50
pci_dev_wait()
pci_bridge_wait_for_secondary_bus()
dpc_reset_link()
pcie_do_recovery()
dpc_handler() |
["https://git.kernel.org/stable/c/11a1f4bc47362700fcbde717292158873fb847ed","https://git.kernel.org/stable/c/2c111413f38ca5cf87557cab89f6d82b0e3433e7","https://git.kernel.org/stable/c/2cc8973bdc4d6c928ebe38b88090a2cdfe81f42f","https://git.kernel.org/stable/c/b16f3ea1db47a6766a9f1169244cf1fc287a7c62","https://git.kernel.org/stable/c/c52f9e1a9eb40f13993142c331a6cfd334d4b91d","https://git.kernel.org/stable/c/f63df70b439bb8331358a306541893bf415bf1da"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43858
|
High |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
jfs: Fix array-index-out-of-bounds in diFree |
["https://git.kernel.org/stable/c/538a27c8048f081a5ddd286f886eb986fbbc7f80","https://git.kernel.org/stable/c/55b732c8b09b41148eaab2fa8e31b0af47671e00","https://git.kernel.org/stable/c/63f7fdf733add82f126ea00e2e48f6eba15ac4b9","https://git.kernel.org/stable/c/6aa6892a90a5a7fabffe5692ab9f06a7a46c6e42","https://git.kernel.org/stable/c/8d8f9a477de0d7962342eedf2a599215b7c63d28","https://git.kernel.org/stable/c/9b3a4345957f5372041bc4f59de322f62653e862","https://git.kernel.org/stable/c/f73f969b2eb39ad8056f6c7f3a295fa2f85e313a","https://git.kernel.org/stable/c/ff14eadc278663cac69d57d3ca7fb2f394e1f8a7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46813
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check link_index before accessing dc->links[]
[WHY & HOW]
dc->links[] has max size of MAX_LINKS and NULL is return when trying to
access with out-of-bound index.
This fixes 3 OVERRUN and 1 RESOURCE_LEAK issues reported by Coverity. |
["https://git.kernel.org/stable/c/032c5407a608ac3b2a98bf4fbda27d12c20c5887","https://git.kernel.org/stable/c/8aa2864044b9d13e95fe224f32e808afbf79ecdf","https://git.kernel.org/stable/c/ac04759b4a002969cf0f1384f1b8bb2001cfa782"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48691
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: clean up hook list when offload flags check fails
splice back the hook list so nft_chain_release_hook() has a chance to
release the hooks.
BUG: memory leak
unreferenced object 0xffff88810180b100 (size 96):
comm "syz-executor133", pid 3619, jiffies 4294945714 (age 12.690s)
hex dump (first 32 bytes):
28 64 23 02 81 88 ff ff 28 64 23 02 81 88 ff ff (d#.....(d#.....
90 a8 aa 83 ff ff ff ff 00 00 b5 0f 81 88 ff ff ................
backtrace:
[<ffffffff83a8c59b>] kmalloc include/linux/slab.h:600 [inline]
[<ffffffff83a8c59b>] nft_netdev_hook_alloc+0x3b/0xc0 net/netfilter/nf_tables_api.c:1901
[<ffffffff83a9239a>] nft_chain_parse_netdev net/netfilter/nf_tables_api.c:1998 [inline]
[<ffffffff83a9239a>] nft_chain_parse_hook+0x33a/0x530 net/netfilter/nf_tables_api.c:2073
[<ffffffff83a9b14b>] nf_tables_addchain.constprop.0+0x10b/0x950 net/netfilter/nf_tables_api.c:2218
[<ffffffff83a9c41b>] nf_tables_newchain+0xa8b/0xc60 net/netfilter/nf_tables_api.c:2593
[<ffffffff83a3d6a6>] nfnetlink_rcv_batch+0xa46/0xd20 net/netfilter/nfnetlink.c:517
[<ffffffff83a3db79>] nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:638 [inline]
[<ffffffff83a3db79>] nfnetlink_rcv+0x1f9/0x220 net/netfilter/nfnetlink.c:656
[<ffffffff83a13b17>] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
[<ffffffff83a13b17>] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345
[<ffffffff83a13fd6>] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921
[<ffffffff83865ab6>] sock_sendmsg_nosec net/socket.c:714 [inline]
[<ffffffff83865ab6>] sock_sendmsg+0x56/0x80 net/socket.c:734
[<ffffffff8386601c>] ____sys_sendmsg+0x36c/0x390 net/socket.c:2482
[<ffffffff8386a918>] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536
[<ffffffff8386aaa8>] __sys_sendmsg+0x88/0x100 net/socket.c:2565
[<ffffffff845e5955>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<ffffffff845e5955>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
[<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd |
["https://git.kernel.org/stable/c/1ce55ec5cb7c573c983dffbe290b8d17caf1f157","https://git.kernel.org/stable/c/77972a36ecc4db7fc7c68f0e80714263c5f03f65","https://git.kernel.org/stable/c/910891a2a44cdc49efcc4fe7459c1085ba00d0f4","https://git.kernel.org/stable/c/94ed8eeb8d9aeb00e4f4e19b83a2e28b6442fbc5","https://git.kernel.org/stable/c/1ce55ec5cb7c573c983dffbe290b8d17caf1f157","https://git.kernel.org/stable/c/77972a36ecc4db7fc7c68f0e80714263c5f03f65","https://git.kernel.org/stable/c/910891a2a44cdc49efcc4fe7459c1085ba00d0f4","https://git.kernel.org/stable/c/94ed8eeb8d9aeb00e4f4e19b83a2e28b6442fbc5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42154
|
Medium |
fixed |
- 4.19.318
- 5.4.280
- 5.10.222
- 5.15.163
- 6.1.98
- 6.6.39
- 6.9.9
|
In the Linux kernel, the following vulnerability has been resolved:
tcp_metrics: validate source addr length
I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4
is at least 4 bytes long, and the policy doesn't have an entry
for this attribute at all (neither does it for IPv6 but v6 is
manually validated). |
["https://git.kernel.org/stable/c/19d997b59fa1fd7a02e770ee0881c0652b9c32c9","https://git.kernel.org/stable/c/2a2e79dbe2236a1289412d2044994f7ab419b44c","https://git.kernel.org/stable/c/31f03bb04146c1c6df6c03e9f45401f5f5a985d3","https://git.kernel.org/stable/c/3d550dd5418729a6e77fe7721d27adea7152e321","https://git.kernel.org/stable/c/66be40e622e177316ae81717aa30057ba9e61dff","https://git.kernel.org/stable/c/8c2debdd170e395934ac0e039748576dfde14e99","https://git.kernel.org/stable/c/cdffc358717e436bb67122bb82c1a2a26e050f98","https://git.kernel.org/stable/c/ef7c428b425beeb52b894e16f1c4b629d6cebfb6","http://www.openwall.com/lists/oss-security/2024/09/24/3","http://www.openwall.com/lists/oss-security/2024/09/24/4","http://www.openwall.com/lists/oss-security/2024/09/25/3","https://git.kernel.org/stable/c/19d997b59fa1fd7a02e770ee0881c0652b9c32c9","https://git.kernel.org/stable/c/2a2e79dbe2236a1289412d2044994f7ab419b44c","https://git.kernel.org/stable/c/31f03bb04146c1c6df6c03e9f45401f5f5a985d3","https://git.kernel.org/stable/c/3d550dd5418729a6e77fe7721d27adea7152e321","https://git.kernel.org/stable/c/66be40e622e177316ae81717aa30057ba9e61dff","https://git.kernel.org/stable/c/8c2debdd170e395934ac0e039748576dfde14e99","https://git.kernel.org/stable/c/cdffc358717e436bb67122bb82c1a2a26e050f98","https://git.kernel.org/stable/c/ef7c428b425beeb52b894e16f1c4b629d6cebfb6","https://security.netapp.com/advisory/ntap-20240828-0010/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48970
|
Medium |
fixed |
- 5.4.227
- 5.10.159
- 5.15.83
- 6.0.13
|
In the Linux kernel, the following vulnerability has been resolved:
af_unix: Get user_ns from in_skb in unix_diag_get_exact().
Wei Chen reported a NULL deref in sk_user_ns() [0][1], and Paolo diagnosed
the root cause: in unix_diag_get_exact(), the newly allocated skb does not
have sk. [2]
We must get the user_ns from the NETLINK_CB(in_skb).sk and pass it to
sk_diag_fill().
[0]:
BUG: kernel NULL pointer dereference, address: 0000000000000270
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 12bbce067 P4D 12bbce067 PUD 12bc40067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
CPU: 0 PID: 27942 Comm: syz-executor.0 Not tainted 6.1.0-rc5-next-20221118 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014
RIP: 0010:sk_user_ns include/net/sock.h:920 [inline]
RIP: 0010:sk_diag_dump_uid net/unix/diag.c:119 [inline]
RIP: 0010:sk_diag_fill+0x77d/0x890 net/unix/diag.c:170
Code: 89 ef e8 66 d4 2d fd c7 44 24 40 00 00 00 00 49 8d 7c 24 18 e8
54 d7 2d fd 49 8b 5c 24 18 48 8d bb 70 02 00 00 e8 43 d7 2d fd <48> 8b
9b 70 02 00 00 48 8d 7b 10 e8 33 d7 2d fd 48 8b 5b 10 48 8d
RSP: 0018:ffffc90000d67968 EFLAGS: 00010246
RAX: ffff88812badaa48 RBX: 0000000000000000 RCX: ffffffff840d481d
RDX: 0000000000000465 RSI: 0000000000000000 RDI: 0000000000000270
RBP: ffffc90000d679a8 R08: 0000000000000277 R09: 0000000000000000
R10: 0001ffffffffffff R11: 0001c90000d679a8 R12: ffff88812ac03800
R13: ffff88812c87c400 R14: ffff88812ae42210 R15: ffff888103026940
FS: 00007f08b4e6f700(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000270 CR3: 000000012c58b000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
unix_diag_get_exact net/unix/diag.c:285 [inline]
unix_diag_handler_dump+0x3f9/0x500 net/unix/diag.c:317
__sock_diag_cmd net/core/sock_diag.c:235 [inline]
sock_diag_rcv_msg+0x237/0x250 net/core/sock_diag.c:266
netlink_rcv_skb+0x13e/0x250 net/netlink/af_netlink.c:2564
sock_diag_rcv+0x24/0x40 net/core/sock_diag.c:277
netlink_unicast_kernel net/netlink/af_netlink.c:1330 [inline]
netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1356
netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1932
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg net/socket.c:734 [inline]
____sys_sendmsg+0x38f/0x500 net/socket.c:2476
___sys_sendmsg net/socket.c:2530 [inline]
__sys_sendmsg+0x197/0x230 net/socket.c:2559
__do_sys_sendmsg net/socket.c:2568 [inline]
__se_sys_sendmsg net/socket.c:2566 [inline]
__x64_sys_sendmsg+0x42/0x50 net/socket.c:2566
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x4697f9
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f08b4e6ec48 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 000000000077bf80 RCX: 00000000004697f9
RDX: 0000000000000000 RSI: 00000000200001c0 RDI: 0000000000000003
RBP: 00000000004d29e9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000077bf80
R13: 0000000000000000 R14: 000000000077bf80 R15: 00007ffdb36bc6c0
</TASK>
Modules linked in:
CR2: 0000000000000270
[1]: https://lore.kernel.org/netdev/CAO4mrfdvyjFpokhNsiwZiP-wpdSD0AStcJwfKcKQdAALQ9_2Qw@mail.gmail.com/
[2]: https://lore.kernel.org/netdev/e04315e7c90d9a75613f3993c2baf2d344eef7eb.camel@redhat.com/ |
["https://git.kernel.org/stable/c/575a6266f63dbb3b8eb1da03671451f0d81b8034","https://git.kernel.org/stable/c/5c014eb0ed6c8c57f483e94cc6e90f34ce426d91","https://git.kernel.org/stable/c/9c1d6f79a2c7b8221dcec27defc6dc461052ead4","https://git.kernel.org/stable/c/b3abe42e94900bdd045c472f9c9be620ba5ce553","https://git.kernel.org/stable/c/c66d78aee55dab72c92020ebfbebc464d4f5dd2a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48977
|
Medium |
fixed |
- 5.4.227
- 5.10.159
- 5.15.83
- 6.0.13
|
In the Linux kernel, the following vulnerability has been resolved:
can: af_can: fix NULL pointer dereference in can_rcv_filter
Analogue to commit 8aa59e355949 ("can: af_can: fix NULL pointer
dereference in can_rx_register()") we need to check for a missing
initialization of ml_priv in the receive path of CAN frames.
Since commit 4e096a18867a ("net: introduce CAN specific pointer in the
struct net_device") the check for dev->type to be ARPHRD_CAN is not
sufficient anymore since bonding or tun netdevices claim to be CAN
devices but do not initialize ml_priv accordingly. |
["https://git.kernel.org/stable/c/0acc442309a0a1b01bcdaa135e56e6398a49439c","https://git.kernel.org/stable/c/3982652957e8d79ac32efcb725450580650a8644","https://git.kernel.org/stable/c/c142cba37de29f740a3852f01f59876af8ae462a","https://git.kernel.org/stable/c/c42221efb1159d6a3c89e96685ee38acdce86b6f","https://git.kernel.org/stable/c/fcc63f2f7ee3038d53216edd0d8291e57c752557"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48986
|
Medium |
fixed |
- 4.10
- 4.15
- 4.20
- 5.4.227
- 5.10.159
- 5.15.83
- 6.0.13
|
In the Linux kernel, the following vulnerability has been resolved:
mm/gup: fix gup_pud_range() for dax
For dax pud, pud_huge() returns true on x86. So the function works as long
as hugetlb is configured. However, dax doesn't depend on hugetlb.
Commit 414fd080d125 ("mm/gup: fix gup_pmd_range() for dax") fixed
devmap-backed huge PMDs, but missed devmap-backed huge PUDs. Fix this as
well.
This fixes the below kernel panic:
general protection fault, probably for non-canonical address 0x69e7c000cc478: 0000 [#1] SMP
< snip >
Call Trace:
<TASK>
get_user_pages_fast+0x1f/0x40
iov_iter_get_pages+0xc6/0x3b0
? mempool_alloc+0x5d/0x170
bio_iov_iter_get_pages+0x82/0x4e0
? bvec_alloc+0x91/0xc0
? bio_alloc_bioset+0x19a/0x2a0
blkdev_direct_IO+0x282/0x480
? __io_complete_rw_common+0xc0/0xc0
? filemap_range_has_page+0x82/0xc0
generic_file_direct_write+0x9d/0x1a0
? inode_update_time+0x24/0x30
__generic_file_write_iter+0xbd/0x1e0
blkdev_write_iter+0xb4/0x150
? io_import_iovec+0x8d/0x340
io_write+0xf9/0x300
io_issue_sqe+0x3c3/0x1d30
? sysvec_reschedule_ipi+0x6c/0x80
__io_queue_sqe+0x33/0x240
? fget+0x76/0xa0
io_submit_sqes+0xe6a/0x18d0
? __fget_light+0xd1/0x100
__x64_sys_io_uring_enter+0x199/0x880
? __context_tracking_enter+0x1f/0x70
? irqentry_exit_to_user_mode+0x24/0x30
? irqentry_exit+0x1d/0x30
? __context_tracking_exit+0xe/0x70
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x61/0xcb
RIP: 0033:0x7fc97c11a7be
< snip >
</TASK>
---[ end trace 48b2e0e67debcaeb ]---
RIP: 0010:internal_get_user_pages_fast+0x340/0x990
< snip >
Kernel panic - not syncing: Fatal exception
Kernel Offset: disabled |
["https://git.kernel.org/stable/c/04edfa3dc06ecfc6133a33bc7271298782dee875","https://git.kernel.org/stable/c/3ac29732a2ffa64c7de13a072b0f2848b9c11037","https://git.kernel.org/stable/c/e06d13c36ded750c72521b600293befebb4e56c5","https://git.kernel.org/stable/c/f1cf856123ceb766c49967ec79b841030fa1741f","https://git.kernel.org/stable/c/fcd0ccd836ffad73d98a66f6fea7b16f735ea920"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38560
|
High |
fixed |
- 4.19.316
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: bfa: Ensure the copied buf is NUL terminated
Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from
userspace to that buffer. Later, we use sscanf on this buffer but we don't
ensure that the string is terminated inside the buffer, this can lead to
OOB read when using sscanf. Fix this issue by using memdup_user_nul instead
of memdup_user. |
["https://git.kernel.org/stable/c/00b425ff0891283207d7bad607a2412225274d7a","https://git.kernel.org/stable/c/13d0cecb4626fae67c00c84d3c7851f6b62f7df3","https://git.kernel.org/stable/c/1708e3cf2488788cba5489e4f913d227de757baf","https://git.kernel.org/stable/c/204714e68015d6946279719fd464ecaf57240f35","https://git.kernel.org/stable/c/481fc0c8617304a67649027c4a44723a139a0462","https://git.kernel.org/stable/c/595a6b98deec01b6dbb20139f71edcd5fb760ec2","https://git.kernel.org/stable/c/7510fab46b1cbd1680e2a096e779aec3334b4143","https://git.kernel.org/stable/c/7d3e694c4fe30f3aba9cd5ae86fb947a54c3db5c","https://git.kernel.org/stable/c/ecb76200f5557a2886888aaa53702da1ab9e6cdf","https://git.kernel.org/stable/c/00b425ff0891283207d7bad607a2412225274d7a","https://git.kernel.org/stable/c/13d0cecb4626fae67c00c84d3c7851f6b62f7df3","https://git.kernel.org/stable/c/1708e3cf2488788cba5489e4f913d227de757baf","https://git.kernel.org/stable/c/204714e68015d6946279719fd464ecaf57240f35","https://git.kernel.org/stable/c/481fc0c8617304a67649027c4a44723a139a0462","https://git.kernel.org/stable/c/595a6b98deec01b6dbb20139f71edcd5fb760ec2","https://git.kernel.org/stable/c/7510fab46b1cbd1680e2a096e779aec3334b4143","https://git.kernel.org/stable/c/7d3e694c4fe30f3aba9cd5ae86fb947a54c3db5c","https://git.kernel.org/stable/c/ecb76200f5557a2886888aaa53702da1ab9e6cdf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44999
|
High |
fixed |
- 4.19.321
- 5.4.283
- 5.10.225
- 5.15.166
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
gtp: pull network headers in gtp_dev_xmit()
syzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]
We must make sure the IPv4 or Ipv6 header is pulled in skb->head
before accessing fields in them.
Use pskb_inet_may_pull() to fix this issue.
[1]
BUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline]
BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]
BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281
ipv6_pdp_find drivers/net/gtp.c:220 [inline]
gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]
gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281
__netdev_start_xmit include/linux/netdevice.h:4913 [inline]
netdev_start_xmit include/linux/netdevice.h:4922 [inline]
xmit_one net/core/dev.c:3580 [inline]
dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596
__dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423
dev_queue_xmit include/linux/netdevice.h:3105 [inline]
packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276
packet_snd net/packet/af_packet.c:3145 [inline]
packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x30f/0x380 net/socket.c:745
__sys_sendto+0x685/0x830 net/socket.c:2204
__do_sys_sendto net/socket.c:2216 [inline]
__se_sys_sendto net/socket.c:2212 [inline]
__x64_sys_sendto+0x125/0x1d0 net/socket.c:2212
x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at:
slab_post_alloc_hook mm/slub.c:3994 [inline]
slab_alloc_node mm/slub.c:4037 [inline]
kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583
__alloc_skb+0x363/0x7b0 net/core/skbuff.c:674
alloc_skb include/linux/skbuff.h:1320 [inline]
alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526
sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815
packet_alloc_skb net/packet/af_packet.c:2994 [inline]
packet_snd net/packet/af_packet.c:3088 [inline]
packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x30f/0x380 net/socket.c:745
__sys_sendto+0x685/0x830 net/socket.c:2204
__do_sys_sendto net/socket.c:2216 [inline]
__se_sys_sendto net/socket.c:2212 [inline]
__x64_sys_sendto+0x125/0x1d0 net/socket.c:2212
x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
CPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 |
["https://git.kernel.org/stable/c/137d565ab89ce3584503b443bc9e00d44f482593","https://git.kernel.org/stable/c/1f6b62392453d8f36685d19b761307a8c5617ac1","https://git.kernel.org/stable/c/34ba4f29f3d9eb52dee37512059efb2afd7e966f","https://git.kernel.org/stable/c/3939d787139e359b77aaf9485d1e145d6713d7b9","https://git.kernel.org/stable/c/3a3be7ff9224f424e485287b54be00d2c6bd9c40","https://git.kernel.org/stable/c/3d89d0c4a1c6d4d2a755e826351b0a101dbc86f3","https://git.kernel.org/stable/c/cbb9a969fc190e85195d1b0f08038e7f6199044e","https://git.kernel.org/stable/c/f5dda8db382c5751c4e572afc7c99df7da1f83ca"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46854
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: dpaa: Pad packets to ETH_ZLEN
When sending packets under 60 bytes, up to three bytes of the buffer
following the data may be leaked. Avoid this by extending all packets to
ETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be
reproduced by running
$ ping -s 11 destination |
["https://git.kernel.org/stable/c/1f31f51bfc8214a6deaac2920e6342cb9d019133","https://git.kernel.org/stable/c/34fcac26216ce17886af3eb392355b459367af1a","https://git.kernel.org/stable/c/38f5db5587c0ee53546b28c50ba128253181ac83","https://git.kernel.org/stable/c/cbd7ec083413c6a2e0c326d49e24ec7d12c7a9e0","https://git.kernel.org/stable/c/cd5b9d657ecd44ad5f254c3fea3a6ab1cf0e2ef7","https://git.kernel.org/stable/c/ce8eabc912fe9b9a62be1a5c6af5ad2196e90fc2","https://git.kernel.org/stable/c/dc43a096cfe65b5c32168313846c5cd135d08f1d","https://git.kernel.org/stable/c/f43190e33224c49e1c7ebbc25923ff400d87ec00"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-45026
|
High |
fixed |
- 5.4.283
- 5.10.225
- 5.15.166
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: fix error recovery leading to data corruption on ESE devices
Extent Space Efficient (ESE) or thin provisioned volumes need to be
formatted on demand during usual IO processing.
The dasd_ese_needs_format function checks for error codes that signal
the non existence of a proper track format.
The check for incorrect length is to imprecise since other error cases
leading to transport of insufficient data also have this flag set.
This might lead to data corruption in certain error cases for example
during a storage server warmstart.
Fix by removing the check for incorrect length and replacing by
explicitly checking for invalid track format in transport mode.
Also remove the check for file protected since this is not a valid
ESE handling case. |
["https://git.kernel.org/stable/c/0a228896a1b3654cd461ff654f6a64e97a9c3246","https://git.kernel.org/stable/c/19f60a55b2fda49bc4f6134a5f6356ef62ee69d8","https://git.kernel.org/stable/c/5d4a304338daf83ace2887aaacafd66fe99ed5cc","https://git.kernel.org/stable/c/7db4042336580dfd75cb5faa82c12cd51098c90b","https://git.kernel.org/stable/c/93a7e2856951680cd7fe6ebd705ac10c8a8a5efd","https://git.kernel.org/stable/c/a665e3b7ac7d5cdc26e00e3d0fc8fd490e00316a","https://git.kernel.org/stable/c/e245a18281c252c8dbc467492e09bb5d4b012118"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50230
|
High |
fixed |
- 4.19.323
- 5.4.285
- 5.10.229
- 5.15.171
- 6.1.116
- 6.6.60
- 6.11.7
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix kernel bug due to missing clearing of checked flag
Syzbot reported that in directory operations after nilfs2 detects
filesystem corruption and degrades to read-only,
__block_write_begin_int(), which is called to prepare block writes, may
fail the BUG_ON check for accesses exceeding the folio/page size,
triggering a kernel bug.
This was found to be because the "checked" flag of a page/folio was not
cleared when it was discarded by nilfs2's own routine, which causes the
sanity check of directory entries to be skipped when the directory
page/folio is reloaded. So, fix that.
This was necessary when the use of nilfs2's own page discard routine was
applied to more than just metadata files. |
["https://git.kernel.org/stable/c/41e192ad2779cae0102879612dfe46726e4396aa","https://git.kernel.org/stable/c/56c6171932a7fb267ac6cb4ff8759b93ee1d0e2e","https://git.kernel.org/stable/c/64afad73e4623308d8943645e5631f2c7a2d7971","https://git.kernel.org/stable/c/994b2fa13a6c9cf3feca93090a9c337d48e3d60d","https://git.kernel.org/stable/c/aa0cee46c5d3fd9a39575a4c8a4f65f25f095b89","https://git.kernel.org/stable/c/cd0cdb51b15203fa27d4b714be83b7dfffa0b752","https://git.kernel.org/stable/c/f05dbebb8ee34882505d53d83af7d18f28a49248","https://git.kernel.org/stable/c/f2f1fa446676c21edb777e6d2bc4fa8f956fab68"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50262
|
High |
fixed |
- 4.19.323
- 5.4.285
- 5.10.229
- 5.15.171
- 6.1.116
- 6.6.60
- 6.11.7
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix out-of-bounds write in trie_get_next_key()
trie_get_next_key() allocates a node stack with size trie->max_prefixlen,
while it writes (trie->max_prefixlen + 1) nodes to the stack when it has
full paths from the root to leaves. For example, consider a trie with
max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ...
0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with
.prefixlen = 8 make 9 nodes be written on the node stack with size 8. |
["https://git.kernel.org/stable/c/13400ac8fb80c57c2bfb12ebd35ee121ce9b4d21","https://git.kernel.org/stable/c/590976f921723d53ac199c01d5b7b73a94875e68","https://git.kernel.org/stable/c/86c8ebe02d8806dd8878d0063e8e185622ab6ea6","https://git.kernel.org/stable/c/90a6e0e1e151ef7a9282e78f54c3091de2dcc99c","https://git.kernel.org/stable/c/91afbc0eb3c90258ae378ae3c6ead3d2371e926d","https://git.kernel.org/stable/c/a035df0b98df424559fd383e8e1a268f422ea2ba","https://git.kernel.org/stable/c/c4b4f9a9ab82238cb158fa4fe61a8c0ae21a4980","https://git.kernel.org/stable/c/e8494ac079814a53fbc2258d2743e720907488ed"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50267
|
High |
fixed |
- 4.19.324
- 5.4.286
- 5.10.230
- 5.15.172
- 6.1.117
- 6.6.61
- 6.11.8
|
In the Linux kernel, the following vulnerability has been resolved:
USB: serial: io_edgeport: fix use after free in debug printk
The "dev_dbg(&urb->dev->dev, ..." which happens after usb_free_urb(urb)
is a use after free of the "urb" pointer. Store the "dev" pointer at the
start of the function to avoid this issue. |
["https://git.kernel.org/stable/c/13d6ff3ca76056d06a9d88300be2a293442ff595","https://git.kernel.org/stable/c/275258c30bbda29467216e96fb655b16bcc9992b","https://git.kernel.org/stable/c/314bdf446053e123f37543aa535197ee75f8aa97","https://git.kernel.org/stable/c/37bb5628379295c1254c113a407cab03a0f4d0b4","https://git.kernel.org/stable/c/39709ce93f5c3f9eb535efe2afea088805d1128f","https://git.kernel.org/stable/c/44fff2c16c5aafbdb70c7183dae0a415ae74705e","https://git.kernel.org/stable/c/e567fc8f7a4460e486e52c9261b1e8b9f5dc42aa","https://git.kernel.org/stable/c/e6ceb04eeb6115d872d4c4078d12f1170ed755ce"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50269
|
High |
fixed |
- 4.5
- 4.10
- 4.14
- 4.19.324
- 5.4.286
- 5.10.230
- 5.15.172
- 6.1.117
- 6.6.61
- 6.11.8
|
In the Linux kernel, the following vulnerability has been resolved:
usb: musb: sunxi: Fix accessing an released usb phy
Commit 6ed05c68cbca ("usb: musb: sunxi: Explicitly release USB PHY on
exit") will cause that usb phy @glue->xceiv is accessed after released.
1) register platform driver @sunxi_musb_driver
// get the usb phy @glue->xceiv
sunxi_musb_probe() -> devm_usb_get_phy().
2) register and unregister platform driver @musb_driver
musb_probe() -> sunxi_musb_init()
use the phy here
//the phy is released here
musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy()
3) register @musb_driver again
musb_probe() -> sunxi_musb_init()
use the phy here but the phy has been released at 2).
...
Fixed by reverting the commit, namely, removing devm_usb_put_phy()
from sunxi_musb_exit(). |
["https://git.kernel.org/stable/c/498dbd9aea205db9da674994b74c7bf8e18448bd","https://git.kernel.org/stable/c/4aa77d5ea9944468e16c3eed15e858fd5de44de1","https://git.kernel.org/stable/c/63559ba8077cbadae1c92a65b73ea522bf377dd9","https://git.kernel.org/stable/c/6e2848d1c8c0139161e69ac0a94133e90e9988e8","https://git.kernel.org/stable/c/721ddad945596220c123eb6f7126729fe277ee4f","https://git.kernel.org/stable/c/8a30da5aa9609663b3e05bcc91a916537f66a4cd","https://git.kernel.org/stable/c/b08baa75b989cf779cbfa0969681f8ba2dc46569","https://git.kernel.org/stable/c/ccd811c304d2ee56189bfbc49302cb3c44361893"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53057
|
High |
fixed |
- 4.19.323
- 5.4.285
- 5.10.229
- 5.15.171
- 6.1.116
- 6.6.60
- 6.11.7
|
In the Linux kernel, the following vulnerability has been resolved:
net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT
In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed
to be either root or ingress. This assumption is bogus since it's valid
to create egress qdiscs with major handle ffff:
Budimir Markovic found that for qdiscs like DRR that maintain an active
class list, it will cause a UAF with a dangling class pointer.
In 066a3b5b2346, the concern was to avoid iterating over the ingress
qdisc since its parent is itself. The proper fix is to stop when parent
TC_H_ROOT is reached because the only way to retrieve ingress is when a
hierarchy which does not contain a ffff: major handle call into
qdisc_lookup with TC_H_MAJ(TC_H_ROOT).
In the scenario where major ffff: is an egress qdisc in any of the tree
levels, the updates will also propagate to TC_H_ROOT, which then the
iteration must stop.
net/sched/sch_api.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-) |
["https://git.kernel.org/stable/c/05df1b1dff8f197f1c275b57ccb2ca33021df552","https://git.kernel.org/stable/c/2e95c4384438adeaa772caa560244b1a2efef816","https://git.kernel.org/stable/c/580b3189c1972aff0f993837567d36392e9d981b","https://git.kernel.org/stable/c/597cf9748c3477bf61bc35f0634129f56764ad24","https://git.kernel.org/stable/c/9995909615c3431a5304c1210face5f268d24dba","https://git.kernel.org/stable/c/ce691c814bc7a3c30c220ffb5b7422715458fd9b","https://git.kernel.org/stable/c/dbe778b08b5101df9e89bc06e0a3a7ecd2f4ef20","https://git.kernel.org/stable/c/e7f9a6f97eb067599a74f3bcb6761976b0ed303e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56784
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Adding array index check to prevent memory corruption
[Why & How]
Array indices out of bound caused memory corruption. Adding checks to
ensure that array index stays in bound. |
["https://git.kernel.org/stable/c/2c437d9a0b496168e1a1defd17b531f0a526dbe9","https://git.kernel.org/stable/c/dff526dc3e27f5484f5ba11471b9fbbe681467f2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41061
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix array-index-out-of-bounds in dml2/FCLKChangeSupport
[Why]
Potential out of bounds access in dml2_calculate_rq_and_dlg_params()
because the value of out_lowest_state_idx used as an index for FCLKChangeSupport
array can be greater than 1.
[How]
Currently dml2 core specifies identical values for all FCLKChangeSupport
elements. Always use index 0 in the condition to avoid out of bounds access. |
["https://git.kernel.org/stable/c/0ad4b4a2f6357c45fbe444ead1a929a0b4017d03","https://git.kernel.org/stable/c/94166fe12543fbef122ca2d093e794ea41073a85","https://git.kernel.org/stable/c/0ad4b4a2f6357c45fbe444ead1a929a0b4017d03","https://git.kernel.org/stable/c/94166fe12543fbef122ca2d093e794ea41073a85"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46751
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't BUG_ON() when 0 reference count at btrfs_lookup_extent_info()
Instead of doing a BUG_ON() handle the error by returning -EUCLEAN,
aborting the transaction and logging an error message. |
["https://git.kernel.org/stable/c/18eb53a2734ff61b9a72c4fef5db7b38cb48ae16","https://git.kernel.org/stable/c/28cb13f29faf6290597b24b728dc3100c019356f","https://git.kernel.org/stable/c/3cfec712a439c5c5f5c718c5c669ee41a898f776","https://git.kernel.org/stable/c/d64807ded1b6054f066e03d8add6d920f3db9e5d","https://git.kernel.org/stable/c/ef9a8b73c8b60b27d9db4787e624a3438ffe8428"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40931
|
Medium |
fixed |
- 5.10.221
- 5.15.162
- 6.1.95
- 6.6.35
- 6.9.6
|
In the Linux kernel, the following vulnerability has been resolved:
mptcp: ensure snd_una is properly initialized on connect
This is strictly related to commit fb7a0d334894 ("mptcp: ensure snd_nxt
is properly initialized on connect"). It turns out that syzkaller can
trigger the retransmit after fallback and before processing any other
incoming packet - so that snd_una is still left uninitialized.
Address the issue explicitly initializing snd_una together with snd_nxt
and write_seq. |
["https://git.kernel.org/stable/c/208cd22ef5e57f82d38ec11c1a1703f9401d6dde","https://git.kernel.org/stable/c/7b9c7fc8600b64a86e4b47b2d190bba380267726","https://git.kernel.org/stable/c/8031b58c3a9b1db3ef68b3bd749fbee2e1e1aaa3","https://git.kernel.org/stable/c/ef473bf1dd7e8dd08bcc04b9e2d1bfed69a0a7ce","https://git.kernel.org/stable/c/f03c46eabb3a67bd2993e237ab5517f00a5f1813","https://git.kernel.org/stable/c/f1f0a46f8bb8890b90ab7194f0a0c8fe2a3fb57f","https://git.kernel.org/stable/c/208cd22ef5e57f82d38ec11c1a1703f9401d6dde","https://git.kernel.org/stable/c/7b9c7fc8600b64a86e4b47b2d190bba380267726","https://git.kernel.org/stable/c/8031b58c3a9b1db3ef68b3bd749fbee2e1e1aaa3","https://git.kernel.org/stable/c/ef473bf1dd7e8dd08bcc04b9e2d1bfed69a0a7ce","https://git.kernel.org/stable/c/f03c46eabb3a67bd2993e237ab5517f00a5f1813","https://git.kernel.org/stable/c/f1f0a46f8bb8890b90ab7194f0a0c8fe2a3fb57f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46689
|
Medium |
fixed |
- 5.4.283
- 5.10.225
- 5.15.166
- 6.1.108
- 6.6.49
- 6.10.8
|
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: cmd-db: Map shared memory as WC, not WB
Linux does not write into cmd-db region. This region of memory is write
protected by XPU. XPU may sometime falsely detect clean cache eviction
as "write" into the write protected region leading to secure interrupt
which causes an endless loop somewhere in Trust Zone.
The only reason it is working right now is because Qualcomm Hypervisor
maps the same region as Non-Cacheable memory in Stage 2 translation
tables. The issue manifests if we want to use another hypervisor (like
Xen or KVM), which does not know anything about those specific mappings.
Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC
removes dependency on correct mappings in Stage 2 tables. This patch
fixes the issue by updating the mapping to MEMREMAP_WC.
I tested this on SA8155P with Xen. |
["https://git.kernel.org/stable/c/0ee9594c974368a17e85a431e9fe1c14fb65c278","https://git.kernel.org/stable/c/62c2d63605ca25b5db78a347ed303c0a0a77d5b4","https://git.kernel.org/stable/c/d9d48d70e922b272875cda60d2ada89291c840cf","https://git.kernel.org/stable/c/eaff392c1e34fb77cc61505a31b0191e5e46e271","https://git.kernel.org/stable/c/ef80520be0ff78ae5ed44cb6eee1525e65bebe70","https://git.kernel.org/stable/c/f5a5a5a0e95f36e2792d48e6e4b64e665eb01374","https://git.kernel.org/stable/c/f9bb896eab221618927ae6a2f1d566567999839d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53128
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers
When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the
object_is_on_stack() function may produce incorrect results due to the
presence of tags in the obj pointer, while the stack pointer does not have
tags. This discrepancy can lead to incorrect stack object detection and
subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled.
Example of the warning:
ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated.
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364
Modules linked in:
CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4
Hardware name: linux,dummy-virt (DT)
pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __debug_object_init+0x330/0x364
lr : __debug_object_init+0x330/0x364
sp : ffff800082ea7b40
x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534
x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0
x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418
x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000
x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e
x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e
x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800
x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001
x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4
x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050
Call trace:
__debug_object_init+0x330/0x364
debug_object_init_on_stack+0x30/0x3c
schedule_hrtimeout_range_clock+0xac/0x26c
schedule_hrtimeout+0x1c/0x30
wait_task_inactive+0x1d4/0x25c
kthread_bind_mask+0x28/0x98
init_rescuer+0x1e8/0x280
workqueue_init+0x1a0/0x3cc
kernel_init_freeable+0x118/0x200
kernel_init+0x28/0x1f0
ret_from_fork+0x10/0x20
---[ end trace 0000000000000000 ]---
ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated.
------------[ cut here ]------------ |
["https://git.kernel.org/stable/c/2d2b19ed4169c38dc6c61a186c5f7bdafc709691","https://git.kernel.org/stable/c/397383db9c69470642ac95beb04f2150928d663b","https://git.kernel.org/stable/c/82e813b12b10ff705f3f5d600d8492fc5248618b","https://git.kernel.org/stable/c/fbfe23012cec509dfbe09852019c4e4bb84999d0","https://git.kernel.org/stable/c/fd7b4f9f46d46acbc7af3a439bb0d869efdc5c58"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-45009
|
Medium |
fixed |
- 5.15.167
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
mptcp: pm: only decrement add_addr_accepted for MPJ req
Adding the following warning ...
WARN_ON_ONCE(msk->pm.add_addr_accepted == 0)
... before decrementing the add_addr_accepted counter helped to find a
bug when running the "remove single subflow" subtest from the
mptcp_join.sh selftest.
Removing a 'subflow' endpoint will first trigger a RM_ADDR, then the
subflow closure. Before this patch, and upon the reception of the
RM_ADDR, the other peer will then try to decrement this
add_addr_accepted. That's not correct because the attached subflows have
not been created upon the reception of an ADD_ADDR.
A way to solve that is to decrement the counter only if the attached
subflow was an MP_JOIN to a remote id that was not 0, and initiated by
the host receiving the RM_ADDR. |
["https://git.kernel.org/stable/c/1c1f721375989579e46741f59523e39ec9b2a9bd","https://git.kernel.org/stable/c/2060f1efab370b496c4903b840844ecaff324c3c","https://git.kernel.org/stable/c/35b31f5549ede4070566b949781e83495906b43d","https://git.kernel.org/stable/c/85b866e4c4e63a1d7afb58f1e24273caad03d0b7","https://git.kernel.org/stable/c/d20bf2c96d7ffd171299b32f562f70e5bf5dc608"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-45011
|
Medium |
fixed |
- 5.15.166
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
char: xillybus: Check USB endpoints when probing device
Ensure, as the driver probes the device, that all endpoints that the
driver may attempt to access exist and are of the correct type.
All XillyUSB devices must have a Bulk IN and Bulk OUT endpoint at
address 1. This is verified in xillyusb_setup_base_eps().
On top of that, a XillyUSB device may have additional Bulk OUT
endpoints. The information about these endpoints' addresses is deduced
from a data structure (the IDT) that the driver fetches from the device
while probing it. These endpoints are checked in setup_channels().
A XillyUSB device never has more than one IN endpoint, as all data
towards the host is multiplexed in this single Bulk IN endpoint. This is
why setup_channels() only checks OUT endpoints. |
["https://git.kernel.org/stable/c/1371d32b95972d39c1e6e4bae8b6d0df1b573731","https://git.kernel.org/stable/c/2374bf7558de915edc6ec8cb10ec3291dfab9594","https://git.kernel.org/stable/c/25ee8b2908200fc862c0434e5ad483817d50ceda","https://git.kernel.org/stable/c/4267131278f5cc98f8db31d035d64bdbbfe18658","https://git.kernel.org/stable/c/5cff754692ad45d5086b75fef8cc3a99c30a1005"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50237
|
Medium |
fixed |
- 4.19.323
- 5.4.285
- 5.10.229
- 5.15.171
- 6.1.116
- 6.6.60
- 6.11.7
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower
Avoid potentially crashing in the driver because of uninitialized private data |
["https://git.kernel.org/stable/c/393b6bc174b0dd21bb2a36c13b36e62fc3474a23","https://git.kernel.org/stable/c/3ccf525a73d48e814634847f6d4a6150c6f0dffc","https://git.kernel.org/stable/c/78b698fbf37208ee921ee4cedea75b5d33d6ea9f","https://git.kernel.org/stable/c/8f6cd4d5bb7406656835a90e4f1a2192607f0c21","https://git.kernel.org/stable/c/b0b862aa3dbcd16b3c4715259a825f48ca540088","https://git.kernel.org/stable/c/b2bcbe5450b20641f512d6b26c6b256a5a4f847f","https://git.kernel.org/stable/c/c21efba8b5a86537ccdf43f77536bad02f82776c","https://git.kernel.org/stable/c/ee35c423042c9e04079fdee3db545135d609d6ea"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50273
|
Medium |
fixed |
- 4.19.324
- 5.4.286
- 5.10.230
- 5.15.172
- 6.1.117
- 6.6.61
- 6.11.8
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: reinitialize delayed ref list after deleting it from the list
At insert_delayed_ref() if we need to update the action of an existing
ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's
ref_add_list using list_del(), which leaves the ref's add_list member
not reinitialized, as list_del() sets the next and prev members of the
list to LIST_POISON1 and LIST_POISON2, respectively.
If later we end up calling drop_delayed_ref() against the ref, which can
happen during merging or when destroying delayed refs due to a transaction
abort, we can trigger a crash since at drop_delayed_ref() we call
list_empty() against the ref's add_list, which returns false since
the list was not reinitialized after the list_del() and as a consequence
we call list_del() again at drop_delayed_ref(). This results in an
invalid list access since the next and prev members are set to poison
pointers, resulting in a splat if CONFIG_LIST_HARDENED and
CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences
otherwise.
So fix this by deleting from the list with list_del_init() instead. |
["https://git.kernel.org/stable/c/2cb1a73d1d44a1c11b0ee5eeced765dd80ec48e6","https://git.kernel.org/stable/c/2fd0948a483e9cb2d669c7199bc620a21c97673d","https://git.kernel.org/stable/c/50a3933760b427759afdd23156a7280a19357a92","https://git.kernel.org/stable/c/93c5b8decc0ef39ba84f4211d2db6da0a4aefbeb","https://git.kernel.org/stable/c/bf0b0c6d159767c0d1c21f793950d78486690ee0","https://git.kernel.org/stable/c/c24fa427fc0ae827b2a3a07f13738cbf82c3f851","https://git.kernel.org/stable/c/c9a75ec45f1111ef530ab186c2a7684d0a0c9245","https://git.kernel.org/stable/c/f04be6d68f715c1473a8422fc0460f57b5e99931"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50296
|
Medium |
fixed |
- 4.19.324
- 5.4.286
- 5.10.230
- 5.15
- 5.15.172
- 6.1.117
- 6.6.61
- 6.11.8
|
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix kernel crash when uninstalling driver
When the driver is uninstalled and the VF is disabled concurrently, a
kernel crash occurs. The reason is that the two actions call function
pci_disable_sriov(). The num_VFs is checked to determine whether to
release the corresponding resources. During the second calling, num_VFs
is not 0 and the resource release function is called. However, the
corresponding resource has been released during the first invoking.
Therefore, the problem occurs:
[15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
...
[15278.131557][T50670] Call trace:
[15278.134686][T50670] klist_put+0x28/0x12c
[15278.138682][T50670] klist_del+0x14/0x20
[15278.142592][T50670] device_del+0xbc/0x3c0
[15278.146676][T50670] pci_remove_bus_device+0x84/0x120
[15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80
[15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c
[15278.162485][T50670] sriov_disable+0x50/0x11c
[15278.166829][T50670] pci_disable_sriov+0x24/0x30
[15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3]
[15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge]
[15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230
[15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30
[15278.193848][T50670] invoke_syscall+0x50/0x11c
[15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164
[15278.203837][T50670] do_el0_svc+0x34/0xcc
[15278.207834][T50670] el0_svc+0x20/0x30
For details, see the following figure.
rmmod hclge disable VFs
----------------------------------------------------
hclge_exit() sriov_numvfs_store()
... device_lock()
pci_disable_sriov() hns3_pci_sriov_configure()
pci_disable_sriov()
sriov_disable()
sriov_disable() if !num_VFs :
if !num_VFs : return;
return; sriov_del_vfs()
sriov_del_vfs() ...
... klist_put()
klist_put() ...
... num_VFs = 0;
num_VFs = 0; device_unlock();
In this patch, when driver is removing, we get the device_lock()
to protect num_VFs, just like sriov_numvfs_store(). |
["https://git.kernel.org/stable/c/590a4b2d4e0b73586e88bce9b8135b593355ec09","https://git.kernel.org/stable/c/719edd9f3372ce7fb3b157647c6658672946874b","https://git.kernel.org/stable/c/76b155e14d9b182ce83d32ada2d0d7219ea8c8dd","https://git.kernel.org/stable/c/7ae4e56de7dbd0999578246a536cf52a63f4056d","https://git.kernel.org/stable/c/a0df055775f30850c0da8f7dab40d67c0fd63908","https://git.kernel.org/stable/c/b5c94e4d947d15d521e935ff10c5a22a7883dea5","https://git.kernel.org/stable/c/df3dff8ab6d79edc942464999d06fbaedf8cdd18","https://git.kernel.org/stable/c/e36482b222e00cc7aeeea772fc0cf2943590bc4d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53066
|
Medium |
fixed |
- 4.19.324
- 5.4.286
- 5.10.230
- 5.15.172
- 6.1.117
- 6.6.61
- 6.11.8
|
In the Linux kernel, the following vulnerability has been resolved:
nfs: Fix KMSAN warning in decode_getfattr_attrs()
Fix the following KMSAN warning:
CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B
Tainted: [B]=BAD_PAGE
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)
=====================================================
=====================================================
BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90
decode_getfattr_attrs+0x2d6d/0x2f90
decode_getfattr_generic+0x806/0xb00
nfs4_xdr_dec_getattr+0x1de/0x240
rpcauth_unwrap_resp_decode+0xab/0x100
rpcauth_unwrap_resp+0x95/0xc0
call_decode+0x4ff/0xb50
__rpc_execute+0x57b/0x19d0
rpc_execute+0x368/0x5e0
rpc_run_task+0xcfe/0xee0
nfs4_proc_getattr+0x5b5/0x990
__nfs_revalidate_inode+0x477/0xd00
nfs_access_get_cached+0x1021/0x1cc0
nfs_do_access+0x9f/0xae0
nfs_permission+0x1e4/0x8c0
inode_permission+0x356/0x6c0
link_path_walk+0x958/0x1330
path_lookupat+0xce/0x6b0
filename_lookup+0x23e/0x770
vfs_statx+0xe7/0x970
vfs_fstatat+0x1f2/0x2c0
__se_sys_newfstatat+0x67/0x880
__x64_sys_newfstatat+0xbd/0x120
x64_sys_call+0x1826/0x3cf0
do_syscall_64+0xd0/0x1b0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The KMSAN warning is triggered in decode_getfattr_attrs(), when calling
decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not
initialized.
Fix the issue by initializing fattr->mdsthreshold to NULL in
nfs_fattr_init(). |
["https://git.kernel.org/stable/c/25ffd294fef81a7f3cd9528adf21560c04d98747","https://git.kernel.org/stable/c/8fc5ea9231af9122d227c9c13f5e578fca48d2e3","https://git.kernel.org/stable/c/9b453e8b108a5a93a6e348cf2ba4c9c138314a00","https://git.kernel.org/stable/c/9be0a21ae52b3b822d0eec4d14e909ab394f8a92","https://git.kernel.org/stable/c/bbfcd261cc068fe1cd02a4e871275074a0daa4e2","https://git.kernel.org/stable/c/dc270d7159699ad6d11decadfce9633f0f71c1db","https://git.kernel.org/stable/c/f6b2b2b981af8e7d7c62d34143acefa4e1edfe8b","https://git.kernel.org/stable/c/f749cb60a01f8391c760a1d6ecd938cadacf9549"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48953
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
rtc: cmos: Fix event handler registration ordering issue
Because acpi_install_fixed_event_handler() enables the event
automatically on success, it is incorrect to call it before the
handler routine passed to it is ready to handle events.
Unfortunately, the rtc-cmos driver does exactly the incorrect thing
by calling cmos_wake_setup(), which passes rtc_handler() to
acpi_install_fixed_event_handler(), before cmos_do_probe(), because
rtc_handler() uses dev_get_drvdata() to get to the cmos object
pointer and the driver data pointer is only populated in
cmos_do_probe().
This leads to a NULL pointer dereference in rtc_handler() on boot
if the RTC fixed event happens to be active at the init time.
To address this issue, change the initialization ordering of the
driver so that cmos_wake_setup() is always called after a successful
cmos_do_probe() call.
While at it, change cmos_pnp_probe() to call cmos_do_probe() after
the initial if () statement used for computing the IRQ argument to
be passed to cmos_do_probe() which is cleaner than calling it in
each branch of that if () (local variable "irq" can be of type int,
because it is passed to that function as an argument of type int).
Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check
ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number
of systems, because previously it only affected systems with
ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that
commit. |
["https://git.kernel.org/stable/c/0bcfccb48696aba475f046c2021f0733659ce0ef","https://git.kernel.org/stable/c/1ba745fce13d19775100eece30b0bfb8b8b10ea6","https://git.kernel.org/stable/c/4919d3eb2ec0ee364f7e3cf2d99646c1b224fae8","https://git.kernel.org/stable/c/60c6e563a843032cf6ff84b2fb732cd8754fc10d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48961
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: mdio: fix unbalanced fwnode reference count in mdio_device_release()
There is warning report about of_node refcount leak
while probing mdio device:
OF: ERROR: memory leak, expected refcount 1 instead of 2,
of_node_get()/of_node_put() unbalanced - destroy cset entry:
attach overlay node /spi/soc@0/mdio@710700c0/ethernet@4
In of_mdiobus_register_device(), we increase fwnode refcount
by fwnode_handle_get() before associating the of_node with
mdio device, but it has never been decreased in normal path.
Since that, in mdio_device_release(), it needs to call
fwnode_handle_put() in addition instead of calling kfree()
directly.
After above, just calling mdio_device_free() in the error handle
path of of_mdiobus_register_device() is enough to keep the
refcount balanced. |
["https://git.kernel.org/stable/c/16854177745a5648f8ec322353b432e18460f43a","https://git.kernel.org/stable/c/a5c6de1a6656b8cc6bce7cb3d9874dd7df4968c3","https://git.kernel.org/stable/c/cb37617687f2bfa5b675df7779f869147c9002bd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48975
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
gpiolib: fix memory leak in gpiochip_setup_dev()
Here is a backtrace report about memory leak detected in
gpiochip_setup_dev():
unreferenced object 0xffff88810b406400 (size 512):
comm "python3", pid 1682, jiffies 4295346908 (age 24.090s)
backtrace:
kmalloc_trace
device_add device_private_init at drivers/base/core.c:3361
(inlined by) device_add at drivers/base/core.c:3411
cdev_device_add
gpiolib_cdev_register
gpiochip_setup_dev
gpiochip_add_data_with_key
gcdev_register() & gcdev_unregister() would call device_add() &
device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to
register/unregister device.
However, if device_add() succeeds, some resource (like
struct device_private allocated by device_private_init())
is not released by device_del().
Therefore, after device_add() succeeds by gcdev_register(), it
needs to call put_device() to release resource in the error handle
path.
Here we move forward the register of release function, and let it
release every piece of resource by put_device() instead of kfree().
While at it, fix another subtle issue, i.e. when gc->ngpio is equal
to 0, we still call kcalloc() and, in case of further error, kfree()
on the ZERO_PTR pointer, which is not NULL. It's not a bug per se,
but rather waste of the resources and potentially wrong expectation
about contents of the gdev->descs variable. |
["https://git.kernel.org/stable/c/371363716398ed718e389bea8c5e9843a79dde4e","https://git.kernel.org/stable/c/6daaa84b621485fe28c401be18debf92ae8ef04a","https://git.kernel.org/stable/c/ec851b23084b3a0af8bf0f5e51d33a8d678bdc49"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49000
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Fix PCI device refcount leak in has_external_pci()
for_each_pci_dev() is implemented by pci_get_device(). The comment of
pci_get_device() says that it will increase the reference count for the
returned pci_dev and also decrease the reference count for the input
pci_dev @from if it is not NULL.
If we break for_each_pci_dev() loop with pdev not NULL, we need to call
pci_dev_put() to decrease the reference count. Add the missing
pci_dev_put() before 'return true' to avoid reference count leak. |
["https://git.kernel.org/stable/c/10ed7655a17f6a3eaecd1293830488259ccd5723","https://git.kernel.org/stable/c/17f67414718e6aba123335a33b7d15aa594fff34","https://git.kernel.org/stable/c/afca9e19cc720bfafc75dc5ce429c185ca93f31d","https://git.kernel.org/stable/c/b6eea8b2e858a20ad58ac62dc2de90fea2413f94"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49004
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
riscv: Sync efi page table's kernel mappings before switching
The EFI page table is initially created as a copy of the kernel page table.
With VMAP_STACK enabled, kernel stacks are allocated in the vmalloc area:
if the stack is allocated in a new PGD (one that was not present at the
moment of the efi page table creation or not synced in a previous vmalloc
fault), the kernel will take a trap when switching to the efi page table
when the vmalloc kernel stack is accessed, resulting in a kernel panic.
Fix that by updating the efi kernel mappings before switching to the efi
page table. |
["https://git.kernel.org/stable/c/3f105a742725a1b78766a55169f1d827732e62b8","https://git.kernel.org/stable/c/96f479383d92944406d4b3f2bc03c2f640def9f1","https://git.kernel.org/stable/c/fa7a7d185ef380546b4b1fed6f84f31dbae8cec7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49016
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: mdiobus: fix unbalanced node reference count
I got the following report while doing device(mscc-miim) load test
with CONFIG_OF_UNITTEST and CONFIG_OF_DYNAMIC enabled:
OF: ERROR: memory leak, expected refcount 1 instead of 2,
of_node_get()/of_node_put() unbalanced - destroy cset entry:
attach overlay node /spi/soc@0/mdio@7107009c/ethernet-phy@0
If the 'fwnode' is not an acpi node, the refcount is get in
fwnode_mdiobus_phy_device_register(), but it has never been
put when the device is freed in the normal path. So call
fwnode_handle_put() in phy_device_release() to avoid leak.
If it's an acpi node, it has never been get, but it's put
in the error path, so call fwnode_handle_get() before
phy_device_register() to keep get/put operation balanced. |
["https://git.kernel.org/stable/c/2708b357440427d6a9fee667eb7b8307f4625adc","https://git.kernel.org/stable/c/543d917f691ab06885ee779c862065899eaa4251","https://git.kernel.org/stable/c/cdde1560118f82498fc9e9a7c1ef7f0ef7755891"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49028
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ixgbevf: Fix resource leak in ixgbevf_init_module()
ixgbevf_init_module() won't destroy the workqueue created by
create_singlethread_workqueue() when pci_register_driver() failed. Add
destroy_workqueue() in fail path to prevent the resource leak.
Similar to the handling of u132_hcd_init in commit f276e002793c
("usb: u132-hcd: fix resource leak") |
["https://git.kernel.org/stable/c/7109e941099244cc876a4b3cb7a3ec79f104374a","https://git.kernel.org/stable/c/8cfa238a48f34038464b99d0b4825238c2687181","https://git.kernel.org/stable/c/c99671d4699dcf90d6939923c8fe8a8918e140b2","https://git.kernel.org/stable/c/f166c62cad798c53300b4b327e44300c73ec492d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2020-35501
|
Low |
|
N/A
|
A flaw was found in the Linux kernels implementation of audit rules, where a syscall can unexpectedly not be correctly not be logged by the audit subsystem |
["https://bugzilla.redhat.com/show_bug.cgi?id=1908577","https://bugzilla.redhat.com/show_bug.cgi?id=1908577"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-4090
|
High |
fixed |
|
An out-of-bounds (OOB) memory write flaw was found in the NFSD in the Linux kernel. Missing sanity may lead to a write beyond bmval[bmlen-1] in nfsd4_decode_bitmap4 in fs/nfsd/nfs4xdr.c. In this flaw, a local attacker with user privilege may gain access to out-of-bounds memory, leading to a system integrity and confidentiality threat. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2025101","https://lore.kernel.org/linux-nfs/163692036074.16710.5678362976688977923.stgit%40klimt.1015granger.net/","https://security.netapp.com/advisory/ntap-20220318-0010/","https://bugzilla.redhat.com/show_bug.cgi?id=2025101","https://lore.kernel.org/linux-nfs/163692036074.16710.5678362976688977923.stgit%40klimt.1015granger.net/","https://security.netapp.com/advisory/ntap-20220318-0010/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42161
|
Medium |
fixed |
- 5.10.222
- 5.15.163
- 6.1.98
- 6.6.39
- 6.9.9
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD
[Changes from V1:
- Use a default branch in the switch statement to initialize `val'.]
GCC warns that `val' may be used uninitialized in the
BPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as:
[...]
unsigned long long val; \
[...] \
switch (__CORE_RELO(s, field, BYTE_SIZE)) { \
case 1: val = *(const unsigned char *)p; break; \
case 2: val = *(const unsigned short *)p; break; \
case 4: val = *(const unsigned int *)p; break; \
case 8: val = *(const unsigned long long *)p; break; \
} \
[...]
val; \
} \
This patch adds a default entry in the switch statement that sets
`val' to zero in order to avoid the warning, and random values to be
used in case __builtin_preserve_field_info returns unexpected values
for BPF_FIELD_BYTE_SIZE.
Tested in bpf-next master.
No regressions. |
["https://git.kernel.org/stable/c/009367099eb61a4fc2af44d4eb06b6b4de7de6db","https://git.kernel.org/stable/c/3364c2ed1c241989847f19cf83e3db903ce689e3","https://git.kernel.org/stable/c/7e5471b5efebc30dd0bc035cda86693a5c73d45f","https://git.kernel.org/stable/c/a21d76bd0b0d39518e9a4c19f6cf7c042a974aff","https://git.kernel.org/stable/c/b694989bb13ed5f166e633faa1eb0f21c6d261a6","https://git.kernel.org/stable/c/ff941a8449e712eaf7efca1a13bfb9afd3d99fc2","https://git.kernel.org/stable/c/009367099eb61a4fc2af44d4eb06b6b4de7de6db","https://git.kernel.org/stable/c/3364c2ed1c241989847f19cf83e3db903ce689e3","https://git.kernel.org/stable/c/7e5471b5efebc30dd0bc035cda86693a5c73d45f","https://git.kernel.org/stable/c/a21d76bd0b0d39518e9a4c19f6cf7c042a974aff","https://git.kernel.org/stable/c/b694989bb13ed5f166e633faa1eb0f21c6d261a6","https://git.kernel.org/stable/c/ff941a8449e712eaf7efca1a13bfb9afd3d99fc2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50115
|
High |
fixed |
- 5.10.229
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory
Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits
4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't
enforce 32-byte alignment of nCR3.
In the absolute worst case scenario, failure to ignore bits 4:0 can result
in an out-of-bounds read, e.g. if the target page is at the end of a
memslot, and the VMM isn't using guard pages.
Per the APM:
The CR3 register points to the base address of the page-directory-pointer
table. The page-directory-pointer table is aligned on a 32-byte boundary,
with the low 5 address bits 4:0 assumed to be 0.
And the SDM's much more explicit:
4:0 Ignored
Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow
that is broken. |
["https://git.kernel.org/stable/c/2c4adc9b192a0815fe58a62bc0709449416cc884","https://git.kernel.org/stable/c/426682afec71ea3f889b972d038238807b9443e4","https://git.kernel.org/stable/c/58cb697d80e669c56197f703e188867c8c54c494","https://git.kernel.org/stable/c/6876793907cbe19d42e9edc8c3315a21e06c32ae","https://git.kernel.org/stable/c/76ce386feb14ec9a460784fcd495d8432acce7a5","https://git.kernel.org/stable/c/f559b2e9c5c5308850544ab59396b7d53cfc67bd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26771
|
Medium |
fixed |
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: ti: edma: Add some null pointer checks to the edma_probe
devm_kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity. |
["https://git.kernel.org/stable/c/4fe4e5adc7d29d214c59b59f61db73dec505ca3d","https://git.kernel.org/stable/c/6e2276203ac9ff10fc76917ec9813c660f627369","https://git.kernel.org/stable/c/7b24760f3a3c7ae1a176d343136b6c25174b7b27","https://git.kernel.org/stable/c/9d508c897153ae8dd79303f7f035f078139f6b49","https://git.kernel.org/stable/c/c432094aa7c9970f2fa10d2305d550d3810657ce","https://git.kernel.org/stable/c/f2a5e30d1e9a629de6179fa23923a318d5feb29e","https://git.kernel.org/stable/c/4fe4e5adc7d29d214c59b59f61db73dec505ca3d","https://git.kernel.org/stable/c/6e2276203ac9ff10fc76917ec9813c660f627369","https://git.kernel.org/stable/c/7b24760f3a3c7ae1a176d343136b6c25174b7b27","https://git.kernel.org/stable/c/9d508c897153ae8dd79303f7f035f078139f6b49","https://git.kernel.org/stable/c/c432094aa7c9970f2fa10d2305d550d3810657ce","https://git.kernel.org/stable/c/f2a5e30d1e9a629de6179fa23923a318d5feb29e","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35885
|
Medium |
fixed |
- 5.15.154
- 6.1.85
- 6.6.26
- 6.8.5
|
In the Linux kernel, the following vulnerability has been resolved:
mlxbf_gige: stop interface during shutdown
The mlxbf_gige driver intermittantly encounters a NULL pointer
exception while the system is shutting down via "reboot" command.
The mlxbf_driver will experience an exception right after executing
its shutdown() method. One example of this exception is:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070
Mem abort info:
ESR = 0x0000000096000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
Data abort info:
ISV = 0, ISS = 0x00000004
CM = 0, WnR = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=000000011d373000
[0000000000000070] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 96000004 [#1] SMP
CPU: 0 PID: 13 Comm: ksoftirqd/0 Tainted: G S OE 5.15.0-bf.6.gef6992a #1
Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.0.2.12669 Apr 21 2023
pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige]
lr : mlxbf_gige_poll+0x54/0x160 [mlxbf_gige]
sp : ffff8000080d3c10
x29: ffff8000080d3c10 x28: ffffcce72cbb7000 x27: ffff8000080d3d58
x26: ffff0000814e7340 x25: ffff331cd1a05000 x24: ffffcce72c4ea008
x23: ffff0000814e4b40 x22: ffff0000814e4d10 x21: ffff0000814e4128
x20: 0000000000000000 x19: ffff0000814e4a80 x18: ffffffffffffffff
x17: 000000000000001c x16: ffffcce72b4553f4 x15: ffff80008805b8a7
x14: 0000000000000000 x13: 0000000000000030 x12: 0101010101010101
x11: 7f7f7f7f7f7f7f7f x10: c2ac898b17576267 x9 : ffffcce720fa5404
x8 : ffff000080812138 x7 : 0000000000002e9a x6 : 0000000000000080
x5 : ffff00008de3b000 x4 : 0000000000000000 x3 : 0000000000000001
x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
Call trace:
mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige]
mlxbf_gige_poll+0x54/0x160 [mlxbf_gige]
__napi_poll+0x40/0x1c8
net_rx_action+0x314/0x3a0
__do_softirq+0x128/0x334
run_ksoftirqd+0x54/0x6c
smpboot_thread_fn+0x14c/0x190
kthread+0x10c/0x110
ret_from_fork+0x10/0x20
Code: 8b070000 f9000ea0 f95056c0 f86178a1 (b9407002)
---[ end trace 7cc3941aa0d8e6a4 ]---
Kernel panic - not syncing: Oops: Fatal exception in interrupt
Kernel Offset: 0x4ce722520000 from 0xffff800008000000
PHYS_OFFSET: 0x80000000
CPU features: 0x000005c1,a3330e5a
Memory Limit: none
---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---
During system shutdown, the mlxbf_gige driver's shutdown() is always executed.
However, the driver's stop() method will only execute if networking interface
configuration logic within the Linux distribution has been setup to do so.
If shutdown() executes but stop() does not execute, NAPI remains enabled
and this can lead to an exception if NAPI is scheduled while the hardware
interface has only been partially deinitialized.
The networking interface managed by the mlxbf_gige driver must be properly
stopped during system shutdown so that IFF_UP is cleared, the hardware
interface is put into a clean state, and NAPI is fully deinitialized. |
["https://git.kernel.org/stable/c/09ba28e1cd3cf715daab1fca6e1623e22fd754a6","https://git.kernel.org/stable/c/36a1cb0371aa6f0698910ee70cb4ed3c349f4fa4","https://git.kernel.org/stable/c/63a10b530e22cc923008b5925821c26872f37971","https://git.kernel.org/stable/c/80247e0eca14ff177d565f58ecd3010f6b7910a4","https://git.kernel.org/stable/c/9783b3b0e71d704949214a8f76468f591a31f3f5","https://git.kernel.org/stable/c/09ba28e1cd3cf715daab1fca6e1623e22fd754a6","https://git.kernel.org/stable/c/36a1cb0371aa6f0698910ee70cb4ed3c349f4fa4","https://git.kernel.org/stable/c/63a10b530e22cc923008b5925821c26872f37971","https://git.kernel.org/stable/c/80247e0eca14ff177d565f58ecd3010f6b7910a4","https://git.kernel.org/stable/c/9783b3b0e71d704949214a8f76468f591a31f3f5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50236
|
Medium |
fixed |
- 4.19.323
- 5.4.285
- 5.10.229
- 5.15.171
- 6.1.116
- 6.6.60
- 6.11.7
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath10k: Fix memory leak in management tx
In the current logic, memory is allocated for storing the MSDU context
during management packet TX but this memory is not being freed during
management TX completion. Similar leaks are seen in the management TX
cleanup logic.
Kmemleak reports this problem as below,
unreferenced object 0xffffff80b64ed250 (size 16):
comm "kworker/u16:7", pid 148, jiffies 4294687130 (age 714.199s)
hex dump (first 16 bytes):
00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t......
backtrace:
[<ffffffe6e7b245dc>] __kmem_cache_alloc_node+0x1e4/0x2d8
[<ffffffe6e7adde88>] kmalloc_trace+0x48/0x110
[<ffffffe6bbd765fc>] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core]
[<ffffffe6bbd3eed4>] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core]
[<ffffffe6e78d5974>] process_scheduled_works+0x1ac/0x400
[<ffffffe6e78d60b8>] worker_thread+0x208/0x328
[<ffffffe6e78dc890>] kthread+0x100/0x1c0
[<ffffffe6e78166c0>] ret_from_fork+0x10/0x20
Free the memory during completion and cleanup to fix the leak.
Protect the mgmt_pending_tx idr_remove() operation in
ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to
other instances.
Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1 |
["https://git.kernel.org/stable/c/2f6f1e26ac6d2b38e2198a71f81f0ade14d6b07b","https://git.kernel.org/stable/c/4112450da7d67b59ccedc2208bae622db17dbcb8","https://git.kernel.org/stable/c/5f5a939759c79e7385946c85e62feca51a18d816","https://git.kernel.org/stable/c/6cc23898e6ba47e976050d3c080b4d2c1add3748","https://git.kernel.org/stable/c/6fc9af3df6ca7f3c94774d20f62dc7b49616026d","https://git.kernel.org/stable/c/705be2dc45c7f852e211e16bc41a916fab741983","https://git.kernel.org/stable/c/e15d84b3bba187aa372dff7c58ce1fd5cb48a076","https://git.kernel.org/stable/c/eff818238bedb9c2484c251ec46f9f160911cdc0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50287
|
Medium |
fixed |
- 4.19.324
- 5.4.286
- 5.10.230
- 5.15.172
- 6.1.117
- 6.6.61
- 6.11.8
|
In the Linux kernel, the following vulnerability has been resolved:
media: v4l2-tpg: prevent the risk of a division by zero
As reported by Coverity, the logic at tpg_precalculate_line()
blindly rescales the buffer even when scaled_witdh is equal to
zero. If this ever happens, this will cause a division by zero.
Instead, add a WARN_ON_ONCE() to trigger such cases and return
without doing any precalculation. |
["https://git.kernel.org/stable/c/054931ca3cfcb8e8fa036e887d6f379942b02565","https://git.kernel.org/stable/c/0bfc6e38ee2250f0503d96f1a1de441c31d88715","https://git.kernel.org/stable/c/0cdb42ba0b28f548c1a4e86bb8489dba0d78fc21","https://git.kernel.org/stable/c/2d0f01aa602fd15a805771bdf3f4d9a9b4df7f47","https://git.kernel.org/stable/c/a749c15dccc58d9cbad9cd23bd8ab4b5fa96cf47","https://git.kernel.org/stable/c/c63c30c9d9f2c8de34b16cd2b8400240533b914e","https://git.kernel.org/stable/c/e3c36d0bde309f690ed1f9cd5f7e63b3a513f94a","https://git.kernel.org/stable/c/e6a3ea83fbe15d4818d01804e904cbb0e64e543b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48870
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
tty: fix possible null-ptr-defer in spk_ttyio_release
Run the following tests on the qemu platform:
syzkaller:~# modprobe speakup_audptr
input: Speakup as /devices/virtual/input/input4
initialized device: /dev/synth, node (MAJOR 10, MINOR 125)
speakup 3.1.6: initialized
synth name on entry is: (null)
synth probe
spk_ttyio_initialise_ldisc failed because tty_kopen_exclusive returned
failed (errno -16), then remove the module, we will get a null-ptr-defer
problem, as follow:
syzkaller:~# modprobe -r speakup_audptr
releasing synth audptr
BUG: kernel NULL pointer dereference, address: 0000000000000080
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 0 P4D 0
Oops: 0002 [#1] PREEMPT SMP PTI
CPU: 2 PID: 204 Comm: modprobe Not tainted 6.1.0-rc6-dirty #1
RIP: 0010:mutex_lock+0x14/0x30
Call Trace:
<TASK>
spk_ttyio_release+0x19/0x70 [speakup]
synth_release.part.6+0xac/0xc0 [speakup]
synth_remove+0x56/0x60 [speakup]
__x64_sys_delete_module+0x156/0x250
? fpregs_assert_state_consistent+0x1d/0x50
do_syscall_64+0x37/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
</TASK>
Modules linked in: speakup_audptr(-) speakup
Dumping ftrace buffer:
in_synth->dev was not initialized during modprobe, so we add check
for in_synth->dev to fix this bug. |
["https://git.kernel.org/stable/c/2da67bff29ab49caafb0766e8b8383b735ff796f","https://git.kernel.org/stable/c/5abbeebd8296c2301023b8dc4b5a6c0d5229b4f5","https://git.kernel.org/stable/c/64152e05a4de3ebf59f1740a0985a6d5fba0c77b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43823
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
PCI: keystone: Fix NULL pointer dereference in case of DT error in ks_pcie_setup_rc_app_regs()
If IORESOURCE_MEM is not provided in Device Tree due to
any error, resource_list_first_type() will return NULL and
pci_parse_request_of_pci_ranges() will just emit a warning.
This will cause a NULL pointer dereference. Fix this bug by adding NULL
return check.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/0a6f1b5fe8ef8268aaa069035639968ceeea0a23","https://git.kernel.org/stable/c/a231707a91f323af1e5d9f1722055ec2fc1c7775","https://git.kernel.org/stable/c/bbba48ad67c53feea05936ea1e029dcca8057506","https://git.kernel.org/stable/c/dbcdd1863ba2ec9b76ec131df25d797709e05597"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41080
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
io_uring: fix possible deadlock in io_register_iowq_max_workers()
The io_register_iowq_max_workers() function calls io_put_sq_data(),
which acquires the sqd->lock without releasing the uring_lock.
Similar to the commit 009ad9f0c6ee ("io_uring: drop ctx->uring_lock
before acquiring sqd->lock"), this can lead to a potential deadlock
situation.
To resolve this issue, the uring_lock is released before calling
io_put_sq_data(), and then it is re-acquired after the function call.
This change ensures that the locks are acquired in the correct
order, preventing the possibility of a deadlock. |
["https://git.kernel.org/stable/c/73254a297c2dd094abec7c9efee32455ae875bdf","https://git.kernel.org/stable/c/950ac86cff338ab56e2eaf611f4936ee34893b63","https://git.kernel.org/stable/c/97ed7ff58de66c544692b3c2b988f3f594348de0","https://git.kernel.org/stable/c/b17397a0a5c56e111f61cb5b77d162664dc00de9","https://git.kernel.org/stable/c/b571a367502c7ef94c688ef9c7f7d69a2ce3bcca","https://git.kernel.org/stable/c/fdacd09f2ddf7a00787291f08ee48c0421e5b709","https://git.kernel.org/stable/c/73254a297c2dd094abec7c9efee32455ae875bdf","https://git.kernel.org/stable/c/b571a367502c7ef94c688ef9c7f7d69a2ce3bcca"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36968
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()
l2cap_le_flowctl_init() can cause both div-by-zero and an integer
overflow since hdev->le_mtu may not fall in the valid range.
Move MTU from hci_dev to hci_conn to validate MTU and stop the connection
process earlier if MTU is invalid.
Also, add a missing validation in read_buffer_size() and make it return
an error value if the validation fails.
Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a
kzalloc failure and invalid MTU value.
divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: hci0 hci_rx_work
RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547
Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c
89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d
b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42
RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246
RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000
RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f
RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa
R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084
R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000
FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0
PKRU: 55555554
Call Trace:
<TASK>
l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline]
l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline]
l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline]
l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809
l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506
hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline]
hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176
process_one_work kernel/workqueue.c:3254 [inline]
process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335
worker_thread+0x926/0xe70 kernel/workqueue.c:3416
kthread+0x2e3/0x380 kernel/kthread.c:388
ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]--- |
["https://git.kernel.org/stable/c/4d3dbaa252257d20611c3647290e6171f1bbd6c8","https://git.kernel.org/stable/c/a5b862c6a221459d54e494e88965b48dcfa6cc44","https://git.kernel.org/stable/c/ad3f7986c5a0f82b8b66a0afe1cc1f5421e1d674","https://git.kernel.org/stable/c/d2b2f7d3936dc5990549bc36ab7ac7ac37f22c30","https://git.kernel.org/stable/c/dfece2b4e3759759b2bdfac2cd6d0ee9fbf055f3","https://git.kernel.org/stable/c/4d3dbaa252257d20611c3647290e6171f1bbd6c8","https://git.kernel.org/stable/c/a5b862c6a221459d54e494e88965b48dcfa6cc44","https://git.kernel.org/stable/c/ad3f7986c5a0f82b8b66a0afe1cc1f5421e1d674","https://git.kernel.org/stable/c/d2b2f7d3936dc5990549bc36ab7ac7ac37f22c30","https://git.kernel.org/stable/c/dfece2b4e3759759b2bdfac2cd6d0ee9fbf055f3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49026
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
e100: Fix possible use after free in e100_xmit_prepare
In e100_xmit_prepare(), if we can't map the skb, then return -ENOMEM, so
e100_xmit_frame() will return NETDEV_TX_BUSY and the upper layer will
resend the skb. But the skb is already freed, which will cause UAF bug
when the upper layer resends the skb.
Remove the harmful free. |
["https://git.kernel.org/stable/c/45605c75c52c7ae7bfe902214343aabcfe5ba0ff","https://git.kernel.org/stable/c/9fc27d22cdb9b1fcd754599d216a8992fed280cd","https://git.kernel.org/stable/c/b46f6144ab89d3d757ead940759c505091626a7d","https://git.kernel.org/stable/c/b775f37d943966f6f77dca402f5a9dedce502c25"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47691
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()
syzbot reports a f2fs bug as below:
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
print_report+0xe8/0x550 mm/kasan/report.c:491
kasan_report+0x143/0x180 mm/kasan/report.c:601
kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
instrument_atomic_read_write include/linux/instrumented.h:96 [inline]
atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline]
__refcount_add include/linux/refcount.h:184 [inline]
__refcount_inc include/linux/refcount.h:241 [inline]
refcount_inc include/linux/refcount.h:258 [inline]
get_task_struct include/linux/sched/task.h:118 [inline]
kthread_stop+0xca/0x630 kernel/kthread.c:704
f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210
f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283
f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline]
__f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The root cause is below race condition, it may cause use-after-free
issue in sbi->gc_th pointer.
- remount
- f2fs_remount
- f2fs_stop_gc_thread
- kfree(gc_th)
- f2fs_ioc_shutdown
- f2fs_do_shutdown
- f2fs_stop_gc_thread
- kthread_stop(gc_th->f2fs_gc_task)
: sbi->gc_thread = NULL;
We will call f2fs_do_shutdown() in two paths:
- for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore
for fixing.
- for f2fs_shutdown() path, it's safe since caller has already grabbed
sb->s_umount semaphore. |
["https://git.kernel.org/stable/c/7c339dee7eb0f8e4cadc317c595f898ef04dae30","https://git.kernel.org/stable/c/c7f114d864ac91515bb07ac271e9824a20f5ed95","https://git.kernel.org/stable/c/d79343cd66343709e409d96b2abb139a0a55ce34","https://git.kernel.org/stable/c/fc18e655b62ac6bc9f12f5de0d749b4a3fe1e812"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26930
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix double free of the ha->vp_map pointer
Coverity scan reported potential risk of double free of the pointer
ha->vp_map. ha->vp_map was freed in qla2x00_mem_alloc(), and again freed
in function qla2x00_mem_free(ha).
Assign NULL to vp_map and kfree take care of NULL. |
["https://git.kernel.org/stable/c/825d63164a2e6bacb059a9afb5605425b485413f","https://git.kernel.org/stable/c/b7deb675d674f44e0ddbab87fee8f9f098925e73","https://git.kernel.org/stable/c/e288285d47784fdcf7c81be56df7d65c6f10c58b","https://git.kernel.org/stable/c/f14cee7a882cb79528f17a2335f53e9fd1848467","https://git.kernel.org/stable/c/825d63164a2e6bacb059a9afb5605425b485413f","https://git.kernel.org/stable/c/b7deb675d674f44e0ddbab87fee8f9f098925e73","https://git.kernel.org/stable/c/e288285d47784fdcf7c81be56df7d65c6f10c58b","https://git.kernel.org/stable/c/f14cee7a882cb79528f17a2335f53e9fd1848467"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38581
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/mes: fix use-after-free issue
Delete fence fallback timer to fix the ramdom
use-after-free issue.
v2: move to amdgpu_mes.c |
["https://git.kernel.org/stable/c/0f98c144c15c8fc0f3176c994bd4e727ef718a5c","https://git.kernel.org/stable/c/39cfce75168c11421d70b8c0c65f6133edccb82a","https://git.kernel.org/stable/c/70b1bf6d9edc8692d241f59a65f073aec6d501de","https://git.kernel.org/stable/c/948255282074d9367e01908b3f5dcf8c10fc9c3d","https://git.kernel.org/stable/c/0f98c144c15c8fc0f3176c994bd4e727ef718a5c","https://git.kernel.org/stable/c/39cfce75168c11421d70b8c0c65f6133edccb82a","https://git.kernel.org/stable/c/70b1bf6d9edc8692d241f59a65f073aec6d501de","https://git.kernel.org/stable/c/948255282074d9367e01908b3f5dcf8c10fc9c3d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42136
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
cdrom: rearrange last_media_change check to avoid unintentional overflow
When running syzkaller with the newly reintroduced signed integer wrap
sanitizer we encounter this splat:
[ 366.015950] UBSAN: signed-integer-overflow in ../drivers/cdrom/cdrom.c:2361:33
[ 366.021089] -9223372036854775808 - 346321 cannot be represented in type '__s64' (aka 'long long')
[ 366.025894] program syz-executor.4 is using a deprecated SCSI ioctl, please convert it to SG_IO
[ 366.027502] CPU: 5 PID: 28472 Comm: syz-executor.7 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1
[ 366.027512] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 366.027518] Call Trace:
[ 366.027523] <TASK>
[ 366.027533] dump_stack_lvl+0x93/0xd0
[ 366.027899] handle_overflow+0x171/0x1b0
[ 366.038787] ata1.00: invalid multi_count 32 ignored
[ 366.043924] cdrom_ioctl+0x2c3f/0x2d10
[ 366.063932] ? __pm_runtime_resume+0xe6/0x130
[ 366.071923] sr_block_ioctl+0x15d/0x1d0
[ 366.074624] ? __pfx_sr_block_ioctl+0x10/0x10
[ 366.077642] blkdev_ioctl+0x419/0x500
[ 366.080231] ? __pfx_blkdev_ioctl+0x10/0x10
...
Historically, the signed integer overflow sanitizer did not work in the
kernel due to its interaction with `-fwrapv` but this has since been
changed [1] in the newest version of Clang. It was re-enabled in the
kernel with Commit 557f8c582a9ba8ab ("ubsan: Reintroduce signed overflow
sanitizer").
Let's rearrange the check to not perform any arithmetic, thus not
tripping the sanitizer. |
["https://git.kernel.org/stable/c/0c97527e916054acc4a46ffb02842988acb2e92b","https://git.kernel.org/stable/c/3ee21e14c8c329168a0b66bab00ecd18f5d0dee3","https://git.kernel.org/stable/c/e809bc112712da8f7e15822674c6562da6cdf24c","https://git.kernel.org/stable/c/efb905aeb44b0e99c0e6b07865b1885ae0471ebf","https://git.kernel.org/stable/c/0c97527e916054acc4a46ffb02842988acb2e92b","https://git.kernel.org/stable/c/3ee21e14c8c329168a0b66bab00ecd18f5d0dee3","https://git.kernel.org/stable/c/e809bc112712da8f7e15822674c6562da6cdf24c","https://git.kernel.org/stable/c/efb905aeb44b0e99c0e6b07865b1885ae0471ebf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42147
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
crypto: hisilicon/debugfs - Fix debugfs uninit process issue
During the zip probe process, the debugfs failure does not stop
the probe. When debugfs initialization fails, jumping to the
error branch will also release regs, in addition to its own
rollback operation.
As a result, it may be released repeatedly during the regs
uninit process. Therefore, the null check needs to be added to
the regs uninit process. |
["https://git.kernel.org/stable/c/7fc8d9a525b5c3f8dfa5ed50901e764d8ede7e1e","https://git.kernel.org/stable/c/8be0913389718e8d27c4f1d4537b5e1b99ed7739","https://git.kernel.org/stable/c/e0a2d2df9ba7bd6bd7e0a9b6a5e3894f7e8445b3","https://git.kernel.org/stable/c/eda60520cfe3aba9f088c68ebd5bcbca9fc6ac3c","https://git.kernel.org/stable/c/7fc8d9a525b5c3f8dfa5ed50901e764d8ede7e1e","https://git.kernel.org/stable/c/8be0913389718e8d27c4f1d4537b5e1b99ed7739","https://git.kernel.org/stable/c/e0a2d2df9ba7bd6bd7e0a9b6a5e3894f7e8445b3","https://git.kernel.org/stable/c/eda60520cfe3aba9f088c68ebd5bcbca9fc6ac3c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42159
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpi3mr: Sanitise num_phys
Information is stored in mr_sas_port->phy_mask, values larger then size of
this field shouldn't be allowed. |
["https://git.kernel.org/stable/c/3668651def2c1622904e58b0280ee93121f2b10b","https://git.kernel.org/stable/c/586b41060113ae43032ec6c4a16d518cef5da6e0","https://git.kernel.org/stable/c/b869ec89d2ee923d46608b76e54c006680c9b4df","https://git.kernel.org/stable/c/c8707901b53a48106d7501bdbd0350cefaefa4cf","https://git.kernel.org/stable/c/3668651def2c1622904e58b0280ee93121f2b10b","https://git.kernel.org/stable/c/586b41060113ae43032ec6c4a16d518cef5da6e0","https://git.kernel.org/stable/c/b869ec89d2ee923d46608b76e54c006680c9b4df","https://git.kernel.org/stable/c/c8707901b53a48106d7501bdbd0350cefaefa4cf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50051
|
High |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
spi: mpc52xx: Add cancel_work_sync before module remove
If we remove the module which will call mpc52xx_spi_remove
it will free 'ms' through spi_unregister_controller.
while the work ms->work will be used. The sequence of operations
that may lead to a UAF bug.
Fix it by ensuring that the work is canceled before proceeding with
the cleanup in mpc52xx_spi_remove. |
["https://git.kernel.org/stable/c/373d55a47dc662e5e30d12ad5d334312f757c1f1","https://git.kernel.org/stable/c/90b72189de2cddacb26250579da0510b29a8b82b","https://git.kernel.org/stable/c/984836621aad98802d92c4a3047114cf518074c8","https://git.kernel.org/stable/c/cd5106c77d6d6828aa82449f01f4eb436d602a21","https://git.kernel.org/stable/c/d0cde3911cf24e1bcdd4caa1d1b9ef57589db5a1","https://git.kernel.org/stable/c/e0c6ce8424095c2da32a063d3fc027494c689817","https://git.kernel.org/stable/c/f65d85bc1ffd8a2c194bb2cd65e35ed3648ddd59"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56759
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix use-after-free when COWing tree bock and tracing is enabled
When a COWing a tree block, at btrfs_cow_block(), and we have the
tracepoint trace_btrfs_cow_block() enabled and preemption is also enabled
(CONFIG_PREEMPT=y), we can trigger a use-after-free in the COWed extent
buffer while inside the tracepoint code. This is because in some paths
that call btrfs_cow_block(), such as btrfs_search_slot(), we are holding
the last reference on the extent buffer @buf so btrfs_force_cow_block()
drops the last reference on the @buf extent buffer when it calls
free_extent_buffer_stale(buf), which schedules the release of the extent
buffer with RCU. This means that if we are on a kernel with preemption,
the current task may be preempted before calling trace_btrfs_cow_block()
and the extent buffer already released by the time trace_btrfs_cow_block()
is called, resulting in a use-after-free.
Fix this by moving the trace_btrfs_cow_block() from btrfs_cow_block() to
btrfs_force_cow_block() before the COWed extent buffer is freed.
This also has a side effect of invoking the tracepoint in the tree defrag
code, at defrag.c:btrfs_realloc_node(), since btrfs_force_cow_block() is
called there, but this is fine and it was actually missing there. |
["https://git.kernel.org/stable/c/44f52bbe96dfdbe4aca3818a2534520082a07040","https://git.kernel.org/stable/c/526ff5b27f090fb15040471f892cd2c9899ce314","https://git.kernel.org/stable/c/66376f1a73cba57fd0af2631d7888605b738e499","https://git.kernel.org/stable/c/9a466b8693b9add05de99af00c7bdff8259ecf19","https://git.kernel.org/stable/c/ba5120a2fb5f23b4d39d302e181aa5d4e28a90d1","https://git.kernel.org/stable/c/c3a403d8ce36f5a809a492581de5ad17843e4701"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57896
|
High |
fixed |
- 5.10.233
- 5.15.176
- 6.1.124
- 6.6.70
- 6.12.9
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: flush delalloc workers queue before stopping cleaner kthread during unmount
During the unmount path, at close_ctree(), we first stop the cleaner
kthread, using kthread_stop() which frees the associated task_struct, and
then stop and destroy all the work queues. However after we stopped the
cleaner we may still have a worker from the delalloc_workers queue running
inode.c:submit_compressed_extents(), which calls btrfs_add_delayed_iput(),
which in turn tries to wake up the cleaner kthread - which was already
destroyed before, resulting in a use-after-free on the task_struct.
Syzbot reported this with the following stack traces:
BUG: KASAN: slab-use-after-free in __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089
Read of size 8 at addr ffff8880259d2818 by task kworker/u8:3/52
CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.13.0-rc1-syzkaller-00002-gcdd30ebb1b9f #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Workqueue: btrfs-delalloc btrfs_work_helper
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0x169/0x550 mm/kasan/report.c:489
kasan_report+0x143/0x180 mm/kasan/report.c:602
__lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089
lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162
class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline]
try_to_wake_up+0xc2/0x1470 kernel/sched/core.c:4205
submit_compressed_extents+0xdf/0x16e0 fs/btrfs/inode.c:1615
run_ordered_work fs/btrfs/async-thread.c:288 [inline]
btrfs_work_helper+0x96f/0xc40 fs/btrfs/async-thread.c:324
process_one_work kernel/workqueue.c:3229 [inline]
process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310
worker_thread+0x870/0xd30 kernel/workqueue.c:3391
kthread+0x2f0/0x390 kernel/kthread.c:389
ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
</TASK>
Allocated by task 2:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
unpoison_slab_object mm/kasan/common.c:319 [inline]
__kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345
kasan_slab_alloc include/linux/kasan.h:250 [inline]
slab_post_alloc_hook mm/slub.c:4104 [inline]
slab_alloc_node mm/slub.c:4153 [inline]
kmem_cache_alloc_node_noprof+0x1d9/0x380 mm/slub.c:4205
alloc_task_struct_node kernel/fork.c:180 [inline]
dup_task_struct+0x57/0x8c0 kernel/fork.c:1113
copy_process+0x5d1/0x3d50 kernel/fork.c:2225
kernel_clone+0x223/0x870 kernel/fork.c:2807
kernel_thread+0x1bc/0x240 kernel/fork.c:2869
create_kthread kernel/kthread.c:412 [inline]
kthreadd+0x60d/0x810 kernel/kthread.c:767
ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
Freed by task 24:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582
poison_slab_object mm/kasan/common.c:247 [inline]
__kasan_slab_free+0x59/0x70 mm/kasan/common.c:264
kasan_slab_free include/linux/kasan.h:233 [inline]
slab_free_hook mm/slub.c:2338 [inline]
slab_free mm/slub.c:4598 [inline]
kmem_cache_free+0x195/0x410 mm/slub.c:4700
put_task_struct include/linux/sched/task.h:144 [inline]
delayed_put_task_struct+0x125/0x300 kernel/exit.c:227
rcu_do_batch kernel/rcu/tree.c:2567 [inline]
rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823
handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:554
run_ksoftirqd+0xca/0x130 kernel/softirq.c:943
---truncated--- |
["https://git.kernel.org/stable/c/1ea629e7bb2fb40555e5e01a1b5095df31287017","https://git.kernel.org/stable/c/35916b2f96505a18dc7242a115611b718d9de725","https://git.kernel.org/stable/c/63f4b594a688bf922e8691f0784679aa7af7988c","https://git.kernel.org/stable/c/a2718ed1eb8c3611b63f8933c7e68c8821fe2808","https://git.kernel.org/stable/c/d77a3a99b53d12c061c007cdc96df38825dee476","https://git.kernel.org/stable/c/f10bef73fb355e3fc85e63a50386798be68ff486"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57900
|
High |
fixed |
- 5.4.289
- 5.10.233
- 5.15.176
- 6.1.124
- 6.6.70
- 6.12.9
|
In the Linux kernel, the following vulnerability has been resolved:
ila: serialize calls to nf_register_net_hooks()
syzbot found a race in ila_add_mapping() [1]
commit 031ae72825ce ("ila: call nf_unregister_net_hooks() sooner")
attempted to fix a similar issue.
Looking at the syzbot repro, we have concurrent ILA_CMD_ADD commands.
Add a mutex to make sure at most one thread is calling nf_register_net_hooks().
[1]
BUG: KASAN: slab-use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline]
BUG: KASAN: slab-use-after-free in __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604
Read of size 4 at addr ffff888028f40008 by task dhcpcd/5501
CPU: 1 UID: 0 PID: 5501 Comm: dhcpcd Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xc3/0x620 mm/kasan/report.c:489
kasan_report+0xd9/0x110 mm/kasan/report.c:602
rht_key_hashfn include/linux/rhashtable.h:159 [inline]
__rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604
rhashtable_lookup include/linux/rhashtable.h:646 [inline]
rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline]
ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:127 [inline]
ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline]
ila_nf_input+0x1ee/0x620 net/ipv6/ila/ila_xlat.c:185
nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
nf_hook_slow+0xbb/0x200 net/netfilter/core.c:626
nf_hook.constprop.0+0x42e/0x750 include/linux/netfilter.h:269
NF_HOOK include/linux/netfilter.h:312 [inline]
ipv6_rcv+0xa4/0x680 net/ipv6/ip6_input.c:309
__netif_receive_skb_one_core+0x12e/0x1e0 net/core/dev.c:5672
__netif_receive_skb+0x1d/0x160 net/core/dev.c:5785
process_backlog+0x443/0x15f0 net/core/dev.c:6117
__napi_poll.constprop.0+0xb7/0x550 net/core/dev.c:6883
napi_poll net/core/dev.c:6952 [inline]
net_rx_action+0xa94/0x1010 net/core/dev.c:7074
handle_softirqs+0x213/0x8f0 kernel/softirq.c:561
__do_softirq kernel/softirq.c:595 [inline]
invoke_softirq kernel/softirq.c:435 [inline]
__irq_exit_rcu+0x109/0x170 kernel/softirq.c:662
irq_exit_rcu+0x9/0x30 kernel/softirq.c:678
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]
sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049 |
["https://git.kernel.org/stable/c/1638f430f8900f2375f5de45508fbe553997e190","https://git.kernel.org/stable/c/17e8fa894345e8d2c7a7642482267b275c3d4553","https://git.kernel.org/stable/c/260466b576bca0081a7d4acecc8e93687aa22d0e","https://git.kernel.org/stable/c/3d1b63cf468e446b9feaf4e4e73182b9cc82f460","https://git.kernel.org/stable/c/ad0677c37c14fa28913daea92d139644d7acf04e","https://git.kernel.org/stable/c/d3017895e393536b234cf80a83fc463c08a28137","https://git.kernel.org/stable/c/eba25e21dce7ec70e2b3f121b2f3a25a4ec43eca"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46673
|
High |
fixed |
- 4.19.321
- 5.4.283
- 5.10.225
- 5.15.166
- 6.1.108
- 6.6.49
- 6.10.8
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: aacraid: Fix double-free on probe failure
aac_probe_one() calls hardware-specific init functions through the
aac_driver_ident::init pointer, all of which eventually call down to
aac_init_adapter().
If aac_init_adapter() fails after allocating memory for aac_dev::queues,
it frees the memory but does not clear that member.
After the hardware-specific init function returns an error,
aac_probe_one() goes down an error path that frees the memory pointed to
by aac_dev::queues, resulting.in a double-free. |
["https://git.kernel.org/stable/c/4b540ec7c0045c2d01c4e479f34bbc8f147afa4c","https://git.kernel.org/stable/c/564e1986b00c5f05d75342f8407f75f0a17b94df","https://git.kernel.org/stable/c/60962c3d8e18e5d8dfa16df788974dd7f35bd87a","https://git.kernel.org/stable/c/85449b28ff6a89c4513115e43ddcad949b5890c9","https://git.kernel.org/stable/c/8a3995a3ffeca280a961b59f5c99843d81b15929","https://git.kernel.org/stable/c/919ddf8336f0b84c0453bac583808c9f165a85c2","https://git.kernel.org/stable/c/9e96dea7eff6f2bbcd0b42a098012fc66af9eb69","https://git.kernel.org/stable/c/d237c7d06ffddcdb5d36948c527dc01284388218"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50063
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Prevent tail call between progs attached to different hooks
bpf progs can be attached to kernel functions, and the attached functions
can take different parameters or return different return values. If
prog attached to one kernel function tail calls prog attached to another
kernel function, the ctx access or return value verification could be
bypassed.
For example, if prog1 is attached to func1 which takes only 1 parameter
and prog2 is attached to func2 which takes two parameters. Since verifier
assumes the bpf ctx passed to prog2 is constructed based on func2's
prototype, verifier allows prog2 to access the second parameter from
the bpf ctx passed to it. The problem is that verifier does not prevent
prog1 from passing its bpf ctx to prog2 via tail call. In this case,
the bpf ctx passed to prog2 is constructed from func1 instead of func2,
that is, the assumption for ctx access verification is bypassed.
Another example, if BPF LSM prog1 is attached to hook file_alloc_security,
and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier
knows the return value rules for these two hooks, e.g. it is legal for
bpf_lsm_audit_rule_known to return positive number 1, and it is illegal
for file_alloc_security to return positive number. So verifier allows
prog2 to return positive number 1, but does not allow prog1 to return
positive number. The problem is that verifier does not prevent prog1
from calling prog2 via tail call. In this case, prog2's return value 1
will be used as the return value for prog1's hook file_alloc_security.
That is, the return value rule is bypassed.
This patch adds restriction for tail call to prevent such bypasses. |
["https://git.kernel.org/stable/c/28ead3eaabc16ecc907cfb71876da028080f6356","https://git.kernel.org/stable/c/5d5e3b4cbe8ee16b7bf96fd73a421c92a9da3ca1","https://git.kernel.org/stable/c/88c2a10e6c176c2860cd0659f4c0e9d20b3f64d1","https://git.kernel.org/stable/c/d9a807fb7cbfad4328824186e2e4bee28f72169b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48834
|
High |
fixed |
- 5.4.187
- 5.10.108
- 5.15.31
- 5.16.17
|
In the Linux kernel, the following vulnerability has been resolved:
usb: usbtmc: Fix bug in pipe direction for control transfers
The syzbot fuzzer reported a minor bug in the usbtmc driver:
usb 5-1: BOGUS control dir, pipe 80001e80 doesn't match bRequestType 0
WARNING: CPU: 0 PID: 3813 at drivers/usb/core/urb.c:412
usb_submit_urb+0x13a5/0x1970 drivers/usb/core/urb.c:410
Modules linked in:
CPU: 0 PID: 3813 Comm: syz-executor122 Not tainted
5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #0
...
Call Trace:
<TASK>
usb_start_wait_urb+0x113/0x530 drivers/usb/core/message.c:58
usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
usb_control_msg+0x2a5/0x4b0 drivers/usb/core/message.c:153
usbtmc_ioctl_request drivers/usb/class/usbtmc.c:1947 [inline]
The problem is that usbtmc_ioctl_request() uses usb_rcvctrlpipe() for
all of its transfers, whether they are in or out. It's easy to fix. |
["https://git.kernel.org/stable/c/10a805334a11acd547602d6c4cf540a0f6ab5c6e","https://git.kernel.org/stable/c/5f6a2d63c68c12cf61259df7c3527a0e05dce952","https://git.kernel.org/stable/c/700a0715854c1e79a73341724ce4f5bb01abc016","https://git.kernel.org/stable/c/c69aef9db878ab277068a8cc1b4bf0cf309dc2b7","https://git.kernel.org/stable/c/e9b667a82cdcfe21d590344447d65daed52b353b","https://git.kernel.org/stable/c/10a805334a11acd547602d6c4cf540a0f6ab5c6e","https://git.kernel.org/stable/c/5f6a2d63c68c12cf61259df7c3527a0e05dce952","https://git.kernel.org/stable/c/700a0715854c1e79a73341724ce4f5bb01abc016","https://git.kernel.org/stable/c/c69aef9db878ab277068a8cc1b4bf0cf309dc2b7","https://git.kernel.org/stable/c/e9b667a82cdcfe21d590344447d65daed52b353b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39496
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: zoned: fix use-after-free due to race with dev replace
While loading a zone's info during creation of a block group, we can race
with a device replace operation and then trigger a use-after-free on the
device that was just replaced (source device of the replace operation).
This happens because at btrfs_load_zone_info() we extract a device from
the chunk map into a local variable and then use the device while not
under the protection of the device replace rwsem. So if there's a device
replace operation happening when we extract the device and that device
is the source of the replace operation, we will trigger a use-after-free
if before we finish using the device the replace operation finishes and
frees the device.
Fix this by enlarging the critical section under the protection of the
device replace rwsem so that all uses of the device are done inside the
critical section. |
["https://git.kernel.org/stable/c/0090d6e1b210551e63cf43958dc7a1ec942cdde9","https://git.kernel.org/stable/c/092571ef9a812566c8f2c9038d9c2a64c49788d6","https://git.kernel.org/stable/c/17765964703b88d8befd899f8501150bb7e07e43","https://git.kernel.org/stable/c/a0cc006f4214b87e70983c692e05bb36c59b5752","https://git.kernel.org/stable/c/0090d6e1b210551e63cf43958dc7a1ec942cdde9","https://git.kernel.org/stable/c/092571ef9a812566c8f2c9038d9c2a64c49788d6","https://git.kernel.org/stable/c/17765964703b88d8befd899f8501150bb7e07e43","https://git.kernel.org/stable/c/a0cc006f4214b87e70983c692e05bb36c59b5752"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57892
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix slab-use-after-free due to dangling pointer dqi_priv
When mounting ocfs2 and then remounting it as read-only, a
slab-use-after-free occurs after the user uses a syscall to
quota_getnextquota. Specifically, sb_dqinfo(sb, type)->dqi_priv is the
dangling pointer.
During the remounting process, the pointer dqi_priv is freed but is never
set as null leaving it to be accessed. Additionally, the read-only option
for remounting sets the DQUOT_SUSPENDED flag instead of setting the
DQUOT_USAGE_ENABLED flags. Moreover, later in the process of getting the
next quota, the function ocfs2_get_next_id is called and only checks the
quota usage flags and not the quota suspended flags.
To fix this, I set dqi_priv to null when it is freed after remounting with
read-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id.
[akpm@linux-foundation.org: coding-style cleanups] |
["https://git.kernel.org/stable/c/2d431192486367eee03cc28d0b53b97dafcb8e63","https://git.kernel.org/stable/c/2e3d203b1adede46bbba049e497765d67865be18","https://git.kernel.org/stable/c/58f9e20e2a7602e1dd649a1ec4790077c251cb6c","https://git.kernel.org/stable/c/5f3fd772d152229d94602bca243fbb658068a597","https://git.kernel.org/stable/c/8ff6f635a08c30559ded0c110c7ce03ba7747d11","https://git.kernel.org/stable/c/ba950a02d8d23811aa1120affd3adedcfac6153d","https://git.kernel.org/stable/c/f44e6d70c100614c211703f065cad448050e4a0e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-53021
|
High |
fixed |
- 5.4.231
- 5.10.166
- 5.15.91
- 6.1.9
|
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_taprio: fix possible use-after-free
syzbot reported a nasty crash [1] in net_tx_action() which
made little sense until we got a repro.
This repro installs a taprio qdisc, but providing an
invalid TCA_RATE attribute.
qdisc_create() has to destroy the just initialized
taprio qdisc, and taprio_destroy() is called.
However, the hrtimer used by taprio had already fired,
therefore advance_sched() called __netif_schedule().
Then net_tx_action was trying to use a destroyed qdisc.
We can not undo the __netif_schedule(), so we must wait
until one cpu serviced the qdisc before we can proceed.
Many thanks to Alexander Potapenko for his help.
[1]
BUG: KMSAN: uninit-value in queued_spin_trylock include/asm-generic/qspinlock.h:94 [inline]
BUG: KMSAN: uninit-value in do_raw_spin_trylock include/linux/spinlock.h:191 [inline]
BUG: KMSAN: uninit-value in __raw_spin_trylock include/linux/spinlock_api_smp.h:89 [inline]
BUG: KMSAN: uninit-value in _raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138
queued_spin_trylock include/asm-generic/qspinlock.h:94 [inline]
do_raw_spin_trylock include/linux/spinlock.h:191 [inline]
__raw_spin_trylock include/linux/spinlock_api_smp.h:89 [inline]
_raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138
spin_trylock include/linux/spinlock.h:359 [inline]
qdisc_run_begin include/net/sch_generic.h:187 [inline]
qdisc_run+0xee/0x540 include/net/pkt_sched.h:125
net_tx_action+0x77c/0x9a0 net/core/dev.c:5086
__do_softirq+0x1cc/0x7fb kernel/softirq.c:571
run_ksoftirqd+0x2c/0x50 kernel/softirq.c:934
smpboot_thread_fn+0x554/0x9f0 kernel/smpboot.c:164
kthread+0x31b/0x430 kernel/kthread.c:376
ret_from_fork+0x1f/0x30
Uninit was created at:
slab_post_alloc_hook mm/slab.h:732 [inline]
slab_alloc_node mm/slub.c:3258 [inline]
__kmalloc_node_track_caller+0x814/0x1250 mm/slub.c:4970
kmalloc_reserve net/core/skbuff.c:358 [inline]
__alloc_skb+0x346/0xcf0 net/core/skbuff.c:430
alloc_skb include/linux/skbuff.h:1257 [inline]
nlmsg_new include/net/netlink.h:953 [inline]
netlink_ack+0x5f3/0x12b0 net/netlink/af_netlink.c:2436
netlink_rcv_skb+0x55d/0x6c0 net/netlink/af_netlink.c:2507
rtnetlink_rcv+0x30/0x40 net/core/rtnetlink.c:6108
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg net/socket.c:734 [inline]
____sys_sendmsg+0xabc/0xe90 net/socket.c:2482
___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2536
__sys_sendmsg net/socket.c:2565 [inline]
__do_sys_sendmsg net/socket.c:2574 [inline]
__se_sys_sendmsg net/socket.c:2572 [inline]
__x64_sys_sendmsg+0x367/0x540 net/socket.c:2572
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
CPU: 0 PID: 13 Comm: ksoftirqd/0 Not tainted 6.0.0-rc2-syzkaller-47461-gac3859c02d7f #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022 |
["https://git.kernel.org/stable/c/1200388a0b1c3c6fda48d4d2143db8f7e4ef5348","https://git.kernel.org/stable/c/3a415d59c1dbec9d772dbfab2d2520d98360caae","https://git.kernel.org/stable/c/c53acbf2facfdfabdc6e6984a1a38f5d38b606a1","https://git.kernel.org/stable/c/c60fe70078d6e515f424cb868d07e00411b27fbc","https://git.kernel.org/stable/c/d3b2d2820a005e43855fa71b80c4a4b194201c60"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49349
|
High |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix use-after-free in ext4_rename_dir_prepare
We got issue as follows:
EXT4-fs (loop0): mounted filesystem without journal. Opts: ,errors=continue
ext4_get_first_dir_block: bh->b_data=0xffff88810bee6000 len=34478
ext4_get_first_dir_block: *parent_de=0xffff88810beee6ae bh->b_data=0xffff88810bee6000
ext4_rename_dir_prepare: [1] parent_de=0xffff88810beee6ae
==================================================================
BUG: KASAN: use-after-free in ext4_rename_dir_prepare+0x152/0x220
Read of size 4 at addr ffff88810beee6ae by task rep/1895
CPU: 13 PID: 1895 Comm: rep Not tainted 5.10.0+ #241
Call Trace:
dump_stack+0xbe/0xf9
print_address_description.constprop.0+0x1e/0x220
kasan_report.cold+0x37/0x7f
ext4_rename_dir_prepare+0x152/0x220
ext4_rename+0xf44/0x1ad0
ext4_rename2+0x11c/0x170
vfs_rename+0xa84/0x1440
do_renameat2+0x683/0x8f0
__x64_sys_renameat+0x53/0x60
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f45a6fc41c9
RSP: 002b:00007ffc5a470218 EFLAGS: 00000246 ORIG_RAX: 0000000000000108
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f45a6fc41c9
RDX: 0000000000000005 RSI: 0000000020000180 RDI: 0000000000000005
RBP: 00007ffc5a470240 R08: 00007ffc5a470160 R09: 0000000020000080
R10: 00000000200001c0 R11: 0000000000000246 R12: 0000000000400bb0
R13: 00007ffc5a470320 R14: 0000000000000000 R15: 0000000000000000
The buggy address belongs to the page:
page:00000000440015ce refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x10beee
flags: 0x200000000000000()
raw: 0200000000000000 ffffea00043ff4c8 ffffea0004325608 0000000000000000
raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88810beee580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff88810beee600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>ffff88810beee680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff88810beee700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff88810beee780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================
Disabling lock debugging due to kernel taint
ext4_rename_dir_prepare: [2] parent_de->inode=3537895424
ext4_rename_dir_prepare: [3] dir=0xffff888124170140
ext4_rename_dir_prepare: [4] ino=2
ext4_rename_dir_prepare: ent->dir->i_ino=2 parent=-757071872
Reason is first directory entry which 'rec_len' is 34478, then will get illegal
parent entry. Now, we do not check directory entry after read directory block
in 'ext4_get_first_dir_block'.
To solve this issue, check directory entry in 'ext4_get_first_dir_block'.
[ Trigger an ext4_error() instead of just warning if the directory is
missing a '.' or '..' entry. Also make sure we return an error code
if the file system is corrupted. -TYT ] |
["https://git.kernel.org/stable/c/0be698ecbe4471fcad80e81ec6a05001421041b3","https://git.kernel.org/stable/c/0ff38b99fa075ddd246487a28cb9af049f4ceef1","https://git.kernel.org/stable/c/10801095224de0d0ab06ae60698680c1f883a3ae","https://git.kernel.org/stable/c/1a3a15bf6f9963d755270cbdb282863b84839195","https://git.kernel.org/stable/c/364380c00912bed9b5d99eb485018360b0ecf64f","https://git.kernel.org/stable/c/4a2bea60cf7ff957b3eda0b17750d483876a02fa","https://git.kernel.org/stable/c/97f802a652a749422dede32071d29a53cf4bd034","https://git.kernel.org/stable/c/dd887f83ea54aea5b780a84527e23ab95f777fed","https://git.kernel.org/stable/c/eaecf7ebfd5dd09038a80b14be46b844f54cfc5c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57887
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm: adv7511: Fix use-after-free in adv7533_attach_dsi()
The host_node pointer was assigned and freed in adv7533_parse_dt(), and
later, adv7533_attach_dsi() uses the same. Fix this use-after-free issue
by dropping of_node_put() in adv7533_parse_dt() and calling of_node_put()
in error path of probe() and also in the remove(). |
["https://git.kernel.org/stable/c/1f49aaf55652580ae63ab83d67211fe6a55d83dc","https://git.kernel.org/stable/c/81adbd3ff21c1182e06aa02c6be0bfd9ea02d8e8","https://git.kernel.org/stable/c/acec80d9f126cd3fa764bbe3d96bc0cb5cd2b087","https://git.kernel.org/stable/c/ca9d077350fa21897de8bf64cba23b198740aab5","https://git.kernel.org/stable/c/d208571943ffddc438a7ce533d5d0b9219806242"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41073
|
High |
fixed |
- 5.15.164
- 6.1.101
- 6.6.42
- 6.9.11
|
In the Linux kernel, the following vulnerability has been resolved:
nvme: avoid double free special payload
If a discard request needs to be retried, and that retry may fail before
a new special payload is added, a double free will result. Clear the
RQF_SPECIAL_LOAD when the request is cleaned. |
["https://git.kernel.org/stable/c/1b9fd1265fac85916f90b4648de02adccdb7220b","https://git.kernel.org/stable/c/882574942a9be8b9d70d13462ddacc80c4b385ba","https://git.kernel.org/stable/c/ae84383c96d6662c24697ab6b44aae855ab670aa","https://git.kernel.org/stable/c/c5942a14f795de957ae9d66027aac8ff4fe70057","https://git.kernel.org/stable/c/e5d574ab37f5f2e7937405613d9b1a724811e5ad","https://git.kernel.org/stable/c/f3ab45aacd25d957547fb6d115c1574c20964b3b","https://git.kernel.org/stable/c/1b9fd1265fac85916f90b4648de02adccdb7220b","https://git.kernel.org/stable/c/ae84383c96d6662c24697ab6b44aae855ab670aa","https://git.kernel.org/stable/c/c5942a14f795de957ae9d66027aac8ff4fe70057","https://git.kernel.org/stable/c/e5d574ab37f5f2e7937405613d9b1a724811e5ad","https://git.kernel.org/stable/c/f3ab45aacd25d957547fb6d115c1574c20964b3b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46782
|
High |
fixed |
- 4.19.322
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
ila: call nf_unregister_net_hooks() sooner
syzbot found an use-after-free Read in ila_nf_input [1]
Issue here is that ila_xlat_exit_net() frees the rhashtable,
then call nf_unregister_net_hooks().
It should be done in the reverse way, with a synchronize_rcu().
This is a good match for a pre_exit() method.
[1]
BUG: KASAN: use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline]
BUG: KASAN: use-after-free in __rhashtable_lookup include/linux/rhashtable.h:604 [inline]
BUG: KASAN: use-after-free in rhashtable_lookup include/linux/rhashtable.h:646 [inline]
BUG: KASAN: use-after-free in rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672
Read of size 4 at addr ffff888064620008 by task ksoftirqd/0/16
CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:93 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x169/0x550 mm/kasan/report.c:488
kasan_report+0x143/0x180 mm/kasan/report.c:601
rht_key_hashfn include/linux/rhashtable.h:159 [inline]
__rhashtable_lookup include/linux/rhashtable.h:604 [inline]
rhashtable_lookup include/linux/rhashtable.h:646 [inline]
rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672
ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:132 [inline]
ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline]
ila_nf_input+0x1fe/0x3c0 net/ipv6/ila/ila_xlat.c:190
nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626
nf_hook include/linux/netfilter.h:269 [inline]
NF_HOOK+0x29e/0x450 include/linux/netfilter.h:312
__netif_receive_skb_one_core net/core/dev.c:5661 [inline]
__netif_receive_skb+0x1ea/0x650 net/core/dev.c:5775
process_backlog+0x662/0x15b0 net/core/dev.c:6108
__napi_poll+0xcb/0x490 net/core/dev.c:6772
napi_poll net/core/dev.c:6841 [inline]
net_rx_action+0x89b/0x1240 net/core/dev.c:6963
handle_softirqs+0x2c4/0x970 kernel/softirq.c:554
run_ksoftirqd+0xca/0x130 kernel/softirq.c:928
smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164
kthread+0x2f0/0x390 kernel/kthread.c:389
ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
</TASK>
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x64620
flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
page_type: 0xbfffffff(buddy)
raw: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000
raw: 0000000000000000 0000000000000003 00000000bfffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as freed
page last allocated via order 3, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5242, tgid 5242 (syz-executor), ts 73611328570, free_ts 618981657187
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493
prep_new_page mm/page_alloc.c:1501 [inline]
get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439
__alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695
__alloc_pages_node_noprof include/linux/gfp.h:269 [inline]
alloc_pages_node_noprof include/linux/gfp.h:296 [inline]
___kmalloc_large_node+0x8b/0x1d0 mm/slub.c:4103
__kmalloc_large_node_noprof+0x1a/0x80 mm/slub.c:4130
__do_kmalloc_node mm/slub.c:4146 [inline]
__kmalloc_node_noprof+0x2d2/0x440 mm/slub.c:4164
__kvmalloc_node_noprof+0x72/0x190 mm/util.c:650
bucket_table_alloc lib/rhashtable.c:186 [inline]
rhashtable_init_noprof+0x534/0xa60 lib/rhashtable.c:1071
ila_xlat_init_net+0xa0/0x110 net/ipv6/ila/ila_xlat.c:613
ops_ini
---truncated--- |
["https://git.kernel.org/stable/c/031ae72825cef43e4650140b800ad58bf7a6a466","https://git.kernel.org/stable/c/18a5a16940464b301ea91bf5da3a324aedb347b2","https://git.kernel.org/stable/c/43d34110882b97ba1ec66cc8234b18983efb9abf","https://git.kernel.org/stable/c/47abd8adddbc0aecb8f231269ef659148d5dabe4","https://git.kernel.org/stable/c/925c18a7cff93d8a4320d652351294ff7d0ac93c","https://git.kernel.org/stable/c/93ee345ba349922834e6a9d1dadabaedcc12dce6","https://git.kernel.org/stable/c/bda4d84ac0d5421b346faee720011f58bdb99673","https://git.kernel.org/stable/c/dcaf4e2216824839d26727a15b638c6a677bd9fc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46798
|
High |
fixed |
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: dapm: Fix UAF for snd_soc_pcm_runtime object
When using kernel with the following extra config,
- CONFIG_KASAN=y
- CONFIG_KASAN_GENERIC=y
- CONFIG_KASAN_INLINE=y
- CONFIG_KASAN_VMALLOC=y
- CONFIG_FRAME_WARN=4096
kernel detects that snd_pcm_suspend_all() access a freed
'snd_soc_pcm_runtime' object when the system is suspended, which
leads to a use-after-free bug:
[ 52.047746] BUG: KASAN: use-after-free in snd_pcm_suspend_all+0x1a8/0x270
[ 52.047765] Read of size 1 at addr ffff0000b9434d50 by task systemd-sleep/2330
[ 52.047785] Call trace:
[ 52.047787] dump_backtrace+0x0/0x3c0
[ 52.047794] show_stack+0x34/0x50
[ 52.047797] dump_stack_lvl+0x68/0x8c
[ 52.047802] print_address_description.constprop.0+0x74/0x2c0
[ 52.047809] kasan_report+0x210/0x230
[ 52.047815] __asan_report_load1_noabort+0x3c/0x50
[ 52.047820] snd_pcm_suspend_all+0x1a8/0x270
[ 52.047824] snd_soc_suspend+0x19c/0x4e0
The snd_pcm_sync_stop() has a NULL check on 'substream->runtime' before
making any access. So we need to always set 'substream->runtime' to NULL
everytime we kfree() it. |
["https://git.kernel.org/stable/c/3033ed903b4f28b5e1ab66042084fbc2c48f8624","https://git.kernel.org/stable/c/5d13afd021eb43868fe03cef6da34ad08831ad6d","https://git.kernel.org/stable/c/6a14fad8be178df6c4589667efec1789a3307b4e","https://git.kernel.org/stable/c/8ca21e7a27c66b95a4b215edc8e45e5d66679f9f","https://git.kernel.org/stable/c/993b60c7f93fa1d8ff296b58f646a867e945ae89","https://git.kernel.org/stable/c/b4a90b543d9f62d3ac34ec1ab97fc5334b048565","https://git.kernel.org/stable/c/fe5046ca91d631ec432eee3bdb1f1c49b09c8b5e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46849
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: meson: axg-card: fix 'use-after-free'
Buffer 'card->dai_link' is reallocated in 'meson_card_reallocate_links()',
so move 'pad' pointer initialization after this function when memory is
already reallocated.
Kasan bug report:
==================================================================
BUG: KASAN: slab-use-after-free in axg_card_add_link+0x76c/0x9bc
Read of size 8 at addr ffff000000e8b260 by task modprobe/356
CPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1
Call trace:
dump_backtrace+0x94/0xec
show_stack+0x18/0x24
dump_stack_lvl+0x78/0x90
print_report+0xfc/0x5c0
kasan_report+0xb8/0xfc
__asan_load8+0x9c/0xb8
axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card]
meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils]
platform_probe+0x8c/0xf4
really_probe+0x110/0x39c
__driver_probe_device+0xb8/0x18c
driver_probe_device+0x108/0x1d8
__driver_attach+0xd0/0x25c
bus_for_each_dev+0xe0/0x154
driver_attach+0x34/0x44
bus_add_driver+0x134/0x294
driver_register+0xa8/0x1e8
__platform_driver_register+0x44/0x54
axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card]
do_one_initcall+0xdc/0x25c
do_init_module+0x10c/0x334
load_module+0x24c4/0x26cc
init_module_from_file+0xd4/0x128
__arm64_sys_finit_module+0x1f4/0x41c
invoke_syscall+0x60/0x188
el0_svc_common.constprop.0+0x78/0x13c
do_el0_svc+0x30/0x40
el0_svc+0x38/0x78
el0t_64_sync_handler+0x100/0x12c
el0t_64_sync+0x190/0x194 |
["https://git.kernel.org/stable/c/4f9a71435953f941969a4f017e2357db62d85a86","https://git.kernel.org/stable/c/5a2cc2bb81399e9ebc72560541137eb04d61dc3d","https://git.kernel.org/stable/c/7d318166bf55e9029d56997c3b134f4ac2ae2607","https://git.kernel.org/stable/c/a33145f494e6cb82f3e018662cc7c4febf271f22","https://git.kernel.org/stable/c/e1a199ec31617242e1a0ea8f312341e682d0c037","https://git.kernel.org/stable/c/e43364f578cdc2f8083abbc0cb743ea55e827c29","https://git.kernel.org/stable/c/fb0530025d502cb79d2b2801b14a9d5261833f1a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46852
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
dma-buf: heaps: Fix off-by-one in CMA heap fault handler
Until VM_DONTEXPAND was added in commit 1c1914d6e8c6 ("dma-buf: heaps:
Don't track CMA dma-buf pages under RssFile") it was possible to obtain
a mapping larger than the buffer size via mremap and bypass the overflow
check in dma_buf_mmap_internal. When using such a mapping to attempt to
fault past the end of the buffer, the CMA heap fault handler also checks
the fault offset against the buffer size, but gets the boundary wrong by
1. Fix the boundary check so that we don't read off the end of the pages
array and insert an arbitrary page in the mapping. |
["https://git.kernel.org/stable/c/007180fcb6cc4a93211d4cc45fef3f5ccccd56ae","https://git.kernel.org/stable/c/79cce5e81d20fa9ad553be439d665ac3302d3c95","https://git.kernel.org/stable/c/84175dc5b2c932266a50c04e5ce342c30f817a2f","https://git.kernel.org/stable/c/e79050882b857c37634baedbdcf7c2047c24cbff","https://git.kernel.org/stable/c/ea5ff5d351b520524019f7ff7f9ce418de2dad87","https://git.kernel.org/stable/c/eb7fc8b65cea22f9038c52398c8b22849e9620ea"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26699
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix array-index-out-of-bounds in dcn35_clkmgr
[Why]
There is a potential memory access violation while
iterating through array of dcn35 clks.
[How]
Limit iteration per array size. |
["https://git.kernel.org/stable/c/46806e59a87790760870d216f54951a5b4d545bc","https://git.kernel.org/stable/c/ca400d8e0c1c9d79c08dfb6b7f966e26c8cae7fb","https://git.kernel.org/stable/c/46806e59a87790760870d216f54951a5b4d545bc","https://git.kernel.org/stable/c/ca400d8e0c1c9d79c08dfb6b7f966e26c8cae7fb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-35829
|
High |
fixed |
- 5.10.180
- 5.15.111
- 6.1.28
- 6.2.15
- 6.3.2
|
An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in rkvdec_remove in drivers/staging/media/rkvdec/rkvdec.c. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3228cec23b8b29215e18090c6ba635840190993d","https://lore.kernel.org/all/a4dafa22-3ee3-dbe1-fd50-fee07883ce1a%40xs4all.nl/","https://lore.kernel.org/lkml/20230307173900.1299387-1-zyytlz.wz%40163.com/T/","https://security.netapp.com/advisory/ntap-20230803-0002/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3228cec23b8b29215e18090c6ba635840190993d","https://lore.kernel.org/all/a4dafa22-3ee3-dbe1-fd50-fee07883ce1a%40xs4all.nl/","https://lore.kernel.org/lkml/20230307173900.1299387-1-zyytlz.wz%40163.com/T/","https://security.netapp.com/advisory/ntap-20230803-0002/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42311
|
Medium |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
hfs: fix to initialize fields of hfs_inode_info after hfs_alloc_inode()
Syzbot reports uninitialized value access issue as below:
loop0: detected capacity change from 0 to 64
=====================================================
BUG: KMSAN: uninit-value in hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30
hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30
d_revalidate fs/namei.c:862 [inline]
lookup_fast+0x89e/0x8e0 fs/namei.c:1649
walk_component fs/namei.c:2001 [inline]
link_path_walk+0x817/0x1480 fs/namei.c:2332
path_lookupat+0xd9/0x6f0 fs/namei.c:2485
filename_lookup+0x22e/0x740 fs/namei.c:2515
user_path_at_empty+0x8b/0x390 fs/namei.c:2924
user_path_at include/linux/namei.h:57 [inline]
do_mount fs/namespace.c:3689 [inline]
__do_sys_mount fs/namespace.c:3898 [inline]
__se_sys_mount+0x66b/0x810 fs/namespace.c:3875
__x64_sys_mount+0xe4/0x140 fs/namespace.c:3875
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
BUG: KMSAN: uninit-value in hfs_ext_read_extent fs/hfs/extent.c:196 [inline]
BUG: KMSAN: uninit-value in hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366
hfs_ext_read_extent fs/hfs/extent.c:196 [inline]
hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366
block_read_full_folio+0x4ff/0x11b0 fs/buffer.c:2271
hfs_read_folio+0x55/0x60 fs/hfs/inode.c:39
filemap_read_folio+0x148/0x4f0 mm/filemap.c:2426
do_read_cache_folio+0x7c8/0xd90 mm/filemap.c:3553
do_read_cache_page mm/filemap.c:3595 [inline]
read_cache_page+0xfb/0x2f0 mm/filemap.c:3604
read_mapping_page include/linux/pagemap.h:755 [inline]
hfs_btree_open+0x928/0x1ae0 fs/hfs/btree.c:78
hfs_mdb_get+0x260c/0x3000 fs/hfs/mdb.c:204
hfs_fill_super+0x1fb1/0x2790 fs/hfs/super.c:406
mount_bdev+0x628/0x920 fs/super.c:1359
hfs_mount+0xcd/0xe0 fs/hfs/super.c:456
legacy_get_tree+0x167/0x2e0 fs/fs_context.c:610
vfs_get_tree+0xdc/0x5d0 fs/super.c:1489
do_new_mount+0x7a9/0x16f0 fs/namespace.c:3145
path_mount+0xf98/0x26a0 fs/namespace.c:3475
do_mount fs/namespace.c:3488 [inline]
__do_sys_mount fs/namespace.c:3697 [inline]
__se_sys_mount+0x919/0x9e0 fs/namespace.c:3674
__ia32_sys_mount+0x15b/0x1b0 fs/namespace.c:3674
do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
__do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178
do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203
do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246
entry_SYSENTER_compat_after_hwframe+0x70/0x82
Uninit was created at:
__alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590
__alloc_pages_node include/linux/gfp.h:238 [inline]
alloc_pages_node include/linux/gfp.h:261 [inline]
alloc_slab_page mm/slub.c:2190 [inline]
allocate_slab mm/slub.c:2354 [inline]
new_slab+0x2d7/0x1400 mm/slub.c:2407
___slab_alloc+0x16b5/0x3970 mm/slub.c:3540
__slab_alloc mm/slub.c:3625 [inline]
__slab_alloc_node mm/slub.c:3678 [inline]
slab_alloc_node mm/slub.c:3850 [inline]
kmem_cache_alloc_lru+0x64d/0xb30 mm/slub.c:3879
alloc_inode_sb include/linux/fs.h:3018 [inline]
hfs_alloc_inode+0x5a/0xc0 fs/hfs/super.c:165
alloc_inode+0x83/0x440 fs/inode.c:260
new_inode_pseudo fs/inode.c:1005 [inline]
new_inode+0x38/0x4f0 fs/inode.c:1031
hfs_new_inode+0x61/0x1010 fs/hfs/inode.c:186
hfs_mkdir+0x54/0x250 fs/hfs/dir.c:228
vfs_mkdir+0x49a/0x700 fs/namei.c:4126
do_mkdirat+0x529/0x810 fs/namei.c:4149
__do_sys_mkdirat fs/namei.c:4164 [inline]
__se_sys_mkdirat fs/namei.c:4162 [inline]
__x64_sys_mkdirat+0xc8/0x120 fs/namei.c:4162
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
It missed to initialize .tz_secondswest, .cached_start and .cached_blocks
fields in struct hfs_inode_info after hfs_alloc_inode(), fix it. |
["https://git.kernel.org/stable/c/10f7163bfb5f8b4e0c9c05a939f20b8540e33c65","https://git.kernel.org/stable/c/26a2ed107929a855155429b11e1293b83e6b2a8b","https://git.kernel.org/stable/c/4a52861cd76e79f1a593beb23d096523eb9732c2","https://git.kernel.org/stable/c/58d83fc160505a7009c39dec64effaac5129b971","https://git.kernel.org/stable/c/9c4e40b9b731220f9464975e49da75496e3865c4","https://git.kernel.org/stable/c/d3493d6f0dfb1ab5225b62faa77732983f2187a1","https://git.kernel.org/stable/c/d55aae5c1730d6b70d5d8eaff00113cd34772ea3","https://git.kernel.org/stable/c/f7316b2b2f11cf0c6de917beee8d3de728be24db"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-45025
|
Medium |
fixed |
- 4.19.321
- 5.4.283
- 5.10.225
- 5.15.166
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE
copy_fd_bitmaps(new, old, count) is expected to copy the first
count/BITS_PER_LONG bits from old->full_fds_bits[] and fill
the rest with zeroes. What it does is copying enough words
(BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.
That works fine, *if* all bits past the cutoff point are
clear. Otherwise we are risking garbage from the last word
we'd copied.
For most of the callers that is true - expand_fdtable() has
count equal to old->max_fds, so there's no open descriptors
past count, let alone fully occupied words in ->open_fds[],
which is what bits in ->full_fds_bits[] correspond to.
The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),
which is the smallest multiple of BITS_PER_LONG that covers all
opened descriptors below max_fds. In the common case (copying on
fork()) max_fds is ~0U, so all opened descriptors will be below
it and we are fine, by the same reasons why the call in expand_fdtable()
is safe.
Unfortunately, there is a case where max_fds is less than that
and where we might, indeed, end up with junk in ->full_fds_bits[] -
close_range(from, to, CLOSE_RANGE_UNSHARE) with
* descriptor table being currently shared
* 'to' being above the current capacity of descriptor table
* 'from' being just under some chunk of opened descriptors.
In that case we end up with observably wrong behaviour - e.g. spawn
a child with CLONE_FILES, get all descriptors in range 0..127 open,
then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending
up with descriptor #128, despite #64 being observably not open.
The minimally invasive fix would be to deal with that in dup_fd().
If this proves to add measurable overhead, we can go that way, but
let's try to fix copy_fd_bitmaps() first.
* new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).
* make copy_fd_bitmaps() take the bitmap size in words, rather than
bits; it's 'count' argument is always a multiple of BITS_PER_LONG,
so we are not losing any information, and that way we can use the
same helper for all three bitmaps - compiler will see that count
is a multiple of BITS_PER_LONG for the large ones, so it'll generate
plain memcpy()+memset().
Reproducer added to tools/testing/selftests/core/close_range_test.c |
["https://git.kernel.org/stable/c/5053581fe5dfb09b58c65dd8462bf5dea71f41ff","https://git.kernel.org/stable/c/8cad3b2b3ab81ca55f37405ffd1315bcc2948058","https://git.kernel.org/stable/c/9a2fa1472083580b6c66bdaf291f591e1170123a","https://git.kernel.org/stable/c/c69d18f0ac7060de724511537810f10f29a27958","https://git.kernel.org/stable/c/dd72ae8b0fce9c0bbe9582b9b50820f0407f8d8a","https://git.kernel.org/stable/c/e807487a1d5fd5d941f26578ae826ca815dbfcd6","https://git.kernel.org/stable/c/ee501f827f3db02d4e599afbbc1a7f8b792d05d7","https://git.kernel.org/stable/c/fe5bf14881701119aeeda7cf685f3c226c7380df"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46675
|
Medium |
fixed |
- 4.19.321
- 5.4.283
- 5.10.225
- 5.15.166
- 6.1.108
- 6.6.49
- 6.10.8
|
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: core: Prevent USB core invalid event buffer address access
This commit addresses an issue where the USB core could access an
invalid event buffer address during runtime suspend, potentially causing
SMMU faults and other memory issues in Exynos platforms. The problem
arises from the following sequence.
1. In dwc3_gadget_suspend, there is a chance of a timeout when
moving the USB core to the halt state after clearing the
run/stop bit by software.
2. In dwc3_core_exit, the event buffer is cleared regardless of
the USB core's status, which may lead to an SMMU faults and
other memory issues. if the USB core tries to access the event
buffer address.
To prevent this hardware quirk on Exynos platforms, this commit ensures
that the event buffer address is not cleared by software when the USB
core is active during runtime suspend by checking its status before
clearing the buffer address. |
["https://git.kernel.org/stable/c/111277b881def3153335acfe0d1f43e6cd83ac93","https://git.kernel.org/stable/c/14e497183df28c006603cc67fd3797a537eef7b9","https://git.kernel.org/stable/c/2189fd13c577d7881f94affc09c950a795064c4b","https://git.kernel.org/stable/c/7bb11a75dd4d3612378b90e2a4aa49bdccea28ab","https://git.kernel.org/stable/c/b72da4d89b97da71e056cc4d1429b2bc426a9c2f","https://git.kernel.org/stable/c/d2afc2bffec77316b90d530b07695e3f534df914","https://git.kernel.org/stable/c/e23f6ad8d110bf632f7471482e10b43dc174fb72","https://git.kernel.org/stable/c/eca3f543f817da87c00d1a5697b473efb548204f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26706
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
parisc: Fix random data corruption from exception handler
The current exception handler implementation, which assists when accessing
user space memory, may exhibit random data corruption if the compiler decides
to use a different register than the specified register %r29 (defined in
ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another
register, the fault handler will nevertheless store -EFAULT into %r29 and thus
trash whatever this register is used for.
Looking at the assembly I found that this happens sometimes in emulate_ldd().
To solve the issue, the easiest solution would be if it somehow is
possible to tell the fault handler which register is used to hold the error
code. Using %0 or %1 in the inline assembly is not posssible as it will show
up as e.g. %r29 (with the "%r" prefix), which the GNU assembler can not
convert to an integer.
This patch takes another, better and more flexible approach:
We extend the __ex_table (which is out of the execution path) by one 32-word.
In this word we tell the compiler to insert the assembler instruction
"or %r0,%r0,%reg", where %reg references the register which the compiler
choosed for the error return code.
In case of an access failure, the fault handler finds the __ex_table entry and
can examine the opcode. The used register is encoded in the lowest 5 bits, and
the fault handler can then store -EFAULT into this register.
Since we extend the __ex_table to 3 words we can't use the BUILDTIME_TABLE_SORT
config option any longer. |
["https://git.kernel.org/stable/c/23027309b099ffc4efca5477009a11dccbdae592","https://git.kernel.org/stable/c/8b1d72395635af45410b66cc4c4ab37a12c4a831","https://git.kernel.org/stable/c/ce31d79aa1f13a2345791f84935281a2c194e003","https://git.kernel.org/stable/c/fa69a8063f8b27f3c7434a0d4f464a76a62f24d2","https://git.kernel.org/stable/c/23027309b099ffc4efca5477009a11dccbdae592","https://git.kernel.org/stable/c/8b1d72395635af45410b66cc4c4ab37a12c4a831","https://git.kernel.org/stable/c/ce31d79aa1f13a2345791f84935281a2c194e003","https://git.kernel.org/stable/c/fa69a8063f8b27f3c7434a0d4f464a76a62f24d2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57922
|
Medium |
fixed |
- 5.4.290
- 5.10.234
- 5.15.177
- 6.1.125
- 6.6.72
- 6.12.10
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add check for granularity in dml ceil/floor helpers
[Why]
Wrapper functions for dcn_bw_ceil2() and dcn_bw_floor2()
should check for granularity is non zero to avoid assert and
divide-by-zero error in dcn_bw_ functions.
[How]
Add check for granularity 0.
(cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec) |
["https://git.kernel.org/stable/c/0881fbc4fd62e00a2b8e102725f76d10351b2ea8","https://git.kernel.org/stable/c/497471baf53bb8fd3cd1529d65d4d7f7b81f1917","https://git.kernel.org/stable/c/4f0dd09ed3001725ffd8cdc2868e71df585392fe","https://git.kernel.org/stable/c/8a9315e6f7b2d94c65a1ba476481deddb20fc3ae","https://git.kernel.org/stable/c/95793f9684e58d2aa56671b2d616b4f9f577a0a8","https://git.kernel.org/stable/c/ae9ab63a268be99a27a4720ca24f6be801744fee","https://git.kernel.org/stable/c/f3d1e4062ef251fa55ccfeca1e54a98b6818b3a1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42246
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket
When using a BPF program on kernel_connect(), the call can return -EPERM. This
causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing
the kernel to potentially freeze up.
Neil suggested:
This will propagate -EPERM up into other layers which might not be ready
to handle it. It might be safer to map EPERM to an error we would be more
likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.
ECONNREFUSED as error seems reasonable. For programs setting a different error
can be out of reach (see handling in 4fbac77d2d09) in particular on kernels
which do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err
instead of allow boolean"), thus given that it is better to simply remap for
consistent behavior. UDP does handle EPERM in xs_udp_send_request(). |
["https://git.kernel.org/stable/c/02ee1976edb21a96ce8e3fd4ef563f14cc16d041","https://git.kernel.org/stable/c/5d8254e012996cee1a0f9cc920531cb7e4d9a011","https://git.kernel.org/stable/c/626dfed5fa3bfb41e0dffd796032b555b69f9cde","https://git.kernel.org/stable/c/934247ea65bc5eca8bdb7f8c0ddc15cef992a5d6","https://git.kernel.org/stable/c/bc790261218952635f846aaf90bcc0974f6f62c6","https://git.kernel.org/stable/c/d6c686c01c5f12ff8f7264e0ddf71df6cb0d4414","https://git.kernel.org/stable/c/f2431e7db0fe0daccb2f06bb0d23740affcd2fa6","https://git.kernel.org/stable/c/f388cfd913a2b96c05339a335f365795db1b36b6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-0400
|
High |
|
N/A
|
An out-of-bounds read vulnerability was discovered in linux kernel in the smc protocol stack, causing remote dos. |
["https://access.redhat.com/security/cve/CVE-2022-0400","https://bugzilla.redhat.com/show_bug.cgi?id=2040604","https://bugzilla.redhat.com/show_bug.cgi?id=2044575","https://access.redhat.com/security/cve/CVE-2022-0400","https://bugzilla.redhat.com/show_bug.cgi?id=2040604","https://bugzilla.redhat.com/show_bug.cgi?id=2044575"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50278
|
High |
fixed |
- 4.19.324
- 5.4.286
- 5.10.230
- 5.15.172
- 6.1.117
- 6.6.61
- 6.11.8
|
In the Linux kernel, the following vulnerability has been resolved:
dm cache: fix potential out-of-bounds access on the first resume
Out-of-bounds access occurs if the fast device is expanded unexpectedly
before the first-time resume of the cache table. This happens because
expanding the fast device requires reloading the cache table for
cache_create to allocate new in-core data structures that fit the new
size, and the check in cache_preresume is not performed during the
first resume, leading to the issue.
Reproduce steps:
1. prepare component devices:
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"
dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"
dmsetup create corig --table "0 524288 linear /dev/sdc 262144"
dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct
2. load a cache table of 512 cache blocks, and deliberately expand the
fast device before resuming the cache, making the in-core data
structures inadequate.
dmsetup create cache --notable
dmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \
/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"
dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192"
dmsetup resume cdata
dmsetup resume cache
3. suspend the cache to write out the in-core dirty bitset and hint
array, leading to out-of-bounds access to the dirty bitset at offset
0x40:
dmsetup suspend cache
KASAN reports:
BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80
Read of size 8 at addr ffffc90000085040 by task dmsetup/90
(...snip...)
The buggy address belongs to the virtual mapping at
[ffffc90000085000, ffffc90000087000) created by:
cache_ctr+0x176a/0x35f0
(...snip...)
Memory state around the buggy address:
ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8
^
ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
Fix by checking the size change on the first resume. |
["https://git.kernel.org/stable/c/036dd6e3d2638103e0092864577ea1d091466b86","https://git.kernel.org/stable/c/13ed3624c6ef283acefa4cc42cc8ae54fd4391a4","https://git.kernel.org/stable/c/2222b0929d00e2d13732b799b63be391b5de4492","https://git.kernel.org/stable/c/483b7261b35a9d369082ab298a6670912243f0be","https://git.kernel.org/stable/c/c0ade5d98979585d4f5a93e4514c2e9a65afa08d","https://git.kernel.org/stable/c/c52ec00cb2f9bebfada22edcc0db385b910a1cdb","https://git.kernel.org/stable/c/e492f71854ce03474d49e87fd98b8df1f7cd1d2d","https://git.kernel.org/stable/c/fdef3b94dfebd57e3077a578b6e309a2bb6fa688"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50279
|
High |
fixed |
- 4.19.324
- 5.4.286
- 5.10.230
- 5.15.172
- 6.1.117
- 6.6.61
- 6.11.8
|
In the Linux kernel, the following vulnerability has been resolved:
dm cache: fix out-of-bounds access to the dirty bitset when resizing
dm-cache checks the dirty bits of the cache blocks to be dropped when
shrinking the fast device, but an index bug in bitset iteration causes
out-of-bounds access.
Reproduce steps:
1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"
dmsetup create cdata --table "0 131072 linear /dev/sdc 8192"
dmsetup create corig --table "0 524288 linear /dev/sdc 262144"
dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct
dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \
/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"
2. shrink the fast device to 512 cache blocks, triggering out-of-bounds
access to the dirty bitset (offset 0x80)
dmsetup suspend cache
dmsetup reload cdata --table "0 65536 linear /dev/sdc 8192"
dmsetup resume cdata
dmsetup resume cache
KASAN reports:
BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0
Read of size 8 at addr ffffc900000f3080 by task dmsetup/131
(...snip...)
The buggy address belongs to the virtual mapping at
[ffffc900000f3000, ffffc900000f5000) created by:
cache_ctr+0x176a/0x35f0
(...snip...)
Memory state around the buggy address:
ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
^
ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
Fix by making the index post-incremented. |
["https://git.kernel.org/stable/c/3b02c40ff10fdf83cc545850db208de855ebe22c","https://git.kernel.org/stable/c/4fa4feb873cea0e9d6ff883b37cca6f33169d8b4","https://git.kernel.org/stable/c/56507203e1b6127967ec2b51fb0b23a0d4af1334","https://git.kernel.org/stable/c/792227719725497ce10a8039803bec13f89f8910","https://git.kernel.org/stable/c/8501e38dc9e0060814c4085815fc83da3e6d43bf","https://git.kernel.org/stable/c/e57648ce325fa405fe6bbd0e6a618ced7c301a2d","https://git.kernel.org/stable/c/ee1f74925717ab36f6a091104c170639501ce818","https://git.kernel.org/stable/c/ff1dd8a04c30e8d4e2fd5c83198ca672eb6a9e7f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50301
|
High |
fixed |
- 4.19.324
- 5.4.286
- 5.10.230
- 5.15.172
- 6.1.117
- 6.6.61
- 6.11.8
|
In the Linux kernel, the following vulnerability has been resolved:
security/keys: fix slab-out-of-bounds in key_task_permission
KASAN reports an out of bounds read:
BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36
BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline]
BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410
security/keys/permission.c:54
Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362
CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15
Call Trace:
__dump_stack lib/dump_stack.c:82 [inline]
dump_stack+0x107/0x167 lib/dump_stack.c:123
print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400
__kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560
kasan_report+0x3a/0x50 mm/kasan/report.c:585
__kuid_val include/linux/uidgid.h:36 [inline]
uid_eq include/linux/uidgid.h:63 [inline]
key_task_permission+0x394/0x410 security/keys/permission.c:54
search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793
This issue was also reported by syzbot.
It can be reproduced by following these steps(more details [1]):
1. Obtain more than 32 inputs that have similar hashes, which ends with the
pattern '0xxxxxxxe6'.
2. Reboot and add the keys obtained in step 1.
The reproducer demonstrates how this issue happened:
1. In the search_nested_keyrings function, when it iterates through the
slots in a node(below tag ascend_to_node), if the slot pointer is meta
and node->back_pointer != NULL(it means a root), it will proceed to
descend_to_node. However, there is an exception. If node is the root,
and one of the slots points to a shortcut, it will be treated as a
keyring.
2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function.
However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as
ASSOC_ARRAY_PTR_SUBTYPE_MASK.
3. When 32 keys with the similar hashes are added to the tree, the ROOT
has keys with hashes that are not similar (e.g. slot 0) and it splits
NODE A without using a shortcut. When NODE A is filled with keys that
all hashes are xxe6, the keys are similar, NODE A will split with a
shortcut. Finally, it forms the tree as shown below, where slot 6 points
to a shortcut.
NODE A
+------>+---+
ROOT | | 0 | xxe6
+---+ | +---+
xxxx | 0 | shortcut : : xxe6
+---+ | +---+
xxe6 : : | | | xxe6
+---+ | +---+
| 6 |---+ : : xxe6
+---+ +---+
xxe6 : : | f | xxe6
+---+ +---+
xxe6 | f |
+---+
4. As mentioned above, If a slot(slot 6) of the root points to a shortcut,
it may be mistakenly transferred to a key*, leading to a read
out-of-bounds read.
To fix this issue, one should jump to descend_to_node if the ptr is a
shortcut, regardless of whether the node is root or not.
[1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/
[jarkko: tweaked the commit message a bit to have an appropriate closes
tag.] |
["https://git.kernel.org/stable/c/199c20fb7499c79557a075dc24e9a7dae7d9f1ce","https://git.kernel.org/stable/c/1e4332581cd4eed75aea77af6f66cdcdda8b49b9","https://git.kernel.org/stable/c/3e79ad156bedf2da0ab909a118d2cec6c9c22b79","https://git.kernel.org/stable/c/4a74da044ec9ec8679e6beccc4306b936b62873f","https://git.kernel.org/stable/c/4efb69a0e294ef201bcdf7ce3d6202cd0a545a5d","https://git.kernel.org/stable/c/bbad2d5b6c99db468d8f88b6ba6a56ed409b4881","https://git.kernel.org/stable/c/c3ce634ad953ce48c75c39bdfd8b711dd95f346f","https://git.kernel.org/stable/c/e0a317ad68e4ea48a0158187238c5407e4fdec8b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38540
|
Medium |
fixed |
- 6.1.117
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq
Undefined behavior is triggered when bnxt_qplib_alloc_init_hwq is called
with hwq_attr->aux_depth != 0 and hwq_attr->aux_stride == 0.
In that case, "roundup_pow_of_two(hwq_attr->aux_stride)" gets called.
roundup_pow_of_two is documented as undefined for 0.
Fix it in the one caller that had this combination.
The undefined behavior was detected by UBSAN:
UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13
shift exponent 64 is too large for 64-bit type 'long unsigned int'
CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4
Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 10/25/2023
Call Trace:
<TASK>
dump_stack_lvl+0x5d/0x80
ubsan_epilogue+0x5/0x30
__ubsan_handle_shift_out_of_bounds.cold+0x61/0xec
__roundup_pow_of_two+0x25/0x35 [bnxt_re]
bnxt_qplib_alloc_init_hwq+0xa1/0x470 [bnxt_re]
bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re]
bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re]
? srso_alias_return_thunk+0x5/0xfbef5
? srso_alias_return_thunk+0x5/0xfbef5
? __kmalloc+0x1b6/0x4f0
? create_qp.part.0+0x128/0x1c0 [ib_core]
? __pfx_bnxt_re_create_qp+0x10/0x10 [bnxt_re]
create_qp.part.0+0x128/0x1c0 [ib_core]
ib_create_qp_kernel+0x50/0xd0 [ib_core]
create_mad_qp+0x8e/0xe0 [ib_core]
? __pfx_qp_event_handler+0x10/0x10 [ib_core]
ib_mad_init_device+0x2be/0x680 [ib_core]
add_client_context+0x10d/0x1a0 [ib_core]
enable_device_and_get+0xe0/0x1d0 [ib_core]
ib_register_device+0x53c/0x630 [ib_core]
? srso_alias_return_thunk+0x5/0xfbef5
bnxt_re_probe+0xbd8/0xe50 [bnxt_re]
? __pfx_bnxt_re_probe+0x10/0x10 [bnxt_re]
auxiliary_bus_probe+0x49/0x80
? driver_sysfs_add+0x57/0xc0
really_probe+0xde/0x340
? pm_runtime_barrier+0x54/0x90
? __pfx___driver_attach+0x10/0x10
__driver_probe_device+0x78/0x110
driver_probe_device+0x1f/0xa0
__driver_attach+0xba/0x1c0
bus_for_each_dev+0x8f/0xe0
bus_add_driver+0x146/0x220
driver_register+0x72/0xd0
__auxiliary_driver_register+0x6e/0xd0
? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]
bnxt_re_mod_init+0x3e/0xff0 [bnxt_re]
? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]
do_one_initcall+0x5b/0x310
do_init_module+0x90/0x250
init_module_from_file+0x86/0xc0
idempotent_init_module+0x121/0x2b0
__x64_sys_finit_module+0x5e/0xb0
do_syscall_64+0x82/0x160
? srso_alias_return_thunk+0x5/0xfbef5
? syscall_exit_to_user_mode_prepare+0x149/0x170
? srso_alias_return_thunk+0x5/0xfbef5
? syscall_exit_to_user_mode+0x75/0x230
? srso_alias_return_thunk+0x5/0xfbef5
? do_syscall_64+0x8e/0x160
? srso_alias_return_thunk+0x5/0xfbef5
? __count_memcg_events+0x69/0x100
? srso_alias_return_thunk+0x5/0xfbef5
? count_memcg_events.constprop.0+0x1a/0x30
? srso_alias_return_thunk+0x5/0xfbef5
? handle_mm_fault+0x1f0/0x300
? srso_alias_return_thunk+0x5/0xfbef5
? do_user_addr_fault+0x34e/0x640
? srso_alias_return_thunk+0x5/0xfbef5
? srso_alias_return_thunk+0x5/0xfbef5
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7f4e5132821d
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48
RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d
RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b
RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 R09: 00007ffca9c906f0
R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d
R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0000563ec8a8fa60
</TASK>
---[ end trace ]--- |
["https://git.kernel.org/stable/c/627493443f3a8458cb55cdae1da254a7001123bc","https://git.kernel.org/stable/c/66a9937187ac9b5c5ffff07b8b284483e56804d1","https://git.kernel.org/stable/c/78cfd17142ef70599d6409cbd709d94b3da58659","https://git.kernel.org/stable/c/84d2f29152184f0d72ed7c9648c4ee6927df4e59","https://git.kernel.org/stable/c/8b799c00cea6fcfe5b501bbaeb228c8821acb753","https://git.kernel.org/stable/c/a658f011d89dd20cf2c7cb4760ffd79201700b98","https://git.kernel.org/stable/c/627493443f3a8458cb55cdae1da254a7001123bc","https://git.kernel.org/stable/c/78cfd17142ef70599d6409cbd709d94b3da58659","https://git.kernel.org/stable/c/8b799c00cea6fcfe5b501bbaeb228c8821acb753","https://git.kernel.org/stable/c/a658f011d89dd20cf2c7cb4760ffd79201700b98"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46859
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: panasonic-laptop: Fix SINF array out of bounds accesses
The panasonic laptop code in various places uses the SINF array with index
values of 0 - SINF_CUR_BRIGHT(0x0d) without checking that the SINF array
is big enough.
Not all panasonic laptops have this many SINF array entries, for example
the Toughbook CF-18 model only has 10 SINF array entries. So it only
supports the AC+DC brightness entries and mute.
Check that the SINF array has a minimum size which covers all AC+DC
brightness entries and refuse to load if the SINF array is smaller.
For higher SINF indexes hide the sysfs attributes when the SINF array
does not contain an entry for that attribute, avoiding show()/store()
accessing the array out of bounds and add bounds checking to the probe()
and resume() code accessing these. |
["https://git.kernel.org/stable/c/6821a82616f60aa72c5909b3e252ad97fb9f7e2a","https://git.kernel.org/stable/c/9291fadbd2720a869b1d2fcf82305648e2e62a16","https://git.kernel.org/stable/c/b38c19783286a71693c2194ed1b36665168c09c4","https://git.kernel.org/stable/c/b7c2f692307fe704be87ea80d7328782b33c3cef","https://git.kernel.org/stable/c/f52e98d16e9bd7dd2b3aef8e38db5cbc9899d6a4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44949
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
parisc: fix a possible DMA corruption
ARCH_DMA_MINALIGN was defined as 16 - this is too small - it may be
possible that two unrelated 16-byte allocations share a cache line. If
one of these allocations is written using DMA and the other is written
using cached write, the value that was written with DMA may be
corrupted.
This commit changes ARCH_DMA_MINALIGN to be 128 on PA20 and 32 on PA1.1 -
that's the largest possible cache line size.
As different parisc microarchitectures have different cache line size, we
define arch_slab_minalign(), cache_line_size() and
dma_get_cache_alignment() so that the kernel may tune slab cache
parameters dynamically, based on the detected cache line size. |
["https://git.kernel.org/stable/c/00baca74fb5879e5f9034b6156671301f500f8ee","https://git.kernel.org/stable/c/533de2f470baac40d3bf622fe631f15231a03c9f","https://git.kernel.org/stable/c/642a0b7453daff0295310774016fcb56d1f5bc7f","https://git.kernel.org/stable/c/7ae04ba36b381bffe2471eff3a93edced843240f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52760
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix slab-use-after-free in gfs2_qd_dealloc
In gfs2_put_super(), whether withdrawn or not, the quota should
be cleaned up by gfs2_quota_cleanup().
Otherwise, struct gfs2_sbd will be freed before gfs2_qd_dealloc (rcu
callback) has run for all gfs2_quota_data objects, resulting in
use-after-free.
Also, gfs2_destroy_threads() and gfs2_quota_cleanup() is already called
by gfs2_make_fs_ro(), so in gfs2_put_super(), after calling
gfs2_make_fs_ro(), there is no need to call them again. |
["https://git.kernel.org/stable/c/08a28272faa750d4357ea2cb48d2baefd778ea81","https://git.kernel.org/stable/c/7ad4e0a4f61c57c3ca291ee010a9d677d0199fba","https://git.kernel.org/stable/c/bdcb8aa434c6d36b5c215d02a9ef07551be25a37","https://git.kernel.org/stable/c/08a28272faa750d4357ea2cb48d2baefd778ea81","https://git.kernel.org/stable/c/7ad4e0a4f61c57c3ca291ee010a9d677d0199fba","https://git.kernel.org/stable/c/bdcb8aa434c6d36b5c215d02a9ef07551be25a37"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41070
|
High |
fixed |
- 5.4.281
- 5.10.223
- 5.15.164
- 6.1.101
- 6.6.42
- 6.9.11
|
In the Linux kernel, the following vulnerability has been resolved:
KVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group()
Al reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group().
It looks up `stt` from tablefd, but then continues to use it after doing
fdput() on the returned fd. After the fdput() the tablefd is free to be
closed by another thread. The close calls kvm_spapr_tce_release() and
then release_spapr_tce_table() (via call_rcu()) which frees `stt`.
Although there are calls to rcu_read_lock() in
kvm_spapr_tce_attach_iommu_group() they are not sufficient to prevent
the UAF, because `stt` is used outside the locked regions.
With an artifcial delay after the fdput() and a userspace program which
triggers the race, KASAN detects the UAF:
BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]
Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505
CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1
Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV
Call Trace:
dump_stack_lvl+0xb4/0x108 (unreliable)
print_report+0x2b4/0x6ec
kasan_report+0x118/0x2b0
__asan_load4+0xb8/0xd0
kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]
kvm_vfio_set_attr+0x524/0xac0 [kvm]
kvm_device_ioctl+0x144/0x240 [kvm]
sys_ioctl+0x62c/0x1810
system_call_exception+0x190/0x440
system_call_vectored_common+0x15c/0x2ec
...
Freed by task 0:
...
kfree+0xec/0x3e0
release_spapr_tce_table+0xd4/0x11c [kvm]
rcu_core+0x568/0x16a0
handle_softirqs+0x23c/0x920
do_softirq_own_stack+0x6c/0x90
do_softirq_own_stack+0x58/0x90
__irq_exit_rcu+0x218/0x2d0
irq_exit+0x30/0x80
arch_local_irq_restore+0x128/0x230
arch_local_irq_enable+0x1c/0x30
cpuidle_enter_state+0x134/0x5cc
cpuidle_enter+0x6c/0xb0
call_cpuidle+0x7c/0x100
do_idle+0x394/0x410
cpu_startup_entry+0x60/0x70
start_secondary+0x3fc/0x410
start_secondary_prolog+0x10/0x14
Fix it by delaying the fdput() until `stt` is no longer in use, which
is effectively the entire function. To keep the patch minimal add a call
to fdput() at each of the existing return paths. Future work can convert
the function to goto or __cleanup style cleanup.
With the fix in place the test case no longer triggers the UAF. |
["https://git.kernel.org/stable/c/4cdf6926f443c84f680213c7aafbe6f91a5fcbc0","https://git.kernel.org/stable/c/5f856023971f97fff74cfaf21b48ec320147b50a","https://git.kernel.org/stable/c/82c7a4cf14aa866f8f7f09e662b02eddc49ee0bf","https://git.kernel.org/stable/c/9975f93c760a32453d7639cf6fcf3f73b4e71ffe","https://git.kernel.org/stable/c/a986fa57fd81a1430e00b3c6cf8a325d6f894a63","https://git.kernel.org/stable/c/b26c8c85463ef27a522d24fcd05651f0bb039e47","https://git.kernel.org/stable/c/be847bb20c809de8ac124431b556f244400b0491","https://git.kernel.org/stable/c/4cdf6926f443c84f680213c7aafbe6f91a5fcbc0","https://git.kernel.org/stable/c/5f856023971f97fff74cfaf21b48ec320147b50a","https://git.kernel.org/stable/c/82c7a4cf14aa866f8f7f09e662b02eddc49ee0bf","https://git.kernel.org/stable/c/9975f93c760a32453d7639cf6fcf3f73b4e71ffe","https://git.kernel.org/stable/c/a986fa57fd81a1430e00b3c6cf8a325d6f894a63","https://git.kernel.org/stable/c/b26c8c85463ef27a522d24fcd05651f0bb039e47","https://git.kernel.org/stable/c/be847bb20c809de8ac124431b556f244400b0491"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42104
|
High |
fixed |
- 4.19.318
- 5.4.280
- 5.10.222
- 5.15.163
- 6.1.98
- 6.6.39
- 6.9.9
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: add missing check for inode numbers on directory entries
Syzbot reported that mounting and unmounting a specific pattern of
corrupted nilfs2 filesystem images causes a use-after-free of metadata
file inodes, which triggers a kernel bug in lru_add_fn().
As Jan Kara pointed out, this is because the link count of a metadata file
gets corrupted to 0, and nilfs_evict_inode(), which is called from iput(),
tries to delete that inode (ifile inode in this case).
The inconsistency occurs because directories containing the inode numbers
of these metadata files that should not be visible in the namespace are
read without checking.
Fix this issue by treating the inode numbers of these internal files as
errors in the sanity check helper when reading directory folios/pages.
Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer
analysis. |
["https://git.kernel.org/stable/c/07c176e7acc5579c133bb923ab21316d192d0a95","https://git.kernel.org/stable/c/1b7d549ed2c1fa202c751b69423a0d3a6bd5a180","https://git.kernel.org/stable/c/265fff1a01cdc083aeaf0d934c929db5cc64aebf","https://git.kernel.org/stable/c/2f2fa9cf7c3537958a82fbe8c8595a5eb0861ad7","https://git.kernel.org/stable/c/3ab40870edb883b9633dc5cd55f5a2a11afa618d","https://git.kernel.org/stable/c/b11e8fb93ea5eefb2e4e719497ea177a58ff6131","https://git.kernel.org/stable/c/bb76c6c274683c8570ad788f79d4b875bde0e458","https://git.kernel.org/stable/c/c33c2b0d92aa1c2262d999b2598ad6fbd53bd479","https://git.kernel.org/stable/c/07c176e7acc5579c133bb923ab21316d192d0a95","https://git.kernel.org/stable/c/1b7d549ed2c1fa202c751b69423a0d3a6bd5a180","https://git.kernel.org/stable/c/265fff1a01cdc083aeaf0d934c929db5cc64aebf","https://git.kernel.org/stable/c/2f2fa9cf7c3537958a82fbe8c8595a5eb0861ad7","https://git.kernel.org/stable/c/3ab40870edb883b9633dc5cd55f5a2a11afa618d","https://git.kernel.org/stable/c/b11e8fb93ea5eefb2e4e719497ea177a58ff6131","https://git.kernel.org/stable/c/bb76c6c274683c8570ad788f79d4b875bde0e458","https://git.kernel.org/stable/c/c33c2b0d92aa1c2262d999b2598ad6fbd53bd479"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52691
|
High |
fixed |
- 4.19.306
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: fix a double-free in si_dpm_init
When the allocation of
adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails,
amdgpu_free_extended_power_table is called to free some fields of adev.
However, when the control flow returns to si_dpm_sw_init, it goes to
label dpm_failed and calls si_dpm_fini, which calls
amdgpu_free_extended_power_table again and free those fields again. Thus
a double-free is triggered. |
["https://git.kernel.org/stable/c/06d95c99d5a4f5accdb79464076efe62e668c706","https://git.kernel.org/stable/c/2bf47c89bbaca2bae16581ef1b28aaec0ade0334","https://git.kernel.org/stable/c/ac16667237a82e2597e329eb9bc520d1cf9dff30","https://git.kernel.org/stable/c/aeed2b4e4a70c7568d4a5eecd6a109713c0dfbf4","https://git.kernel.org/stable/c/afe9f5b871f86d58ecdc45b217b662227d7890d0","https://git.kernel.org/stable/c/ca8e2e251c65e5a712f6025e27bd9b26d16e6f4a","https://git.kernel.org/stable/c/f957a1be647f7fc65926cbf572992ec2747a93f2","https://git.kernel.org/stable/c/fb1936cb587262cd539e84b34541abb06e42b2f9","https://git.kernel.org/stable/c/06d95c99d5a4f5accdb79464076efe62e668c706","https://git.kernel.org/stable/c/2bf47c89bbaca2bae16581ef1b28aaec0ade0334","https://git.kernel.org/stable/c/ac16667237a82e2597e329eb9bc520d1cf9dff30","https://git.kernel.org/stable/c/aeed2b4e4a70c7568d4a5eecd6a109713c0dfbf4","https://git.kernel.org/stable/c/afe9f5b871f86d58ecdc45b217b662227d7890d0","https://git.kernel.org/stable/c/ca8e2e251c65e5a712f6025e27bd9b26d16e6f4a","https://git.kernel.org/stable/c/f957a1be647f7fc65926cbf572992ec2747a93f2","https://git.kernel.org/stable/c/fb1936cb587262cd539e84b34541abb06e42b2f9","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48847
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
watch_queue: Fix filter limit check
In watch_queue_set_filter(), there are a couple of places where we check
that the filter type value does not exceed what the type_filter bitmap
can hold. One place calculates the number of bits by:
if (tf[i].type >= sizeof(wfilter->type_filter) * 8)
which is fine, but the second does:
if (tf[i].type >= sizeof(wfilter->type_filter) * BITS_PER_LONG)
which is not. This can lead to a couple of out-of-bounds writes due to
a too-large type:
(1) __set_bit() on wfilter->type_filter
(2) Writing more elements in wfilter->filters[] than we allocated.
Fix this by just using the proper WATCH_TYPE__NR instead, which is the
number of types we actually know about.
The bug may cause an oops looking something like:
BUG: KASAN: slab-out-of-bounds in watch_queue_set_filter+0x659/0x740
Write of size 4 at addr ffff88800d2c66bc by task watch_queue_oob/611
...
Call Trace:
<TASK>
dump_stack_lvl+0x45/0x59
print_address_description.constprop.0+0x1f/0x150
...
kasan_report.cold+0x7f/0x11b
...
watch_queue_set_filter+0x659/0x740
...
__x64_sys_ioctl+0x127/0x190
do_syscall_64+0x43/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
Allocated by task 611:
kasan_save_stack+0x1e/0x40
__kasan_kmalloc+0x81/0xa0
watch_queue_set_filter+0x23a/0x740
__x64_sys_ioctl+0x127/0x190
do_syscall_64+0x43/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
The buggy address belongs to the object at ffff88800d2c66a0
which belongs to the cache kmalloc-32 of size 32
The buggy address is located 28 bytes inside of
32-byte region [ffff88800d2c66a0, ffff88800d2c66c0) |
["https://git.kernel.org/stable/c/1b09f28f70a5046acd64138075ae3f095238b045","https://git.kernel.org/stable/c/648895da69ced90ca770fd941c3d9479a9d72c16","https://git.kernel.org/stable/c/b36588ebbcef74583824c08352e75838d6fb4ff2","https://git.kernel.org/stable/c/c993ee0f9f81caf5767a50d1faeba39a0dc82af2","https://git.kernel.org/stable/c/1b09f28f70a5046acd64138075ae3f095238b045","https://git.kernel.org/stable/c/648895da69ced90ca770fd941c3d9479a9d72c16","https://git.kernel.org/stable/c/b36588ebbcef74583824c08352e75838d6fb4ff2","https://git.kernel.org/stable/c/c993ee0f9f81caf5767a50d1faeba39a0dc82af2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48960
|
High |
fixed |
- 4.9.336
- 4.14.302
- 4.19.269
- 5.4.227
- 5.10.159
- 5.15.83
- 6.0.13
|
In the Linux kernel, the following vulnerability has been resolved:
net: hisilicon: Fix potential use-after-free in hix5hd2_rx()
The skb is delivered to napi_gro_receive() which may free it, after
calling this, dereferencing skb may trigger use-after-free. |
["https://git.kernel.org/stable/c/179499e7a240b2ef590f05eb379c810c26bbc8a4","https://git.kernel.org/stable/c/1b6360a093ab8969c91a30bb58b753282e2ced4c","https://git.kernel.org/stable/c/3a4eddd1cb023a71df4152fcc76092953e6fe95a","https://git.kernel.org/stable/c/433c07a13f59856e4585e89e86b7d4cc59348fab","https://git.kernel.org/stable/c/8067cd244cea2c332f8326842fd10158fa2cb64f","https://git.kernel.org/stable/c/93aaa4bb72e388f6a4887541fd3d18b84f1b5ddc","https://git.kernel.org/stable/c/b6307f7a2fc1c5407b6176f2af34a95214a8c262","https://git.kernel.org/stable/c/b8ce0e6f9f88a6bb49d291498377e61ea27a5387"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48962
|
High |
fixed |
- 4.9.336
- 4.14.302
- 4.19.269
- 5.4.227
- 5.10.159
- 5.15.83
- 6.0.13
|
In the Linux kernel, the following vulnerability has been resolved:
net: hisilicon: Fix potential use-after-free in hisi_femac_rx()
The skb is delivered to napi_gro_receive() which may free it, after
calling this, dereferencing skb may trigger use-after-free. |
["https://git.kernel.org/stable/c/196e12671cb629d9f3b77b4d8bec854fc445533a","https://git.kernel.org/stable/c/296a50aa8b2982117520713edc1375777a9f8506","https://git.kernel.org/stable/c/3501da8eb6d0f5f114a09ec953c54423f6f35885","https://git.kernel.org/stable/c/4640177049549de1a43e9bc49265f0cdfce08cfd","https://git.kernel.org/stable/c/6f4798ac9c9e98f41553c4f5e6c832c8860a6942","https://git.kernel.org/stable/c/8595a2db8eb0ffcbb466eb9f4a7507a5ba06ebb9","https://git.kernel.org/stable/c/aceec8ab752428d8e151321479e82cc1a40fee2e","https://git.kernel.org/stable/c/e71a46cc8c9ad75f3bb0e4b361e81f79c0214cca"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47695
|
High |
fixed |
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds
In the function init_conns(), after the create_con() and create_cm() for
loop if something fails. In the cleanup for loop after the destroy tag, we
access out of bound memory because cid is set to clt_path->s.con_num.
This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds
in the cleanup loop later. |
["https://git.kernel.org/stable/c/01b9be936ee8839ab9f83a7e84ee02ac6c8303c4","https://git.kernel.org/stable/c/0429a4e972082e3a2351da414b1c017daaf8aed2","https://git.kernel.org/stable/c/1c50e0265fa332c94a4a182e4efa0fc70d8fad94","https://git.kernel.org/stable/c/3e4289b29e216a55d08a89e126bc0b37cbad9f38","https://git.kernel.org/stable/c/5ac73f8191f3de41fef4f934d84d97f3aadb301f","https://git.kernel.org/stable/c/c8b7f3d9fada0d4b4b7db86bf7345cd61f1d972e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47718
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw88: always wait for both firmware loading attempts
In 'rtw_wait_firmware_completion()', always wait for both (regular and
wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()'
has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue
'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually
the wowlan one) is still in progress, causing UAF detected by KASAN. |
["https://git.kernel.org/stable/c/0e735a4c6137262bcefe45bb52fde7b1f5fc6c4d","https://git.kernel.org/stable/c/1b8178a2ae272256ea0dc4f940320a81003535e2","https://git.kernel.org/stable/c/7887ad11995a4142671cc49146db536f923c8568","https://git.kernel.org/stable/c/9432185540bafd42b7bfac6e6ef2f0a0fb4be447","https://git.kernel.org/stable/c/a0c1e2da652cf70825739bc12d49ea15805690bf","https://git.kernel.org/stable/c/ceaab3fb64d6a5426a3db8f87f3e5757964f2532","https://git.kernel.org/stable/c/e9a78d9417e167410d6fb83c4e908b077ad8ba6d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47730
|
High |
fixed |
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
crypto: hisilicon/qm - inject error before stopping queue
The master ooo cannot be completely closed when the
accelerator core reports memory error. Therefore, the driver
needs to inject the qm error to close the master ooo. Currently,
the qm error is injected after stopping queue, memory may be
released immediately after stopping queue, causing the device to
access the released memory. Therefore, error is injected to close master
ooo before stopping queue to ensure that the device does not access
the released memory. |
["https://git.kernel.org/stable/c/801d64177faaec184cee1e1aa4d8487df1364a54","https://git.kernel.org/stable/c/85e81103033324d7a271dafb584991da39554a89","https://git.kernel.org/stable/c/98d3be34c9153eceadb56de50d9f9347e88d86e4","https://git.kernel.org/stable/c/aa3e0db35a60002fb34ef0e4ad203aa59fd00203","https://git.kernel.org/stable/c/b04f06fc0243600665b3b50253869533b7938468","https://git.kernel.org/stable/c/c5f5b813e546f7fe133539c3d7a5086cc8dd2aa1","https://git.kernel.org/stable/c/f8024f12752e32ffbbf59e1c09d949f977ff743f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47748
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
vhost_vdpa: assign irq bypass producer token correctly
We used to call irq_bypass_unregister_producer() in
vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the
token pointer is still valid or not.
Actually, we use the eventfd_ctx as the token so the life cycle of the
token should be bound to the VHOST_SET_VRING_CALL instead of
vhost_vdpa_setup_vq_irq() which could be called by set_status().
Fixing this by setting up irq bypass producer's token when handling
VHOST_SET_VRING_CALL and un-registering the producer before calling
vhost_vring_ioctl() to prevent a possible use after free as eventfd
could have been released in vhost_vring_ioctl(). And such registering
and unregistering will only be done if DRIVER_OK is set. |
["https://git.kernel.org/stable/c/02e9e9366fefe461719da5d173385b6685f70319","https://git.kernel.org/stable/c/0c170b1e918b9afac25e2bbd01eaa2bfc0ece8c0","https://git.kernel.org/stable/c/7cf2fb51175cafe01df8c43fa15a06194a59c6e2","https://git.kernel.org/stable/c/927a2580208e0f9b0b47b08f1c802b7233a7ba3c","https://git.kernel.org/stable/c/ca64edd7ae93402af2596a952e0d94d545e2b9c0","https://git.kernel.org/stable/c/ec5f1b54ceb23475049ada6e7a43452cf4df88d1","https://git.kernel.org/stable/c/fae9b1776f53aab93ab345bdbf653b991aed717d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49852
|
High |
fixed |
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del()
The kref_put() function will call nport->release if the refcount drops to
zero. The nport->release release function is _efc_nport_free() which frees
"nport". But then we dereference "nport" on the next line which is a use
after free. Re-order these lines to avoid the use after free. |
["https://git.kernel.org/stable/c/16a570f07d870a285b0c0b0d1ca4dff79e8aa5ff","https://git.kernel.org/stable/c/2e4b02fad094976763af08fec2c620f4f8edd9ae","https://git.kernel.org/stable/c/7c2908985e4ae0ea1b526b3916de9e5351650908","https://git.kernel.org/stable/c/98752fcd076a8cbc978016eae7125b4971be1eec","https://git.kernel.org/stable/c/abc71e89170ed32ecf0a5a29f31aa711e143e941","https://git.kernel.org/stable/c/baeb8628ab7f4577740f00e439d3fdf7c876b0ff"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49854
|
High |
fixed |
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
block, bfq: fix uaf for accessing waker_bfqq after splitting
After commit 42c306ed7233 ("block, bfq: don't break merge chain in
bfq_split_bfqq()"), if the current procress is the last holder of bfqq,
the bfqq can be freed after bfq_split_bfqq(). Hence recored the bfqq and
then access bfqq->waker_bfqq may trigger UAF. What's more, the waker_bfqq
may in the merge chain of bfqq, hence just recored waker_bfqq is still
not safe.
Fix the problem by adding a helper bfq_waker_bfqq() to check if
bfqq->waker_bfqq is in the merge chain, and current procress is the only
holder. |
["https://git.kernel.org/stable/c/0780451f03bf518bc032a7c584de8f92e2d39d7f","https://git.kernel.org/stable/c/0b8bda0ff17156cd3f60944527c9d8c9f99f1583","https://git.kernel.org/stable/c/1ba0403ac6447f2d63914fb760c44a3b19c44eaf","https://git.kernel.org/stable/c/63a07379fdb6c72450cb05294461c6016b8b7726","https://git.kernel.org/stable/c/cae58d19121a70329cf971359e2518c93fec04fe","https://git.kernel.org/stable/c/de0456460f2abf921e356ed2bd8da87a376680bd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49983
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free
When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(),
the 'ppath' is updated but it is the 'path' that is freed, thus potentially
triggering a double-free in the following process:
ext4_ext_replay_update_ex
ppath = path
ext4_force_split_extent_at(&ppath)
ext4_split_extent_at
ext4_ext_insert_extent
ext4_ext_create_new_leaf
ext4_ext_grow_indepth
ext4_find_extent
if (depth > path[0].p_maxdepth)
kfree(path) ---> path First freed
*orig_path = path = NULL ---> null ppath
kfree(path) ---> path double-free !!!
So drop the unnecessary ppath and use path directly to avoid this problem.
And use ext4_find_extent() directly to update path, avoiding unnecessary
memory allocation and freeing. Also, propagate the error returned by
ext4_find_extent() instead of using strange error codes. |
["https://git.kernel.org/stable/c/1b558006d98b7b0b730027be0ee98973dd10ee0d","https://git.kernel.org/stable/c/3ff710662e8d86a63a39b334e9ca0cb10e5c14b0","https://git.kernel.org/stable/c/5c0f4cc84d3a601c99bc5e6e6eb1cbda542cce95","https://git.kernel.org/stable/c/6367d3f04c69e2b8770b8137bd800e0784b0abbc","https://git.kernel.org/stable/c/63adc9016917e6970fb0104ee5fd6770f02b2d80","https://git.kernel.org/stable/c/8c26d9e53e5fbacda0732a577e97c5a5b7882aaf","https://git.kernel.org/stable/c/a34bed978364114390162c27e50fca50791c568d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50074
|
High |
fixed |
- 5.10.228
- 5.15.169
- 6.1.114
- 6.6.58
- 6.11.5
|
In the Linux kernel, the following vulnerability has been resolved:
parport: Proper fix for array out-of-bounds access
The recent fix for array out-of-bounds accesses replaced sprintf()
calls blindly with snprintf(). However, since snprintf() returns the
would-be-printed size, not the actually output size, the length
calculation can still go over the given limit.
Use scnprintf() instead of snprintf(), which returns the actually
output letters, for addressing the potential out-of-bounds access
properly. |
["https://git.kernel.org/stable/c/02ac3a9ef3a18b58d8f3ea2b6e46de657bf6c4f9","https://git.kernel.org/stable/c/1826b6d69bbb7f9ae8711827facbb2ad7f8d0aaa","https://git.kernel.org/stable/c/2a8b26a09c8e3ea03da1ef3cd0ef6b96e559fba6","https://git.kernel.org/stable/c/440311903231c6e6c9bcf8acb6a2885a422e00bc","https://git.kernel.org/stable/c/66029078fee00646e2e9dbb8f41ff7819f8e7569","https://git.kernel.org/stable/c/8aadef73ba3b325704ed5cfc4696a25c350182cf","https://git.kernel.org/stable/c/b0641e53e6cb937487b6cfb15772374f0ba149b3","https://git.kernel.org/stable/c/fca048f222ce9dcbde5708ba2bf81d85a4a27952"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50127
|
High |
fixed |
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
net: sched: fix use-after-free in taprio_change()
In 'taprio_change()', 'admin' pointer may become dangling due to sched
switch / removal caused by 'advance_sched()', and critical section
protected by 'q->current_entry_lock' is too small to prevent from such
a scenario (which causes use-after-free detected by KASAN). Fix this
by prefer 'rcu_replace_pointer()' over 'rcu_assign_pointer()' to update
'admin' immediately before an attempt to schedule freeing. |
["https://git.kernel.org/stable/c/0d4c0d2844e4eac3aed647f948fd7e60eea56a61","https://git.kernel.org/stable/c/2240f9376f20f8b6463232b4ca7292569217237f","https://git.kernel.org/stable/c/2f868ce6013548a713c431c679ef73747a66fcf3","https://git.kernel.org/stable/c/8a283a19026aaae8a773fd8061263cfa315b127f","https://git.kernel.org/stable/c/999612996df28d81f163dad530d7f8026e03aec6","https://git.kernel.org/stable/c/f504465970aebb2467da548f7c1efbbf36d0f44b","https://git.kernel.org/stable/c/fe371f084073e8672a2d7d46b335c3c060d1e301"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50131
|
High |
fixed |
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
tracing: Consider the NULL character when validating the event length
strlen() returns a string length excluding the null byte. If the string
length equals to the maximum buffer length, the buffer will have no
space for the NULL terminating character.
This commit checks this condition and returns failure for it. |
["https://git.kernel.org/stable/c/02874ca52df2ca2423ba6122039315ed61c25972","https://git.kernel.org/stable/c/0b6e2e22cb23105fcb171ab92f0f7516c69c8471","https://git.kernel.org/stable/c/5e3231b352725ff4a3a0095e6035af674f2d8725","https://git.kernel.org/stable/c/5fd942598ddeed9a212d1ff41f9f5b47bcc990a7","https://git.kernel.org/stable/c/a14a075a14af8d622c576145455702591bdde09d","https://git.kernel.org/stable/c/b86b0d6eea204116e4185acc35041ca4ff11a642","https://git.kernel.org/stable/c/f4ed40d1c669bba1a54407d8182acdc405683f29"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52752
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free bug in cifs_debug_data_proc_show()
Skip SMB sessions that are being teared down
(e.g. @ses->ses_status == SES_EXITING) in cifs_debug_data_proc_show()
to avoid use-after-free in @ses.
This fixes the following GPF when reading from /proc/fs/cifs/DebugData
while mounting and umounting
[ 816.251274] general protection fault, probably for non-canonical
address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI
...
[ 816.260138] Call Trace:
[ 816.260329] <TASK>
[ 816.260499] ? die_addr+0x36/0x90
[ 816.260762] ? exc_general_protection+0x1b3/0x410
[ 816.261126] ? asm_exc_general_protection+0x26/0x30
[ 816.261502] ? cifs_debug_tcon+0xbd/0x240 [cifs]
[ 816.261878] ? cifs_debug_tcon+0xab/0x240 [cifs]
[ 816.262249] cifs_debug_data_proc_show+0x516/0xdb0 [cifs]
[ 816.262689] ? seq_read_iter+0x379/0x470
[ 816.262995] seq_read_iter+0x118/0x470
[ 816.263291] proc_reg_read_iter+0x53/0x90
[ 816.263596] ? srso_alias_return_thunk+0x5/0x7f
[ 816.263945] vfs_read+0x201/0x350
[ 816.264211] ksys_read+0x75/0x100
[ 816.264472] do_syscall_64+0x3f/0x90
[ 816.264750] entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[ 816.265135] RIP: 0033:0x7fd5e669d381 |
["https://git.kernel.org/stable/c/0ab6f842452ce2cae04209d4671ac6289d0aef8a","https://git.kernel.org/stable/c/2abdf136784b7edaec7ffe0f4b461b63f9c4c4de","https://git.kernel.org/stable/c/336a066990bb3962c46daf574ace596bda9303ce","https://git.kernel.org/stable/c/558817597d5fbd7af31f891b67b0fd20f0d047b7","https://git.kernel.org/stable/c/89929ea46f9cc11ba66d2c64713aa5d5dc723b09","https://git.kernel.org/stable/c/d328c09ee9f15ee5a26431f5aad7c9239fa85e62","https://git.kernel.org/stable/c/0ab6f842452ce2cae04209d4671ac6289d0aef8a","https://git.kernel.org/stable/c/558817597d5fbd7af31f891b67b0fd20f0d047b7","https://git.kernel.org/stable/c/89929ea46f9cc11ba66d2c64713aa5d5dc723b09","https://git.kernel.org/stable/c/d328c09ee9f15ee5a26431f5aad7c9239fa85e62"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50125
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: SCO: Fix UAF on sco_sock_timeout
conn->sk maybe have been unlinked/freed while waiting for sco_conn_lock
so this checks if the conn->sk is still valid by checking if it part of
sco_sk_list. |
["https://git.kernel.org/stable/c/1bf4470a3939c678fb822073e9ea77a0560bc6bb","https://git.kernel.org/stable/c/74a466a15731a754bcd8b5a83c126b5122e15a45","https://git.kernel.org/stable/c/80b05fbfa998480fb3d5299d93eab946f51e9c36","https://git.kernel.org/stable/c/9ddda5d967e84796e7df1b54a55f36b4b9f21079","https://git.kernel.org/stable/c/d30803f6a972b5b9e26d1d43b583c7ec151de04b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42160
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: check validation of fault attrs in f2fs_build_fault_attr()
- It missed to check validation of fault attrs in parse_options(),
let's fix to add check condition in f2fs_build_fault_attr().
- Use f2fs_build_fault_attr() in __sbi_store() to clean up code. |
["https://git.kernel.org/stable/c/44958ca9e400f57bd0478115519ffc350fcee61e","https://git.kernel.org/stable/c/4ed886b187f47447ad559619c48c086f432d2b77","https://git.kernel.org/stable/c/6e5b601706ce05d94338cad598736d96bb8096c8","https://git.kernel.org/stable/c/bc84dd2c33e0c10fd90d60f0cfc0bfb504d4692d","https://git.kernel.org/stable/c/ecb641f424d6d1f055d149a15b892edcc92c504b","https://git.kernel.org/stable/c/44958ca9e400f57bd0478115519ffc350fcee61e","https://git.kernel.org/stable/c/4ed886b187f47447ad559619c48c086f432d2b77","https://git.kernel.org/stable/c/bc84dd2c33e0c10fd90d60f0cfc0bfb504d4692d","https://git.kernel.org/stable/c/ecb641f424d6d1f055d149a15b892edcc92c504b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-35828
|
High |
fixed |
- 4.19.283
- 5.4.243
- 5.10.180
- 5.15.111
- 6.1.28
- 6.2.15
- 6.3.2
|
An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in renesas_usb3_remove in drivers/usb/gadget/udc/renesas_usb3.c. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2b947f8769be8b8181dc795fd292d3e7120f5204","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lore.kernel.org/all/20230327121700.52d881e0%40canb.auug.org.au/","https://lore.kernel.org/lkml/CAJedcCwkuznS1kSTvJXhzPoavcZDWNhNMshi-Ux0spSVRwU=RA%40mail.gmail.com/T/","https://security.netapp.com/advisory/ntap-20230803-0002/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2b947f8769be8b8181dc795fd292d3e7120f5204","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lore.kernel.org/all/20230327121700.52d881e0%40canb.auug.org.au/","https://lore.kernel.org/lkml/CAJedcCwkuznS1kSTvJXhzPoavcZDWNhNMshi-Ux0spSVRwU=RA%40mail.gmail.com/T/","https://security.netapp.com/advisory/ntap-20230803-0002/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50208
|
Medium |
fixed |
- 5.10.229
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages
Avoid memory corruption while setting up Level-2 PBL pages for the non MR
resources when num_pages > 256K.
There will be a single PDE page address (contiguous pages in the case of >
PAGE_SIZE), but, current logic assumes multiple pages, leading to invalid
memory access after 256K PBL entries in the PDE. |
["https://git.kernel.org/stable/c/7988bdbbb85ac85a847baf09879edcd0f70521dc","https://git.kernel.org/stable/c/87cb3b0054e53e0155b630bdf8fb714ded62565f","https://git.kernel.org/stable/c/daac56dd98e1ba814c878ac0acd482a37f2ab94b","https://git.kernel.org/stable/c/de5857fa7bcc9a496a914c7e21390be873109f26","https://git.kernel.org/stable/c/df6fed0a2a1a5e57f033bca40dc316b18e0d0ce6","https://git.kernel.org/stable/c/ea701c1849e7250ea41a4f7493e0a5f136c1d47e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52845
|
Medium |
fixed |
- 4.14.330
- 4.19.299
- 5.4.261
- 5.10.201
- 5.15.139
- 6.1.63
- 6.5.12
- 6.6.2
|
In the Linux kernel, the following vulnerability has been resolved:
tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING
syzbot reported the following uninit-value access issue [1]:
=====================================================
BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]
BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756
strlen lib/string.c:418 [inline]
strstr+0xb8/0x2f0 lib/string.c:756
tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595
genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline]
genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline]
genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066
netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545
genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075
netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]
netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368
netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910
sock_sendmsg_nosec net/socket.c:730 [inline]
sock_sendmsg net/socket.c:753 [inline]
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
__sys_sendmsg net/socket.c:2624 [inline]
__do_sys_sendmsg net/socket.c:2633 [inline]
__se_sys_sendmsg net/socket.c:2631 [inline]
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2631
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Uninit was created at:
slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767
slab_alloc_node mm/slub.c:3478 [inline]
kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559
__alloc_skb+0x318/0x740 net/core/skbuff.c:650
alloc_skb include/linux/skbuff.h:1286 [inline]
netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline]
netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885
sock_sendmsg_nosec net/socket.c:730 [inline]
sock_sendmsg net/socket.c:753 [inline]
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
__sys_sendmsg net/socket.c:2624 [inline]
__do_sys_sendmsg net/socket.c:2633 [inline]
__se_sys_sendmsg net/socket.c:2631 [inline]
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2631
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
TIPC bearer-related names including link names must be null-terminated
strings. If a link name which is not null-terminated is passed through
netlink, strstr() and similar functions can cause buffer overrun. This
causes the above issue.
This patch changes the nla_policy for bearer-related names from NLA_STRING
to NLA_NUL_STRING. This resolves the issue by ensuring that only
null-terminated strings are accepted as bearer-related names.
syzbot reported similar uninit-value issue related to bearer names [2]. The
root cause of this issue is that a non-null-terminated bearer name was
passed. This patch also resolved this issue. |
["https://git.kernel.org/stable/c/19b3f72a41a8751e26bffc093bb7e1cef29ad579","https://git.kernel.org/stable/c/2199260c42e6fbc5af8adae3bf78e623407c91b0","https://git.kernel.org/stable/c/2426425d686b43adbc4f2f4a367b494f06f159d6","https://git.kernel.org/stable/c/3907b89cd17fcc23e9a80789c36856f00ece0ba8","https://git.kernel.org/stable/c/4c731e98fe4d678e87ba3e4d45d3cf0a5a193dc4","https://git.kernel.org/stable/c/560992f41c0cea44b7603bc9e6c73bffbf6b5709","https://git.kernel.org/stable/c/6744008c354bca2e4686a5b6056ee6b535d9f67d","https://git.kernel.org/stable/c/abc1582119e8c4af14cedb0db6541fd603f45a04","https://git.kernel.org/stable/c/b33d130f07f1decd756b849ab03c23d11d4dd294","https://git.kernel.org/stable/c/19b3f72a41a8751e26bffc093bb7e1cef29ad579","https://git.kernel.org/stable/c/2199260c42e6fbc5af8adae3bf78e623407c91b0","https://git.kernel.org/stable/c/2426425d686b43adbc4f2f4a367b494f06f159d6","https://git.kernel.org/stable/c/3907b89cd17fcc23e9a80789c36856f00ece0ba8","https://git.kernel.org/stable/c/4c731e98fe4d678e87ba3e4d45d3cf0a5a193dc4","https://git.kernel.org/stable/c/560992f41c0cea44b7603bc9e6c73bffbf6b5709","https://git.kernel.org/stable/c/6744008c354bca2e4686a5b6056ee6b535d9f67d","https://git.kernel.org/stable/c/abc1582119e8c4af14cedb0db6541fd603f45a04","https://git.kernel.org/stable/c/b33d130f07f1decd756b849ab03c23d11d4dd294"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48772
|
Medium |
fixed |
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.94
- 6.6.34
- 6.9.5
|
In the Linux kernel, the following vulnerability has been resolved:
media: lgdt3306a: Add a check against null-pointer-def
The driver should check whether the client provides the platform_data.
The following log reveals it:
[ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
[ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
[ 29.612820] Call Trace:
[ 29.613030] <TASK>
[ 29.613201] dump_stack_lvl+0x56/0x6f
[ 29.613496] ? kmemdup+0x30/0x40
[ 29.613754] print_report.cold+0x494/0x6b7
[ 29.614082] ? kmemdup+0x30/0x40
[ 29.614340] kasan_report+0x8a/0x190
[ 29.614628] ? kmemdup+0x30/0x40
[ 29.614888] kasan_check_range+0x14d/0x1d0
[ 29.615213] memcpy+0x20/0x60
[ 29.615454] kmemdup+0x30/0x40
[ 29.615700] lgdt3306a_probe+0x52/0x310
[ 29.616339] i2c_device_probe+0x951/0xa90 |
["https://git.kernel.org/stable/c/526238d32c3acc3d597fd8c9a34652bfe9086cea","https://git.kernel.org/stable/c/7d12e918f2994c883f41f22552a61b9310fa1e87","https://git.kernel.org/stable/c/8915dcd29a82096acacf54364a8425363782aea0","https://git.kernel.org/stable/c/8e1e00718d0d9dd83337300572561e30b9c0d115","https://git.kernel.org/stable/c/b479fd59a1f4a342b69fce34f222d93bf791dca4","https://git.kernel.org/stable/c/c1115ddbda9c930fba0fdd062e7a8873ebaf898d","https://git.kernel.org/stable/c/d082757b8359201c3864323cea4b91ea30a1e676","https://git.kernel.org/stable/c/526238d32c3acc3d597fd8c9a34652bfe9086cea","https://git.kernel.org/stable/c/7d12e918f2994c883f41f22552a61b9310fa1e87","https://git.kernel.org/stable/c/8915dcd29a82096acacf54364a8425363782aea0","https://git.kernel.org/stable/c/8e1e00718d0d9dd83337300572561e30b9c0d115","https://git.kernel.org/stable/c/b479fd59a1f4a342b69fce34f222d93bf791dca4","https://git.kernel.org/stable/c/c1115ddbda9c930fba0fdd062e7a8873ebaf898d","https://git.kernel.org/stable/c/d082757b8359201c3864323cea4b91ea30a1e676"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39292
|
Medium |
fixed |
- 2.6.23
- 4.19.316
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.9.4
|
In the Linux kernel, the following vulnerability has been resolved:
um: Add winch to winch_handlers before registering winch IRQ
Registering a winch IRQ is racy, an interrupt may occur before the winch is
added to the winch_handlers list.
If that happens, register_winch_irq() adds to that list a winch that is
scheduled to be (or has already been) freed, causing a panic later in
winch_cleanup().
Avoid the race by adding the winch to the winch_handlers list before
registering the IRQ, and rolling back if um_request_irq() fails. |
["https://git.kernel.org/stable/c/0c02d425a2fbe52643a5859a779db0329e7dddd4","https://git.kernel.org/stable/c/31960d991e43c8d6dc07245f19fc13398e90ead2","https://git.kernel.org/stable/c/351d1a64544944b44732f6a64ed65573b00b9e14","https://git.kernel.org/stable/c/434a06c38ee1217a8baa0dd7c37cc85d50138fb0","https://git.kernel.org/stable/c/66ea9a7c6824821476914bed21a476cd20094f33","https://git.kernel.org/stable/c/73b8e21f76c7dda4905655d2e2c17dc5a73b87f1","https://git.kernel.org/stable/c/a0fbbd36c156b9f7b2276871d499c9943dfe5101","https://git.kernel.org/stable/c/dc1ff95602ee908fcd7d8acee7a0dadb61b1a0c0","https://git.kernel.org/stable/c/0c02d425a2fbe52643a5859a779db0329e7dddd4","https://git.kernel.org/stable/c/31960d991e43c8d6dc07245f19fc13398e90ead2","https://git.kernel.org/stable/c/351d1a64544944b44732f6a64ed65573b00b9e14","https://git.kernel.org/stable/c/434a06c38ee1217a8baa0dd7c37cc85d50138fb0","https://git.kernel.org/stable/c/66ea9a7c6824821476914bed21a476cd20094f33","https://git.kernel.org/stable/c/73b8e21f76c7dda4905655d2e2c17dc5a73b87f1","https://git.kernel.org/stable/c/a0fbbd36c156b9f7b2276871d499c9943dfe5101","https://git.kernel.org/stable/c/dc1ff95602ee908fcd7d8acee7a0dadb61b1a0c0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41064
|
Medium |
fixed |
- 5.4.281
- 5.10.223
- 5.15.164
- 6.1.101
- 6.6.42
- 6.9.11
|
In the Linux kernel, the following vulnerability has been resolved:
powerpc/eeh: avoid possible crash when edev->pdev changes
If a PCI device is removed during eeh_pe_report_edev(), edev->pdev
will change and can cause a crash, hold the PCI rescan/remove lock
while taking a copy of edev->pdev->bus. |
["https://git.kernel.org/stable/c/033c51dfdbb6b79ab43fb3587276fa82d0a329e1","https://git.kernel.org/stable/c/428d940a8b6b3350b282c14d3f63350bde65c48b","https://git.kernel.org/stable/c/4bc246d2d60d071314842fa448faa4ed39082aff","https://git.kernel.org/stable/c/4fad7fef847b6028475dd7b4c14fcb82b3e51274","https://git.kernel.org/stable/c/8836e1bf5838ac6c08760e0a2dd7cf6410aa7ff3","https://git.kernel.org/stable/c/a1216e62d039bf63a539bbe718536ec789a853dd","https://git.kernel.org/stable/c/f23c3d1ca9c4b2d626242a4e7e1ec1770447f7b5","https://git.kernel.org/stable/c/033c51dfdbb6b79ab43fb3587276fa82d0a329e1","https://git.kernel.org/stable/c/428d940a8b6b3350b282c14d3f63350bde65c48b","https://git.kernel.org/stable/c/4bc246d2d60d071314842fa448faa4ed39082aff","https://git.kernel.org/stable/c/4fad7fef847b6028475dd7b4c14fcb82b3e51274","https://git.kernel.org/stable/c/8836e1bf5838ac6c08760e0a2dd7cf6410aa7ff3","https://git.kernel.org/stable/c/a1216e62d039bf63a539bbe718536ec789a853dd","https://git.kernel.org/stable/c/f23c3d1ca9c4b2d626242a4e7e1ec1770447f7b5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42145
|
Medium |
fixed |
- 4.19.318
- 5.4.280
- 5.10.222
- 5.15.163
- 6.1.98
- 6.6.39
- 6.9.9
|
In the Linux kernel, the following vulnerability has been resolved:
IB/core: Implement a limit on UMAD receive List
The existing behavior of ib_umad, which maintains received MAD
packets in an unbounded list, poses a risk of uncontrolled growth.
As user-space applications extract packets from this list, the rate
of extraction may not match the rate of incoming packets, leading
to potential list overflow.
To address this, we introduce a limit to the size of the list. After
considering typical scenarios, such as OpenSM processing, which can
handle approximately 100k packets per second, and the 1-second retry
timeout for most packets, we set the list size limit to 200k. Packets
received beyond this limit are dropped, assuming they are likely timed
out by the time they are handled by user-space.
Notably, packets queued on the receive list due to reasons like
timed-out sends are preserved even when the list is full. |
["https://git.kernel.org/stable/c/1288cf1cceb0e6df276e182f5412370fb4169bcb","https://git.kernel.org/stable/c/62349fbf86b5e13b02721bdadf98c29afd1e7b5f","https://git.kernel.org/stable/c/63d202d948bb6d3a28cd8e8b96b160fa53e18baa","https://git.kernel.org/stable/c/a6627fba793cc75b7365d9504a0095fb2902dda4","https://git.kernel.org/stable/c/b4913702419d064ec4c4bbf7270643c95cc89a1b","https://git.kernel.org/stable/c/b8c5f635997f49c625178d1a0cb32a80ed33abe6","https://git.kernel.org/stable/c/ca0b44e20a6f3032224599f02e7c8fb49525c894","https://git.kernel.org/stable/c/d73cb8862e4d6760ccc94d3b57b9ef6271400607","https://git.kernel.org/stable/c/1288cf1cceb0e6df276e182f5412370fb4169bcb","https://git.kernel.org/stable/c/62349fbf86b5e13b02721bdadf98c29afd1e7b5f","https://git.kernel.org/stable/c/63d202d948bb6d3a28cd8e8b96b160fa53e18baa","https://git.kernel.org/stable/c/a6627fba793cc75b7365d9504a0095fb2902dda4","https://git.kernel.org/stable/c/b4913702419d064ec4c4bbf7270643c95cc89a1b","https://git.kernel.org/stable/c/b8c5f635997f49c625178d1a0cb32a80ed33abe6","https://git.kernel.org/stable/c/ca0b44e20a6f3032224599f02e7c8fb49525c894","https://git.kernel.org/stable/c/d73cb8862e4d6760ccc94d3b57b9ef6271400607"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42223
|
Medium |
fixed |
- 4.19.318
- 5.4.280
- 5.10.222
- 5.15.163
- 6.1.98
- 6.6.39
- 6.9.9
|
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-frontends: tda10048: Fix integer overflow
state->xtal_hz can be up to 16M, so it can overflow a 32 bit integer
when multiplied by pll_mfactor.
Create a new 64 bit variable to hold the calculations. |
["https://git.kernel.org/stable/c/1121d8a5c6ed6b8fad492e43b63b386cb6a3a9d8","https://git.kernel.org/stable/c/1663e2474e4d777187d749a5c90ae83232db32bd","https://git.kernel.org/stable/c/1aa1329a67cc214c3b7bd2a14d1301a795760b07","https://git.kernel.org/stable/c/5c72587d024f087aecec0221eaff2fe850d856ce","https://git.kernel.org/stable/c/8167e4d7dc086d4f7ca7897dcff3827e4d22c99a","https://git.kernel.org/stable/c/8ac224e9371dc3c4eb666033e6b42d05cf5184a1","https://git.kernel.org/stable/c/bd5620439959a7e02012588c724c6ff5143b80af","https://git.kernel.org/stable/c/e1ba22618758e95e09c9fd30c69ccce38edf94c0","https://git.kernel.org/stable/c/1121d8a5c6ed6b8fad492e43b63b386cb6a3a9d8","https://git.kernel.org/stable/c/1663e2474e4d777187d749a5c90ae83232db32bd","https://git.kernel.org/stable/c/1aa1329a67cc214c3b7bd2a14d1301a795760b07","https://git.kernel.org/stable/c/5c72587d024f087aecec0221eaff2fe850d856ce","https://git.kernel.org/stable/c/8167e4d7dc086d4f7ca7897dcff3827e4d22c99a","https://git.kernel.org/stable/c/8ac224e9371dc3c4eb666033e6b42d05cf5184a1","https://git.kernel.org/stable/c/bd5620439959a7e02012588c724c6ff5143b80af","https://git.kernel.org/stable/c/e1ba22618758e95e09c9fd30c69ccce38edf94c0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46737
|
Medium |
fixed |
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
nvmet-tcp: fix kernel crash if commands allocation fails
If the commands allocation fails in nvmet_tcp_alloc_cmds()
the kernel crashes in nvmet_tcp_release_queue_work() because of
a NULL pointer dereference.
nvmet: failed to install queue 0 cntlid 1 ret 6
Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000008
Fix the bug by setting queue->nr_cmds to zero in case
nvmet_tcp_alloc_cmd() fails. |
["https://git.kernel.org/stable/c/03e1fd0327fa5e2174567f5fe9290fe21d21b8f4","https://git.kernel.org/stable/c/489f2913a63f528cfe3f21722583fb981967ecda","https://git.kernel.org/stable/c/50632b877ce55356f5d276b9add289b1e7ddc683","https://git.kernel.org/stable/c/5572a55a6f830ee3f3a994b6b962a5c327d28cb3","https://git.kernel.org/stable/c/6c04d1e3ab22cc5394ef656429638a5947f87244","https://git.kernel.org/stable/c/7957c731fc2b23312f8935812dee5a0b14b04e2d","https://git.kernel.org/stable/c/91dad30c5607e62864f888e735d0965567827bdf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52698
|
Medium |
fixed |
- 4.19.306
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
calipso: fix memory leak in netlbl_calipso_add_pass()
If IPv6 support is disabled at boot (ipv6.disable=1),
the calipso_init() -> netlbl_calipso_ops_register() function isn't called,
and the netlbl_calipso_ops_get() function always returns NULL.
In this case, the netlbl_calipso_add_pass() function allocates memory
for the doi_def variable but doesn't free it with the calipso_doi_free().
BUG: memory leak
unreferenced object 0xffff888011d68180 (size 64):
comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s)
hex dump (first 32 bytes):
00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<...>] kmalloc include/linux/slab.h:552 [inline]
[<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline]
[<...>] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111
[<...>] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739
[<...>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]
[<...>] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800
[<...>] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515
[<...>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811
[<...>] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]
[<...>] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339
[<...>] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934
[<...>] sock_sendmsg_nosec net/socket.c:651 [inline]
[<...>] sock_sendmsg+0x157/0x190 net/socket.c:671
[<...>] ____sys_sendmsg+0x712/0x870 net/socket.c:2342
[<...>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396
[<...>] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429
[<...>] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46
[<...>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
Found by InfoTeCS on behalf of Linux Verification Center
(linuxtesting.org) with Syzkaller
[PM: merged via the LSM tree at Jakub Kicinski request] |
["https://git.kernel.org/stable/c/321b3a5592c8a9d6b654c7c64833ea67dbb33149","https://git.kernel.org/stable/c/36e19f84634aaa94f543fedc0a07588949638d53","https://git.kernel.org/stable/c/408bbd1e1746fe33e51f4c81c2febd7d3841d031","https://git.kernel.org/stable/c/44a88650ba55e6a7f2ec485d2c2413ba7e216f01","https://git.kernel.org/stable/c/9a8f811a146aa2a0230f8edb2e9f4b6609aab8da","https://git.kernel.org/stable/c/a4529a08d3704c17ea9c7277d180e46b99250ded","https://git.kernel.org/stable/c/ec4e9d630a64df500641892f4e259e8149594a99","https://git.kernel.org/stable/c/f14d36e6e97fe935a20e0ceb159c100f90b6627c","https://git.kernel.org/stable/c/321b3a5592c8a9d6b654c7c64833ea67dbb33149","https://git.kernel.org/stable/c/36e19f84634aaa94f543fedc0a07588949638d53","https://git.kernel.org/stable/c/408bbd1e1746fe33e51f4c81c2febd7d3841d031","https://git.kernel.org/stable/c/44a88650ba55e6a7f2ec485d2c2413ba7e216f01","https://git.kernel.org/stable/c/9a8f811a146aa2a0230f8edb2e9f4b6609aab8da","https://git.kernel.org/stable/c/a4529a08d3704c17ea9c7277d180e46b99250ded","https://git.kernel.org/stable/c/ec4e9d630a64df500641892f4e259e8149594a99","https://git.kernel.org/stable/c/f14d36e6e97fe935a20e0ceb159c100f90b6627c","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52855
|
Medium |
fixed |
- 4.14.330
- 4.19.299
- 5.4.261
- 5.10.201
- 5.15.139
- 6.1.63
- 6.5.12
- 6.6.2
|
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency
In _dwc2_hcd_urb_enqueue(), "urb->hcpriv = NULL" is executed without
holding the lock "hsotg->lock". In _dwc2_hcd_urb_dequeue():
spin_lock_irqsave(&hsotg->lock, flags);
...
if (!urb->hcpriv) {
dev_dbg(hsotg->dev, "## urb->hcpriv is NULL ##\n");
goto out;
}
rc = dwc2_hcd_urb_dequeue(hsotg, urb->hcpriv); // Use urb->hcpriv
...
out:
spin_unlock_irqrestore(&hsotg->lock, flags);
When _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are
concurrently executed, the NULL check of "urb->hcpriv" can be executed
before "urb->hcpriv = NULL". After urb->hcpriv is NULL, it can be used
in the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL
pointer dereference.
This possible bug is found by an experimental static analysis tool
developed by myself. This tool analyzes the locking APIs to extract
function pairs that can be concurrently executed, and then analyzes the
instructions in the paired functions to identify possible concurrency
bugs including data races and atomicity violations. The above possible
bug is reported, when my tool analyzes the source code of Linux 6.5.
To fix this possible bug, "urb->hcpriv = NULL" should be executed with
holding the lock "hsotg->lock". After using this patch, my tool never
reports the possible bug, with the kernelconfiguration allyesconfig for
x86_64. Because I have no associated hardware, I cannot test the patch
in runtime testing, and just verify it according to the code logic. |
["https://git.kernel.org/stable/c/14c9ec34e8118fbffd7f5431814d767726323e72","https://git.kernel.org/stable/c/3e851a77a13ce944d703721793f49ee82622986d","https://git.kernel.org/stable/c/64c47749fc7507ed732e155c958253968c1d275e","https://git.kernel.org/stable/c/6b21a22728852d020a6658d39cd7bb7e14b07790","https://git.kernel.org/stable/c/a7bee9598afb38004841a41dd8fe68c1faff4e90","https://git.kernel.org/stable/c/bdb3dd4096302d6b87441fdc528439f171b04be6","https://git.kernel.org/stable/c/ef307bc6ef04e8c1ea843231db58e3afaafa9fa6","https://git.kernel.org/stable/c/fcaafb574fc88a52dce817f039f7ff2f9da38001","https://git.kernel.org/stable/c/fed492aa6493a91a77ebd51da6fb939c98d94a0d","https://git.kernel.org/stable/c/14c9ec34e8118fbffd7f5431814d767726323e72","https://git.kernel.org/stable/c/3e851a77a13ce944d703721793f49ee82622986d","https://git.kernel.org/stable/c/64c47749fc7507ed732e155c958253968c1d275e","https://git.kernel.org/stable/c/6b21a22728852d020a6658d39cd7bb7e14b07790","https://git.kernel.org/stable/c/a7bee9598afb38004841a41dd8fe68c1faff4e90","https://git.kernel.org/stable/c/bdb3dd4096302d6b87441fdc528439f171b04be6","https://git.kernel.org/stable/c/ef307bc6ef04e8c1ea843231db58e3afaafa9fa6","https://git.kernel.org/stable/c/fcaafb574fc88a52dce817f039f7ff2f9da38001","https://git.kernel.org/stable/c/fed492aa6493a91a77ebd51da6fb939c98d94a0d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46807
|
Medium |
fixed |
- 5.15.167
- 6.1.109
- 6.6.50
- 6.10.9
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/amdgpu: Check tbo resource pointer
Validate tbo resource pointer, skip if NULL |
["https://git.kernel.org/stable/c/2be1eb6304d9623ba21dd6f3e68ffb753a759635","https://git.kernel.org/stable/c/4dfec5f5501a27e0a0da00e136d65ef9011ded4c","https://git.kernel.org/stable/c/6cd2b872643bb29bba01a8ac739138db7bd79007","https://git.kernel.org/stable/c/e55e3904ffeaff81715256a711b1a61f4ad5258a","https://git.kernel.org/stable/c/e8765364d4f3aaf88c7abe0a4fc99089d059ab49"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46810
|
Medium |
fixed |
- 5.15.167
- 6.1.109
- 6.6.50
- 6.10.9
|
In the Linux kernel, the following vulnerability has been resolved:
drm/bridge: tc358767: Check if fully initialized before signalling HPD event via IRQ
Make sure the connector is fully initialized before signalling any
HPD events via drm_kms_helper_hotplug_event(), otherwise this may
lead to NULL pointer dereference. |
["https://git.kernel.org/stable/c/162e48cb1d84c2c966b649b8ac5c9d4f75f6d44f","https://git.kernel.org/stable/c/1fb13693953737783b424aa4712f0a27a9eaf5a8","https://git.kernel.org/stable/c/9d567126474e68f959b2c2543c375f3bb32e948a","https://git.kernel.org/stable/c/adc5674c23b8191e596ed0dbaa9600265ac896a8","https://git.kernel.org/stable/c/e1b121f21bbc56a6ae035aa5b77daac62bfb9be5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48997
|
Medium |
fixed |
- 5.4.226
- 5.10.158
- 5.15.82
- 6.0.12
|
In the Linux kernel, the following vulnerability has been resolved:
char: tpm: Protect tpm_pm_suspend with locks
Currently tpm transactions are executed unconditionally in
tpm_pm_suspend() function, which may lead to races with other tpm
accessors in the system.
Specifically, the hw_random tpm driver makes use of tpm_get_random(),
and this function is called in a loop from a kthread, which means it's
not frozen alongside userspace, and so can race with the work done
during system suspend:
tpm tpm0: tpm_transmit: tpm_recv: error -52
tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics
CPU: 0 PID: 1 Comm: init Not tainted 6.1.0-rc5+ #135
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014
Call Trace:
tpm_tis_status.cold+0x19/0x20
tpm_transmit+0x13b/0x390
tpm_transmit_cmd+0x20/0x80
tpm1_pm_suspend+0xa6/0x110
tpm_pm_suspend+0x53/0x80
__pnp_bus_suspend+0x35/0xe0
__device_suspend+0x10f/0x350
Fix this by calling tpm_try_get_ops(), which itself is a wrapper around
tpm_chip_start(), but takes the appropriate mutex.
[Jason: reworked commit message, added metadata] |
["https://git.kernel.org/stable/c/23393c6461422df5bf8084a086ada9a7e17dc2ba","https://git.kernel.org/stable/c/25b78bf98b07ff5aceb9b1e24f72ec0236c5c053","https://git.kernel.org/stable/c/4e0d6c687c925e27fd4bc78a2721d10acf5614d6","https://git.kernel.org/stable/c/571b6bbbf54d835ea6120f65575cb55cd767e603","https://git.kernel.org/stable/c/d699373ac5f3545243d3c73a1ccab77fdef8cec6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-26607
|
High |
fixed |
- 4.9.334
- 4.14.300
- 4.19.267
- 5.4.225
- 5.10.156
- 5.15.80
- 6.0.10
|
In the Linux kernel 6.0.8, there is an out-of-bounds read in ntfs_attr_find in fs/ntfs/attrib.c. |
["https://bugzilla.suse.com/show_bug.cgi?id=1208703","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=36a4d82dddbbd421d2b8e79e1cab68c8126d5075","https://lkml.org/lkml/2023/2/21/1353","https://security.netapp.com/advisory/ntap-20230316-0010/","https://bugzilla.suse.com/show_bug.cgi?id=1208703","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=36a4d82dddbbd421d2b8e79e1cab68c8126d5075","https://lkml.org/lkml/2023/2/21/1353","https://security.netapp.com/advisory/ntap-20230316-0010/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57906
|
High |
fixed |
- 4.20
- 5.5
- 5.11
- 5.13
- 6.1.125
- 6.6.72
- 6.12.10
|
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: ti-ads8688: fix information leak in triggered buffer
The 'buffer' local array is used to push data to user space from a
triggered buffer, but it does not set values for inactive channels, as
it only uses iio_for_each_active_channel() to assign new values.
Initialize the array to zero before using it to avoid pushing
uninitialized information to userspace. |
["https://git.kernel.org/stable/c/1c80a0985a9a14f33dbf63cd703ca010f094f878","https://git.kernel.org/stable/c/2a7377ccfd940cd6e9201756aff1e7852c266e69","https://git.kernel.org/stable/c/3bf8d1e87939b8a19c9b738564fddf5b73322f2f","https://git.kernel.org/stable/c/455df95eb8f24a37abc549d6738fc8ee07eb623b","https://git.kernel.org/stable/c/485570ed82b7a6bb109fa1d0a79998e21f7f4c73","https://git.kernel.org/stable/c/aae96738006840533cf147ffd5f41830987f21c5","https://git.kernel.org/stable/c/ebe2672bc42a0dfe31bb539f8ce79d024aa7e46d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57907
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: rockchip_saradc: fix information leak in triggered buffer
The 'data' local struct is used to push data to user space from a
triggered buffer, but it does not set values for inactive channels, as
it only uses iio_for_each_active_channel() to assign new values.
Initialize the struct to zero before using it to avoid pushing
uninitialized information to userspace. |
["https://git.kernel.org/stable/c/38724591364e1e3b278b4053f102b49ea06ee17c","https://git.kernel.org/stable/c/5a95fbbecec7a34bbad5dcc3156700b8711d53c4","https://git.kernel.org/stable/c/64b79afdca7b27a768c7d3716b7f4deb1d6b955c","https://git.kernel.org/stable/c/7a07fb80ea886e9134284a27d0155cca7649e293","https://git.kernel.org/stable/c/8193941bc4fe7247ff13233f328aea709f574554","https://git.kernel.org/stable/c/85a9c98a5e0f22d911b00077d751e34fff1401aa"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57908
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
iio: imu: kmx61: fix information leak in triggered buffer
The 'buffer' local array is used to push data to user space from a
triggered buffer, but it does not set values for inactive channels, as
it only uses iio_for_each_active_channel() to assign new values.
Initialize the array to zero before using it to avoid pushing
uninitialized information to userspace. |
["https://git.kernel.org/stable/c/0871eb8d700b33dd7fa86c80630d62ddaef58c2c","https://git.kernel.org/stable/c/565814cbbaa674d2901428796801de49a611e59d","https://git.kernel.org/stable/c/6985ba4467e4b15b809043fa7740d1fb23a1897b","https://git.kernel.org/stable/c/6ae053113f6a226a2303caa4936a4c37f3bfff7b","https://git.kernel.org/stable/c/a07f698084412a3ef5e950fcac1d6b0f53289efd","https://git.kernel.org/stable/c/a386d9d2dc6635f2ec210b8199cfb3acf4d31305","https://git.kernel.org/stable/c/cde312e257b59ecaa0fad3af9ec7e2370bb24639"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57910
|
High |
fixed |
- 5.4.290
- 5.10.234
- 5.13
- 5.15.177
- 6.1.125
- 6.6.72
- 6.12.10
|
In the Linux kernel, the following vulnerability has been resolved:
iio: light: vcnl4035: fix information leak in triggered buffer
The 'buffer' local array is used to push data to userspace from a
triggered buffer, but it does not set an initial value for the single
data element, which is an u16 aligned to 8 bytes. That leaves at least
4 bytes uninitialized even after writing an integer value with
regmap_read().
Initialize the array to zero before using it to avoid pushing
uninitialized information to userspace. |
["https://git.kernel.org/stable/c/13e56229fc81051a42731046e200493c4a7c28ff","https://git.kernel.org/stable/c/47b43e53c0a0edf5578d5d12f5fc71c019649279","https://git.kernel.org/stable/c/47d245be86492974db3aeb048609542167f56518","https://git.kernel.org/stable/c/a15ea87d4337479c9446b5d71616f4668337afed","https://git.kernel.org/stable/c/b0e9c11c762e4286732d80e66c08c2cb3157b06b","https://git.kernel.org/stable/c/cb488706cdec0d6d13f2895bcdf0c32b283a7cc7","https://git.kernel.org/stable/c/f6fb1c59776b4263634c472a5be8204c906ffc2c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57911
|
High |
fixed |
- 5.4.290
- 5.10.234
- 5.15.177
- 6.1.125
- 6.6.72
- 6.12.10
|
In the Linux kernel, the following vulnerability has been resolved:
iio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer
The 'data' array is allocated via kmalloc() and it is used to push data
to user space from a triggered buffer, but it does not set values for
inactive channels, as it only uses iio_for_each_active_channel()
to assign new values.
Use kzalloc for the memory allocation to avoid pushing uninitialized
information to userspace. |
["https://git.kernel.org/stable/c/006073761888a632c5d6f93e47c41760fa627f77","https://git.kernel.org/stable/c/03fa47621bf8fcbf5994c5716021527853f9af3d","https://git.kernel.org/stable/c/333be433ee908a53f283beb95585dfc14c8ffb46","https://git.kernel.org/stable/c/74058395b2c63c8a438cf199d09094b640f8c7f4","https://git.kernel.org/stable/c/b0642d9c871aea1f28eb02cd84d60434df594f67","https://git.kernel.org/stable/c/e1c1e8c05010103c9c9ea3e9c4304b0b7e2c8e4a","https://git.kernel.org/stable/c/ea703cda36da0dacb9a2fd876370003197d8a019"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57912
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
iio: pressure: zpa2326: fix information leak in triggered buffer
The 'sample' local struct is used to push data to user space from a
triggered buffer, but it has a hole between the temperature and the
timestamp (u32 pressure, u16 temperature, GAP, u64 timestamp).
This hole is never initialized.
Initialize the struct to zero before using it to avoid pushing
uninitialized information to userspace. |
["https://git.kernel.org/stable/c/6007d10c5262f6f71479627c1216899ea7f09073","https://git.kernel.org/stable/c/64a989aa7475b8e76e69b9ec86819ea293e53bab","https://git.kernel.org/stable/c/9629ff1a86823269b12fb1ba9ca4efa945906287","https://git.kernel.org/stable/c/979a0db76ceda8fe1f2f85a116bfe97620ebbadf","https://git.kernel.org/stable/c/b7849f62e61242e0e02c776e1109eb81e59c567c","https://git.kernel.org/stable/c/d25f1fc273670271412a52a1efbdaf5dcf274ed8","https://git.kernel.org/stable/c/fefb88a4da961a0b9c2473cbdcfce1a942fcfa9a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42094
|
High |
fixed |
- 4.19.317
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.97
- 6.6.37
- 6.9.8
|
In the Linux kernel, the following vulnerability has been resolved:
net/iucv: Avoid explicit cpumask var allocation on stack
For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
variable on stack is not recommended since it can cause potential stack
overflow.
Instead, kernel code should always use *cpumask_var API(s) to allocate
cpumask var in config-neutral way, leaving allocation strategy to
CONFIG_CPUMASK_OFFSTACK.
Use *cpumask_var API(s) to address it. |
["https://git.kernel.org/stable/c/0af718a690acc089aa1bbb95a93df833d864ef53","https://git.kernel.org/stable/c/2b085521be5292016097b5e7ca81b26be3f7098d","https://git.kernel.org/stable/c/2d090c7f7be3b26fcb80ac04d08a4a8062b1d959","https://git.kernel.org/stable/c/724e7965af054079242b8d6f7e50ee226730a756","https://git.kernel.org/stable/c/842afb47d84536fc976fece8fb6c54bea711ad1a","https://git.kernel.org/stable/c/9dadab0db7d904413ea1cdaa13f127da05c31e71","https://git.kernel.org/stable/c/be4e1304419c99a164b4c0e101c7c2a756b635b9","https://git.kernel.org/stable/c/d85ca8179a54ff8cf1e1f8c3c9e3799831319bae","https://git.kernel.org/stable/c/0af718a690acc089aa1bbb95a93df833d864ef53","https://git.kernel.org/stable/c/2b085521be5292016097b5e7ca81b26be3f7098d","https://git.kernel.org/stable/c/2d090c7f7be3b26fcb80ac04d08a4a8062b1d959","https://git.kernel.org/stable/c/724e7965af054079242b8d6f7e50ee226730a756","https://git.kernel.org/stable/c/842afb47d84536fc976fece8fb6c54bea711ad1a","https://git.kernel.org/stable/c/9dadab0db7d904413ea1cdaa13f127da05c31e71","https://git.kernel.org/stable/c/be4e1304419c99a164b4c0e101c7c2a756b635b9","https://git.kernel.org/stable/c/d85ca8179a54ff8cf1e1f8c3c9e3799831319bae"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38597
|
Medium |
fixed |
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
eth: sungem: remove .ndo_poll_controller to avoid deadlocks
Erhard reports netpoll warnings from sungem:
netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398)
WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c
gem_poll_controller() disables interrupts, which may sleep.
We can't sleep in netpoll, it has interrupts disabled completely.
Strangely, gem_poll_controller() doesn't even poll the completions,
and instead acts as if an interrupt has fired so it just schedules
NAPI and exits. None of this has been necessary for years, since
netpoll invokes NAPI directly. |
["https://git.kernel.org/stable/c/476adb3bbbd7886e8251d3b9ce2d3c3e680f35d6","https://git.kernel.org/stable/c/5de5aeb98f9a000adb0db184e32765e4815d860b","https://git.kernel.org/stable/c/6400d205fbbcbcf9b8510157e1f379c1d7e2e937","https://git.kernel.org/stable/c/ac0a230f719b02432d8c7eba7615ebd691da86f4","https://git.kernel.org/stable/c/e22b23f5888a065d084e87db1eec639c445e677f","https://git.kernel.org/stable/c/faf94f1eb8a34b2c31b2042051ef36f63420ecce","https://git.kernel.org/stable/c/fbeeb55dbb33d562149c57e794f06b7414e44289","https://git.kernel.org/stable/c/476adb3bbbd7886e8251d3b9ce2d3c3e680f35d6","https://git.kernel.org/stable/c/5de5aeb98f9a000adb0db184e32765e4815d860b","https://git.kernel.org/stable/c/6400d205fbbcbcf9b8510157e1f379c1d7e2e937","https://git.kernel.org/stable/c/ac0a230f719b02432d8c7eba7615ebd691da86f4","https://git.kernel.org/stable/c/e22b23f5888a065d084e87db1eec639c445e677f","https://git.kernel.org/stable/c/faf94f1eb8a34b2c31b2042051ef36f63420ecce","https://git.kernel.org/stable/c/fbeeb55dbb33d562149c57e794f06b7414e44289"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39476
|
Medium |
fixed |
- 4.19.316
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.94
- 6.6.34
- 6.9.5
|
In the Linux kernel, the following vulnerability has been resolved:
md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with
small possibility, the root cause is exactly the same as commit
bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")
However, Dan reported another hang after that, and junxiao investigated
the problem and found out that this is caused by plugged bio can't issue
from raid5d().
Current implementation in raid5d() has a weird dependence:
1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
MD_SB_CHANGE_PENDING;
2) raid5d() handles IO in a deadloop, until all IO are issued;
3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;
This behaviour is introduce before v2.6, and for consequence, if other
context hold 'reconfig_mutex', and md_check_recovery() can't update
super_block, then raid5d() will waste one cpu 100% by the deadloop, until
'reconfig_mutex' is released.
Refer to the implementation from raid1 and raid10, fix this problem by
skipping issue IO if MD_SB_CHANGE_PENDING is still set after
md_check_recovery(), daemon thread will be woken up when 'reconfig_mutex'
is released. Meanwhile, the hang problem will be fixed as well. |
["https://git.kernel.org/stable/c/098d54934814dd876963abfe751c3b1cf7fbe56a","https://git.kernel.org/stable/c/151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa","https://git.kernel.org/stable/c/3f8d5e802d4cedd445f9a89be8c3fd2d0e99024b","https://git.kernel.org/stable/c/634ba3c97ec413cb10681c7b196db43ee461ecf4","https://git.kernel.org/stable/c/aa64464c8f4d2ab92f6d0b959a1e0767b829d787","https://git.kernel.org/stable/c/b32aa95843cac6b12c2c014d40fca18aef24a347","https://git.kernel.org/stable/c/cd2538e5af495b3c747e503db346470fc1ffc447","https://git.kernel.org/stable/c/e332a12f65d8fed8cf63bedb4e9317bb872b9ac7","https://git.kernel.org/stable/c/098d54934814dd876963abfe751c3b1cf7fbe56a","https://git.kernel.org/stable/c/151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa","https://git.kernel.org/stable/c/3f8d5e802d4cedd445f9a89be8c3fd2d0e99024b","https://git.kernel.org/stable/c/634ba3c97ec413cb10681c7b196db43ee461ecf4","https://git.kernel.org/stable/c/aa64464c8f4d2ab92f6d0b959a1e0767b829d787","https://git.kernel.org/stable/c/b32aa95843cac6b12c2c014d40fca18aef24a347","https://git.kernel.org/stable/c/cd2538e5af495b3c747e503db346470fc1ffc447","https://git.kernel.org/stable/c/e332a12f65d8fed8cf63bedb4e9317bb872b9ac7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41098
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ata: libata-core: Fix null pointer dereference on error
If the ata_port_alloc() call in ata_host_alloc() fails,
ata_host_release() will get called.
However, the code in ata_host_release() tries to free ata_port struct
members unconditionally, which can lead to the following:
BUG: unable to handle page fault for address: 0000000000003990
PGD 0 P4D 0
Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:ata_host_release.cold+0x2f/0x6e [libata]
Code: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41
RSP: 0018:ffffc90000ebb968 EFLAGS: 00010246
RAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0
RBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68
R10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004
R13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006
FS: 00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
<TASK>
? __die_body.cold+0x19/0x27
? page_fault_oops+0x15a/0x2f0
? exc_page_fault+0x7e/0x180
? asm_exc_page_fault+0x26/0x30
? ata_host_release.cold+0x2f/0x6e [libata]
? ata_host_release.cold+0x2f/0x6e [libata]
release_nodes+0x35/0xb0
devres_release_group+0x113/0x140
ata_host_alloc+0xed/0x120 [libata]
ata_host_alloc_pinfo+0x14/0xa0 [libata]
ahci_init_one+0x6c9/0xd20 [ahci]
Do not access ata_port struct members unconditionally. |
["https://git.kernel.org/stable/c/0f0d37c154bb108730c90a91aa31e3170e827962","https://git.kernel.org/stable/c/119c97ace2a9ffcf4dc09a23bb057d6c281aff28","https://git.kernel.org/stable/c/221e3b1297e74fdec32d0f572f4dcb2260a0a2af","https://git.kernel.org/stable/c/56e62977eaaae3eb7122ee2cf9b720b6703114a9","https://git.kernel.org/stable/c/5d92c7c566dc76d96e0e19e481d926bbe6631c1e","https://git.kernel.org/stable/c/8a8ff7e3b736a70d7b7c8764cbcd2724d4079ec8","https://git.kernel.org/stable/c/d9c4df80b1b009de1eb77c07e3bb4d45bd212aa5","https://git.kernel.org/stable/c/e83405e75d90694ee6a5d898f7f0473ac2686054","https://git.kernel.org/stable/c/119c97ace2a9ffcf4dc09a23bb057d6c281aff28","https://git.kernel.org/stable/c/5d92c7c566dc76d96e0e19e481d926bbe6631c1e","https://git.kernel.org/stable/c/8a8ff7e3b736a70d7b7c8764cbcd2724d4079ec8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46676
|
Medium |
fixed |
- 5.4.283
- 5.10.225
- 5.15.166
- 6.1.108
- 6.6.49
- 6.10.8
|
In the Linux kernel, the following vulnerability has been resolved:
nfc: pn533: Add poll mod list filling check
In case of im_protocols value is 1 and tm_protocols value is 0 this
combination successfully passes the check
'if (!im_protocols && !tm_protocols)' in the nfc_start_poll().
But then after pn533_poll_create_mod_list() call in pn533_start_poll()
poll mod list will remain empty and dev->poll_mod_count will remain 0
which lead to division by zero.
Normally no im protocol has value 1 in the mask, so this combination is
not expected by driver. But these protocol values actually come from
userspace via Netlink interface (NFC_CMD_START_POLL operation). So a
broken or malicious program may pass a message containing a "bad"
combination of protocol parameter values so that dev->poll_mod_count
is not incremented inside pn533_poll_create_mod_list(), thus leading
to division by zero.
Call trace looks like:
nfc_genl_start_poll()
nfc_start_poll()
->start_poll()
pn533_start_poll()
Add poll mod list filling check.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/56ad559cf6d87f250a8d203b555dfc3716afa946","https://git.kernel.org/stable/c/64513d0e546a1f19e390f7e5eba3872bfcbdacf5","https://git.kernel.org/stable/c/7535db0624a2dede374c42040808ad9a9101d723","https://git.kernel.org/stable/c/7ecd3dd4f8eecd3309432156ccfe24768e009ec4","https://git.kernel.org/stable/c/8ddaea033de051ed61b39f6b69ad54a411172b33","https://git.kernel.org/stable/c/c5e05237444f32f6cfe5d907603a232c77a08b31","https://git.kernel.org/stable/c/febccb39255f9df35527b88c953b2e0deae50e53"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47665
|
Medium |
fixed |
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
i3c: mipi-i3c-hci: Error out instead on BUG_ON() in IBI DMA setup
Definitely condition dma_get_cache_alignment * defined value > 256
during driver initialization is not reason to BUG_ON(). Turn that to
graceful error out with -EINVAL. |
["https://git.kernel.org/stable/c/2666085335bdfedf90d91f4071490ad3980be785","https://git.kernel.org/stable/c/5a022269abb22809f2a174b90f200fc4b9526058","https://git.kernel.org/stable/c/8a2be2f1db268ec735419e53ef04ca039fc027dc","https://git.kernel.org/stable/c/cacb76df247a7cd842ff29755a523b1cba6c0508","https://git.kernel.org/stable/c/e2d14bfda9eb5393f8a17008afe2aa7fe0a29815"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47673
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: pause TCM when the firmware is stopped
Not doing so will make us send a host command to the transport while the
firmware is not alive, which will trigger a WARNING.
bad state = 0
WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]
RIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]
Call Trace:
<TASK>
iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm]
iwl_mvm_config_scan+0x198/0x260 [iwlmvm]
iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm]
iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm]
process_one_work+0x29e/0x640
worker_thread+0x2df/0x690
? rescuer_thread+0x540/0x540
kthread+0x192/0x1e0
? set_kthread_struct+0x90/0x90
ret_from_fork+0x22/0x30 |
["https://git.kernel.org/stable/c/0668ebc8c2282ca1e7eb96092a347baefffb5fe7","https://git.kernel.org/stable/c/2c61b561baf92a2860c76c2302a62169e22c21cc","https://git.kernel.org/stable/c/55086c97a55d781b04a2667401c75ffde190135c","https://git.kernel.org/stable/c/5948a191906b54e10f02f6b7a7670243a39f99f4","https://git.kernel.org/stable/c/a15df5f37fa3a8b7a8ec7a339d1e897bc524e28f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49905
|
Medium |
fixed |
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2)
This commit adds a null check for the 'afb' variable in the
amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was
assumed to be null, but was used later in the code without a null check.
This could potentially lead to a null pointer dereference.
Changes since v1:
- Moved the null check for 'afb' to the line where 'afb' is used. (Alex)
Fixes the below:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252) |
["https://git.kernel.org/stable/c/75839e2365b666ff4e1b9047e442cab138eac4f6","https://git.kernel.org/stable/c/9132882eaae4d21d2fc5843b3308379a481ebdf0","https://git.kernel.org/stable/c/bd0e24e5e608ccb9fdda300bb974496d6d8cf57d","https://git.kernel.org/stable/c/cd9e9e0852d501f169aa3bb34e4b413d2eb48c37","https://git.kernel.org/stable/c/e4e26cbe34d7c1c1db5fb7b3101573c29866439f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49912
|
Medium |
fixed |
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream'
This commit adds a null check for 'stream_status' in the function
'planes_changed_for_existing_stream'. Previously, the code assumed
'stream_status' could be null, but did not handle the case where it was
actually null. This could lead to a null pointer dereference.
Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774) |
["https://git.kernel.org/stable/c/0ffd9fb03bbc99ed1eb5dc989d5c7da2faac0659","https://git.kernel.org/stable/c/4778982c73d6c9f3fdbdbc6b6c8aa18df98251af","https://git.kernel.org/stable/c/8141f21b941710ecebe49220b69822cab3abd23d","https://git.kernel.org/stable/c/c4b699b93496c423b0e5b584d4eb4ab849313bcf","https://git.kernel.org/stable/c/ec6c32b58e6c4e87760e797c525e99a460c82bcb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50062
|
Medium |
fixed |
- 5.15.168
- 6.1.113
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rtrs-srv: Avoid null pointer deref during path establishment
For RTRS path establishment, RTRS client initiates and completes con_num
of connections. After establishing all its connections, the information
is exchanged between the client and server through the info_req message.
During this exchange, it is essential that all connections have been
established, and the state of the RTRS srv path is CONNECTED.
So add these sanity checks, to make sure we detect and abort process in
error scenarios to avoid null pointer deref. |
["https://git.kernel.org/stable/c/394b2f4d5e014820455af3eb5859eb328eaafcfd","https://git.kernel.org/stable/c/b5d4076664465487a9a3d226756995b12fb73d71","https://git.kernel.org/stable/c/b720792d7e8515bc695752e0ed5884e2ea34d12a","https://git.kernel.org/stable/c/ccb8e44ae3e2391235f80ffc6be59bec6b889ead","https://git.kernel.org/stable/c/d0e62bf7b575fbfe591f6f570e7595dd60a2f5eb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43900
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
media: xc2028: avoid use-after-free in load_firmware_cb()
syzkaller reported use-after-free in load_firmware_cb() [1].
The reason is because the module allocated a struct tuner in tuner_probe(),
and then the module initialization failed, the struct tuner was released.
A worker which created during module initialization accesses this struct
tuner later, it caused use-after-free.
The process is as follows:
task-6504 worker_thread
tuner_probe <= alloc dvb_frontend [2]
...
request_firmware_nowait <= create a worker
...
tuner_remove <= free dvb_frontend
...
request_firmware_work_func <= the firmware is ready
load_firmware_cb <= but now the dvb_frontend has been freed
To fix the issue, check the dvd_frontend in load_firmware_cb(), if it is
null, report a warning and just return.
[1]:
==================================================================
BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0
Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504
Call trace:
load_firmware_cb+0x1310/0x17a0
request_firmware_work_func+0x128/0x220
process_one_work+0x770/0x1824
worker_thread+0x488/0xea0
kthread+0x300/0x430
ret_from_fork+0x10/0x20
Allocated by task 6504:
kzalloc
tuner_probe+0xb0/0x1430
i2c_device_probe+0x92c/0xaf0
really_probe+0x678/0xcd0
driver_probe_device+0x280/0x370
__device_attach_driver+0x220/0x330
bus_for_each_drv+0x134/0x1c0
__device_attach+0x1f4/0x410
device_initial_probe+0x20/0x30
bus_probe_device+0x184/0x200
device_add+0x924/0x12c0
device_register+0x24/0x30
i2c_new_device+0x4e0/0xc44
v4l2_i2c_new_subdev_board+0xbc/0x290
v4l2_i2c_new_subdev+0xc8/0x104
em28xx_v4l2_init+0x1dd0/0x3770
Freed by task 6504:
kfree+0x238/0x4e4
tuner_remove+0x144/0x1c0
i2c_device_remove+0xc8/0x290
__device_release_driver+0x314/0x5fc
device_release_driver+0x30/0x44
bus_remove_device+0x244/0x490
device_del+0x350/0x900
device_unregister+0x28/0xd0
i2c_unregister_device+0x174/0x1d0
v4l2_device_unregister+0x224/0x380
em28xx_v4l2_init+0x1d90/0x3770
The buggy address belongs to the object at ffff8000d7ca2000
which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 776 bytes inside of
2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800)
The buggy address belongs to the page:
page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0
flags: 0x7ff800000000100(slab)
raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000
raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
[2]
Actually, it is allocated for struct tuner, and dvb_frontend is inside. |
["https://git.kernel.org/stable/c/208deb6d8c3cb8c3acb1f41eb31cf68ea08726d5","https://git.kernel.org/stable/c/68594cec291ff9523b9feb3f43fd853dcddd1f60","https://git.kernel.org/stable/c/850304152d367f104d21c77cfbcc05806504218b","https://git.kernel.org/stable/c/ef517bdfc01818419f7bd426969a0c86b14f3e0e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49950
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix uaf in l2cap_connect
[Syzbot reported]
BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949
Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54
CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Workqueue: hci2 hci_rx_work
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:93 [inline]
dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119
print_address_description mm/kasan/report.c:377 [inline]
print_report+0xc3/0x620 mm/kasan/report.c:488
kasan_report+0xd9/0x110 mm/kasan/report.c:601
l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949
l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline]
l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline]
l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline]
l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825
l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514
hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline]
hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028
process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231
process_scheduled_works kernel/workqueue.c:3312 [inline]
worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389
kthread+0x2c1/0x3a0 kernel/kthread.c:389
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
...
Freed by task 5245:
kasan_save_stack+0x33/0x60 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579
poison_slab_object+0xf7/0x160 mm/kasan/common.c:240
__kasan_slab_free+0x32/0x50 mm/kasan/common.c:256
kasan_slab_free include/linux/kasan.h:184 [inline]
slab_free_hook mm/slub.c:2256 [inline]
slab_free mm/slub.c:4477 [inline]
kfree+0x12a/0x3b0 mm/slub.c:4598
l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline]
kref_put include/linux/kref.h:65 [inline]
l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline]
l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802
l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241
hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline]
hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265
hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583
abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917
hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328
process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231
process_scheduled_works kernel/workqueue.c:3312 [inline]
worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389
kthread+0x2c1/0x3a0 kernel/kthread.c:389
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 |
["https://git.kernel.org/stable/c/333b4fd11e89b29c84c269123f871883a30be586","https://git.kernel.org/stable/c/686e05c9dbd68766c6bda5f31f7e077f36a7fb29","https://git.kernel.org/stable/c/78d30ce16fdf9c301bcd8b83ce613cea079cea83","https://git.kernel.org/stable/c/a1c6174e23df10b8e5770e82d63bc6e2118a3dc7","https://git.kernel.org/stable/c/b22346eec479a30bfa4a02ad2c551b54809694d0","https://git.kernel.org/stable/c/b90907696c30172b809aa3dd2f0caffae761e4c6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39494
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ima: Fix use-after-free on a dentry's dname.name
->d_name.name can change on rename and the earlier value can be freed;
there are conditions sufficient to stabilize it (->d_lock on dentry,
->d_lock on its parent, ->i_rwsem exclusive on the parent's inode,
rename_lock), but none of those are met at any of the sites. Take a stable
snapshot of the name instead. |
["https://git.kernel.org/stable/c/0b31e28fbd773aefb6164687e0767319b8199829","https://git.kernel.org/stable/c/480afcbeb7aaaa22677d3dd48ec590b441eaac1a","https://git.kernel.org/stable/c/7fb374981e31c193b1152ed8d3b0a95b671330d4","https://git.kernel.org/stable/c/a78a6f0da57d058e2009e9958fdcef66f165208c","https://git.kernel.org/stable/c/be84f32bb2c981ca670922e047cdde1488b233de","https://git.kernel.org/stable/c/dd431c3ac1fc34a9268580dd59ad3e3c76b32a8c","https://git.kernel.org/stable/c/edf287bc610b18d7a9c0c0c1cb2e97b9348c71bb","https://git.kernel.org/stable/c/7fb374981e31c193b1152ed8d3b0a95b671330d4","https://git.kernel.org/stable/c/a78a6f0da57d058e2009e9958fdcef66f165208c","https://git.kernel.org/stable/c/be84f32bb2c981ca670922e047cdde1488b233de","https://git.kernel.org/stable/c/dd431c3ac1fc34a9268580dd59ad3e3c76b32a8c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52757
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential deadlock when releasing mids
All release_mid() callers seem to hold a reference of @mid so there is
no need to call kref_put(&mid->refcount, __release_mid) under
@server->mid_lock spinlock. If they don't, then an use-after-free bug
would have occurred anyways.
By getting rid of such spinlock also fixes a potential deadlock as
shown below
CPU 0 CPU 1
------------------------------------------------------------------
cifs_demultiplex_thread() cifs_debug_data_proc_show()
release_mid()
spin_lock(&server->mid_lock);
spin_lock(&cifs_tcp_ses_lock)
spin_lock(&server->mid_lock)
__release_mid()
smb2_find_smb_tcon()
spin_lock(&cifs_tcp_ses_lock) *deadlock* |
["https://git.kernel.org/stable/c/99f476e27aad5964ab13777d84fda67d1356dec1","https://git.kernel.org/stable/c/9eb44db68c5b7f5aa22b8fc7de74a3e2e08d1f29","https://git.kernel.org/stable/c/b9bb9607b1fc12fca51f5632da25b36975f599bf","https://git.kernel.org/stable/c/c1a5962f1462b64fe7b69f20a4b6af8067bc2d26","https://git.kernel.org/stable/c/ce49569079a9d4cad26c0f1d4653382fd9a5ca7a","https://git.kernel.org/stable/c/e6322fd177c6885a21dd4609dc5e5c973d1a2eb7","https://git.kernel.org/stable/c/9eb44db68c5b7f5aa22b8fc7de74a3e2e08d1f29","https://git.kernel.org/stable/c/b9bb9607b1fc12fca51f5632da25b36975f599bf","https://git.kernel.org/stable/c/c1a5962f1462b64fe7b69f20a4b6af8067bc2d26","https://git.kernel.org/stable/c/e6322fd177c6885a21dd4609dc5e5c973d1a2eb7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48837
|
High |
fixed |
- 4.9.308
- 4.14.273
- 4.19.236
- 5.4.187
- 5.10.108
- 5.15.31
- 5.16.17
|
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: rndis: prevent integer overflow in rndis_set_response()
If "BufOffset" is very large the "BufOffset + 8" operation can have an
integer overflow. |
["https://git.kernel.org/stable/c/138d4f739b35dfb40438a0d5d7054965763bfbe7","https://git.kernel.org/stable/c/21829376268397f9fd2c35cfa9135937b6aa3a1e","https://git.kernel.org/stable/c/28bc0267399f42f987916a7174e2e32f0833cc65","https://git.kernel.org/stable/c/56b38e3ca4064041d93c1ca18828c8cedad2e16c","https://git.kernel.org/stable/c/65f3324f4b6fed78b8761c3b74615ecf0ffa81fa","https://git.kernel.org/stable/c/8b3e4d26bc9cd0f6373d0095b9ffd99e7da8006b","https://git.kernel.org/stable/c/c7953cf03a26876d676145ce5d2ae6d8c9630b90","https://git.kernel.org/stable/c/df7e088d51cdf78b1a0bf1f3d405c2593295c7b0","https://git.kernel.org/stable/c/138d4f739b35dfb40438a0d5d7054965763bfbe7","https://git.kernel.org/stable/c/21829376268397f9fd2c35cfa9135937b6aa3a1e","https://git.kernel.org/stable/c/28bc0267399f42f987916a7174e2e32f0833cc65","https://git.kernel.org/stable/c/56b38e3ca4064041d93c1ca18828c8cedad2e16c","https://git.kernel.org/stable/c/65f3324f4b6fed78b8761c3b74615ecf0ffa81fa","https://git.kernel.org/stable/c/8b3e4d26bc9cd0f6373d0095b9ffd99e7da8006b","https://git.kernel.org/stable/c/c7953cf03a26876d676145ce5d2ae6d8c9630b90","https://git.kernel.org/stable/c/df7e088d51cdf78b1a0bf1f3d405c2593295c7b0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46759
|
High |
fixed |
- 4.19.322
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (adc128d818) Fix underflows seen when writing limit attributes
DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large
negative number such as -9223372036854775808 is provided by the user.
Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations. |
["https://git.kernel.org/stable/c/019ef2d396363ecddc46e826153a842f8603799b","https://git.kernel.org/stable/c/05419d0056dcf7088687e561bb583cc06deba777","https://git.kernel.org/stable/c/2a3add62f183459a057336381ef3a896da01ce38","https://git.kernel.org/stable/c/6891b11a0c6227ca7ed15786928a07b1c0e4d4af","https://git.kernel.org/stable/c/7645d783df23878342d5d8d22030c3861d2d5426","https://git.kernel.org/stable/c/8cad724c8537fe3e0da8004646abc00290adae40","https://git.kernel.org/stable/c/b0bdb43852bf7f55ba02f0cbf00b4ea7ca897bff","https://git.kernel.org/stable/c/f7f5101af5b47a331cdbfa42ba64c507b47dd1fe"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44941
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to cover read extent cache access with lock
syzbot reports a f2fs bug as below:
BUG: KASAN: slab-use-after-free in sanity_check_extent_cache+0x370/0x410 fs/f2fs/extent_cache.c:46
Read of size 4 at addr ffff8880739ab220 by task syz-executor200/5097
CPU: 0 PID: 5097 Comm: syz-executor200 Not tainted 6.9.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x169/0x550 mm/kasan/report.c:488
kasan_report+0x143/0x180 mm/kasan/report.c:601
sanity_check_extent_cache+0x370/0x410 fs/f2fs/extent_cache.c:46
do_read_inode fs/f2fs/inode.c:509 [inline]
f2fs_iget+0x33e1/0x46e0 fs/f2fs/inode.c:560
f2fs_nfs_get_inode+0x74/0x100 fs/f2fs/super.c:3237
generic_fh_to_dentry+0x9f/0xf0 fs/libfs.c:1413
exportfs_decode_fh_raw+0x152/0x5f0 fs/exportfs/expfs.c:444
exportfs_decode_fh+0x3c/0x80 fs/exportfs/expfs.c:584
do_handle_to_path fs/fhandle.c:155 [inline]
handle_to_path fs/fhandle.c:210 [inline]
do_handle_open+0x495/0x650 fs/fhandle.c:226
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
We missed to cover sanity_check_extent_cache() w/ extent cache lock,
so, below race case may happen, result in use after free issue.
- f2fs_iget
- do_read_inode
- f2fs_init_read_extent_tree
: add largest extent entry in to cache
- shrink
- f2fs_shrink_read_extent_tree
- __shrink_extent_tree
- __detach_extent_node
: drop largest extent entry
- sanity_check_extent_cache
: access et->largest w/o lock
let's refactor sanity_check_extent_cache() to avoid extent cache access
and call it before f2fs_init_read_extent_tree() to fix this issue. |
["https://git.kernel.org/stable/c/263df78166d3a9609b97d28c34029bd01874cbb8","https://git.kernel.org/stable/c/323ef20b5558b9d9fd10c1224327af6f11a8177d","https://git.kernel.org/stable/c/d7409b05a64f212735f0d33f5f1602051a886eab"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48919
|
High |
fixed |
- 4.9.305
- 4.14.270
- 4.19.233
- 5.4.183
- 5.10.104
- 5.15.27
- 5.16.13
|
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix double free race when mount fails in cifs_get_root()
When cifs_get_root() fails during cifs_smb3_do_mount() we call
deactivate_locked_super() which eventually will call delayed_free() which
will free the context.
In this situation we should not proceed to enter the out: section in
cifs_smb3_do_mount() and free the same resources a second time.
[Thu Feb 10 12:59:06 2022] BUG: KASAN: use-after-free in rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022] Read of size 8 at addr ffff888364f4d110 by task swapper/1/0
[Thu Feb 10 12:59:06 2022] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G OE 5.17.0-rc3+ #4
[Thu Feb 10 12:59:06 2022] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 12/17/2019
[Thu Feb 10 12:59:06 2022] Call Trace:
[Thu Feb 10 12:59:06 2022] <IRQ>
[Thu Feb 10 12:59:06 2022] dump_stack_lvl+0x5d/0x78
[Thu Feb 10 12:59:06 2022] print_address_description.constprop.0+0x24/0x150
[Thu Feb 10 12:59:06 2022] ? rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022] kasan_report.cold+0x7d/0x117
[Thu Feb 10 12:59:06 2022] ? rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022] __asan_load8+0x86/0xa0
[Thu Feb 10 12:59:06 2022] rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022] rcu_core+0x547/0xca0
[Thu Feb 10 12:59:06 2022] ? call_rcu+0x3c0/0x3c0
[Thu Feb 10 12:59:06 2022] ? __this_cpu_preempt_check+0x13/0x20
[Thu Feb 10 12:59:06 2022] ? lock_is_held_type+0xea/0x140
[Thu Feb 10 12:59:06 2022] rcu_core_si+0xe/0x10
[Thu Feb 10 12:59:06 2022] __do_softirq+0x1d4/0x67b
[Thu Feb 10 12:59:06 2022] __irq_exit_rcu+0x100/0x150
[Thu Feb 10 12:59:06 2022] irq_exit_rcu+0xe/0x30
[Thu Feb 10 12:59:06 2022] sysvec_hyperv_stimer0+0x9d/0xc0
...
[Thu Feb 10 12:59:07 2022] Freed by task 58179:
[Thu Feb 10 12:59:07 2022] kasan_save_stack+0x26/0x50
[Thu Feb 10 12:59:07 2022] kasan_set_track+0x25/0x30
[Thu Feb 10 12:59:07 2022] kasan_set_free_info+0x24/0x40
[Thu Feb 10 12:59:07 2022] ____kasan_slab_free+0x137/0x170
[Thu Feb 10 12:59:07 2022] __kasan_slab_free+0x12/0x20
[Thu Feb 10 12:59:07 2022] slab_free_freelist_hook+0xb3/0x1d0
[Thu Feb 10 12:59:07 2022] kfree+0xcd/0x520
[Thu Feb 10 12:59:07 2022] cifs_smb3_do_mount+0x149/0xbe0 [cifs]
[Thu Feb 10 12:59:07 2022] smb3_get_tree+0x1a0/0x2e0 [cifs]
[Thu Feb 10 12:59:07 2022] vfs_get_tree+0x52/0x140
[Thu Feb 10 12:59:07 2022] path_mount+0x635/0x10c0
[Thu Feb 10 12:59:07 2022] __x64_sys_mount+0x1bf/0x210
[Thu Feb 10 12:59:07 2022] do_syscall_64+0x5c/0xc0
[Thu Feb 10 12:59:07 2022] entry_SYSCALL_64_after_hwframe+0x44/0xae
[Thu Feb 10 12:59:07 2022] Last potentially related work creation:
[Thu Feb 10 12:59:07 2022] kasan_save_stack+0x26/0x50
[Thu Feb 10 12:59:07 2022] __kasan_record_aux_stack+0xb6/0xc0
[Thu Feb 10 12:59:07 2022] kasan_record_aux_stack_noalloc+0xb/0x10
[Thu Feb 10 12:59:07 2022] call_rcu+0x76/0x3c0
[Thu Feb 10 12:59:07 2022] cifs_umount+0xce/0xe0 [cifs]
[Thu Feb 10 12:59:07 2022] cifs_kill_sb+0xc8/0xe0 [cifs]
[Thu Feb 10 12:59:07 2022] deactivate_locked_super+0x5d/0xd0
[Thu Feb 10 12:59:07 2022] cifs_smb3_do_mount+0xab9/0xbe0 [cifs]
[Thu Feb 10 12:59:07 2022] smb3_get_tree+0x1a0/0x2e0 [cifs]
[Thu Feb 10 12:59:07 2022] vfs_get_tree+0x52/0x140
[Thu Feb 10 12:59:07 2022] path_mount+0x635/0x10c0
[Thu Feb 10 12:59:07 2022] __x64_sys_mount+0x1bf/0x210
[Thu Feb 10 12:59:07 2022] do_syscall_64+0x5c/0xc0
[Thu Feb 10 12:59:07 2022] entry_SYSCALL_64_after_hwframe+0x44/0xae |
["https://git.kernel.org/stable/c/147a0e71ccf96df9fc8c2ac500829d8e423ef02c","https://git.kernel.org/stable/c/2fe0e281f7ad0a62259649764228227dd6b2561d","https://git.kernel.org/stable/c/3d6cc9898efdfb062efb74dc18cfc700e082f5d5","https://git.kernel.org/stable/c/546d60859ecf13380fcabcbeace53a5971493a2b","https://git.kernel.org/stable/c/563431c1f3c8f2230e4a9c445fa23758742bc4f0","https://git.kernel.org/stable/c/da834d6c1147c7519a9e55b510a03b7055104749","https://git.kernel.org/stable/c/df9db1a2af37f39ad1653c7b9b0d275d72d0bc67","https://git.kernel.org/stable/c/e208668ef7ba23efcbf76a8200cab8deee501c4d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-25258
|
Medium |
fixed |
|
An issue was discovered in drivers/usb/gadget/composite.c in the Linux kernel before 5.16.10. The USB Gadget subsystem lacks certain validation of interface OS descriptor requests (ones with a large array index and ones associated with NULL function pointer retrieval). Memory corruption might occur. |
["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.10","https://github.com/szymonh/d-os-descriptor","https://github.com/torvalds/linux/commit/75e5b4849b81e19e9efe1654b30d7f3151c33c2c","https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/TCW2KZYJ2H6BKZE3CVLHRIXYDGNYYC5P/","https://security.netapp.com/advisory/ntap-20221028-0007/","https://www.debian.org/security/2022/dsa-5092","https://www.debian.org/security/2022/dsa-5096","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.10","https://github.com/szymonh/d-os-descriptor","https://github.com/torvalds/linux/commit/75e5b4849b81e19e9efe1654b30d7f3151c33c2c","https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/TCW2KZYJ2H6BKZE3CVLHRIXYDGNYYC5P/","https://security.netapp.com/advisory/ntap-20221028-0007/","https://www.debian.org/security/2022/dsa-5092","https://www.debian.org/security/2022/dsa-5096"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46679
|
Medium |
fixed |
- 5.4.283
- 5.10.225
- 5.15.166
- 6.1.108
- 6.6.49
- 6.10.8
|
In the Linux kernel, the following vulnerability has been resolved:
ethtool: check device is present when getting link settings
A sysfs reader can race with a device reset or removal, attempting to
read device state when the device is not actually present. eg:
[exception RIP: qed_get_current_link+17]
#8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]
#9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3
#10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4
#11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300
#12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c
#13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b
#14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3
#15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1
#16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f
#17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb
crash> struct net_device.state ffff9a9d21336000
state = 5,
state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).
The device is not present, note lack of __LINK_STATE_PRESENT (0b10).
This is the same sort of panic as observed in commit 4224cfd7fb65
("net-sysfs: add check for netdevice being present to speed_show").
There are many other callers of __ethtool_get_link_ksettings() which
don't have a device presence check.
Move this check into ethtool to protect all callers. |
["https://git.kernel.org/stable/c/1d6d9b5b1b95bfeccb84386a51b7e6c510ec13b2","https://git.kernel.org/stable/c/7a8d98b6d6484d3ad358510366022da080c37cbc","https://git.kernel.org/stable/c/842a40c7273ba1c1cb30dda50405b328de1d860e","https://git.kernel.org/stable/c/94ab317024ba373d37340893d1c0358638935fbb","https://git.kernel.org/stable/c/9bba5955eed160102114d4cc00c3d399be9bdae4","https://git.kernel.org/stable/c/a699781c79ecf6cfe67fb00a0331b4088c7c8466","https://git.kernel.org/stable/c/ec7b4f7f644018ac293cb1b02528a40a32917e62"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49599
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix data-races around sysctl_tcp_l3mdev_accept.
While reading sysctl_tcp_l3mdev_accept, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its readers. |
["https://git.kernel.org/stable/c/08a75f10679470552a3a443f9aefd1399604d31d","https://git.kernel.org/stable/c/1d9c81833dec46ccb52a1d0db970fefb7c4fa071","https://git.kernel.org/stable/c/7d38d86b818104cf88961f3aebea34da89364a8e","https://git.kernel.org/stable/c/9ba9cd43b5776c27d25e5a32dde9e80bdeb1c6a1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42093
|
High |
fixed |
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.97
- 6.6.37
- 6.9.8
|
In the Linux kernel, the following vulnerability has been resolved:
net/dpaa2: Avoid explicit cpumask var allocation on stack
For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
variable on stack is not recommended since it can cause potential stack
overflow.
Instead, kernel code should always use *cpumask_var API(s) to allocate
cpumask var in config-neutral way, leaving allocation strategy to
CONFIG_CPUMASK_OFFSTACK.
Use *cpumask_var API(s) to address it. |
["https://git.kernel.org/stable/c/48147337d7efdea6ad6e49f5b8eb894b95868ef0","https://git.kernel.org/stable/c/5e4f25091e6d06e99a23f724c839a58a8776a527","https://git.kernel.org/stable/c/69f49527aea12c23b78fb3d0a421950bf44fb4e2","https://git.kernel.org/stable/c/763896ab62a672d728f5eb10ac90d98c607a8509","https://git.kernel.org/stable/c/a55afc0f5f20ba30970aaf7271929dc00eee5e7d","https://git.kernel.org/stable/c/b2262b3be27cee334a2fa175ae3afb53f38fb0b1","https://git.kernel.org/stable/c/d33fe1714a44ff540629b149d8fab4ac6967585c","https://git.kernel.org/stable/c/48147337d7efdea6ad6e49f5b8eb894b95868ef0","https://git.kernel.org/stable/c/5e4f25091e6d06e99a23f724c839a58a8776a527","https://git.kernel.org/stable/c/69f49527aea12c23b78fb3d0a421950bf44fb4e2","https://git.kernel.org/stable/c/763896ab62a672d728f5eb10ac90d98c607a8509","https://git.kernel.org/stable/c/a55afc0f5f20ba30970aaf7271929dc00eee5e7d","https://git.kernel.org/stable/c/b2262b3be27cee334a2fa175ae3afb53f38fb0b1","https://git.kernel.org/stable/c/d33fe1714a44ff540629b149d8fab4ac6967585c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36910
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
uio_hv_generic: Don't free decrypted memory
In CoCo VMs it is possible for the untrusted host to cause
set_memory_encrypted() or set_memory_decrypted() to fail such that an
error is returned and the resulting memory is shared. Callers need to
take care to handle these errors to avoid returning decrypted (shared)
memory to the page allocator, which could lead to functional or security
issues.
The VMBus device UIO driver could free decrypted/shared pages if
set_memory_decrypted() fails. Check the decrypted field in the gpadl
to decide whether to free the memory. |
["https://git.kernel.org/stable/c/3d788b2fbe6a1a1a9e3db09742b90809d51638b7","https://git.kernel.org/stable/c/6466a0f6d235c8a18c602cb587160d7e49876db9","https://git.kernel.org/stable/c/dabf12bf994318d939f70d47cfda30e47abb2c54","https://git.kernel.org/stable/c/fe2c58602354fbd60680dc42ac3a0b772cda7d23","https://git.kernel.org/stable/c/3d788b2fbe6a1a1a9e3db09742b90809d51638b7","https://git.kernel.org/stable/c/6466a0f6d235c8a18c602cb587160d7e49876db9","https://git.kernel.org/stable/c/dabf12bf994318d939f70d47cfda30e47abb2c54","https://git.kernel.org/stable/c/fe2c58602354fbd60680dc42ac3a0b772cda7d23"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52844
|
Medium |
fixed |
- 5.10.201
- 5.15.139
- 6.1.63
- 6.5.12
- 6.6.2
|
In the Linux kernel, the following vulnerability has been resolved:
media: vidtv: psi: Add check for kstrdup
Add check for the return value of kstrdup() and return the error
if it fails in order to avoid NULL pointer dereference. |
["https://git.kernel.org/stable/c/3387490c89b10aeb4e71d78b65dbc9ba4b2385b9","https://git.kernel.org/stable/c/5c26aae3723965c291c65dd2ecad6a3240d422b0","https://git.kernel.org/stable/c/5cfcc8de7d733a1137b86954cc28ce99972311ad","https://git.kernel.org/stable/c/76a2c5df6ca8bd8ada45e953b8c72b746f42918d","https://git.kernel.org/stable/c/a51335704a3f90eaf23a6864faefca34b382490a","https://git.kernel.org/stable/c/d17269fb9161995303985ab2fe6f16cfb72152f9","https://git.kernel.org/stable/c/3387490c89b10aeb4e71d78b65dbc9ba4b2385b9","https://git.kernel.org/stable/c/5c26aae3723965c291c65dd2ecad6a3240d422b0","https://git.kernel.org/stable/c/5cfcc8de7d733a1137b86954cc28ce99972311ad","https://git.kernel.org/stable/c/76a2c5df6ca8bd8ada45e953b8c72b746f42918d","https://git.kernel.org/stable/c/a51335704a3f90eaf23a6864faefca34b382490a","https://git.kernel.org/stable/c/d17269fb9161995303985ab2fe6f16cfb72152f9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52858
|
Medium |
fixed |
- 5.4.261
- 5.10.201
- 5.15.139
- 6.1.63
- 6.5.12
- 6.6.2
|
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt7629: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to
avoid NULL pointer dereference. |
["https://git.kernel.org/stable/c/1d89430fc3158f872d492f1b88d07262f48290c0","https://git.kernel.org/stable/c/2befa515c1bb6cdd33c262b909d93d1973a219aa","https://git.kernel.org/stable/c/4f861b63945e076f9f003a5fad958174096df1ee","https://git.kernel.org/stable/c/5fbea47eebff5daeca7d918c99289bcd3ae4dc8d","https://git.kernel.org/stable/c/a836efc21ef04608333d6d05753e558ebd1f85d0","https://git.kernel.org/stable/c/e8ae4b49dd9cfde69d8de8c0c0cd7cf1b004482e","https://git.kernel.org/stable/c/e964d21dc034b650d719c4ea39564bec72b42f94","https://git.kernel.org/stable/c/1d89430fc3158f872d492f1b88d07262f48290c0","https://git.kernel.org/stable/c/2befa515c1bb6cdd33c262b909d93d1973a219aa","https://git.kernel.org/stable/c/4f861b63945e076f9f003a5fad958174096df1ee","https://git.kernel.org/stable/c/5fbea47eebff5daeca7d918c99289bcd3ae4dc8d","https://git.kernel.org/stable/c/a836efc21ef04608333d6d05753e558ebd1f85d0","https://git.kernel.org/stable/c/e8ae4b49dd9cfde69d8de8c0c0cd7cf1b004482e","https://git.kernel.org/stable/c/e964d21dc034b650d719c4ea39564bec72b42f94"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2016-3699
|
High |
|
N/A
|
The Linux kernel, as used in Red Hat Enterprise Linux 7.2 and Red Hat Enterprise MRG 2 and when booted with UEFI Secure Boot enabled, allows local users to bypass intended Secure Boot restrictions and execute untrusted code by appending ACPI tables to the initrd. |
["http://rhn.redhat.com/errata/RHSA-2016-2574.html","http://rhn.redhat.com/errata/RHSA-2016-2584.html","http://www.openwall.com/lists/oss-security/2016/09/22/4","http://www.securityfocus.com/bid/93114","https://bugzilla.redhat.com/show_bug.cgi?id=1329653","https://github.com/mjg59/linux/commit/a4a5ed2835e8ea042868b7401dced3f517cafa76","http://rhn.redhat.com/errata/RHSA-2016-2574.html","http://rhn.redhat.com/errata/RHSA-2016-2584.html","http://www.openwall.com/lists/oss-security/2016/09/22/4","http://www.securityfocus.com/bid/93114","https://bugzilla.redhat.com/show_bug.cgi?id=1329653","https://github.com/mjg59/linux/commit/a4a5ed2835e8ea042868b7401dced3f517cafa76"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46721
|
Medium |
fixed |
- 4.19.322
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.109
- 6.6.50
- 6.10.9
|
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix possible NULL pointer dereference
profile->parent->dents[AAFS_PROF_DIR] could be NULL only if its parent is made
from __create_missing_ancestors(..) and 'ent->old' is NULL in
aa_replace_profiles(..).
In that case, it must return an error code and the code, -ENOENT represents
its state that the path of its parent is not existed yet.
BUG: kernel NULL pointer dereference, address: 0000000000000030
PGD 0 P4D 0
PREEMPT SMP PTI
CPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
RIP: 0010:aafs_create.constprop.0+0x7f/0x130
Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae
RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS: 00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0
Call Trace:
<TASK>
? show_regs+0x6d/0x80
? __die+0x24/0x80
? page_fault_oops+0x99/0x1b0
? kernelmode_fixup_or_oops+0xb2/0x140
? __bad_area_nosemaphore+0x1a5/0x2c0
? find_vma+0x34/0x60
? bad_area_nosemaphore+0x16/0x30
? do_user_addr_fault+0x2a2/0x6b0
? exc_page_fault+0x83/0x1b0
? asm_exc_page_fault+0x27/0x30
? aafs_create.constprop.0+0x7f/0x130
? aafs_create.constprop.0+0x51/0x130
__aafs_profile_mkdir+0x3d6/0x480
aa_replace_profiles+0x83f/0x1270
policy_update+0xe3/0x180
profile_load+0xbc/0x150
? rw_verify_area+0x47/0x140
vfs_write+0x100/0x480
? __x64_sys_openat+0x55/0xa0
? syscall_exit_to_user_mode+0x86/0x260
ksys_write+0x73/0x100
__x64_sys_write+0x19/0x30
x64_sys_call+0x7e/0x25c0
do_syscall_64+0x7f/0x180
entry_SYSCALL_64_after_hwframe+0x78/0x80
RIP: 0033:0x7be9f211c574
Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89
RSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574
RDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004
RBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80
R13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30
</TASK>
Modules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesas
CR2: 0000000000000030
---[ end trace 0000000000000000 ]---
RIP: 0010:aafs_create.constprop.0+0x7f/0x130
Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae
RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000
---truncated--- |
["https://git.kernel.org/stable/c/09b2d107fe63e55b6ae643f9f26bf8eb14a261d9","https://git.kernel.org/stable/c/3dd384108d53834002be5630132ad5c3f32166ad","https://git.kernel.org/stable/c/52338a3aa772762b8392ce7cac106c1099aeab85","https://git.kernel.org/stable/c/59f742e55a469ef36c5c1533b6095a103b61eda8","https://git.kernel.org/stable/c/730ee2686af0d55372e97a2695005ff142702363","https://git.kernel.org/stable/c/8d9da10a392a32368392f7a16775e1f36e2a5346","https://git.kernel.org/stable/c/c49bbe69ee152bd9c1c1f314c0f582e76c578f64","https://git.kernel.org/stable/c/e3c7d23f7a5c0b11ba0093cea32261ab8098b94e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46755
|
Medium |
fixed |
- 4.19.322
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()
mwifiex_get_priv_by_id() returns the priv pointer corresponding to
the bss_num and bss_type, but without checking if the priv is actually
currently in use.
Unused priv pointers do not have a wiphy attached to them which can
lead to NULL pointer dereferences further down the callstack. Fix
this by returning only used priv pointers which have priv->bss_mode
set to something else than NL80211_IFTYPE_UNSPECIFIED.
Said NULL pointer dereference happened when an Accesspoint was started
with wpa_supplicant -i mlan0 with this config:
network={
ssid="somessid"
mode=2
frequency=2412
key_mgmt=WPA-PSK WPA-PSK-SHA256
proto=RSN
group=CCMP
pairwise=CCMP
psk="12345678"
}
When waiting for the AP to be established, interrupting wpa_supplicant
with <ctrl-c> and starting it again this happens:
| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140
| Mem abort info:
| ESR = 0x0000000096000004
| EC = 0x25: DABT (current EL), IL = 32 bits
| SET = 0, FnV = 0
| EA = 0, S1PTW = 0
| FSC = 0x04: level 0 translation fault
| Data abort info:
| ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
| CM = 0, WnR = 0, TnD = 0, TagAccess = 0
| GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000
| [0000000000000140] pgd=0000000000000000, p4d=0000000000000000
| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
| Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio
+mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs
+imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6
| CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18
| Hardware name: somemachine (DT)
| Workqueue: events sdio_irq_work
| pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
| pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]
| lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]
| sp : ffff8000818b3a70
| x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004
| x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9
| x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000
| x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000
| x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517
| x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1
| x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157
| x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124
| x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000
| x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000
| Call trace:
| mwifiex_get_cfp+0xd8/0x15c [mwifiex]
| mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]
| mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]
| mwifiex_process_sta_event+0x298/0xf0c [mwifiex]
| mwifiex_process_event+0x110/0x238 [mwifiex]
| mwifiex_main_process+0x428/0xa44 [mwifiex]
| mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]
| process_sdio_pending_irqs+0x64/0x1b8
| sdio_irq_work+0x4c/0x7c
| process_one_work+0x148/0x2a0
| worker_thread+0x2fc/0x40c
| kthread+0x110/0x114
| ret_from_fork+0x10/0x20
| Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)
| ---[ end trace 0000000000000000 ]--- |
["https://git.kernel.org/stable/c/1a05d8d02cfa3540ea5dbd6b39446bd3f515521f","https://git.kernel.org/stable/c/9813770f25855b866b8ead8155b8806b2db70f6d","https://git.kernel.org/stable/c/a12cf97cbefa139ef8d95081f2ea047cbbd74b7a","https://git.kernel.org/stable/c/c145eea2f75ff7949392aebecf7ef0a81c1f6c14","https://git.kernel.org/stable/c/c16916dd6c16fa7e13ca3923eb6b9f50d848ad03","https://git.kernel.org/stable/c/c2618dcb26c7211342b54520b5b148c0d3471c8a","https://git.kernel.org/stable/c/cb67b2e51b75f1a17bee7599c8161b96e1808a70","https://git.kernel.org/stable/c/d834433ff313838a259bb6607055ece87b895b66"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46761
|
Medium |
fixed |
- 4.19.322
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
pci/hotplug/pnv_php: Fix hotplug driver crash on Powernv
The hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel
crash when we try to hot-unplug/disable the PCIe switch/bridge from
the PHB.
The crash occurs because although the MSI data structure has been
released during disable/hot-unplug path and it has been assigned
with NULL, still during unregistration the code was again trying to
explicitly disable the MSI which causes the NULL pointer dereference and
kernel crash.
The patch fixes the check during unregistration path to prevent invoking
pci_disable_msi/msix() since its data structure is already freed. |
["https://git.kernel.org/stable/c/335e35b748527f0c06ded9eebb65387f60647fda","https://git.kernel.org/stable/c/438d522227374042b5c8798f8ce83bbe479dca4d","https://git.kernel.org/stable/c/4eb4085c1346d19d4a05c55246eb93e74e671048","https://git.kernel.org/stable/c/b82d4d5c736f4fd2ed224c35f554f50d1953d21e","https://git.kernel.org/stable/c/bc1faed19db95abf0933b104910a3fb01b138f59","https://git.kernel.org/stable/c/bfc44075b19740d372f989f21dd03168bfda0689","https://git.kernel.org/stable/c/c0d8094dc740cfacf3775bbc6a1c4720459e8de4","https://git.kernel.org/stable/c/c4c681999d385e28f84808bbf3a85ea8e982da55"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50299
|
Medium |
fixed |
- 4.19.324
- 5.4.286
- 5.10.230
- 5.15.172
- 6.1.117
- 6.6.61
- 6.11.8
|
In the Linux kernel, the following vulnerability has been resolved:
sctp: properly validate chunk size in sctp_sf_ootb()
A size validation fix similar to that in Commit 50619dbf8db7 ("sctp: add
size validation when walking chunks") is also required in sctp_sf_ootb()
to address a crash reported by syzbot:
BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712
sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712
sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166
sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407
sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88
sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243
sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159
ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205
ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 |
["https://git.kernel.org/stable/c/0ead60804b64f5bd6999eec88e503c6a1a242d41","https://git.kernel.org/stable/c/40b283ba76665437bc2ac72079c51b57b25bff9e","https://git.kernel.org/stable/c/67b9a278b80f71ec62091ded97c6bcbea33b5ec3","https://git.kernel.org/stable/c/8820d2d6589f62ee5514793fff9b50c9f8101182","https://git.kernel.org/stable/c/9b5d42aeaf1a52f73b003a33da6deef7df34685f","https://git.kernel.org/stable/c/a758aa6a773bb872196bcc3173171ef8996bddf0","https://git.kernel.org/stable/c/bf9bff13225baf5f658577f7d985fc4933d79527","https://git.kernel.org/stable/c/d3fb3cc83cf313e4f87063ce0f3fea76b071567b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53060
|
Medium |
fixed |
- 4.19.324
- 5.4.286
- 5.10.230
- 5.15.172
- 6.1.117
- 6.6.61
- 6.11.8
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported
acpi_evaluate_object() may return AE_NOT_FOUND (failure), which
would result in dereferencing buffer.pointer (obj) while being NULL.
Although this case may be unrealistic for the current code, it is
still better to protect against possible bugs.
Bail out also when status is AE_NOT_FOUND.
This fixes 1 FORWARD_NULL issue reported by Coverity
Report: CID 1600951: Null pointer dereferences (FORWARD_NULL)
(cherry picked from commit 91c9e221fe2553edf2db71627d8453f083de87a1) |
["https://git.kernel.org/stable/c/1a9f55ed5b512f510ccd21ad527d532e60550e80","https://git.kernel.org/stable/c/27fc29b5376998c126c85cf9b15d9dfc2afc9cbe","https://git.kernel.org/stable/c/2ac7f253deada4d449559b65a1c1cd0a6f6f19b7","https://git.kernel.org/stable/c/8d7a28eca7553d35d4ce192fa1f390f2357df41b","https://git.kernel.org/stable/c/a613a392417532ca5aaf3deac6e3277aa7aaef2b","https://git.kernel.org/stable/c/a6dd15981c03f2cdc9a351a278f09b5479d53d2e","https://git.kernel.org/stable/c/b9d9881237afeb52eddd70077b7174bf17e2fa30","https://git.kernel.org/stable/c/ce8a00a00e36f61f5a1e47734332420b68784c43"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38553
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: fec: remove .ndo_poll_controller to avoid deadlocks
There is a deadlock issue found in sungem driver, please refer to the
commit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoid
deadlocks"). The root cause of the issue is that netpoll is in atomic
context and disable_irq() is called by .ndo_poll_controller interface
of sungem driver, however, disable_irq() might sleep. After analyzing
the implementation of fec_poll_controller(), the fec driver should have
the same issue. Due to the fec driver uses NAPI for TX completions, the
.ndo_poll_controller is unnecessary to be implemented in the fec driver,
so fec_poll_controller() can be safely removed. |
["https://git.kernel.org/stable/c/87bcbc9b7e0b43a69d44efa5f32f11e32d08fa6f","https://git.kernel.org/stable/c/accdd6b912c4219b8e056d1f1ad2e85bc66ee243","https://git.kernel.org/stable/c/c2e0c58b25a0a0c37ec643255558c5af4450c9f5","https://git.kernel.org/stable/c/d38625f71950e79e254515c5fc585552dad4b33e","https://git.kernel.org/stable/c/e2348d8c61d03feece1de4c05f72e6e99f74c650","https://git.kernel.org/stable/c/87bcbc9b7e0b43a69d44efa5f32f11e32d08fa6f","https://git.kernel.org/stable/c/accdd6b912c4219b8e056d1f1ad2e85bc66ee243","https://git.kernel.org/stable/c/c2e0c58b25a0a0c37ec643255558c5af4450c9f5","https://git.kernel.org/stable/c/d38625f71950e79e254515c5fc585552dad4b33e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42063
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Mark bpf prog stack with kmsan_unposion_memory in interpreter mode
syzbot reported uninit memory usages during map_{lookup,delete}_elem.
==========
BUG: KMSAN: uninit-value in __dev_map_lookup_elem kernel/bpf/devmap.c:441 [inline]
BUG: KMSAN: uninit-value in dev_map_lookup_elem+0xf3/0x170 kernel/bpf/devmap.c:796
__dev_map_lookup_elem kernel/bpf/devmap.c:441 [inline]
dev_map_lookup_elem+0xf3/0x170 kernel/bpf/devmap.c:796
____bpf_map_lookup_elem kernel/bpf/helpers.c:42 [inline]
bpf_map_lookup_elem+0x5c/0x80 kernel/bpf/helpers.c:38
___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997
__bpf_prog_run256+0xb5/0xe0 kernel/bpf/core.c:2237
==========
The reproducer should be in the interpreter mode.
The C reproducer is trying to run the following bpf prog:
0: (18) r0 = 0x0
2: (18) r1 = map[id:49]
4: (b7) r8 = 16777216
5: (7b) *(u64 *)(r10 -8) = r8
6: (bf) r2 = r10
7: (07) r2 += -229
^^^^^^^^^^
8: (b7) r3 = 8
9: (b7) r4 = 0
10: (85) call dev_map_lookup_elem#1543472
11: (95) exit
It is due to the "void *key" (r2) passed to the helper. bpf allows uninit
stack memory access for bpf prog with the right privileges. This patch
uses kmsan_unpoison_memory() to mark the stack as initialized.
This should address different syzbot reports on the uninit "void *key"
argument during map_{lookup,delete}_elem. |
["https://git.kernel.org/stable/c/3189983c26108cf0990e5c46856dc9feb9470d12","https://git.kernel.org/stable/c/b30f3197a6cd080052d5d4973f9a6b479fd9fff5","https://git.kernel.org/stable/c/d812ae6e02bd6e6a9cd1fdb09519c2f33e875faf","https://git.kernel.org/stable/c/e8742081db7d01f980c6161ae1e8a1dbc1e30979","https://git.kernel.org/stable/c/3189983c26108cf0990e5c46856dc9feb9470d12","https://git.kernel.org/stable/c/b30f3197a6cd080052d5d4973f9a6b479fd9fff5","https://git.kernel.org/stable/c/d812ae6e02bd6e6a9cd1fdb09519c2f33e875faf","https://git.kernel.org/stable/c/e8742081db7d01f980c6161ae1e8a1dbc1e30979"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-45018
|
Medium |
fixed |
- 5.10.225
- 5.15.166
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: flowtable: initialise extack before use
Fix missing initialisation of extack in flow offload. |
["https://git.kernel.org/stable/c/119be227bc04f5035efa64cb823b8a5ca5e2d1c1","https://git.kernel.org/stable/c/356beb911b63a8cff34cb57f755c2a2d2ee9dec7","https://git.kernel.org/stable/c/7eafeec6be68ebd6140a830ce9ae68ad5b67ec78","https://git.kernel.org/stable/c/c7b760499f7791352b49b11667ed04b23d7f5b0f","https://git.kernel.org/stable/c/e5ceff2196dc633c995afb080f6f44a72cff6e1d","https://git.kernel.org/stable/c/e9767137308daf906496613fd879808a07f006a2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26740
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_mirred: use the backlog for mirred ingress
The test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlog
for nested calls to mirred ingress") hangs our testing VMs every 10 or so
runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by
lockdep.
The problem as previously described by Davide (see Link) is that
if we reverse flow of traffic with the redirect (egress -> ingress)
we may reach the same socket which generated the packet. And we may
still be holding its socket lock. The common solution to such deadlocks
is to put the packet in the Rx backlog, rather than run the Rx path
inline. Do that for all egress -> ingress reversals, not just once
we started to nest mirred calls.
In the past there was a concern that the backlog indirection will
lead to loss of error reporting / less accurate stats. But the current
workaround does not seem to address the issue. |
["https://git.kernel.org/stable/c/52f671db18823089a02f07efc04efdb2272ddc17","https://git.kernel.org/stable/c/60ddea1600bc476e0f5e02bce0e29a460ccbf0be","https://git.kernel.org/stable/c/7c787888d164689da8b1b115f3ef562c1e843af4","https://git.kernel.org/stable/c/52f671db18823089a02f07efc04efdb2272ddc17","https://git.kernel.org/stable/c/60ddea1600bc476e0f5e02bce0e29a460ccbf0be","https://git.kernel.org/stable/c/7c787888d164689da8b1b115f3ef562c1e843af4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48648
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
sfc: fix null pointer dereference in efx_hard_start_xmit
Trying to get the channel from the tx_queue variable here is wrong
because we can only be here if tx_queue is NULL, so we shouldn't
dereference it. As the above comment in the code says, this is very
unlikely to happen, but it's wrong anyway so let's fix it.
I hit this issue because of a different bug that caused tx_queue to be
NULL. If that happens, this is the error message that we get here:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
[...]
RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc] |
["https://git.kernel.org/stable/c/0a242eb2913a4aa3d6fbdb86559f27628e9466f3","https://git.kernel.org/stable/c/8547c7bfc0617e7184e4da65b9b96681fcfe9998","https://git.kernel.org/stable/c/b3b41d4d95d3822b2e459ecbc80d030ea6aec5e7","https://git.kernel.org/stable/c/b3b952168ee1f220ba729fa100fd9d5aa752eb03","https://git.kernel.org/stable/c/0a242eb2913a4aa3d6fbdb86559f27628e9466f3","https://git.kernel.org/stable/c/8547c7bfc0617e7184e4da65b9b96681fcfe9998","https://git.kernel.org/stable/c/b3b41d4d95d3822b2e459ecbc80d030ea6aec5e7","https://git.kernel.org/stable/c/b3b952168ee1f220ba729fa100fd9d5aa752eb03"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39471
|
High |
fixed |
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.94
- 6.6.34
- 6.9.5
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: add error handle to avoid out-of-bounds
if the sdma_v4_0_irq_id_to_seq return -EINVAL, the process should
be stop to avoid out-of-bounds read, so directly return -EINVAL. |
["https://git.kernel.org/stable/c/011552f29f20842c9a7a21bffe1f6a2d6457ba46","https://git.kernel.org/stable/c/0964c84b93db7fbf74f357c1e20957850e092db3","https://git.kernel.org/stable/c/5594971e02764aa1c8210ffb838cb4e7897716e8","https://git.kernel.org/stable/c/5b0a3dc3e87821acb80e841b464d335aff242691","https://git.kernel.org/stable/c/8112fa72b7f139052843ff484130d6f97e9f052f","https://git.kernel.org/stable/c/8b2faf1a4f3b6c748c0da36cda865a226534d520","https://git.kernel.org/stable/c/ea906e9ac61e3152bef63597f2d9f4a812fc346a","https://git.kernel.org/stable/c/011552f29f20842c9a7a21bffe1f6a2d6457ba46","https://git.kernel.org/stable/c/0964c84b93db7fbf74f357c1e20957850e092db3","https://git.kernel.org/stable/c/5594971e02764aa1c8210ffb838cb4e7897716e8","https://git.kernel.org/stable/c/5b0a3dc3e87821acb80e841b464d335aff242691","https://git.kernel.org/stable/c/8112fa72b7f139052843ff484130d6f97e9f052f","https://git.kernel.org/stable/c/8b2faf1a4f3b6c748c0da36cda865a226534d520","https://git.kernel.org/stable/c/ea906e9ac61e3152bef63597f2d9f4a812fc346a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41059
|
High |
fixed |
- 4.19.319
- 5.4.281
- 5.10.223
- 5.15.164
- 6.1.101
- 6.6.42
- 6.9.11
|
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix uninit-value in copy_name
[syzbot reported]
BUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160
sized_strscpy+0xc4/0x160
copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411
hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750
vfs_listxattr fs/xattr.c:493 [inline]
listxattr+0x1f3/0x6b0 fs/xattr.c:840
path_listxattr fs/xattr.c:864 [inline]
__do_sys_listxattr fs/xattr.c:876 [inline]
__se_sys_listxattr fs/xattr.c:873 [inline]
__x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873
x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at:
slab_post_alloc_hook mm/slub.c:3877 [inline]
slab_alloc_node mm/slub.c:3918 [inline]
kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065
kmalloc include/linux/slab.h:628 [inline]
hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699
vfs_listxattr fs/xattr.c:493 [inline]
listxattr+0x1f3/0x6b0 fs/xattr.c:840
path_listxattr fs/xattr.c:864 [inline]
__do_sys_listxattr fs/xattr.c:876 [inline]
__se_sys_listxattr fs/xattr.c:873 [inline]
__x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873
x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
[Fix]
When allocating memory to strbuf, initialize memory to 0. |
["https://git.kernel.org/stable/c/0570730c16307a72f8241df12363f76600baf57d","https://git.kernel.org/stable/c/22999936b91ba545ce1fbbecae6895127945e91c","https://git.kernel.org/stable/c/34f8efd2743f2d961e92e8e994de4c7a2f9e74a0","https://git.kernel.org/stable/c/72805debec8f7aa342da194fe0ed7bc8febea335","https://git.kernel.org/stable/c/ad57dc2caf1e0a3c0a9904400fae7afbc9f74bb2","https://git.kernel.org/stable/c/c733e24a61cbcff10f660041d6d84d32bb7e4cb4","https://git.kernel.org/stable/c/d02d8c1dacafb28930c39e16d48e40bb6e4cbc70","https://git.kernel.org/stable/c/f08956d8e0f80fd0d4ad84ec917302bb2f3a9c6a","https://git.kernel.org/stable/c/0570730c16307a72f8241df12363f76600baf57d","https://git.kernel.org/stable/c/22999936b91ba545ce1fbbecae6895127945e91c","https://git.kernel.org/stable/c/34f8efd2743f2d961e92e8e994de4c7a2f9e74a0","https://git.kernel.org/stable/c/72805debec8f7aa342da194fe0ed7bc8febea335","https://git.kernel.org/stable/c/ad57dc2caf1e0a3c0a9904400fae7afbc9f74bb2","https://git.kernel.org/stable/c/c733e24a61cbcff10f660041d6d84d32bb7e4cb4","https://git.kernel.org/stable/c/d02d8c1dacafb28930c39e16d48e40bb6e4cbc70","https://git.kernel.org/stable/c/f08956d8e0f80fd0d4ad84ec917302bb2f3a9c6a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50033
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
slip: make slhc_remember() more robust against malicious packets
syzbot found that slhc_remember() was missing checks against
malicious packets [1].
slhc_remember() only checked the size of the packet was at least 20,
which is not good enough.
We need to make sure the packet includes the IPv4 and TCP header
that are supposed to be carried.
Add iph and th pointers to make the code more readable.
[1]
BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666
slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666
ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455
ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline]
ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212
ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327
pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379
sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113
__release_sock+0x1da/0x330 net/core/sock.c:3072
release_sock+0x6b/0x250 net/core/sock.c:3626
pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903
sock_sendmsg_nosec net/socket.c:729 [inline]
__sock_sendmsg+0x30f/0x380 net/socket.c:744
____sys_sendmsg+0x903/0xb60 net/socket.c:2602
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
__sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
__do_sys_sendmmsg net/socket.c:2771 [inline]
__se_sys_sendmmsg net/socket.c:2768 [inline]
__x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at:
slab_post_alloc_hook mm/slub.c:4091 [inline]
slab_alloc_node mm/slub.c:4134 [inline]
kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587
__alloc_skb+0x363/0x7b0 net/core/skbuff.c:678
alloc_skb include/linux/skbuff.h:1322 [inline]
sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732
pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867
sock_sendmsg_nosec net/socket.c:729 [inline]
__sock_sendmsg+0x30f/0x380 net/socket.c:744
____sys_sendmsg+0x903/0xb60 net/socket.c:2602
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
__sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
__do_sys_sendmmsg net/socket.c:2771 [inline]
__se_sys_sendmmsg net/socket.c:2768 [inline]
__x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 |
["https://git.kernel.org/stable/c/29e8d96d44f51cf89a62dd042be35d052833b95c","https://git.kernel.org/stable/c/36b054324d18e51cf466134e13b6fbe3c91f52af","https://git.kernel.org/stable/c/5e336384cc9b608e0551f99c3d87316ca3b0e51a","https://git.kernel.org/stable/c/7d3fce8cbe3a70a1c7c06c9b53696be5d5d8dd5c","https://git.kernel.org/stable/c/8bb79eb1db85a10865f0d4dd15b013def3f2d246","https://git.kernel.org/stable/c/ba6501ea06462d6404d57d5644cf2854db38e7d7","https://git.kernel.org/stable/c/ff5e0f895315706e4ca5a19df15be6866cee4f5d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27020
|
High |
fixed |
- 4.19.313
- 5.4.275
- 5.10.216
- 5.15.157
- 6.1.88
- 6.6.29
- 6.8.8
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()
nft_unregister_expr() can concurrent with __nft_expr_type_get(),
and there is not any protection when iterate over nf_tables_expressions
list in __nft_expr_type_get(). Therefore, there is potential data-race
of nf_tables_expressions list entry.
Use list_for_each_entry_rcu() to iterate over nf_tables_expressions
list in __nft_expr_type_get(), and use rcu_read_lock() in the caller
nft_expr_type_get() to protect the entire type query process. |
["https://git.kernel.org/stable/c/01f1a678b05ade4b1248019c2dcca773aebbeb7f","https://git.kernel.org/stable/c/0b6de00206adbbfc6373b3ae38d2a6f197987907","https://git.kernel.org/stable/c/8d56bad42ac4c43c6c72ddd6a654a2628bf839c5","https://git.kernel.org/stable/c/934e66e231cff2b18faa2c8aad0b8cec13957e05","https://git.kernel.org/stable/c/939109c0a8e2a006a6cc8209e262d25065f4403a","https://git.kernel.org/stable/c/a9ebf340d123ae12582210407f879d6a5a1bc25b","https://git.kernel.org/stable/c/b38a133d37fa421c8447b383d788c9cc6f5cb34c","https://git.kernel.org/stable/c/f969eb84ce482331a991079ab7a5c4dc3b7f89bf","https://git.kernel.org/stable/c/01f1a678b05ade4b1248019c2dcca773aebbeb7f","https://git.kernel.org/stable/c/0b6de00206adbbfc6373b3ae38d2a6f197987907","https://git.kernel.org/stable/c/8d56bad42ac4c43c6c72ddd6a654a2628bf839c5","https://git.kernel.org/stable/c/934e66e231cff2b18faa2c8aad0b8cec13957e05","https://git.kernel.org/stable/c/939109c0a8e2a006a6cc8209e262d25065f4403a","https://git.kernel.org/stable/c/a9ebf340d123ae12582210407f879d6a5a1bc25b","https://git.kernel.org/stable/c/b38a133d37fa421c8447b383d788c9cc6f5cb34c","https://git.kernel.org/stable/c/f969eb84ce482331a991079ab7a5c4dc3b7f89bf","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48873
|
High |
fixed |
- 5.4.230
- 5.10.165
- 5.15.90
- 6.1.8
|
In the Linux kernel, the following vulnerability has been resolved:
misc: fastrpc: Don't remove map on creater_process and device_release
Do not remove the map from the list on error path in
fastrpc_init_create_process, instead call fastrpc_map_put, to avoid
use-after-free. Do not remove it on fastrpc_device_release either,
call fastrpc_map_put instead.
The fastrpc_free_map is the only proper place to remove the map.
This is called only after the reference count is 0. |
["https://git.kernel.org/stable/c/193cd853145b63e670bd73740250983af1475330","https://git.kernel.org/stable/c/1b7b7bb400dd13dcb03fc6e591bb7ca4664bbec8","https://git.kernel.org/stable/c/35ddd482345c43d9eec1f3406c0f20a95ed4054b","https://git.kernel.org/stable/c/4b5c44e924a571d0ad07054de549624fbc04e4d7","https://git.kernel.org/stable/c/5bb96c8f9268e2fdb0e5321cbc358ee5941efc15"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27045
|
High |
fixed |
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix a potential buffer overflow in 'dp_dsc_clock_en_read()'
Tell snprintf() to store at most 10 bytes in the output buffer
instead of 30.
Fixes the below:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:1508 dp_dsc_clock_en_read() error: snprintf() is printing too much 30 vs 10 |
["https://git.kernel.org/stable/c/440f059837418fac1695b65d3ebc6080d33be877","https://git.kernel.org/stable/c/4b09715f1504f1b6e8dff0e9643630610bc05141","https://git.kernel.org/stable/c/ad76fd30557d6a106c481e4606a981221ca525f7","https://git.kernel.org/stable/c/cf114d8d4a8d78df272116a745bb43b48cef65f4","https://git.kernel.org/stable/c/d346b3e5b25c95d504478507eb867cd3818775ab","https://git.kernel.org/stable/c/eb9327af3621d26b1d83f767c97a3fe8191a3a65","https://git.kernel.org/stable/c/ff28893c96c5e0927a4da10cd24a3522ca663515","https://git.kernel.org/stable/c/440f059837418fac1695b65d3ebc6080d33be877","https://git.kernel.org/stable/c/4b09715f1504f1b6e8dff0e9643630610bc05141","https://git.kernel.org/stable/c/ad76fd30557d6a106c481e4606a981221ca525f7","https://git.kernel.org/stable/c/cf114d8d4a8d78df272116a745bb43b48cef65f4","https://git.kernel.org/stable/c/d346b3e5b25c95d504478507eb867cd3818775ab","https://git.kernel.org/stable/c/eb9327af3621d26b1d83f767c97a3fe8191a3a65","https://git.kernel.org/stable/c/ff28893c96c5e0927a4da10cd24a3522ca663515","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47697
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error
Ensure index in rtl2830_pid_filter does not exceed 31 to prevent
out-of-bounds access.
dev->filters is a 32-bit value, so set_bit and clear_bit functions should
only operate on indices from 0 to 31. If index is 32, it will attempt to
access a non-existent 33rd bit, leading to out-of-bounds access.
Change the boundary check from index > 32 to index >= 32 to resolve this
issue. |
["https://git.kernel.org/stable/c/042b101d7bf70616c4967c286ffa6fcca65babfb","https://git.kernel.org/stable/c/3dba83d3c81de1368d15a39f22df7b53e306052f","https://git.kernel.org/stable/c/46d7ebfe6a75a454a5fa28604f0ef1491f9d8d14","https://git.kernel.org/stable/c/58f31be7dfbc0c84a6497ad51924949cf64b86a2","https://git.kernel.org/stable/c/7fd6aae7e53b94f4035b1bfce28b8dfa0d0ae470","https://git.kernel.org/stable/c/86d920d2600c3a48efc2775c1666c1017eec6956","https://git.kernel.org/stable/c/883f794c6e498ae24680aead55c16f66b06cfc30","https://git.kernel.org/stable/c/8ffbe7d07b8e76193b151107878ddc1ccc94deb5","https://git.kernel.org/stable/c/badbd736e6649c4e6d7b4ff7e2b9857acfa9ea94"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47698
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error
Ensure index in rtl2832_pid_filter does not exceed 31 to prevent
out-of-bounds access.
dev->filters is a 32-bit value, so set_bit and clear_bit functions should
only operate on indices from 0 to 31. If index is 32, it will attempt to
access a non-existent 33rd bit, leading to out-of-bounds access.
Change the boundary check from index > 32 to index >= 32 to resolve this
issue.
[hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg] |
["https://git.kernel.org/stable/c/15bea004e939d938a6771dfcf2a26cc899ffd20a","https://git.kernel.org/stable/c/49b33c38d202d3327dcfd058e27f541dcc308b92","https://git.kernel.org/stable/c/527ab3eb3b0b4a6ee00e183c1de6a730239e2835","https://git.kernel.org/stable/c/66dbe0df6eccc7ee53a2c35016ce81e13b3ff447","https://git.kernel.org/stable/c/6ae3b9aee42616ee93c4585174f40c767828006d","https://git.kernel.org/stable/c/7065c05c6d58b9b9a98127aa14e9a5ec68173918","https://git.kernel.org/stable/c/8ae06f360cfaca2b88b98ca89144548b3186aab1","https://git.kernel.org/stable/c/a879b6cdd48134a3d58949ea4f075c75fa2d7d71","https://git.kernel.org/stable/c/bedd42e07988dbdd124b23e758ffef7a681b9c60"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47701
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid OOB when system.data xattr changes underneath the filesystem
When looking up for an entry in an inlined directory, if e_value_offs is
changed underneath the filesystem by some change in the block device, it
will lead to an out-of-bounds access that KASAN detects as an UAF.
EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none.
loop0: detected capacity change from 2048 to 2047
==================================================================
BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500
Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103
CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:93 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x169/0x550 mm/kasan/report.c:488
kasan_report+0x143/0x180 mm/kasan/report.c:601
ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500
ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697
__ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573
ext4_lookup_entry fs/ext4/namei.c:1727 [inline]
ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795
lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633
filename_create+0x297/0x540 fs/namei.c:3980
do_symlinkat+0xf9/0x3a0 fs/namei.c:4587
__do_sys_symlinkat fs/namei.c:4610 [inline]
__se_sys_symlinkat fs/namei.c:4607 [inline]
__x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f3e73ced469
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a
RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469
RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0
RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290
R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c
R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0
</TASK>
Calling ext4_xattr_ibody_find right after reading the inode with
ext4_get_inode_loc will lead to a check of the validity of the xattrs,
avoiding this problem. |
["https://git.kernel.org/stable/c/2a6579ef5f2576a940125729f7409cc182f1c8df","https://git.kernel.org/stable/c/371d0bacecd529f887ea2547333d9173e7bcdc0a","https://git.kernel.org/stable/c/5b076d37e8d99918e9294bd6b35a8bbb436819b0","https://git.kernel.org/stable/c/7fc22c3b3ffc0e952f5e0062dd11aa6ae76affba","https://git.kernel.org/stable/c/8adf0eb4e361a9e060d54f4bd0ac9c5d85277d20","https://git.kernel.org/stable/c/be2e9b111e2790962cc66a177869b4e9717b4e29","https://git.kernel.org/stable/c/c6b72f5d82b1017bad80f9ebf502832fc321d796","https://git.kernel.org/stable/c/ccb8c18076e2e630fea23fbec583cdad61787fc5","https://git.kernel.org/stable/c/ea32883e4a03ed575a2eb7a66542022312bde477"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49882
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix double brelse() the buffer of the extents path
In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been
released, otherwise it may be released twice. An example of what triggers
this is as follows:
split2 map split1
|--------|-------|--------|
ext4_ext_map_blocks
ext4_ext_handle_unwritten_extents
ext4_split_convert_extents
// path->p_depth == 0
ext4_split_extent
// 1. do split1
ext4_split_extent_at
|ext4_ext_insert_extent
| ext4_ext_create_new_leaf
| ext4_ext_grow_indepth
| le16_add_cpu(&neh->eh_depth, 1)
| ext4_find_extent
| // return -ENOMEM
|// get error and try zeroout
|path = ext4_find_extent
| path->p_depth = 1
|ext4_ext_try_to_merge
| ext4_ext_try_to_merge_up
| path->p_depth = 0
| brelse(path[1].p_bh) ---> not set to NULL here
|// zeroout success
// 2. update path
ext4_find_extent
// 3. do split2
ext4_split_extent_at
ext4_ext_insert_extent
ext4_ext_create_new_leaf
ext4_ext_grow_indepth
le16_add_cpu(&neh->eh_depth, 1)
ext4_find_extent
path[0].p_bh = NULL;
path->p_depth = 1
read_extent_tree_block ---> return err
// path[1].p_bh is still the old value
ext4_free_ext_path
ext4_ext_drop_refs
// path->p_depth == 1
brelse(path[1].p_bh) ---> brelse a buffer twice
Finally got the following WARRNING when removing the buffer from lru:
============================================
VFS: brelse: Trying to free free buffer
WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90
CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716
RIP: 0010:__brelse+0x58/0x90
Call Trace:
<TASK>
__find_get_block+0x6e7/0x810
bdev_getblk+0x2b/0x480
__ext4_get_inode_loc+0x48a/0x1240
ext4_get_inode_loc+0xb2/0x150
ext4_reserve_inode_write+0xb7/0x230
__ext4_mark_inode_dirty+0x144/0x6a0
ext4_ext_insert_extent+0x9c8/0x3230
ext4_ext_map_blocks+0xf45/0x2dc0
ext4_map_blocks+0x724/0x1700
ext4_do_writepages+0x12d6/0x2a70
[...]
============================================ |
["https://git.kernel.org/stable/c/230ee0535d01478bad9a3037292043f39b9be10b","https://git.kernel.org/stable/c/32bbb59e3f18facd7201bef110010bf35819b8c3","https://git.kernel.org/stable/c/68a69cf60660c73990c1875f94a5551600b04775","https://git.kernel.org/stable/c/7633407ca4ab8be2916ab214eb44ccebc6a50e1a","https://git.kernel.org/stable/c/78bbc3d15b6f443acb26e94418c445bac940d414","https://git.kernel.org/stable/c/b6c29c8f3d7cb67b505f3b2f6c242d52298d1f2e","https://git.kernel.org/stable/c/d4574bda63906bf69660e001470bfe1a0ac524ae","https://git.kernel.org/stable/c/dcaa6c31134c0f515600111c38ed7750003e1b9c","https://git.kernel.org/stable/c/f9fd47c9d9548f9e47fa60098eab99dde175401d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49883
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: aovid use-after-free in ext4_ext_insert_extent()
As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is
reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and
cause UAF. Below is a sample trace with dummy values:
ext4_ext_insert_extent
path = *ppath = 2000
ext4_ext_create_new_leaf(ppath)
ext4_find_extent(ppath)
path = *ppath = 2000
if (depth > path[0].p_maxdepth)
kfree(path = 2000);
*ppath = path = NULL;
path = kcalloc() = 3000
*ppath = 3000;
return path;
/* here path is still 2000, UAF! */
eh = path[depth].p_hdr
==================================================================
BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330
Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179
CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866
Call Trace:
<TASK>
ext4_ext_insert_extent+0x26d4/0x3330
ext4_ext_map_blocks+0xe22/0x2d40
ext4_map_blocks+0x71e/0x1700
ext4_do_writepages+0x1290/0x2800
[...]
Allocated by task 179:
ext4_find_extent+0x81c/0x1f70
ext4_ext_map_blocks+0x146/0x2d40
ext4_map_blocks+0x71e/0x1700
ext4_do_writepages+0x1290/0x2800
ext4_writepages+0x26d/0x4e0
do_writepages+0x175/0x700
[...]
Freed by task 179:
kfree+0xcb/0x240
ext4_find_extent+0x7c0/0x1f70
ext4_ext_insert_extent+0xa26/0x3330
ext4_ext_map_blocks+0xe22/0x2d40
ext4_map_blocks+0x71e/0x1700
ext4_do_writepages+0x1290/0x2800
ext4_writepages+0x26d/0x4e0
do_writepages+0x175/0x700
[...]
==================================================================
So use *ppath to update the path to avoid the above problem. |
["https://git.kernel.org/stable/c/51db04892a993cace63415be99848970a0f15ef2","https://git.kernel.org/stable/c/5e811066c5ab709b070659197dccfb80ab650ddd","https://git.kernel.org/stable/c/8162ee5d94b8c0351be0a9321be134872a7654a1","https://git.kernel.org/stable/c/975ca06f3fd154c5f7742083e7b2574c57d1c0c3","https://git.kernel.org/stable/c/9df59009dfc6d9fc1bd9ddf6c5ab6e56d6ed887a","https://git.kernel.org/stable/c/a164f3a432aae62ca23d03e6d926b122ee5b860d","https://git.kernel.org/stable/c/beb7b66fb489041c50c6473100b383f7a51648fc","https://git.kernel.org/stable/c/bfed082ce4b1ce6349b05c09a0fa4f3da35ecb1b","https://git.kernel.org/stable/c/e17ebe4fdd7665c93ae9459ba40fcdfb76769ac1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49884
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix slab-use-after-free in ext4_split_extent_at()
We hit the following use-after-free:
==================================================================
BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0
Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40
CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724
Call Trace:
<TASK>
kasan_report+0x93/0xc0
ext4_split_extent_at+0xba8/0xcc0
ext4_split_extent.isra.0+0x18f/0x500
ext4_split_convert_extents+0x275/0x750
ext4_ext_handle_unwritten_extents+0x73e/0x1580
ext4_ext_map_blocks+0xe20/0x2dc0
ext4_map_blocks+0x724/0x1700
ext4_do_writepages+0x12d6/0x2a70
[...]
Allocated by task 40:
__kmalloc_noprof+0x1ac/0x480
ext4_find_extent+0xf3b/0x1e70
ext4_ext_map_blocks+0x188/0x2dc0
ext4_map_blocks+0x724/0x1700
ext4_do_writepages+0x12d6/0x2a70
[...]
Freed by task 40:
kfree+0xf1/0x2b0
ext4_find_extent+0xa71/0x1e70
ext4_ext_insert_extent+0xa22/0x3260
ext4_split_extent_at+0x3ef/0xcc0
ext4_split_extent.isra.0+0x18f/0x500
ext4_split_convert_extents+0x275/0x750
ext4_ext_handle_unwritten_extents+0x73e/0x1580
ext4_ext_map_blocks+0xe20/0x2dc0
ext4_map_blocks+0x724/0x1700
ext4_do_writepages+0x12d6/0x2a70
[...]
==================================================================
The flow of issue triggering is as follows:
ext4_split_extent_at
path = *ppath
ext4_ext_insert_extent(ppath)
ext4_ext_create_new_leaf(ppath)
ext4_find_extent(orig_path)
path = *orig_path
read_extent_tree_block
// return -ENOMEM or -EIO
ext4_free_ext_path(path)
kfree(path)
*orig_path = NULL
a. If err is -ENOMEM:
ext4_ext_dirty(path + path->p_depth)
// path use-after-free !!!
b. If err is -EIO and we have EXT_DEBUG defined:
ext4_ext_show_leaf(path)
eh = path[depth].p_hdr
// path also use-after-free !!!
So when trying to zeroout or fix the extent length, call ext4_find_extent()
to update the path.
In addition we use *ppath directly as an ext4_ext_show_leaf() input to
avoid possible use-after-free when EXT_DEBUG is defined, and to avoid
unnecessary path updates. |
["https://git.kernel.org/stable/c/393a46f60ea4f249dc9d496d4eb2d542f5e11ade","https://git.kernel.org/stable/c/448100a29395b0c8b4c42967155849fe0fbe808f","https://git.kernel.org/stable/c/5d949ea75bb529ea6342e83465938a3b0ac51238","https://git.kernel.org/stable/c/8fe117790b37c84c651e2bad9efc0e7fda73c0e3","https://git.kernel.org/stable/c/915ac3630488af0ca194dc63b86d99802b4f6e18","https://git.kernel.org/stable/c/a5401d4c3e2a3d25643c567d26e6de327774a2c9","https://git.kernel.org/stable/c/c26ab35702f8cd0cdc78f96aa5856bfb77be798f","https://git.kernel.org/stable/c/cafcc1bd62934547c76abf46c6d0d54f135006fe","https://git.kernel.org/stable/c/e52f933598b781d291b9297e39c463536da0e185"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49966
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: cancel dqi_sync_work before freeing oinfo
ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the
end, if error occurs after successfully reading global quota, it will
trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled:
ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c
This reports that there is an active delayed work when freeing oinfo in
error handling, so cancel dqi_sync_work first. BTW, return status instead
of -1 when .read_file_info fails. |
["https://git.kernel.org/stable/c/0d707a33c84b371cb66120e198eed3374726ddd8","https://git.kernel.org/stable/c/14114d8148db07e7946fb06b56a50cfa425e26c7","https://git.kernel.org/stable/c/35fccce29feb3706f649726d410122dd81b92c18","https://git.kernel.org/stable/c/4173d1277c00baeedaaca76783e98b8fd0e3c08d","https://git.kernel.org/stable/c/89043e7ed63c7fc141e68ea5a79758ed24b6c699","https://git.kernel.org/stable/c/a4346c04d055bf7e184c18a73dbd23b6a9811118","https://git.kernel.org/stable/c/bbf41277df8b33fbedf4750a9300c147e8f104eb","https://git.kernel.org/stable/c/ef768020366f47d23f39c4f57bcb03af6d1e24b3","https://git.kernel.org/stable/c/fc5cc716dfbdc5fd5f373ff3b51358174cf88bfc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38577
|
High |
fixed |
- 5.10.226
- 5.15.167
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow
There is a possibility of buffer overflow in
show_rcu_tasks_trace_gp_kthread() if counters, passed
to sprintf() are huge. Counter numbers, needed for this
are unrealistically high, but buffer overflow is still
possible.
Use snprintf() with buffer size instead of sprintf().
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/08186d0c5fb64a1cc4b43e009314ee6b173ed222","https://git.kernel.org/stable/c/17c43211d45f13d1badea3942b76bf16bcc49281","https://git.kernel.org/stable/c/1a240e138071b25944ded0f5b3e357aa99fabcb7","https://git.kernel.org/stable/c/32d988f48ed287e676a29a15ac30701c35849aec","https://git.kernel.org/stable/c/6593d857ce5b5b802fb73d8091ac9c84b92c1697","https://git.kernel.org/stable/c/af7b560c88fb420099e29890aa682b8a3efc8784","https://git.kernel.org/stable/c/cc5645fddb0ce28492b15520306d092730dffa48","https://git.kernel.org/stable/c/08186d0c5fb64a1cc4b43e009314ee6b173ed222","https://git.kernel.org/stable/c/1a240e138071b25944ded0f5b3e357aa99fabcb7","https://git.kernel.org/stable/c/32d988f48ed287e676a29a15ac30701c35849aec","https://git.kernel.org/stable/c/6593d857ce5b5b802fb73d8091ac9c84b92c1697","https://git.kernel.org/stable/c/cc5645fddb0ce28492b15520306d092730dffa48"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39480
|
High |
fixed |
- 4.19.316
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.94
- 6.6.34
- 6.9.5
|
In the Linux kernel, the following vulnerability has been resolved:
kdb: Fix buffer overflow during tab-complete
Currently, when the user attempts symbol completion with the Tab key, kdb
will use strncpy() to insert the completed symbol into the command buffer.
Unfortunately it passes the size of the source buffer rather than the
destination to strncpy() with predictably horrible results. Most obviously
if the command buffer is already full but cp, the cursor position, is in
the middle of the buffer, then we will write past the end of the supplied
buffer.
Fix this by replacing the dubious strncpy() calls with memmove()/memcpy()
calls plus explicit boundary checks to make sure we have enough space
before we start moving characters around. |
["https://git.kernel.org/stable/c/107e825cc448b7834b31e8b1b3cf0f57426d46d5","https://git.kernel.org/stable/c/33d9c814652b971461d1e30bead6792851c209e7","https://git.kernel.org/stable/c/cfdc2fa4db57503bc6d3817240547c8ddc55fa96","https://git.kernel.org/stable/c/ddd2972d8e2dee3b33e8121669d55def59f0be8a","https://git.kernel.org/stable/c/e9730744bf3af04cda23799029342aa3cddbc454","https://git.kernel.org/stable/c/f636a40834d22e5e3fc748f060211879c056cd33","https://git.kernel.org/stable/c/f694da720dcf795dc3eb97bf76d220213f76aaa7","https://git.kernel.org/stable/c/fb824a99e148ff272a53d71d84122728b5f00992","https://git.kernel.org/stable/c/107e825cc448b7834b31e8b1b3cf0f57426d46d5","https://git.kernel.org/stable/c/33d9c814652b971461d1e30bead6792851c209e7","https://git.kernel.org/stable/c/cfdc2fa4db57503bc6d3817240547c8ddc55fa96","https://git.kernel.org/stable/c/ddd2972d8e2dee3b33e8121669d55def59f0be8a","https://git.kernel.org/stable/c/e9730744bf3af04cda23799029342aa3cddbc454","https://git.kernel.org/stable/c/f636a40834d22e5e3fc748f060211879c056cd33","https://git.kernel.org/stable/c/f694da720dcf795dc3eb97bf76d220213f76aaa7","https://git.kernel.org/stable/c/fb824a99e148ff272a53d71d84122728b5f00992"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44942
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on F2FS_INLINE_DATA flag in inode during GC
syzbot reports a f2fs bug as below:
------------[ cut here ]------------
kernel BUG at fs/f2fs/inline.c:258!
CPU: 1 PID: 34 Comm: kworker/u8:2 Not tainted 6.9.0-rc6-syzkaller-00012-g9e4bc4bcae01 #0
RIP: 0010:f2fs_write_inline_data+0x781/0x790 fs/f2fs/inline.c:258
Call Trace:
f2fs_write_single_data_page+0xb65/0x1d60 fs/f2fs/data.c:2834
f2fs_write_cache_pages fs/f2fs/data.c:3133 [inline]
__f2fs_write_data_pages fs/f2fs/data.c:3288 [inline]
f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3315
do_writepages+0x35b/0x870 mm/page-writeback.c:2612
__writeback_single_inode+0x165/0x10b0 fs/fs-writeback.c:1650
writeback_sb_inodes+0x905/0x1260 fs/fs-writeback.c:1941
wb_writeback+0x457/0xce0 fs/fs-writeback.c:2117
wb_do_writeback fs/fs-writeback.c:2264 [inline]
wb_workfn+0x410/0x1090 fs/fs-writeback.c:2304
process_one_work kernel/workqueue.c:3254 [inline]
process_scheduled_works+0xa12/0x17c0 kernel/workqueue.c:3335
worker_thread+0x86d/0xd70 kernel/workqueue.c:3416
kthread+0x2f2/0x390 kernel/kthread.c:388
ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
The root cause is: inline_data inode can be fuzzed, so that there may
be valid blkaddr in its direct node, once f2fs triggers background GC
to migrate the block, it will hit f2fs_bug_on() during dirty page
writeback.
Let's add sanity check on F2FS_INLINE_DATA flag in inode during GC,
so that, it can forbid migrating inline_data inode's data block for
fixing. |
["https://git.kernel.org/stable/c/26c07775fb5dc74351d1c3a2bc3cdf609b03e49f","https://git.kernel.org/stable/c/ae00e6536a2dd54b64b39e9a39548870cf835745","https://git.kernel.org/stable/c/fc01008c92f40015aeeced94750855a7111b6929"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42076
|
Medium |
fixed |
- 5.4
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.97
- 6.6.37
- 6.9.8
|
In the Linux kernel, the following vulnerability has been resolved:
net: can: j1939: Initialize unused data in j1939_send_one()
syzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one()
creates full frame including unused data, but it doesn't initialize
it. This causes the kernel-infoleak issue. Fix this by initializing
unused data.
[1]
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]
BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]
BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
copy_to_user_iter lib/iov_iter.c:24 [inline]
iterate_ubuf include/linux/iov_iter.h:29 [inline]
iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
iterate_and_advance include/linux/iov_iter.h:271 [inline]
_copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
copy_to_iter include/linux/uio.h:196 [inline]
memcpy_to_msg include/linux/skbuff.h:4113 [inline]
raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008
sock_recvmsg_nosec net/socket.c:1046 [inline]
sock_recvmsg+0x2c4/0x340 net/socket.c:1068
____sys_recvmsg+0x18a/0x620 net/socket.c:2803
___sys_recvmsg+0x223/0x840 net/socket.c:2845
do_recvmmsg+0x4fc/0xfd0 net/socket.c:2939
__sys_recvmmsg net/socket.c:3018 [inline]
__do_sys_recvmmsg net/socket.c:3041 [inline]
__se_sys_recvmmsg net/socket.c:3034 [inline]
__x64_sys_recvmmsg+0x397/0x490 net/socket.c:3034
x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at:
slab_post_alloc_hook mm/slub.c:3804 [inline]
slab_alloc_node mm/slub.c:3845 [inline]
kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577
__alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668
alloc_skb include/linux/skbuff.h:1313 [inline]
alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504
sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795
sock_alloc_send_skb include/net/sock.h:1842 [inline]
j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline]
j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline]
j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x30f/0x380 net/socket.c:745
____sys_sendmsg+0x877/0xb60 net/socket.c:2584
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
__sys_sendmsg net/socket.c:2667 [inline]
__do_sys_sendmsg net/socket.c:2676 [inline]
__se_sys_sendmsg net/socket.c:2674 [inline]
__x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674
x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Bytes 12-15 of 16 are uninitialized
Memory access of size 16 starts at ffff888120969690
Data copied to user address 00000000200017c0
CPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 |
["https://git.kernel.org/stable/c/4c5dc3927e17489c1cae6f48c0d5e4acb4cae01f","https://git.kernel.org/stable/c/5e4ed38eb17eaca42de57d500cc0f9668d2b6abf","https://git.kernel.org/stable/c/a2a0ebff7fdeb2f66e29335adf64b9e457300dd4","https://git.kernel.org/stable/c/ab2a683938ba4416d389c2f5651cbbb2c41b779f","https://git.kernel.org/stable/c/b7cdf1dd5d2a2d8200efd98d1893684db48fe134","https://git.kernel.org/stable/c/ba7e5ae8208ac07d8e1eace0951a34c169a2d298","https://git.kernel.org/stable/c/f97cbce633923588307049c4aef9feb2987e371b","https://git.kernel.org/stable/c/4c5dc3927e17489c1cae6f48c0d5e4acb4cae01f","https://git.kernel.org/stable/c/5e4ed38eb17eaca42de57d500cc0f9668d2b6abf","https://git.kernel.org/stable/c/a2a0ebff7fdeb2f66e29335adf64b9e457300dd4","https://git.kernel.org/stable/c/ab2a683938ba4416d389c2f5651cbbb2c41b779f","https://git.kernel.org/stable/c/b7cdf1dd5d2a2d8200efd98d1893684db48fe134","https://git.kernel.org/stable/c/ba7e5ae8208ac07d8e1eace0951a34c169a2d298","https://git.kernel.org/stable/c/f97cbce633923588307049c4aef9feb2987e371b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48856
|
Medium |
fixed |
- 4.19.235
- 5.4.185
- 5.10.106
- 5.15.29
- 5.16.15
|
In the Linux kernel, the following vulnerability has been resolved:
gianfar: ethtool: Fix refcount leak in gfar_get_ts_info
The of_find_compatible_node() function returns a node pointer with
refcount incremented, We should use of_node_put() on it when done
Add the missing of_node_put() to release the refcount. |
["https://git.kernel.org/stable/c/0e1b9a2078e07fb1e6e91bf8badfd89ecab1e848","https://git.kernel.org/stable/c/21044e679ed535345042d2023f7df0ca8e897e2a","https://git.kernel.org/stable/c/2ac5b58e645c66932438bb021cb5b52097ce70b0","https://git.kernel.org/stable/c/6263f2eb93a85ad7df504daf0c341a7fb6bbe8a6","https://git.kernel.org/stable/c/f49f646f9ec296fc0afe7ae92c2bb47f23e3846c","https://git.kernel.org/stable/c/f7b3b520349193f8a82cca74daf366199e06add9","https://git.kernel.org/stable/c/0e1b9a2078e07fb1e6e91bf8badfd89ecab1e848","https://git.kernel.org/stable/c/21044e679ed535345042d2023f7df0ca8e897e2a","https://git.kernel.org/stable/c/2ac5b58e645c66932438bb021cb5b52097ce70b0","https://git.kernel.org/stable/c/6263f2eb93a85ad7df504daf0c341a7fb6bbe8a6","https://git.kernel.org/stable/c/f49f646f9ec296fc0afe7ae92c2bb47f23e3846c","https://git.kernel.org/stable/c/f7b3b520349193f8a82cca74daf366199e06add9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48857
|
Medium |
fixed |
- 4.9.307
- 4.14.272
- 4.19.235
- 5.4.185
- 5.10.106
- 5.15.29
- 5.16.15
|
In the Linux kernel, the following vulnerability has been resolved:
NFC: port100: fix use-after-free in port100_send_complete
Syzbot reported UAF in port100_send_complete(). The root case is in
missing usb_kill_urb() calls on error handling path of ->probe function.
port100_send_complete() accesses devm allocated memory which will be
freed on probe failure. We should kill this urbs before returning an
error from probe function to prevent reported use-after-free
Fail log:
BUG: KASAN: use-after-free in port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935
Read of size 1 at addr ffff88801bb59540 by task ksoftirqd/2/26
...
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255
__kasan_report mm/kasan/report.c:442 [inline]
kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935
__usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1670
...
Allocated by task 1255:
kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:45 [inline]
set_alloc_info mm/kasan/common.c:436 [inline]
____kasan_kmalloc mm/kasan/common.c:515 [inline]
____kasan_kmalloc mm/kasan/common.c:474 [inline]
__kasan_kmalloc+0xa6/0xd0 mm/kasan/common.c:524
alloc_dr drivers/base/devres.c:116 [inline]
devm_kmalloc+0x96/0x1d0 drivers/base/devres.c:823
devm_kzalloc include/linux/device.h:209 [inline]
port100_probe+0x8a/0x1320 drivers/nfc/port100.c:1502
Freed by task 1255:
kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
kasan_set_track+0x21/0x30 mm/kasan/common.c:45
kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370
____kasan_slab_free mm/kasan/common.c:366 [inline]
____kasan_slab_free+0xff/0x140 mm/kasan/common.c:328
kasan_slab_free include/linux/kasan.h:236 [inline]
__cache_free mm/slab.c:3437 [inline]
kfree+0xf8/0x2b0 mm/slab.c:3794
release_nodes+0x112/0x1a0 drivers/base/devres.c:501
devres_release_all+0x114/0x190 drivers/base/devres.c:530
really_probe+0x626/0xcc0 drivers/base/dd.c:670 |
["https://git.kernel.org/stable/c/0e721b8f2ee5e11376dd55363f9ccb539d754b8a","https://git.kernel.org/stable/c/205c4ec78e71cbf561794e6043da80e7bae6790f","https://git.kernel.org/stable/c/2b1c85f56512d49e43bc53741fce2f508cd90029","https://git.kernel.org/stable/c/32e866ae5a7af590597ef4bcff8451bf96d5f980","https://git.kernel.org/stable/c/7194737e1be8fdc89d2a9382bd2f371f7ee2eda8","https://git.kernel.org/stable/c/b1db33d4e54bc35d8db96ce143ea0ef92e23d58e","https://git.kernel.org/stable/c/cd2a5c0da0d1ddf11d1f84e9c9b1949f50f6e161","https://git.kernel.org/stable/c/f80cfe2f26581f188429c12bd937eb905ad3ac7b","https://git.kernel.org/stable/c/0e721b8f2ee5e11376dd55363f9ccb539d754b8a","https://git.kernel.org/stable/c/205c4ec78e71cbf561794e6043da80e7bae6790f","https://git.kernel.org/stable/c/2b1c85f56512d49e43bc53741fce2f508cd90029","https://git.kernel.org/stable/c/32e866ae5a7af590597ef4bcff8451bf96d5f980","https://git.kernel.org/stable/c/7194737e1be8fdc89d2a9382bd2f371f7ee2eda8","https://git.kernel.org/stable/c/b1db33d4e54bc35d8db96ce143ea0ef92e23d58e","https://git.kernel.org/stable/c/cd2a5c0da0d1ddf11d1f84e9c9b1949f50f6e161","https://git.kernel.org/stable/c/f80cfe2f26581f188429c12bd937eb905ad3ac7b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48860
|
Medium |
fixed |
- 4.9.307
- 4.14.272
- 4.19.235
- 5.4.185
- 5.10.106
- 5.15.29
- 5.16.15
|
In the Linux kernel, the following vulnerability has been resolved:
ethernet: Fix error handling in xemaclite_of_probe
This node pointer is returned by of_parse_phandle() with refcount
incremented in this function. Calling of_node_put() to avoid the
refcount leak. As the remove function do. |
["https://git.kernel.org/stable/c/1852854ee349881efb78ccdbbb237838975902e4","https://git.kernel.org/stable/c/5e7c402892e189a7bc152b125e72261154aa585d","https://git.kernel.org/stable/c/669172ce976608b25a2f76f3c65d47f042d125c9","https://git.kernel.org/stable/c/8609e29611befc4bfbe7a91bb50fc65ae72ff549","https://git.kernel.org/stable/c/8ee065a7a9b6a3976c16340503677efc4d8351f6","https://git.kernel.org/stable/c/979b418b96e35f07136f77962ccfaa54cf3e30e1","https://git.kernel.org/stable/c/b19ab4b38b06aae12442b2de95ccf58b5dc53584","https://git.kernel.org/stable/c/b7220f8e9d6c6b9594ddfb3125dad938cd478b1f","https://git.kernel.org/stable/c/1852854ee349881efb78ccdbbb237838975902e4","https://git.kernel.org/stable/c/5e7c402892e189a7bc152b125e72261154aa585d","https://git.kernel.org/stable/c/669172ce976608b25a2f76f3c65d47f042d125c9","https://git.kernel.org/stable/c/8609e29611befc4bfbe7a91bb50fc65ae72ff549","https://git.kernel.org/stable/c/8ee065a7a9b6a3976c16340503677efc4d8351f6","https://git.kernel.org/stable/c/979b418b96e35f07136f77962ccfaa54cf3e30e1","https://git.kernel.org/stable/c/b19ab4b38b06aae12442b2de95ccf58b5dc53584","https://git.kernel.org/stable/c/b7220f8e9d6c6b9594ddfb3125dad938cd478b1f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42236
|
Medium |
fixed |
- 4.19.318
- 5.4.280
- 5.10.222
- 5.15.163
- 6.1.100
- 6.6.41
- 6.9.10
|
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: configfs: Prevent OOB read/write in usb_string_copy()
Userspace provided string 's' could trivially have the length zero. Left
unchecked this will firstly result in an OOB read in the form
`if (str[0 - 1] == '\n') followed closely by an OOB write in the form
`str[0 - 1] = '\0'`.
There is already a validating check to catch strings that are too long.
Let's supply an additional check for invalid strings that are too short. |
["https://git.kernel.org/stable/c/2d16f63d8030903e5031853e79d731ee5d474e70","https://git.kernel.org/stable/c/6d3c721e686ea6c59e18289b400cc95c76e927e0","https://git.kernel.org/stable/c/72b8ee0d9826e8ed00e0bdfce3e46b98419b37ce","https://git.kernel.org/stable/c/a444c3fc264119801575ab086e03fb4952f23fd0","https://git.kernel.org/stable/c/c95fbdde87e39e5e0ae27f28bf6711edfb985caa","https://git.kernel.org/stable/c/d1205033e912f9332c1dbefa812e6ceb0575ce0a","https://git.kernel.org/stable/c/e8474a10c535e6a2024c3b06e37e4a3a23beb490","https://git.kernel.org/stable/c/eecfefad0953b2f31aaefa058f7f348ff39c4bba"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42286
|
Medium |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: validate nvme_local_port correctly
The driver load failed with error message,
qla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef
and with a kernel crash,
BUG: unable to handle kernel NULL pointer dereference at 0000000000000070
Workqueue: events_unbound qla_register_fcport_fn [qla2xxx]
RIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc]
RSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000
RDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000
RBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030
R10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4
R13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8
FS: 0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0
Call Trace:
qla_nvme_register_remote+0xeb/0x1f0 [qla2xxx]
? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx]
qla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx]
qla_register_fcport_fn+0x54/0xc0 [qla2xxx]
Exit the qla_nvme_register_remote() function when qla_nvme_register_hba()
fails and correctly validate nvme_local_port. |
["https://git.kernel.org/stable/c/3eac973eb5cb2b874b3918f924798afc5affd46b","https://git.kernel.org/stable/c/549aac9655320c9b245a24271b204668c5d40430","https://git.kernel.org/stable/c/7cec2c3bfe84539c415f5e16f989228eba1d2f1e","https://git.kernel.org/stable/c/a3ab508a4853a9f5ae25a7816a4889f09938f63c","https://git.kernel.org/stable/c/cde43031df533751b4ead37d173922feee2f550f","https://git.kernel.org/stable/c/e1f010844443c389bc552884ac5cfa47de34d54c","https://git.kernel.org/stable/c/eb1d4ce2609584eeb7694866f34d4b213caa3af9","https://git.kernel.org/stable/c/f6be298cc1042f24d521197af29c7c4eb95af4d5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42289
|
Medium |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: During vport delete send async logout explicitly
During vport delete, it is observed that during unload we hit a crash
because of stale entries in outstanding command array. For all these stale
I/O entries, eh_abort was issued and aborted (fast_fail_io = 2009h) but
I/Os could not complete while vport delete is in process of deleting.
BUG: kernel NULL pointer dereference, address: 000000000000001c
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
Workqueue: qla2xxx_wq qla_do_work [qla2xxx]
RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0
RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046
RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001
RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0
RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8
R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000
R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0
Call Trace:
<TASK>
qla2xxx_qpair_sp_free_dma+0x417/0x4e0
? qla2xxx_qpair_sp_compl+0x10d/0x1a0
? qla2x00_status_entry+0x768/0x2830
? newidle_balance+0x2f0/0x430
? dequeue_entity+0x100/0x3c0
? qla24xx_process_response_queue+0x6a1/0x19e0
? __schedule+0x2d5/0x1140
? qla_do_work+0x47/0x60
? process_one_work+0x267/0x440
? process_one_work+0x440/0x440
? worker_thread+0x2d/0x3d0
? process_one_work+0x440/0x440
? kthread+0x156/0x180
? set_kthread_struct+0x50/0x50
? ret_from_fork+0x22/0x30
</TASK>
Send out async logout explicitly for all the ports during vport delete. |
["https://git.kernel.org/stable/c/086489256696eb774654a5410e86381c346356fe","https://git.kernel.org/stable/c/171ac4b495f9473bc134356a00095b47e6409e52","https://git.kernel.org/stable/c/76f480d7c717368f29a3870f7d64471ce0ff8fb2","https://git.kernel.org/stable/c/87c25fcb95aafabb6a4914239f4ab41b07a4f9b7","https://git.kernel.org/stable/c/b12c54e51ba83c1fbc619d35083d7872e42ecdef","https://git.kernel.org/stable/c/b35d6d5a2f38605cddea7d5c64cded894fbe8ede","https://git.kernel.org/stable/c/d28a2075bb530489715a3b011e1dd8765ba20313","https://git.kernel.org/stable/c/e5ed6a26ffdec0c91cf0b6138afbd675c00ad5fc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43893
|
Medium |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.105
- 6.6.46
- 6.10.5
|
In the Linux kernel, the following vulnerability has been resolved:
serial: core: check uartclk for zero to avoid divide by zero
Calling ioctl TIOCSSERIAL with an invalid baud_base can
result in uartclk being zero, which will result in a
divide by zero error in uart_get_divisor(). The check for
uartclk being zero in uart_set_info() needs to be done
before other settings are made as subsequent calls to
ioctl TIOCSSERIAL for the same port would be impacted if
the uartclk check was done where uartclk gets set.
Oops: divide error: 0000 PREEMPT SMP KASAN PTI
RIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580)
Call Trace:
<TASK>
serial8250_get_divisor (drivers/tty/serial/8250/8250_port.c:2576
drivers/tty/serial/8250/8250_port.c:2589)
serial8250_do_set_termios (drivers/tty/serial/8250/8250_port.c:502
drivers/tty/serial/8250/8250_port.c:2741)
serial8250_set_termios (drivers/tty/serial/8250/8250_port.c:2862)
uart_change_line_settings (./include/linux/spinlock.h:376
./include/linux/serial_core.h:608 drivers/tty/serial/serial_core.c:222)
uart_port_startup (drivers/tty/serial/serial_core.c:342)
uart_startup (drivers/tty/serial/serial_core.c:368)
uart_set_info (drivers/tty/serial/serial_core.c:1034)
uart_set_info_user (drivers/tty/serial/serial_core.c:1059)
tty_set_serial (drivers/tty/tty_io.c:2637)
tty_ioctl (drivers/tty/tty_io.c:2647 drivers/tty/tty_io.c:2791)
__x64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:907
fs/ioctl.c:893 fs/ioctl.c:893)
do_syscall_64 (arch/x86/entry/common.c:52
(discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
Rule: add |
["https://git.kernel.org/stable/c/3bbd90fca824e6fd61fb20f6dd2b0fa5f8b14bba","https://git.kernel.org/stable/c/52b138f1021113e593ee6ad258ce08fe90693a9e","https://git.kernel.org/stable/c/55b2a5d331a6ceb1c4372945fdb77181265ba24f","https://git.kernel.org/stable/c/68dc02f319b9ee54dc23caba742a5c754d1cccc8","https://git.kernel.org/stable/c/6eabce6608d6f3440f4c03aa3d3ef50a47a3d193","https://git.kernel.org/stable/c/9196e42a3b8eeff1707e6ef769112b4b6096be49","https://git.kernel.org/stable/c/e13ba3fe5ee070f8a9dab60029d52b1f61da5051","https://git.kernel.org/stable/c/e3ad503876283ac3fcca922a1bf243ef9eb0b0e2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43907
|
Medium |
fixed |
- 5.10.224
- 5.15.165
- 6.1.105
- 6.6.46
- 6.10.5
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/pm: Fix the null pointer dereference in apply_state_adjust_rules
Check the pointer value to fix potential null pointer
dereference |
["https://git.kernel.org/stable/c/0c065e50445aea2e0a1815f12e97ee49e02cbaac","https://git.kernel.org/stable/c/13937a40aae4efe64592ba48c057ac3c72f7fe82","https://git.kernel.org/stable/c/3a01bf2ca9f860fdc88c358567b8fa3033efcf30","https://git.kernel.org/stable/c/c1749313f35b98e2e655479f037db37f19756622","https://git.kernel.org/stable/c/d19fb10085a49b77578314f69fff21562f7cd054","https://git.kernel.org/stable/c/e04d18c29954441aa1054af649f957ffad90a201"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43914
|
Medium |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.105
- 6.6.46
- 6.10.5
|
In the Linux kernel, the following vulnerability has been resolved:
md/raid5: avoid BUG_ON() while continue reshape after reassembling
Currently, mdadm support --revert-reshape to abort the reshape while
reassembling, as the test 07revert-grow. However, following BUG_ON()
can be triggerred by the test:
kernel BUG at drivers/md/raid5.c:6278!
invalid opcode: 0000 [#1] PREEMPT SMP PTI
irq event stamp: 158985
CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94
RIP: 0010:reshape_request+0x3f1/0xe60
Call Trace:
<TASK>
raid5_sync_request+0x43d/0x550
md_do_sync+0xb7a/0x2110
md_thread+0x294/0x2b0
kthread+0x147/0x1c0
ret_from_fork+0x59/0x70
ret_from_fork_asm+0x1a/0x30
</TASK>
Root cause is that --revert-reshape update the raid_disks from 5 to 4,
while reshape position is still set, and after reassembling the array,
reshape position will be read from super block, then during reshape the
checking of 'writepos' that is caculated by old reshape position will
fail.
Fix this panic the easy way first, by converting the BUG_ON() to
WARN_ON(), and stop the reshape if checkings fail.
Noted that mdadm must fix --revert-shape as well, and probably md/raid
should enhance metadata validation as well, however this means
reassemble will fail and there must be user tools to fix the wrong
metadata. |
["https://git.kernel.org/stable/c/2c92f8c1c456d556f15cbf51667b385026b2e6a0","https://git.kernel.org/stable/c/305a5170dc5cf3d395bb4c4e9239bca6d0b54b49","https://git.kernel.org/stable/c/3b33740c1750a39e046339ff9240e954f0156707","https://git.kernel.org/stable/c/4811d6e5d9f4090c3e0ff9890eb24077108046ab","https://git.kernel.org/stable/c/6b33c468d543f6a83de2d61f09fec74b27e19fd2","https://git.kernel.org/stable/c/775a9ba16c9ffe98fe54ebf14e55d5660f2bf600","https://git.kernel.org/stable/c/bf0ff69a42a3d2d46876d0514ecf13dffc516666","https://git.kernel.org/stable/c/c384dd4f1fb3b14a2fd199360701cc163ea88705"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44960
|
Medium |
fixed |
- 3.16.80
- 4.4.199
- 4.9.199
- 4.14.152
- 4.19.320
- 5.3.9
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.105
- 6.6.46
- 6.10.5
|
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: core: Check for unset descriptor
Make sure the descriptor has been set before looking at maxpacket.
This fixes a null pointer panic in this case.
This may happen if the gadget doesn't properly set up the endpoint
for the current speed, or the gadget descriptors are malformed and
the descriptor for the speed/endpoint are not found.
No current gadget driver is known to have this problem, but this
may cause a hard-to-find bug during development of new gadgets. |
["https://git.kernel.org/stable/c/1a9df57d57452b104c46c918569143cf21d7ebf1","https://git.kernel.org/stable/c/50c5248b0ea8aae0529fdf28dac42a41312d3b62","https://git.kernel.org/stable/c/716cba46f73a92645cf13eded8d257ed48afc2a4","https://git.kernel.org/stable/c/7cc9ebcfe58be22f18056ad8bc6272d120bdcb3e","https://git.kernel.org/stable/c/973a57891608a98e894db2887f278777f564de18","https://git.kernel.org/stable/c/a0362cd6e503278add954123957fd47990e8d9bf","https://git.kernel.org/stable/c/ba15815dd24cc5ec0d23e2170dc58c7db1e03b4a","https://git.kernel.org/stable/c/df8e734ae5e605348aa0ca2498aedb73e815f244"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39472
|
Medium |
|
N/A
|
In the Linux kernel, the following vulnerability has been resolved:
xfs: fix log recovery buffer allocation for the legacy h_size fixup
Commit a70f9fe52daa ("xfs: detect and handle invalid iclog size set by
mkfs") added a fixup for incorrect h_size values used for the initial
umount record in old xfsprogs versions. Later commit 0c771b99d6c9
("xfs: clean up calculation of LR header blocks") cleaned up the log
reover buffer calculation, but stoped using the fixed up h_size value
to size the log recovery buffer, which can lead to an out of bounds
access when the incorrect h_size does not come from the old mkfs
tool, but a fuzzer.
Fix this by open coding xlog_logrec_hblks and taking the fixed h_size
into account for this calculation. |
["https://git.kernel.org/stable/c/45cf976008ddef4a9c9a30310c9b4fb2a9a6602a","https://git.kernel.org/stable/c/57835c0e7152e36b03875dd6c56dfeed685c1b1f","https://git.kernel.org/stable/c/c2389c074973aa94e34992e7f66dac0de37595b5","https://git.kernel.org/stable/c/f754591b17d0ee91c2b45fe9509d0cdc420527cb","https://git.kernel.org/stable/c/45cf976008ddef4a9c9a30310c9b4fb2a9a6602a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46772
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check denominator crb_pipes before used
[WHAT & HOW]
A denominator cannot be 0, and is checked before used.
This fixes 2 DIVIDE_BY_ZERO issues reported by Coverity. |
["https://git.kernel.org/stable/c/04805efe8623f8721f3c01182ea73d68e88c62d8","https://git.kernel.org/stable/c/b9264aa24f628eba5779d1c916441e0cedde9b3d","https://git.kernel.org/stable/c/ea79068d4073bf303f8203f2625af7d9185a1bc6","https://git.kernel.org/stable/c/ede06d23392529b039cf7ac11b5875b047900f1c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46823
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
kunit/overflow: Fix UB in overflow_allocation_test
The 'device_name' array doesn't exist out of the
'overflow_allocation_test' function scope. However, it is being used as
a driver name when calling 'kunit_driver_create' from
'kunit_device_register'. It produces the kernel panic with KASAN
enabled.
Since this variable is used in one place only, remove it and pass the
device name into kunit_device_register directly as an ascii string. |
["https://git.kernel.org/stable/c/92e9bac18124682c4b99ede9ee3bcdd68f121e92","https://git.kernel.org/stable/c/99ddb9c58511f1b71e23d02a06082bf6d2dd2133","https://git.kernel.org/stable/c/cacce7faa7c475cea55e82cc3a27794561fac157","https://git.kernel.org/stable/c/d1207f07decc66546a7fa463d2f335a856c986ef"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38559
|
Medium |
fixed |
- 4.19.316
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: qedf: Ensure the copied buf is NUL terminated
Currently, we allocate a count-sized kernel buffer and copy count from
userspace to that buffer. Later, we use kstrtouint on this buffer but we
don't ensure that the string is terminated inside the buffer, this can
lead to OOB read when using kstrtouint. Fix this issue by using
memdup_user_nul instead of memdup_user. |
["https://git.kernel.org/stable/c/177f43c6892e6055de6541fe9391a8a3d1f95fc9","https://git.kernel.org/stable/c/1f84a2744ad813be23fc4be99fb74bfb24aadb95","https://git.kernel.org/stable/c/4907f5ad246fa9b51093ed7dfc7da9ebbd3f20b8","https://git.kernel.org/stable/c/563e609275927c0b75fbfd0d90441543aa7b5e0d","https://git.kernel.org/stable/c/769b9fd2af02c069451fe9108dba73355d9a021c","https://git.kernel.org/stable/c/a75001678e1d38aa607d5b898ec7ff8ed0700d59","https://git.kernel.org/stable/c/d0184a375ee797eb657d74861ba0935b6e405c62","https://git.kernel.org/stable/c/d93318f19d1e1a6d5f04f5d965eaa9055bb7c613","https://git.kernel.org/stable/c/dccd97b39ab2f2b1b9a47a1394647a4d65815255","https://git.kernel.org/stable/c/177f43c6892e6055de6541fe9391a8a3d1f95fc9","https://git.kernel.org/stable/c/1f84a2744ad813be23fc4be99fb74bfb24aadb95","https://git.kernel.org/stable/c/4907f5ad246fa9b51093ed7dfc7da9ebbd3f20b8","https://git.kernel.org/stable/c/563e609275927c0b75fbfd0d90441543aa7b5e0d","https://git.kernel.org/stable/c/769b9fd2af02c069451fe9108dba73355d9a021c","https://git.kernel.org/stable/c/a75001678e1d38aa607d5b898ec7ff8ed0700d59","https://git.kernel.org/stable/c/d0184a375ee797eb657d74861ba0935b6e405c62","https://git.kernel.org/stable/c/d93318f19d1e1a6d5f04f5d965eaa9055bb7c613","https://git.kernel.org/stable/c/dccd97b39ab2f2b1b9a47a1394647a4d65815255"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46722
|
High |
fixed |
- 4.19.322
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.109
- 6.6.50
- 6.10.9
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix mc_data out-of-bounds read warning
Clear warning that read mc_data[i-1] may out-of-bounds. |
["https://git.kernel.org/stable/c/2097edede72ec5bb3869cf0205337d392fb2a553","https://git.kernel.org/stable/c/310b9d8363b88e818afec97ca7652bd7fe3d0650","https://git.kernel.org/stable/c/345bd3ad387f9e121aaad9c95957b80895e2f2ec","https://git.kernel.org/stable/c/51dfc0a4d609fe700750a62f41447f01b8c9ea50","https://git.kernel.org/stable/c/578ae965e8b90cd09edeb0252b50fa0503ea35c5","https://git.kernel.org/stable/c/5fa4df25ecfc7b6c9006f5b871c46cfe25ea8826","https://git.kernel.org/stable/c/b862a0bc5356197ed159fed7b1c647e77bc9f653","https://git.kernel.org/stable/c/d0a43bf367ed640e527e8ef3d53aac1e71f80114"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46723
|
High |
fixed |
- 4.19.322
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.109
- 6.6.50
- 6.10.9
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix ucode out-of-bounds read warning
Clear warning that read ucode[] may out-of-bounds. |
["https://git.kernel.org/stable/c/0bef65e069d84d1cd77ce757aea0e437b8e2bd33","https://git.kernel.org/stable/c/23fefef859c6057e6770584242bdd938254f8ddd","https://git.kernel.org/stable/c/5f09fa5e0ad45fbca71933a0e024ca52da47d59b","https://git.kernel.org/stable/c/82ac8f1d02886b5d8aeb9e058989d3bd6fc581e2","https://git.kernel.org/stable/c/8944acd0f9db33e17f387fdc75d33bb473d7936f","https://git.kernel.org/stable/c/8981927ebc6c12fa76b30c4178acb462bab15f54","https://git.kernel.org/stable/c/e789e05388854a5436b2b5d8695fdb864c9bcc27","https://git.kernel.org/stable/c/f2b7a9f3839e92f43559b2795b34640ca8cf839f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46743
|
High |
fixed |
- 4.19.322
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
of/irq: Prevent device address out-of-bounds read in interrupt map walk
When of_irq_parse_raw() is invoked with a device address smaller than
the interrupt parent node (from #address-cells property), KASAN detects
the following out-of-bounds read when populating the initial match table
(dyndbg="func of_irq_parse_* +p"):
OF: of_irq_parse_one: dev=/soc@0/picasso/watchdog, index=0
OF: parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2
OF: intspec=4
OF: of_irq_parse_raw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2
OF: -> addrsize=3
==================================================================
BUG: KASAN: slab-out-of-bounds in of_irq_parse_raw+0x2b8/0x8d0
Read of size 4 at addr ffffff81beca5608 by task bash/764
CPU: 1 PID: 764 Comm: bash Tainted: G O 6.1.67-484c613561-nokia_sm_arm64 #1
Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023
Call trace:
dump_backtrace+0xdc/0x130
show_stack+0x1c/0x30
dump_stack_lvl+0x6c/0x84
print_report+0x150/0x448
kasan_report+0x98/0x140
__asan_load4+0x78/0xa0
of_irq_parse_raw+0x2b8/0x8d0
of_irq_parse_one+0x24c/0x270
parse_interrupts+0xc0/0x120
of_fwnode_add_links+0x100/0x2d0
fw_devlink_parse_fwtree+0x64/0xc0
device_add+0xb38/0xc30
of_device_add+0x64/0x90
of_platform_device_create_pdata+0xd0/0x170
of_platform_bus_create+0x244/0x600
of_platform_notify+0x1b0/0x254
blocking_notifier_call_chain+0x9c/0xd0
__of_changeset_entry_notify+0x1b8/0x230
__of_changeset_apply_notify+0x54/0xe4
of_overlay_fdt_apply+0xc04/0xd94
...
The buggy address belongs to the object at ffffff81beca5600
which belongs to the cache kmalloc-128 of size 128
The buggy address is located 8 bytes inside of
128-byte region [ffffff81beca5600, ffffff81beca5680)
The buggy address belongs to the physical page:
page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4
head:00000000230d3d03 order:1 compound_mapcount:0 compound_pincount:0
flags: 0x8000000000010200(slab|head|zone=2)
raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300
raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc
==================================================================
OF: -> got it !
Prevent the out-of-bounds read by copying the device address into a
buffer of sufficient size. |
["https://git.kernel.org/stable/c/7ead730af11ee7da107f16fc77995613c58d292d","https://git.kernel.org/stable/c/8ff351ea12e918db1373b915c4c268815929cbe5","https://git.kernel.org/stable/c/9d1e9f0876b03d74d44513a0ed3ed15ef8f2fed5","https://git.kernel.org/stable/c/b739dffa5d570b411d4bdf4bb9b8dfd6b7d72305","https://git.kernel.org/stable/c/baaf26723beab3a04da578d3008be3544f83758f","https://git.kernel.org/stable/c/bf68acd840b6a5bfd3777e0d5aaa204db6b461a9","https://git.kernel.org/stable/c/d2a79494d8a5262949736fb2c3ac44d20a51b0d8","https://git.kernel.org/stable/c/defcaa426ba0bc89ffdafb799d2e50b52f74ffc4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46747
|
High |
fixed |
- 4.19.322
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
HID: cougar: fix slab-out-of-bounds Read in cougar_report_fixup
report_fixup for the Cougar 500k Gaming Keyboard was not verifying
that the report descriptor size was correct before accessing it |
["https://git.kernel.org/stable/c/30e9ce7cd5591be639b53595c95812f1a2afdfdc","https://git.kernel.org/stable/c/34185de73d74fdc90e8651cfc472bfea6073a13f","https://git.kernel.org/stable/c/48b2108efa205f4579052c27fba2b22cc6ad8aa0","https://git.kernel.org/stable/c/890dde6001b651be79819ef7a3f8c71fc8f9cabf","https://git.kernel.org/stable/c/a6e9c391d45b5865b61e569146304cff72821a5d","https://git.kernel.org/stable/c/e239e44dcd419b13cf840e2a3a833204e4329714","https://git.kernel.org/stable/c/e4a602a45aecd6a98b4b37482f5c9f8f67a32ddd","https://git.kernel.org/stable/c/fac3cb3c6428afe2207593a183b5bc4742529dfd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38538
|
High |
fixed |
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: xmit: make sure we have at least eth header len bytes
syzbot triggered an uninit value[1] error in bridge device's xmit path
by sending a short (less than ETH_HLEN bytes) skb. To fix it check if
we can actually pull that amount instead of assuming.
Tested with dropwatch:
drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3)
origin: software
timestamp: Mon May 13 11:31:53 2024 778214037 nsec
protocol: 0x88a8
length: 2
original length: 2
drop reason: PKT_TOO_SMALL
[1]
BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
__netdev_start_xmit include/linux/netdevice.h:4903 [inline]
netdev_start_xmit include/linux/netdevice.h:4917 [inline]
xmit_one net/core/dev.c:3531 [inline]
dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
__dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
__bpf_tx_skb net/core/filter.c:2136 [inline]
__bpf_redirect_common net/core/filter.c:2180 [inline]
__bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187
____bpf_clone_redirect net/core/filter.c:2460 [inline]
bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432
___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997
__bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238
bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]
__bpf_prog_run include/linux/filter.h:657 [inline]
bpf_prog_run include/linux/filter.h:664 [inline]
bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425
bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058
bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269
__sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678
__do_sys_bpf kernel/bpf/syscall.c:5767 [inline]
__se_sys_bpf kernel/bpf/syscall.c:5765 [inline]
__x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765
x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f |
["https://git.kernel.org/stable/c/1abb371147905ba250b4cc0230c4be7e90bea4d5","https://git.kernel.org/stable/c/28126b83f86ab9cc7936029c2dff845d3dcedba2","https://git.kernel.org/stable/c/3e01fc3c66e65d9afe98f1489047a1b2dd8741ca","https://git.kernel.org/stable/c/5b5d669f569807c7ab07546e73c0741845a2547a","https://git.kernel.org/stable/c/82090f94c723dab724b1c32db406091d40448a17","https://git.kernel.org/stable/c/8bd67ebb50c0145fd2ca8681ab65eb7e8cde1afc","https://git.kernel.org/stable/c/b2b7c43cd32080221bb233741bd6011983fe7c11","https://git.kernel.org/stable/c/c964429ef53f42098a6545a5dabeb1441c1e821d","https://git.kernel.org/stable/c/f482fd4ce919836a49012b2d31b00fc36e2488f2","https://git.kernel.org/stable/c/1abb371147905ba250b4cc0230c4be7e90bea4d5","https://git.kernel.org/stable/c/28126b83f86ab9cc7936029c2dff845d3dcedba2","https://git.kernel.org/stable/c/5b5d669f569807c7ab07546e73c0741845a2547a","https://git.kernel.org/stable/c/8bd67ebb50c0145fd2ca8681ab65eb7e8cde1afc","https://git.kernel.org/stable/c/f482fd4ce919836a49012b2d31b00fc36e2488f2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50036
|
High |
fixed |
- 3.11
- 3.13
- 3.15
- 3.16
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
net: do not delay dst_entries_add() in dst_release()
dst_entries_add() uses per-cpu data that might be freed at netns
dismantle from ip6_route_net_exit() calling dst_entries_destroy()
Before ip6_route_net_exit() can be called, we release all
the dsts associated with this netns, via calls to dst_release(),
which waits an rcu grace period before calling dst_destroy()
dst_entries_add() use in dst_destroy() is racy, because
dst_entries_destroy() could have been called already.
Decrementing the number of dsts must happen sooner.
Notes:
1) in CONFIG_XFRM case, dst_destroy() can call
dst_release_immediate(child), this might also cause UAF
if the child does not have DST_NOCOUNT set.
IPSEC maintainers might take a look and see how to address this.
2) There is also discussion about removing this count of dst,
which might happen in future kernels. |
["https://git.kernel.org/stable/c/3c7c918ec0aa3555372c5a57f18780b7a96c5cfc","https://git.kernel.org/stable/c/547087307bc19417b4f2bc85ba9664a3e8db5a6a","https://git.kernel.org/stable/c/a60db84f772fc3a906c6c4072f9207579c41166f","https://git.kernel.org/stable/c/ac888d58869bb99753e7652be19a151df9ecb35d","https://git.kernel.org/stable/c/e3915f028b1f1c37e87542e5aadd33728c259d96","https://git.kernel.org/stable/c/eae7435b48ffc8e9be0ff9cfeae40af479a609dd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42228
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc
Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001.
V2: To really improve the handling we would actually
need to have a separate value of 0xffffffff.(Christian) |
["https://git.kernel.org/stable/c/3b505759447637dcccb50cbd98ec6f8d2a04fc46","https://git.kernel.org/stable/c/855ae72c20310e5402b2317fc537d911e87537ef","https://git.kernel.org/stable/c/88a9a467c548d0b3c7761b4fd54a68e70f9c0944","https://git.kernel.org/stable/c/9ee1534ecdd5b4c013064663502d7fde824d2144","https://git.kernel.org/stable/c/d35cf41c8eb5d9fe95b21ae6ee2910f9ba4878e8","https://git.kernel.org/stable/c/da6a85d197888067e8d38b5d22c986b5b5cab712","https://git.kernel.org/stable/c/df02642c21c984303fe34c3f7d72965792fb1a15","https://git.kernel.org/stable/c/f8f120b3de48b8b6bdf8988a9b334c2d61c17440","https://git.kernel.org/stable/c/855ae72c20310e5402b2317fc537d911e87537ef","https://git.kernel.org/stable/c/88a9a467c548d0b3c7761b4fd54a68e70f9c0944","https://git.kernel.org/stable/c/f8f120b3de48b8b6bdf8988a9b334c2d61c17440"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42162
|
High |
|
N/A
|
In the Linux kernel, the following vulnerability has been resolved:
gve: Account for stopped queues when reading NIC stats
We now account for the fact that the NIC might send us stats for a
subset of queues. Without this change, gve_get_ethtool_stats might make
an invalid access on the priv->stats_report->stats array. |
["https://git.kernel.org/stable/c/32675d828c8a392e20d5b42375ed112c407e4b62","https://git.kernel.org/stable/c/af9bcf910b1f86244f39e15e701b2dc564b469a6","https://git.kernel.org/stable/c/32675d828c8a392e20d5b42375ed112c407e4b62","https://git.kernel.org/stable/c/af9bcf910b1f86244f39e15e701b2dc564b469a6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36899
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
gpiolib: cdev: Fix use after free in lineinfo_changed_notify
The use-after-free issue occurs as follows: when the GPIO chip device file
is being closed by invoking gpio_chrdev_release(), watched_lines is freed
by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier
chain failed due to waiting write rwsem. Additionally, one of the GPIO
chip's lines is also in the release process and holds the notifier chain's
read rwsem. Consequently, a race condition leads to the use-after-free of
watched_lines.
Here is the typical stack when issue happened:
[free]
gpio_chrdev_release()
--> bitmap_free(cdev->watched_lines) <-- freed
--> blocking_notifier_chain_unregister()
--> down_write(&nh->rwsem) <-- waiting rwsem
--> __down_write_common()
--> rwsem_down_write_slowpath()
--> schedule_preempt_disabled()
--> schedule()
[use]
st54spi_gpio_dev_release()
--> gpio_free()
--> gpiod_free()
--> gpiod_free_commit()
--> gpiod_line_state_notify()
--> blocking_notifier_call_chain()
--> down_read(&nh->rwsem); <-- held rwsem
--> notifier_call_chain()
--> lineinfo_changed_notify()
--> test_bit(xxxx, cdev->watched_lines) <-- use after free
The side effect of the use-after-free issue is that a GPIO line event is
being generated for userspace where it shouldn't. However, since the chrdev
is being closed, userspace won't have the chance to read that event anyway.
To fix the issue, call the bitmap_free() function after the unregistration
of lineinfo_changed_nb notifier chain. |
["https://git.kernel.org/stable/c/02f6b0e1ec7e0e7d059dddc893645816552039da","https://git.kernel.org/stable/c/2d008d4961b039d2edce8976289773961b7e5fb5","https://git.kernel.org/stable/c/2dfbb920a89bdc58087672ad5325dc6c588b6860","https://git.kernel.org/stable/c/95ca7c90eaf5ea8a8460536535101e3e81160e2a","https://git.kernel.org/stable/c/ca710b5f40b8b16fdcad50bebd47f50e4c62d239","https://git.kernel.org/stable/c/d38c49f7bdf14381270736299e2ff68ec248a017","https://git.kernel.org/stable/c/02f6b0e1ec7e0e7d059dddc893645816552039da","https://git.kernel.org/stable/c/95ca7c90eaf5ea8a8460536535101e3e81160e2a","https://git.kernel.org/stable/c/ca710b5f40b8b16fdcad50bebd47f50e4c62d239"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50286
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create
There is a race condition between ksmbd_smb2_session_create and
ksmbd_expire_session. This patch add missing sessions_table_lock
while adding/deleting session from global session table. |
["https://git.kernel.org/stable/c/0a77715db22611df50b178374c51e2ba0d58866e","https://git.kernel.org/stable/c/e7a2ad2044377853cf8c59528dac808a08a99c72","https://git.kernel.org/stable/c/e923503a56b3385b64ae492e3225e4623f560c5b","https://git.kernel.org/stable/c/f56446ba5378d19e31040b548a14ee9a8f1500ea"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26984
|
Medium |
fixed |
- 4.19.313
- 5.4.275
- 5.10.216
- 5.15.157
- 6.1.88
- 6.6.29
- 6.8.8
|
In the Linux kernel, the following vulnerability has been resolved:
nouveau: fix instmem race condition around ptr stores
Running a lot of VK CTS in parallel against nouveau, once every
few hours you might see something like this crash.
BUG: kernel NULL pointer dereference, address: 0000000000000008
PGD 8000000114e6e067 P4D 8000000114e6e067 PUD 109046067 PMD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 7 PID: 53891 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27
Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021
RIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nouveau]
Code: c7 48 01 c8 49 89 45 58 85 d2 0f 84 95 00 00 00 41 0f b7 46 12 49 8b 7e 08 89 da 42 8d 2c f8 48 8b 47 08 41 83 c7 01 48 89 ee <48> 8b 40 08 ff d0 0f 1f 00 49 8b 7e 08 48 89 d9 48 8d 75 04 48 c1
RSP: 0000:ffffac20c5857838 EFLAGS: 00010202
RAX: 0000000000000000 RBX: 00000000004d8001 RCX: 0000000000000001
RDX: 00000000004d8001 RSI: 00000000000006d8 RDI: ffffa07afe332180
RBP: 00000000000006d8 R08: ffffac20c5857ad0 R09: 0000000000ffff10
R10: 0000000000000001 R11: ffffa07af27e2de0 R12: 000000000000001c
R13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15: 000000000000001c
FS: 00007fe395eed7c0(0000) GS:ffffa07e2c980000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 000000011febe001 CR4: 00000000003706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
...
? gp100_vmm_pgt_mem+0xe3/0x180 [nouveau]
? gp100_vmm_pgt_mem+0x37/0x180 [nouveau]
nvkm_vmm_iter+0x351/0xa20 [nouveau]
? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau]
? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
? __lock_acquire+0x3ed/0x2170
? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
nvkm_vmm_ptes_get_map+0xc2/0x100 [nouveau]
? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau]
? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
nvkm_vmm_map_locked+0x224/0x3a0 [nouveau]
Adding any sort of useful debug usually makes it go away, so I hand
wrote the function in a line, and debugged the asm.
Every so often pt->memory->ptrs is NULL. This ptrs ptr is set in
the nv50_instobj_acquire called from nvkm_kmap.
If Thread A and Thread B both get to nv50_instobj_acquire around
the same time, and Thread A hits the refcount_set line, and in
lockstep thread B succeeds at refcount_inc_not_zero, there is a
chance the ptrs value won't have been stored since refcount_set
is unordered. Force a memory barrier here, I picked smp_mb, since
we want it on all CPUs and it's write followed by a read.
v2: use paired smp_rmb/smp_wmb. |
["https://git.kernel.org/stable/c/13d76b2f443dc371842916dd8768009ff1594716","https://git.kernel.org/stable/c/1bc4825d4c3ec6abe43cf06c3c39d664d044cbf7","https://git.kernel.org/stable/c/21ca9539f09360fd83654f78f2c361f2f5ddcb52","https://git.kernel.org/stable/c/3ab056814cd8ab84744c9a19ef51360b2271c572","https://git.kernel.org/stable/c/a019b44b1bc6ed224c46fb5f88a8a10dd116e525","https://git.kernel.org/stable/c/ad74d208f213c06d860916ad40f609ade8c13039","https://git.kernel.org/stable/c/bba8ec5e9b16649d85bc9e9086bf7ae5b5716ff9","https://git.kernel.org/stable/c/fff1386cc889d8fb4089d285f883f8cba62d82ce","https://git.kernel.org/stable/c/13d76b2f443dc371842916dd8768009ff1594716","https://git.kernel.org/stable/c/1bc4825d4c3ec6abe43cf06c3c39d664d044cbf7","https://git.kernel.org/stable/c/21ca9539f09360fd83654f78f2c361f2f5ddcb52","https://git.kernel.org/stable/c/3ab056814cd8ab84744c9a19ef51360b2271c572","https://git.kernel.org/stable/c/a019b44b1bc6ed224c46fb5f88a8a10dd116e525","https://git.kernel.org/stable/c/ad74d208f213c06d860916ad40f609ade8c13039","https://git.kernel.org/stable/c/bba8ec5e9b16649d85bc9e9086bf7ae5b5716ff9","https://git.kernel.org/stable/c/fff1386cc889d8fb4089d285f883f8cba62d82ce","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38589
|
Medium |
fixed |
- 4.19.316
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
netrom: fix possible dead-lock in nr_rt_ioctl()
syzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1]
Make sure we always acquire nr_node_list_lock before nr_node_lock(nr_node)
[1]
WARNING: possible circular locking dependency detected
6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted
------------------------------------------------------
syz-executor350/5129 is trying to acquire lock:
ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline]
ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline]
ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697
but task is already holding lock:
ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]
ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (nr_node_list_lock){+...}-{2:2}:
lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
_raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
spin_lock_bh include/linux/spinlock.h:356 [inline]
nr_remove_node net/netrom/nr_route.c:299 [inline]
nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355
nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683
sock_do_ioctl+0x158/0x460 net/socket.c:1222
sock_ioctl+0x629/0x8e0 net/socket.c:1341
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:904 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (&nr_node->node_lock){+...}-{2:2}:
check_prev_add kernel/locking/lockdep.c:3134 [inline]
check_prevs_add kernel/locking/lockdep.c:3253 [inline]
validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869
__lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137
lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
_raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
spin_lock_bh include/linux/spinlock.h:356 [inline]
nr_node_lock include/net/netrom.h:152 [inline]
nr_dec_obs net/netrom/nr_route.c:464 [inline]
nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697
sock_do_ioctl+0x158/0x460 net/socket.c:1222
sock_ioctl+0x629/0x8e0 net/socket.c:1341
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:904 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(nr_node_list_lock);
lock(&nr_node->node_lock);
lock(nr_node_list_lock);
lock(&nr_node->node_lock);
*** DEADLOCK ***
1 lock held by syz-executor350/5129:
#0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
#0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]
#0: ffffffff8f70
---truncated--- |
["https://git.kernel.org/stable/c/1fbfb483c1a290dce3f41f52d45cc46dd88b7691","https://git.kernel.org/stable/c/3db2fc45d1d2a6457f06ebdfd45b9820e5b5c2b7","https://git.kernel.org/stable/c/421c50fa81836775bf0fd6ce0e57a6eb27af24d5","https://git.kernel.org/stable/c/5bc50a705cfac8f64ce51c95611c3dd0554ef9c3","https://git.kernel.org/stable/c/5fb7e2a4335fc67d6952ad2a6613c46e0b05f7c5","https://git.kernel.org/stable/c/b117e5b4f27c2c9076561b6be450a9619f0b79de","https://git.kernel.org/stable/c/b9d663fbf74290cb68fbc66ae4367bd56837ad1d","https://git.kernel.org/stable/c/e03e7f20ebf7e1611d40d1fdc1bde900fd3335f6","https://git.kernel.org/stable/c/f28bdc2ee5d9300cc77bd3d97b5b3cdd14960fd8","https://git.kernel.org/stable/c/1fbfb483c1a290dce3f41f52d45cc46dd88b7691","https://git.kernel.org/stable/c/3db2fc45d1d2a6457f06ebdfd45b9820e5b5c2b7","https://git.kernel.org/stable/c/421c50fa81836775bf0fd6ce0e57a6eb27af24d5","https://git.kernel.org/stable/c/5bc50a705cfac8f64ce51c95611c3dd0554ef9c3","https://git.kernel.org/stable/c/5fb7e2a4335fc67d6952ad2a6613c46e0b05f7c5","https://git.kernel.org/stable/c/b117e5b4f27c2c9076561b6be450a9619f0b79de","https://git.kernel.org/stable/c/b9d663fbf74290cb68fbc66ae4367bd56837ad1d","https://git.kernel.org/stable/c/e03e7f20ebf7e1611d40d1fdc1bde900fd3335f6","https://git.kernel.org/stable/c/f28bdc2ee5d9300cc77bd3d97b5b3cdd14960fd8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42232
|
Medium |
fixed |
- 4.19.318
- 5.4.280
- 5.10.222
- 5.15.163
- 6.1.100
- 6.6.41
- 6.9.10
|
In the Linux kernel, the following vulnerability has been resolved:
libceph: fix race between delayed_work() and ceph_monc_stop()
The way the delayed work is handled in ceph_monc_stop() is prone to
races with mon_fault() and possibly also finish_hunting(). Both of
these can requeue the delayed work which wouldn't be canceled by any of
the following code in case that happens after cancel_delayed_work_sync()
runs -- __close_session() doesn't mess with the delayed work in order
to avoid interfering with the hunting interval logic. This part was
missed in commit b5d91704f53e ("libceph: behave in mon_fault() if
cur_mon < 0") and use-after-free can still ensue on monc and objects
that hang off of it, with monc->auth and monc->monmap being
particularly susceptible to quickly being reused.
To fix this:
- clear monc->cur_mon and monc->hunting as part of closing the session
in ceph_monc_stop()
- bail from delayed_work() if monc->cur_mon is cleared, similar to how
it's done in mon_fault() and finish_hunting() (based on monc->hunting)
- call cancel_delayed_work_sync() after the session is closed |
["https://git.kernel.org/stable/c/1177afeca833174ba83504688eec898c6214f4bf","https://git.kernel.org/stable/c/20cf67dcb7db842f941eff1af6ee5e9dc41796d7","https://git.kernel.org/stable/c/2d33654d40a05afd91ab24c9a73ab512a0670a9a","https://git.kernel.org/stable/c/33d38c5da17f8db2d80e811b7829d2822c10625e","https://git.kernel.org/stable/c/34b76d1922e41da1fa73d43b764cddd82ac9733c","https://git.kernel.org/stable/c/63e5d035e3a7ab7412a008f202633c5e6a0a28ea","https://git.kernel.org/stable/c/69c7b2fe4c9cc1d3b1186d1c5606627ecf0de883","https://git.kernel.org/stable/c/9525af1f58f67df387768770fcf6d6a8f23aee3d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-45010
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mptcp: pm: only mark 'subflow' endp as available
Adding the following warning ...
WARN_ON_ONCE(msk->pm.local_addr_used == 0)
... before decrementing the local_addr_used counter helped to find a bug
when running the "remove single address" subtest from the mptcp_join.sh
selftests.
Removing a 'signal' endpoint will trigger the removal of all subflows
linked to this endpoint via mptcp_pm_nl_rm_addr_or_subflow() with
rm_type == MPTCP_MIB_RMSUBFLOW. This will decrement the local_addr_used
counter, which is wrong in this case because this counter is linked to
'subflow' endpoints, and here it is a 'signal' endpoint that is being
removed.
Now, the counter is decremented, only if the ID is being used outside
of mptcp_pm_nl_rm_addr_or_subflow(), only for 'subflow' endpoints, and
if the ID is not 0 -- local_addr_used is not taking into account these
ones. This marking of the ID as being available, and the decrement is
done no matter if a subflow using this ID is currently available,
because the subflow could have been closed before. |
["https://git.kernel.org/stable/c/322ea3778965da72862cca2a0c50253aacf65fe6","https://git.kernel.org/stable/c/43cf912b0b0fc7b4fd12cbc735d1f5afb8e1322d","https://git.kernel.org/stable/c/7fdc870d08960961408a44c569f20f50940e7d4f","https://git.kernel.org/stable/c/9849cfc67383ceb167155186f8f8fe8a896b60b3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44995
|
Medium |
fixed |
- 5.4.283
- 5.10.225
- 5.15.166
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix a deadlock problem when config TC during resetting
When config TC during the reset process, may cause a deadlock, the flow is
as below:
pf reset start
│
▼
......
setup tc │
│ ▼
▼ DOWN: napi_disable()
napi_disable()(skip) │
│ │
▼ ▼
...... ......
│ │
▼ │
napi_enable() │
▼
UINIT: netif_napi_del()
│
▼
......
│
▼
INIT: netif_napi_add()
│
▼
...... global reset start
│ │
▼ ▼
UP: napi_enable()(skip) ......
│ │
▼ ▼
...... napi_disable()
In reset process, the driver will DOWN the port and then UINIT, in this
case, the setup tc process will UP the port before UINIT, so cause the
problem. Adds a DOWN process in UINIT to fix it. |
["https://git.kernel.org/stable/c/195918217448a6bb7f929d6a2ffffce9f1ece1cc","https://git.kernel.org/stable/c/67492d4d105c0a6321b00c393eec96b9a7a97a16","https://git.kernel.org/stable/c/6ae2b7d63cd056f363045eb65409143e16f23ae8","https://git.kernel.org/stable/c/be5e816d00a506719e9dbb1a9c861c5ced30a109","https://git.kernel.org/stable/c/de37408d5c26fc4a296a28a0c96dcb814219bfa1","https://git.kernel.org/stable/c/fa1d4de7265c370e673583ac8d1bd17d21826cd9","https://git.kernel.org/stable/c/fc250eca15bde34c4c8f806b9d88f55bd56a992c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48659
|
Medium |
fixed |
- 4.9.330
- 4.14.295
- 4.19.260
- 5.4.215
- 5.10.146
- 5.15.71
- 5.19.12
|
In the Linux kernel, the following vulnerability has been resolved:
mm/slub: fix to return errno if kmalloc() fails
In create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to
out-of-memory, if it fails, return errno correctly rather than
triggering panic via BUG_ON();
kernel BUG at mm/slub.c:5893!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Call trace:
sysfs_slab_add+0x258/0x260 mm/slub.c:5973
__kmem_cache_create+0x60/0x118 mm/slub.c:4899
create_cache mm/slab_common.c:229 [inline]
kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335
kmem_cache_create+0x1c/0x28 mm/slab_common.c:390
f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [inline]
f2fs_init_xattr_caches+0x78/0xb4 fs/f2fs/xattr.c:808
f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149
mount_bdev+0x1b8/0x210 fs/super.c:1400
f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512
legacy_get_tree+0x30/0x74 fs/fs_context.c:610
vfs_get_tree+0x40/0x140 fs/super.c:1530
do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040
path_mount+0x358/0x914 fs/namespace.c:3370
do_mount fs/namespace.c:3383 [inline]
__do_sys_mount fs/namespace.c:3591 [inline]
__se_sys_mount fs/namespace.c:3568 [inline]
__arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568 |
["https://git.kernel.org/stable/c/016b150992eebc32c4a18f783cf2bb6e2545a3d9","https://git.kernel.org/stable/c/02bcd951aa3c2cea95fb241c20802e9501940296","https://git.kernel.org/stable/c/2d6e55e0c03804e1e227b80a5746e086d6c6696c","https://git.kernel.org/stable/c/379ac7905ff3f0a6a4e507d3e9f710ec4fab9124","https://git.kernel.org/stable/c/7e9c323c52b379d261a72dc7bd38120a761a93cd","https://git.kernel.org/stable/c/a1d83a19cec3bfeb2b3547a1f7631e432a766d1c","https://git.kernel.org/stable/c/e9219fa63c5c25804af82c7aa54d1ec770ebe457","https://git.kernel.org/stable/c/e996821717c5cf8aa1e1abdb6b3d900a231e3755","https://git.kernel.org/stable/c/016b150992eebc32c4a18f783cf2bb6e2545a3d9","https://git.kernel.org/stable/c/02bcd951aa3c2cea95fb241c20802e9501940296","https://git.kernel.org/stable/c/2d6e55e0c03804e1e227b80a5746e086d6c6696c","https://git.kernel.org/stable/c/379ac7905ff3f0a6a4e507d3e9f710ec4fab9124","https://git.kernel.org/stable/c/7e9c323c52b379d261a72dc7bd38120a761a93cd","https://git.kernel.org/stable/c/a1d83a19cec3bfeb2b3547a1f7631e432a766d1c","https://git.kernel.org/stable/c/e9219fa63c5c25804af82c7aa54d1ec770ebe457","https://git.kernel.org/stable/c/e996821717c5cf8aa1e1abdb6b3d900a231e3755"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39484
|
Medium |
fixed |
- 2.6.33
- 5.10.221
- 5.15.162
- 6.1.95
- 6.6.34
- 6.9.5
|
In the Linux kernel, the following vulnerability has been resolved:
mmc: davinci: Don't strip remove function when driver is builtin
Using __exit for the remove function results in the remove callback being
discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g.
using sysfs or hotplug), the driver is just removed without the cleanup
being performed. This results in resource leaks. Fix it by compiling in the
remove callback unconditionally.
This also fixes a W=1 modpost warning:
WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in
reference: davinci_mmcsd_driver+0x10 (section: .data) ->
davinci_mmcsd_remove (section: .exit.text) |
["https://git.kernel.org/stable/c/1d5ed0efe51d36b9ae9b64f133bf41cdbf56f584","https://git.kernel.org/stable/c/55c421b364482b61c4c45313a535e61ed5ae4ea3","https://git.kernel.org/stable/c/5ee241f72edc6dce5051a5f100eab6cc019d873e","https://git.kernel.org/stable/c/6ff7cfa02baabec907f6f29ea76634e6256d2ec4","https://git.kernel.org/stable/c/7590da4c04dd4aa9c262da0231e978263861c6eb","https://git.kernel.org/stable/c/aea35157bb9b825faa0432bd0f7fbea37ff39aa1","https://git.kernel.org/stable/c/1d5ed0efe51d36b9ae9b64f133bf41cdbf56f584","https://git.kernel.org/stable/c/55c421b364482b61c4c45313a535e61ed5ae4ea3","https://git.kernel.org/stable/c/5ee241f72edc6dce5051a5f100eab6cc019d873e","https://git.kernel.org/stable/c/6ff7cfa02baabec907f6f29ea76634e6256d2ec4","https://git.kernel.org/stable/c/7590da4c04dd4aa9c262da0231e978263861c6eb","https://git.kernel.org/stable/c/aea35157bb9b825faa0432bd0f7fbea37ff39aa1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40932
|
Medium |
fixed |
- 4.19.317
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.95
- 6.6.35
- 6.9.6
|
In the Linux kernel, the following vulnerability has been resolved:
drm/exynos/vidi: fix memory leak in .get_modes()
The duplicated EDID is never freed. Fix it. |
["https://git.kernel.org/stable/c/0acc356da8546b5c55aabfc2e2c5caa0ac9b0003","https://git.kernel.org/stable/c/38e3825631b1f314b21e3ade00b5a4d737eb054e","https://git.kernel.org/stable/c/540ca99729e28dbe902b01039a3b4bd74520a819","https://git.kernel.org/stable/c/777838c9b571674ef14dbddf671f372265879226","https://git.kernel.org/stable/c/a269c5701244db2722ae0fce5d1854f5d8f31224","https://git.kernel.org/stable/c/cb3ac233434dba130281db330c4b15665b2d2c4d","https://git.kernel.org/stable/c/dcba6bedb439581145d8aa6b0925209f23184ae1","https://git.kernel.org/stable/c/ebcf81504fef03f701b9711e43fea4fe2d82ebc8","https://git.kernel.org/stable/c/0acc356da8546b5c55aabfc2e2c5caa0ac9b0003","https://git.kernel.org/stable/c/38e3825631b1f314b21e3ade00b5a4d737eb054e","https://git.kernel.org/stable/c/540ca99729e28dbe902b01039a3b4bd74520a819","https://git.kernel.org/stable/c/777838c9b571674ef14dbddf671f372265879226","https://git.kernel.org/stable/c/a269c5701244db2722ae0fce5d1854f5d8f31224","https://git.kernel.org/stable/c/cb3ac233434dba130281db330c4b15665b2d2c4d","https://git.kernel.org/stable/c/dcba6bedb439581145d8aa6b0925209f23184ae1","https://git.kernel.org/stable/c/ebcf81504fef03f701b9711e43fea4fe2d82ebc8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27043
|
High |
fixed |
- 4.19.311
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
media: edia: dvbdev: fix a use-after-free
In dvb_register_device, *pdvbdev is set equal to dvbdev, which is freed
in several error-handling paths. However, *pdvbdev is not set to NULL
after dvbdev's deallocation, causing use-after-frees in many places,
for example, in the following call chain:
budget_register
|-> dvb_dmxdev_init
|-> dvb_register_device
|-> dvb_dmxdev_release
|-> dvb_unregister_device
|-> dvb_remove_device
|-> dvb_device_put
|-> kref_put
When calling dvb_unregister_device, dmxdev->dvbdev (i.e. *pdvbdev in
dvb_register_device) could point to memory that had been freed in
dvb_register_device. Thereafter, this pointer is transferred to
kref_put and triggering a use-after-free. |
["https://git.kernel.org/stable/c/096237039d00c839f3e3a5fe6d001bf0db45b644","https://git.kernel.org/stable/c/0d3fe80b6d175c220b3e252efc6c6777e700e98e","https://git.kernel.org/stable/c/35674111a043b0482a9bc69da8850a83f465b07d","https://git.kernel.org/stable/c/437a111f79a2f5b2a5f21e27fdec6f40c8768712","https://git.kernel.org/stable/c/779e8db7efb22316c8581d6c229636d2f5694a62","https://git.kernel.org/stable/c/8c64f4cdf4e6cc5682c52523713af8c39c94e6d5","https://git.kernel.org/stable/c/b7586e902128e4fb7bfbb661cb52e4215a65637b","https://git.kernel.org/stable/c/d0f5c28333822f9baa5280d813124920720fd856","https://git.kernel.org/stable/c/f20c3270f3ed5aa6919a87e4de9bf6c05fb57086","https://git.kernel.org/stable/c/096237039d00c839f3e3a5fe6d001bf0db45b644","https://git.kernel.org/stable/c/0d3fe80b6d175c220b3e252efc6c6777e700e98e","https://git.kernel.org/stable/c/35674111a043b0482a9bc69da8850a83f465b07d","https://git.kernel.org/stable/c/437a111f79a2f5b2a5f21e27fdec6f40c8768712","https://git.kernel.org/stable/c/779e8db7efb22316c8581d6c229636d2f5694a62","https://git.kernel.org/stable/c/8c64f4cdf4e6cc5682c52523713af8c39c94e6d5","https://git.kernel.org/stable/c/b7586e902128e4fb7bfbb661cb52e4215a65637b","https://git.kernel.org/stable/c/d0f5c28333822f9baa5280d813124920720fd856","https://git.kernel.org/stable/c/f20c3270f3ed5aa6919a87e4de9bf6c05fb57086","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48913
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
blktrace: fix use after free for struct blk_trace
When tracing the whole disk, 'dropped' and 'msg' will be created
under 'q->debugfs_dir' and 'bt->dir' is NULL, thus blk_trace_free()
won't remove those files. What's worse, the following UAF can be
triggered because of accessing stale 'dropped' and 'msg':
==================================================================
BUG: KASAN: use-after-free in blk_dropped_read+0x89/0x100
Read of size 4 at addr ffff88816912f3d8 by task blktrace/1188
CPU: 27 PID: 1188 Comm: blktrace Not tainted 5.17.0-rc4-next-20220217+ #469
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-4
Call Trace:
<TASK>
dump_stack_lvl+0x34/0x44
print_address_description.constprop.0.cold+0xab/0x381
? blk_dropped_read+0x89/0x100
? blk_dropped_read+0x89/0x100
kasan_report.cold+0x83/0xdf
? blk_dropped_read+0x89/0x100
kasan_check_range+0x140/0x1b0
blk_dropped_read+0x89/0x100
? blk_create_buf_file_callback+0x20/0x20
? kmem_cache_free+0xa1/0x500
? do_sys_openat2+0x258/0x460
full_proxy_read+0x8f/0xc0
vfs_read+0xc6/0x260
ksys_read+0xb9/0x150
? vfs_write+0x3d0/0x3d0
? fpregs_assert_state_consistent+0x55/0x60
? exit_to_user_mode_prepare+0x39/0x1e0
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7fbc080d92fd
Code: ce 20 00 00 75 10 b8 00 00 00 00 0f 05 48 3d 01 f0 ff ff 73 31 c3 48 83 1
RSP: 002b:00007fbb95ff9cb0 EFLAGS: 00000293 ORIG_RAX: 0000000000000000
RAX: ffffffffffffffda RBX: 00007fbb95ff9dc0 RCX: 00007fbc080d92fd
RDX: 0000000000000100 RSI: 00007fbb95ff9cc0 RDI: 0000000000000045
RBP: 0000000000000045 R08: 0000000000406299 R09: 00000000fffffffd
R10: 000000000153afa0 R11: 0000000000000293 R12: 00007fbb780008c0
R13: 00007fbb78000938 R14: 0000000000608b30 R15: 00007fbb780029c8
</TASK>
Allocated by task 1050:
kasan_save_stack+0x1e/0x40
__kasan_kmalloc+0x81/0xa0
do_blk_trace_setup+0xcb/0x410
__blk_trace_setup+0xac/0x130
blk_trace_ioctl+0xe9/0x1c0
blkdev_ioctl+0xf1/0x390
__x64_sys_ioctl+0xa5/0xe0
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
Freed by task 1050:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
kasan_set_free_info+0x20/0x30
__kasan_slab_free+0x103/0x180
kfree+0x9a/0x4c0
__blk_trace_remove+0x53/0x70
blk_trace_ioctl+0x199/0x1c0
blkdev_common_ioctl+0x5e9/0xb30
blkdev_ioctl+0x1a5/0x390
__x64_sys_ioctl+0xa5/0xe0
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
The buggy address belongs to the object at ffff88816912f380
which belongs to the cache kmalloc-96 of size 96
The buggy address is located 88 bytes inside of
96-byte region [ffff88816912f380, ffff88816912f3e0)
The buggy address belongs to the page:
page:000000009a1b4e7c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0f
flags: 0x17ffffc0000200(slab|node=0|zone=2|lastcpupid=0x1fffff)
raw: 0017ffffc0000200 ffffea00044f1100 dead000000000002 ffff88810004c780
raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88816912f280: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
ffff88816912f300: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
>ffff88816912f380: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
^
ffff88816912f400: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
ffff88816912f480: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
================================================================== |
["https://git.kernel.org/stable/c/30939293262eb433c960c4532a0d59c4073b2b84","https://git.kernel.org/stable/c/6418634238ade86f2b08192928787f39d8afb58c","https://git.kernel.org/stable/c/78acc7dbd84a8c173a08584750845c31611160f2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57979
|
High |
fixed |
- 3.3
- 3.5
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.129
- 6.6.76
- 6.12.13
- 6.13.2
|
In the Linux kernel, the following vulnerability has been resolved:
pps: Fix a use-after-free
On a board running ntpd and gpsd, I'm seeing a consistent use-after-free
in sys_exit() from gpsd when rebooting:
pps pps1: removed
------------[ cut here ]------------
kobject: '(null)' (00000000db4bec24): is not initialized, yet kobject_put() is being called.
WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150
CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1
Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : kobject_put+0x120/0x150
lr : kobject_put+0x120/0x150
sp : ffffffc0803d3ae0
x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001
x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440
x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600
x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20
x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
Call trace:
kobject_put+0x120/0x150
cdev_put+0x20/0x3c
__fput+0x2c4/0x2d8
____fput+0x1c/0x38
task_work_run+0x70/0xfc
do_exit+0x2a0/0x924
do_group_exit+0x34/0x90
get_signal+0x7fc/0x8c0
do_signal+0x128/0x13b4
do_notify_resume+0xdc/0x160
el0_svc+0xd4/0xf8
el0t_64_sync_handler+0x140/0x14c
el0t_64_sync+0x190/0x194
---[ end trace 0000000000000000 ]---
...followed by more symptoms of corruption, with similar stacks:
refcount_t: underflow; use-after-free.
kernel BUG at lib/list_debug.c:62!
Kernel panic - not syncing: Oops - BUG: Fatal exception
This happens because pps_device_destruct() frees the pps_device with the
embedded cdev immediately after calling cdev_del(), but, as the comment
above cdev_del() notes, fops for previously opened cdevs are still
callable even after cdev_del() returns. I think this bug has always
been there: I can't explain why it suddenly started happening every time
I reboot this particular board.
In commit d953e0e837e6 ("pps: Fix a use-after free bug when
unregistering a source."), George Spelvin suggested removing the
embedded cdev. That seems like the simplest way to fix this, so I've
implemented his suggestion, using __register_chrdev() with pps_idr
becoming the source of truth for which minor corresponds to which
device.
But now that pps_idr defines userspace visibility instead of cdev_add(),
we need to be sure the pps->dev refcount can't reach zero while
userspace can still find it again. So, the idr_remove() call moves to
pps_unregister_cdev(), and pps_idr now holds a reference to pps->dev.
pps_core: source serial1 got cdev (251:1)
<...>
pps pps1: removed
pps_core: unregistering pps1
pps_core: deallocating pps1 |
["https://git.kernel.org/stable/c/1a7735ab2cb9747518a7416fb5929e85442dec62","https://git.kernel.org/stable/c/785c78ed0d39d1717cca3ef931d3e51337b5e90e","https://git.kernel.org/stable/c/7e5ee3281dc09014367f5112b6d566ba36ea2d49","https://git.kernel.org/stable/c/85241f7de216f8298f6e48540ea13d7dcd100870","https://git.kernel.org/stable/c/91932db1d96b2952299ce30c1c693d834d10ace6","https://git.kernel.org/stable/c/c4041b6b0a7a3def8cf3f3d6120ff337bc4c40f7","https://git.kernel.org/stable/c/c79a39dc8d060b9e64e8b0fa9d245d44befeefbe","https://git.kernel.org/stable/c/cd3bbcb6b3a7caa5ce67de76723b6d8531fb7f64"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46814
|
High |
fixed |
- 5.10.226
- 5.15.167
- 6.1.109
- 6.6.50
- 6.10.9
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check msg_id before processing transcation
[WHY & HOW]
HDCP_MESSAGE_ID_INVALID (-1) is not a valid msg_id nor is it a valid
array index, and it needs checking before used.
This fixes 4 OVERRUN issues reported by Coverity. |
["https://git.kernel.org/stable/c/0147505f08220c89b3a9c90eb608191276e263a8","https://git.kernel.org/stable/c/6590643c5de74098d27933b7d224d5ac065d7755","https://git.kernel.org/stable/c/916083054670060023d3f8a8ace895d710e268f4","https://git.kernel.org/stable/c/cb63090a17d3abb87f132851fa3711281249b7d2","https://git.kernel.org/stable/c/fa71face755e27dc44bc296416ebdf2c67163316","https://git.kernel.org/stable/c/fe63daf7b10253b0faaa60c55d6153cd276927aa"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46818
|
High |
fixed |
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.109
- 6.6.50
- 6.10.9
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check gpio_id before used as array index
[WHY & HOW]
GPIO_ID_UNKNOWN (-1) is not a valid value for array index and therefore
should be checked in advance.
This fixes 5 OVERRUN issues reported by Coverity. |
["https://git.kernel.org/stable/c/0184cca30cad74d88f5c875d4e26999e26325700","https://git.kernel.org/stable/c/08e7755f754e3d2cef7d3a7da538d33526bd6f7c","https://git.kernel.org/stable/c/276e3fd93e3beb5894eb1cc8480f9f417d51524d","https://git.kernel.org/stable/c/2a5626eeb3b5eec7a36886f9556113dd93ec8ed6","https://git.kernel.org/stable/c/3d4198ab612ad48f73383ad3bb5663e6f0cdf406","https://git.kernel.org/stable/c/40c2e8bc117cab8bca8814735f28a8b121654a84","https://git.kernel.org/stable/c/8520fdc8ecc38f240a8e9e7af89cca6739c3e790"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46821
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: Fix negative array index read
Avoid using the negative values
for clk_idex as an index into an array pptable->DpmDescriptor.
V2: fix clk_index return check (Tim Huang) |
["https://git.kernel.org/stable/c/06a3810010b525b9958424e344f0c25b09e128fa","https://git.kernel.org/stable/c/4711b1347cb9f0c3083da6d87c624d75f9bd1d50","https://git.kernel.org/stable/c/60f4a4bc3329e5cb8c4df0cc961f0d5ffd96e22d","https://git.kernel.org/stable/c/befd1dc693c98bad69a701ede3a298698f0f9436","https://git.kernel.org/stable/c/c8c19ebf7c0b202a6a2d37a52ca112432723db5f","https://git.kernel.org/stable/c/e549cd6da1f21c34ba0f65adeca6a8aa9860b381"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26934
|
High |
fixed |
- 4.19.312
- 5.4.274
- 5.10.215
- 5.15.154
- 6.1.84
- 6.6.24
- 6.7.12
- 6.8.3
|
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix deadlock in usb_deauthorize_interface()
Among the attribute file callback routines in
drivers/usb/core/sysfs.c, the interface_authorized_store() function is
the only one which acquires a device lock on an ancestor device: It
calls usb_deauthorize_interface(), which locks the interface's parent
USB device.
The will lead to deadlock if another process already owns that lock
and tries to remove the interface, whether through a configuration
change or because the device has been disconnected. As part of the
removal procedure, device_del() waits for all ongoing sysfs attribute
callbacks to complete. But usb_deauthorize_interface() can't complete
until the device lock has been released, and the lock won't be
released until the removal has finished.
The mechanism provided by sysfs to prevent this kind of deadlock is
to use the sysfs_break_active_protection() function, which tells sysfs
not to wait for the attribute callback.
Reported-and-tested by: Yue Sun <samsun1006219@gmail.com>
Reported by: xingwei lee <xrivendell7@gmail.com> |
["https://git.kernel.org/stable/c/07acf979da33c721357ff27129edf74c23c036c6","https://git.kernel.org/stable/c/122a06f1068bf5e39089863f4f60b1f5d4273384","https://git.kernel.org/stable/c/12d6a5681a0a5cecc2af7860f0a1613fa7c6e947","https://git.kernel.org/stable/c/1b175bc579f46520b11ecda443bcd2ee4904f66a","https://git.kernel.org/stable/c/80ba43e9f799cbdd83842fc27db667289b3150f5","https://git.kernel.org/stable/c/8cbdd324b41528994027128207fae8100dff094f","https://git.kernel.org/stable/c/ab062fa3dc69aea88fe62162c5881ba14b50ecc5","https://git.kernel.org/stable/c/dbdf66250d2d33e8b27352fcb901de79f3521057","https://git.kernel.org/stable/c/e451709573f8be904a8a72d0775bf114d7c291d9","https://git.kernel.org/stable/c/07acf979da33c721357ff27129edf74c23c036c6","https://git.kernel.org/stable/c/122a06f1068bf5e39089863f4f60b1f5d4273384","https://git.kernel.org/stable/c/12d6a5681a0a5cecc2af7860f0a1613fa7c6e947","https://git.kernel.org/stable/c/1b175bc579f46520b11ecda443bcd2ee4904f66a","https://git.kernel.org/stable/c/80ba43e9f799cbdd83842fc27db667289b3150f5","https://git.kernel.org/stable/c/8cbdd324b41528994027128207fae8100dff094f","https://git.kernel.org/stable/c/ab062fa3dc69aea88fe62162c5881ba14b50ecc5","https://git.kernel.org/stable/c/dbdf66250d2d33e8b27352fcb901de79f3521057","https://git.kernel.org/stable/c/e451709573f8be904a8a72d0775bf114d7c291d9","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50264
|
High |
fixed |
- 4.19.324
- 5.4.286
- 5.10.230
- 5.15.172
- 6.1.117
- 6.6.61
- 6.11.8
|
In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans
During loopback communication, a dangling pointer can be created in
vsk->trans, potentially leading to a Use-After-Free condition. This
issue is resolved by initializing vsk->trans to NULL. |
["https://git.kernel.org/stable/c/2a6a4e69f255b7aed17f93995691ab4f0d3c2203","https://git.kernel.org/stable/c/44d29897eafd0e1196453d3003a4d5e0b968eeab","https://git.kernel.org/stable/c/5f092a4271f6dccf88fe0d132475a17b69ef71df","https://git.kernel.org/stable/c/5f970935d09934222fdef3d0e20c648ea7a963c1","https://git.kernel.org/stable/c/6ca575374dd9a507cdd16dfa0e78c2e9e20bd05f","https://git.kernel.org/stable/c/b110196fec44fe966952004bd426967c2a8fd358","https://git.kernel.org/stable/c/eb1bdcb7dfc30b24495ee4c5533af0ed135cb5f1","https://git.kernel.org/stable/c/fd8ae346692a56b4437d626c5460c7104980f389"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49577
|
Medium |
fixed |
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
udp: Fix a data-race around sysctl_udp_l3mdev_accept.
While reading sysctl_udp_l3mdev_accept, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its reader. |
["https://git.kernel.org/stable/c/3d72bb4188c708bb16758c60822fc4dda7a95174","https://git.kernel.org/stable/c/3f2ac2d6511bb0652abf4d7388d65bb9ff1c641c","https://git.kernel.org/stable/c/cb0d28934ca10f99c47e2c6f451405d6c954fe48","https://git.kernel.org/stable/c/f39b03bd727a8fea62e82f10fe2e0d753b9930ff","https://git.kernel.org/stable/c/fcaef69c79ec222e55643e666b80b221e70fa6a8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49580
|
Medium |
fixed |
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
ipv4: Fix a data-race around sysctl_fib_multipath_use_neigh.
While reading sysctl_fib_multipath_use_neigh, it can be changed
concurrently. Thus, we need to add READ_ONCE() to its reader. |
["https://git.kernel.org/stable/c/14e996577ed2799a1ed6ffeb71c76d63acb28444","https://git.kernel.org/stable/c/6727f39e99e0f545d815edebb6c94228485427ec","https://git.kernel.org/stable/c/87507bcb4f5de16bb419e9509d874f4db6c0ad0f","https://git.kernel.org/stable/c/b8d345db03b4deffb4f04219a51d3b1e94171b76","https://git.kernel.org/stable/c/e045d672ba06e1d35bacb56374d350de0ac99066"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49594
|
Medium |
fixed |
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix a data-race around sysctl_tcp_mtu_probe_floor.
While reading sysctl_tcp_mtu_probe_floor, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its reader. |
["https://git.kernel.org/stable/c/033963b220633ed1602d458e7e4ac06afa9fefb2","https://git.kernel.org/stable/c/8e92d4423615a5257d0d871fc067aa561f597deb","https://git.kernel.org/stable/c/cc36c37f5fe066c4708e623ead96dc8f57224bf5","https://git.kernel.org/stable/c/d5bece4df6090395f891110ef52a6f82d16685db","https://git.kernel.org/stable/c/e2ecbf3f0aa88277d43908c53b99399d55729ff9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2017-1000255
|
Medium |
|
N/A
|
On Linux running on PowerPC hardware (Power8 or later) a user process can craft a signal frame and then do a sigreturn so that the kernel will take an exception (interrupt), and use the r1 value *from the signal frame* as the kernel stack pointer. As part of the exception entry the content of the signal frame is written to the kernel stack, allowing an attacker to overwrite arbitrary locations with arbitrary values. The exception handling does produce an oops, and a panic if panic_on_oops=1, but only after kernel memory has been over written. This flaw was introduced in commit: "5d176f751ee3 (powerpc: tm: Enable transactional memory (TM) lazily for userspace)" which was merged upstream into v4.9-rc1. Please note that kernels built with CONFIG_PPC_TRANSACTIONAL_MEM=n are not vulnerable. |
["http://www.securityfocus.com/bid/101264","https://access.redhat.com/errata/RHSA-2018:0654","https://access.redhat.com/security/cve/CVE-2017-1000255","http://www.securityfocus.com/bid/101264","https://access.redhat.com/errata/RHSA-2018:0654","https://access.redhat.com/security/cve/CVE-2017-1000255"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49934
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name
It's observed that a crash occurs during hot-remove a memory device,
in which user is accessing the hugetlb. See calltrace as following:
------------[ cut here ]------------
WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790
Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s
mirror dm_region_hash dm_log dm_mod
CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
RIP: 0010:do_user_addr_fault+0x2a0/0x790
Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41
RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046
RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658
R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000
FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
? __warn+0x8d/0x190
? do_user_addr_fault+0x2a0/0x790
? report_bug+0x1c3/0x1d0
? handle_bug+0x3c/0x70
? exc_invalid_op+0x14/0x70
? asm_exc_invalid_op+0x16/0x20
? do_user_addr_fault+0x2a0/0x790
? exc_page_fault+0x31/0x200
exc_page_fault+0x68/0x200
<...snip...>
BUG: unable to handle page fault for address: 0000000000001000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0
Oops: Oops: 0000 [#1] PREEMPT SMP PTI
---[ end trace 0000000000000000 ]---
BUG: unable to handle page fault for address: 0000000000001000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0
Oops: Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
RIP: 0010:dentry_name+0x1f4/0x440
<...snip...>
? dentry_name+0x2fa/0x440
vsnprintf+0x1f3/0x4f0
vprintk_store+0x23a/0x540
vprintk_emit+0x6d/0x330
_printk+0x58/0x80
dump_mapping+0x10b/0x1a0
? __pfx_free_object_rcu+0x10/0x10
__dump_page+0x26b/0x3e0
? vprintk_emit+0xe0/0x330
? _printk+0x58/0x80
? dump_page+0x17/0x50
dump_page+0x17/0x50
do_migrate_range+0x2f7/0x7f0
? do_migrate_range+0x42/0x7f0
? offline_pages+0x2f4/0x8c0
offline_pages+0x60a/0x8c0
memory_subsys_offline+0x9f/0x1c0
? lockdep_hardirqs_on+0x77/0x100
? _raw_spin_unlock_irqrestore+0x38/0x60
device_offline+0xe3/0x110
state_store+0x6e/0xc0
kernfs_fop_write_iter+0x143/0x200
vfs_write+0x39f/0x560
ksys_write+0x65/0xf0
do_syscall_64+0x62/0x130
Previously, some sanity check have been done in dump_mapping() before
the print facility parsing '%pd' though, it's still possible to run into
an invalid dentry.d_name.name.
Since dump_mapping() only needs to dump the filename only, retrieve it
by itself in a safer way to prevent an unnecessary crash.
Note that either retrieving the filename with '%pd' or
strncpy_from_kernel_nofault(), the filename could be unreliable. |
["https://git.kernel.org/stable/c/1a4159138e718db6199f0abf376ad52f726dcc5c","https://git.kernel.org/stable/c/7f7b850689ac06a62befe26e1fd1806799e7f152","https://git.kernel.org/stable/c/e0f6ee75f50476607ca82fc7c3711c795ce09b52","https://git.kernel.org/stable/c/ef921bc72328b577cb45772ff7921cba4773b74a","https://git.kernel.org/stable/c/f92b8829c6e75632de4e2b9f70e7a7e6c5c2ba98"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49861
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix helper writes to read-only maps
Lonial found an issue that despite user- and BPF-side frozen BPF map
(like in case of .rodata), it was still possible to write into it from
a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT}
as arguments.
In check_func_arg() when the argument is as mentioned, the meta->raw_mode
is never set. Later, check_helper_mem_access(), under the case of
PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the
subsequent call to check_map_access_type() and given the BPF map is
read-only it succeeds.
The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT
when results are written into them as opposed to read out of them. The
latter indicates that it's okay to pass a pointer to uninitialized memory
as the memory is written to anyway.
However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM
just with additional alignment requirement. So it is better to just get
rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the
fixed size memory types. For this, add MEM_ALIGNED to additionally ensure
alignment given these helpers write directly into the args via *<ptr> = val.
The .arg*_size has been initialized reflecting the actual sizeof(*<ptr>).
MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated
argument types, since in !MEM_FIXED_SIZE cases the verifier does not know
the buffer size a priori and therefore cannot blindly write *<ptr> = val. |
["https://git.kernel.org/stable/c/1e75d25133158b525e0456876e9bcfd6b2993fd5","https://git.kernel.org/stable/c/2ed98ee02d1e08afee88f54baec39ea78dc8a23c","https://git.kernel.org/stable/c/32556ce93bc45c730829083cb60f95a2728ea48b","https://git.kernel.org/stable/c/988e55abcf7fdb8fc9a76a7cf3f4e939a4d4fb3a","https://git.kernel.org/stable/c/a2c8dc7e21803257e762b0bf067fd13e9c995da0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47757
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential oob read in nilfs_btree_check_delete()
The function nilfs_btree_check_delete(), which checks whether degeneration
to direct mapping occurs before deleting a b-tree entry, causes memory
access outside the block buffer when retrieving the maximum key if the
root node has no entries.
This does not usually happen because b-tree mappings with 0 child nodes
are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen
if the b-tree root node read from a device is configured that way, so fix
this potential issue by adding a check for that case. |
["https://git.kernel.org/stable/c/257f9e5185eb6de83377caea686c306e22e871f2","https://git.kernel.org/stable/c/a33e967b681e088a125b979975c93e3453e686cd","https://git.kernel.org/stable/c/a8abfda768b9f33630cfbc4af6c4214f1e5681b0","https://git.kernel.org/stable/c/c4cbcc64bb31e67e02940ce060cc77f7180564cf","https://git.kernel.org/stable/c/c4f8554996e8ada3be872dfb8f60e93bcf15fb27","https://git.kernel.org/stable/c/d20674f31626e0596ae4c1d9401dfb6739b81b58","https://git.kernel.org/stable/c/ed76d381dae125b81d09934e365391a656249da8","https://git.kernel.org/stable/c/f3a9859767c7aea758976f5523903d247e585129","https://git.kernel.org/stable/c/f9c96351aa6718b42a9f42eaf7adce0356bdb5e8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49860
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
ACPI: sysfs: validate return type of _STR method
Only buffer objects are valid return values of _STR.
If something else is returned description_show() will access invalid
memory. |
["https://git.kernel.org/stable/c/0cdfb9178a3bba843c95c2117c82c15f1a64b9ce","https://git.kernel.org/stable/c/2364b6af90c6b6d8a4783e0d3481ca80af699554","https://git.kernel.org/stable/c/4b081991c4363e072e1748efed0bbec8a77daba5","https://git.kernel.org/stable/c/4bb1e7d027413835b086aed35bc3f0713bc0f72b","https://git.kernel.org/stable/c/5c8d007c14aefc3f2ddf71e4c40713733dc827be","https://git.kernel.org/stable/c/92fd5209fc014405f63a7db79802ca4b01dc0c05","https://git.kernel.org/stable/c/f0921ecd4ddc14646bb5511f49db4d7d3b0829f0","https://git.kernel.org/stable/c/f51e5a88f2e7224858b261546cf6b3037dfb1323","https://git.kernel.org/stable/c/f51f711d36e61fbb87c67b524fd200e05172668d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48871
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer
Driver's probe allocates memory for RX FIFO (port->rx_fifo) based on
default RX FIFO depth, e.g. 16. Later during serial startup the
qcom_geni_serial_port_setup() updates the RX FIFO depth
(port->rx_fifo_depth) to match real device capabilities, e.g. to 32.
The RX UART handle code will read "port->rx_fifo_depth" number of words
into "port->rx_fifo" buffer, thus exceeding the bounds. This can be
observed in certain configurations with Qualcomm Bluetooth HCI UART
device and KASAN:
Bluetooth: hci0: QCA Product ID :0x00000010
Bluetooth: hci0: QCA SOC Version :0x400a0200
Bluetooth: hci0: QCA ROM Version :0x00000200
Bluetooth: hci0: QCA Patch Version:0x00000d2b
Bluetooth: hci0: QCA controller version 0x02000200
Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv
bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2
Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2)
Bluetooth: hci0: QCA Failed to download patch (-2)
==================================================================
BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c
Write of size 4 at addr ffff279347d578c0 by task swapper/0/0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26
Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
Call trace:
dump_backtrace.part.0+0xe0/0xf0
show_stack+0x18/0x40
dump_stack_lvl+0x8c/0xb8
print_report+0x188/0x488
kasan_report+0xb4/0x100
__asan_store4+0x80/0xa4
handle_rx_uart+0xa8/0x18c
qcom_geni_serial_handle_rx+0x84/0x9c
qcom_geni_serial_isr+0x24c/0x760
__handle_irq_event_percpu+0x108/0x500
handle_irq_event+0x6c/0x110
handle_fasteoi_irq+0x138/0x2cc
generic_handle_domain_irq+0x48/0x64
If the RX FIFO depth changes after probe, be sure to resize the buffer. |
["https://git.kernel.org/stable/c/894681682dbefdad917b88f86cde1069140a047a","https://git.kernel.org/stable/c/b8caf69a6946e18ffebad49847e258f5b6d52ac2","https://git.kernel.org/stable/c/cb53a3366eb28fed67850c80afa52075bb71a38a","https://git.kernel.org/stable/c/fd524ca7fe45b8a06dca2dd546d62684a9768f95"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52904
|
Medium |
|
N/A
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Fix possible NULL pointer dereference in snd_usb_pcm_has_fixed_rate()
The subs function argument may be NULL, so do not use it before the NULL check. |
["https://git.kernel.org/stable/c/92a9c0ad86d47ff4cce899012e355c400f02cfb8","https://git.kernel.org/stable/c/a474d4ad59cd4642d1b7e3a6c08cef9eca0992c8","https://git.kernel.org/stable/c/f57204edc10760c935d8d36ea999dc8acf018030"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49027
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
iavf: Fix error handling in iavf_init_module()
The iavf_init_module() won't destroy workqueue when pci_register_driver()
failed. Call destroy_workqueue() when pci_register_driver() failed to
prevent the resource leak.
Similar to the handling of u132_hcd_init in commit f276e002793c
("usb: u132-hcd: fix resource leak") |
["https://git.kernel.org/stable/c/0d9f5bd54b913018031c5b964fc1f9a31f5f6cb5","https://git.kernel.org/stable/c/227d8d2f7f2278b8468c5531b0cd0f2a905b4486","https://git.kernel.org/stable/c/971c55f0763b480e63ceb7a22beb19be2509e5ed","https://git.kernel.org/stable/c/bd477b891a4fa084561234eed4afacb3001dd359"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48861
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
vdpa: fix use-after-free on vp_vdpa_remove
When vp_vdpa driver is unbind, vp_vdpa is freed in vdpa_unregister_device
and then vp_vdpa->mdev.pci_dev is dereferenced in vp_modern_remove,
triggering use-after-free.
Call Trace of unbinding driver free vp_vdpa :
do_syscall_64
vfs_write
kernfs_fop_write_iter
device_release_driver_internal
pci_device_remove
vp_vdpa_remove
vdpa_unregister_device
kobject_release
device_release
kfree
Call Trace of dereference vp_vdpa->mdev.pci_dev:
vp_modern_remove
pci_release_selected_regions
pci_release_region
pci_resource_len
pci_resource_end
(dev)->resource[(bar)].end |
["https://git.kernel.org/stable/c/4b1743bc715a3691a63ac21b349079b07bf1b19e","https://git.kernel.org/stable/c/dc54ba9932aeaaa1a21fe214af1f446593a78274","https://git.kernel.org/stable/c/eb057b44dbe35ae14527830236a92f51de8f9184","https://git.kernel.org/stable/c/4b1743bc715a3691a63ac21b349079b07bf1b19e","https://git.kernel.org/stable/c/dc54ba9932aeaaa1a21fe214af1f446593a78274","https://git.kernel.org/stable/c/eb057b44dbe35ae14527830236a92f51de8f9184"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40959
|
Medium |
fixed |
- 4.19.317
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.96
- 6.6.36
- 6.9.7
|
In the Linux kernel, the following vulnerability has been resolved:
xfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()
ip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly.
syzbot reported:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Workqueue: wg-kex-wg1 wg_packet_handshake_send_worker
RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64
Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00
RSP: 0018:ffffc90000117378 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7
RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98
RBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000
R10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline]
xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline]
xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541
xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835
xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline]
xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201
xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline]
xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309
ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256
send6+0x611/0xd20 drivers/net/wireguard/socket.c:139
wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178
wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200
wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40
wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51
process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
process_scheduled_works kernel/workqueue.c:3312 [inline]
worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393
kthread+0x2c1/0x3a0 kernel/kthread.c:389
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 |
["https://git.kernel.org/stable/c/20427b85781aca0ad072851f6907a3d4b2fed8d1","https://git.kernel.org/stable/c/600a62b4232ac027f788c3ca395bc2333adeaacf","https://git.kernel.org/stable/c/83c02fb2cc0afee5bb53cddf3f34f045f654ad6a","https://git.kernel.org/stable/c/9f30f1f1a51d91e19f5a09236bb0b59e6a07ad08","https://git.kernel.org/stable/c/c71761292d4d002a8eccb57b86792c4e3b3eb3c7","https://git.kernel.org/stable/c/caf0bec84c62fb1cf6f7c9f0e8c857c87f8adbc3","https://git.kernel.org/stable/c/d46401052c2d5614da8efea5788532f0401cb164","https://git.kernel.org/stable/c/f897d7171652fcfc76d042bfec798b010ee89e41","https://git.kernel.org/stable/c/20427b85781aca0ad072851f6907a3d4b2fed8d1","https://git.kernel.org/stable/c/600a62b4232ac027f788c3ca395bc2333adeaacf","https://git.kernel.org/stable/c/83c02fb2cc0afee5bb53cddf3f34f045f654ad6a","https://git.kernel.org/stable/c/9f30f1f1a51d91e19f5a09236bb0b59e6a07ad08","https://git.kernel.org/stable/c/c71761292d4d002a8eccb57b86792c4e3b3eb3c7","https://git.kernel.org/stable/c/caf0bec84c62fb1cf6f7c9f0e8c857c87f8adbc3","https://git.kernel.org/stable/c/d46401052c2d5614da8efea5788532f0401cb164","https://git.kernel.org/stable/c/f897d7171652fcfc76d042bfec798b010ee89e41"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40960
|
Medium |
fixed |
- 4.19.317
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.96
- 6.6.36
- 6.9.7
|
In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent possible NULL dereference in rt6_probe()
syzbot caught a NULL dereference in rt6_probe() [1]
Bail out if __in6_dev_get() returns NULL.
[1]
Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f]
CPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline]
RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758
Code: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19
RSP: 0018:ffffc900034af070 EFLAGS: 00010203
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000
RDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c
RBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a
R13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000
FS: 00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784
nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496
__find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825
find_rr_leaf net/ipv6/route.c:853 [inline]
rt6_select net/ipv6/route.c:897 [inline]
fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195
ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231
pol_lookup_func include/net/ip6_fib.h:616 [inline]
fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121
ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline]
ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651
ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147
ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250
rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898
inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
sock_write_iter+0x4b8/0x5c0 net/socket.c:1160
new_sync_write fs/read_write.c:497 [inline]
vfs_write+0x6b6/0x1140 fs/read_write.c:590
ksys_write+0x1f8/0x260 fs/read_write.c:643
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f |
["https://git.kernel.org/stable/c/1ed9849fdf9a1a617129346b11d2094ca26828dc","https://git.kernel.org/stable/c/51ee2f7c30790799d0ec30c0ce0c743e58f046f2","https://git.kernel.org/stable/c/569c9d9ea6648d099187527b93982f406ddcebc0","https://git.kernel.org/stable/c/6eed6d3cd19ff3cfa83aeceed86da14abaf7417b","https://git.kernel.org/stable/c/73e7c8ca6ad76f29b2c99c20845a6f3b203ff0c6","https://git.kernel.org/stable/c/b86762dbe19a62e785c189f313cda5b989931f37","https://git.kernel.org/stable/c/d66fc4826127c82f99c4033380f8e93833d331c7","https://git.kernel.org/stable/c/f0cda984e4e634b221dbf9642b8ecc5b4806b41e","https://git.kernel.org/stable/c/1ed9849fdf9a1a617129346b11d2094ca26828dc","https://git.kernel.org/stable/c/51ee2f7c30790799d0ec30c0ce0c743e58f046f2","https://git.kernel.org/stable/c/569c9d9ea6648d099187527b93982f406ddcebc0","https://git.kernel.org/stable/c/6eed6d3cd19ff3cfa83aeceed86da14abaf7417b","https://git.kernel.org/stable/c/73e7c8ca6ad76f29b2c99c20845a6f3b203ff0c6","https://git.kernel.org/stable/c/b86762dbe19a62e785c189f313cda5b989931f37","https://git.kernel.org/stable/c/d66fc4826127c82f99c4033380f8e93833d331c7","https://git.kernel.org/stable/c/f0cda984e4e634b221dbf9642b8ecc5b4806b41e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35973
|
Medium |
fixed |
- 4.19.313
- 5.4.275
- 5.10.216
- 5.12
- 5.15.156
- 6.1.87
- 6.6.28
- 6.8.7
|
In the Linux kernel, the following vulnerability has been resolved:
geneve: fix header validation in geneve[6]_xmit_skb
syzbot is able to trigger an uninit-value in geneve_xmit() [1]
Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield())
uses skb_protocol(skb, true), pskb_inet_may_pull() is only using
skb->protocol.
If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb->protocol,
pskb_inet_may_pull() does nothing at all.
If a vlan tag was provided by the caller (af_packet in the syzbot case),
the network header might not point to the correct location, and skb
linear part could be smaller than expected.
Add skb_vlan_inet_prepare() to perform a complete mac validation.
Use this in geneve for the moment, I suspect we need to adopt this
more broadly.
v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest
- Only call __vlan_get_protocol() for vlan types.
v2,v3 - Addressed Sabrina comments on v1 and v2
[1]
BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline]
BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030
geneve_xmit_skb drivers/net/geneve.c:910 [inline]
geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030
__netdev_start_xmit include/linux/netdevice.h:4903 [inline]
netdev_start_xmit include/linux/netdevice.h:4917 [inline]
xmit_one net/core/dev.c:3531 [inline]
dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
__dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276
packet_snd net/packet/af_packet.c:3081 [inline]
packet_sendmsg+0x8bb0/0x9ef0 net/packet/af_packet.c:3113
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x30f/0x380 net/socket.c:745
__sys_sendto+0x685/0x830 net/socket.c:2191
__do_sys_sendto net/socket.c:2203 [inline]
__se_sys_sendto net/socket.c:2199 [inline]
__x64_sys_sendto+0x125/0x1d0 net/socket.c:2199
do_syscall_64+0xd5/0x1f0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
Uninit was created at:
slab_post_alloc_hook mm/slub.c:3804 [inline]
slab_alloc_node mm/slub.c:3845 [inline]
kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577
__alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668
alloc_skb include/linux/skbuff.h:1318 [inline]
alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504
sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795
packet_alloc_skb net/packet/af_packet.c:2930 [inline]
packet_snd net/packet/af_packet.c:3024 [inline]
packet_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x30f/0x380 net/socket.c:745
__sys_sendto+0x685/0x830 net/socket.c:2191
__do_sys_sendto net/socket.c:2203 [inline]
__se_sys_sendto net/socket.c:2199 [inline]
__x64_sys_sendto+0x125/0x1d0 net/socket.c:2199
do_syscall_64+0xd5/0x1f0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
CPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 |
["https://git.kernel.org/stable/c/10204df9beda4978bd1d0c2db0d8375bfb03b915","https://git.kernel.org/stable/c/190d9efa5773f26d6f334b1b8be282c4fa13fd5e","https://git.kernel.org/stable/c/357163fff3a6e48fe74745425a32071ec9caf852","https://git.kernel.org/stable/c/3c1ae6de74e3d2d6333d29a2d3e13e6094596c79","https://git.kernel.org/stable/c/43be590456e1f3566054ce78ae2dbb68cbe1a536","https://git.kernel.org/stable/c/4a1b65d1e55d53b397cb27014208be1e04172670","https://git.kernel.org/stable/c/d3adf11d7993518a39bd02b383cfe657ccc0023c","https://git.kernel.org/stable/c/d8a6213d70accb403b82924a1c229e733433a5ef","https://git.kernel.org/stable/c/10204df9beda4978bd1d0c2db0d8375bfb03b915","https://git.kernel.org/stable/c/190d9efa5773f26d6f334b1b8be282c4fa13fd5e","https://git.kernel.org/stable/c/357163fff3a6e48fe74745425a32071ec9caf852","https://git.kernel.org/stable/c/3c1ae6de74e3d2d6333d29a2d3e13e6094596c79","https://git.kernel.org/stable/c/43be590456e1f3566054ce78ae2dbb68cbe1a536","https://git.kernel.org/stable/c/4a1b65d1e55d53b397cb27014208be1e04172670","https://git.kernel.org/stable/c/d3adf11d7993518a39bd02b383cfe657ccc0023c","https://git.kernel.org/stable/c/d8a6213d70accb403b82924a1c229e733433a5ef","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50271
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
signal: restore the override_rlimit logic
Prior to commit d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of
ucounts") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of
signals. However now it's enforced unconditionally, even if
override_rlimit is set. This behavior change caused production issues.
For example, if the limit is reached and a process receives a SIGSEGV
signal, sigqueue_alloc fails to allocate the necessary resources for the
signal delivery, preventing the signal from being delivered with siginfo.
This prevents the process from correctly identifying the fault address and
handling the error. From the user-space perspective, applications are
unaware that the limit has been reached and that the siginfo is
effectively 'corrupted'. This can lead to unpredictable behavior and
crashes, as we observed with java applications.
Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip
the comparison to max there if override_rlimit is set. This effectively
restores the old behavior. |
["https://git.kernel.org/stable/c/012f4d5d25e9ef92ee129bd5aa7aa60f692681e1","https://git.kernel.org/stable/c/0208ea17a1e4456fbfe555f13ae5c28f3d671e40","https://git.kernel.org/stable/c/4877d9b2a2ebad3ae240127aaa4cb8258b145cf7","https://git.kernel.org/stable/c/9e05e5c7ee8758141d2db7e8fea2cab34500c6ed"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43856
|
Medium |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
dma: fix call order in dmam_free_coherent
dmam_free_coherent() frees a DMA allocation, which makes the
freed vaddr available for reuse, then calls devres_destroy()
to remove and free the data structure used to track the DMA
allocation. Between the two calls, it is possible for a
concurrent task to make an allocation with the same vaddr
and add it to the devres list.
If this happens, there will be two entries in the devres list
with the same vaddr and devres_destroy() can free the wrong
entry, triggering the WARN_ON() in dmam_match.
Fix by destroying the devres entry before freeing the DMA
allocation.
kokonut //net/encryption
http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03 |
["https://git.kernel.org/stable/c/1fe97f68fce1ba24bf823bfb0eb0956003473130","https://git.kernel.org/stable/c/22094f5f52e7bc16c5bf9613365049383650b02e","https://git.kernel.org/stable/c/257193083e8f43907e99ea633820fc2b3bcd24c7","https://git.kernel.org/stable/c/28e8b7406d3a1f5329a03aa25a43aa28e087cb20","https://git.kernel.org/stable/c/2f7bbdc744f2e7051d1cb47c8e082162df1923c9","https://git.kernel.org/stable/c/87b34c8c94e29fa01d744e5147697f592998d954","https://git.kernel.org/stable/c/f993a4baf6b622232e4c190d34c220179e5d61eb","https://git.kernel.org/stable/c/fe2d246080f035e0af5793cb79067ba125e4fb63"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-5197
|
Medium |
fixed |
|
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.
Addition and removal of rules from chain bindings within the same transaction causes leads to use-after-free.
We recommend upgrading past commit f15f29fd4779be8a418b66e9d52979bb6d6c2325. |
["http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f15f29fd4779be8a418b66e9d52979bb6d6c2325","https://kernel.dance/f15f29fd4779be8a418b66e9d52979bb6d6c2325","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f15f29fd4779be8a418b66e9d52979bb6d6c2325","https://kernel.dance/f15f29fd4779be8a418b66e9d52979bb6d6c2325","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49576
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ipv4: Fix data-races around sysctl_fib_multipath_hash_fields.
While reading sysctl_fib_multipath_hash_fields, it can be changed
concurrently. Thus, we need to add READ_ONCE() to its readers. |
["https://git.kernel.org/stable/c/36f5b86f309b3b11295d087cd7433f1c897caf94","https://git.kernel.org/stable/c/548d6678c4a3d43667e59686665f8674b82440a3","https://git.kernel.org/stable/c/8895a9c2ac76fb9d3922fed4fe092c8ec5e5cccc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49588
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix data-races around sysctl_tcp_migrate_req.
While reading sysctl_tcp_migrate_req, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its readers. |
["https://git.kernel.org/stable/c/4177f545895b1da08447a80692f30617154efa6e","https://git.kernel.org/stable/c/6e569a11eea20a1ccebc3c4e6366bf0574a449e1","https://git.kernel.org/stable/c/fcf6c6d8aeffebca66f37b17ef1b57112e5e09c1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49600
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ip: Fix a data-race around sysctl_ip_autobind_reuse.
While reading sysctl_ip_autobind_reuse, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its reader. |
["https://git.kernel.org/stable/c/0db232765887d9807df8bcb7b6f29b2871539eab","https://git.kernel.org/stable/c/611ba70e5aca252ef43374dda97ed4cf1c47a07c","https://git.kernel.org/stable/c/87ceaa199a72c5856d49a030941fabcd5c3928d4","https://git.kernel.org/stable/c/fa7cdcf9b28d13aac1eeb34b948db8a18e041341"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49603
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ip: Fix data-races around sysctl_ip_fwd_update_priority.
While reading sysctl_ip_fwd_update_priority, it can be changed
concurrently. Thus, we need to add READ_ONCE() to its readers. |
["https://git.kernel.org/stable/c/11038fa781ab916535c53351537b22d6d405667d","https://git.kernel.org/stable/c/351f81f7d7185d18a9ff76f8f8c2fa8c4eea563b","https://git.kernel.org/stable/c/7bf9e18d9a5e99e3c83482973557e9f047b051e7","https://git.kernel.org/stable/c/bcc03369d3277ae075ed421f0c8bf4adb5e65b74"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26974
|
High |
fixed |
- 4.19.312
- 5.4.274
- 5.10.215
- 5.15.154
- 6.1.84
- 6.6.24
- 6.7.12
- 6.8.3
|
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - resolve race condition during AER recovery
During the PCI AER system's error recovery process, the kernel driver
may encounter a race condition with freeing the reset_data structure's
memory. If the device restart will take more than 10 seconds the function
scheduling that restart will exit due to a timeout, and the reset_data
structure will be freed. However, this data structure is used for
completion notification after the restart is completed, which leads
to a UAF bug.
This results in a KFENCE bug notice.
BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat]
Use-after-free read at 0x00000000bc56fddf (in kfence-#142):
adf_device_reset_worker+0x38/0xa0 [intel_qat]
process_one_work+0x173/0x340
To resolve this race condition, the memory associated to the container
of the work_struct is freed on the worker if the timeout expired,
otherwise on the function that schedules the worker.
The timeout detection can be done by checking if the caller is
still waiting for completion or not by using completion_done() function. |
["https://git.kernel.org/stable/c/0c2cf5142bfb634c0ef0a1a69cdf37950747d0be","https://git.kernel.org/stable/c/226fc408c5fcd23cc4186f05ea3a09a7a9aef2f7","https://git.kernel.org/stable/c/4ae5a97781ce7d6ecc9c7055396535815b64ca4f","https://git.kernel.org/stable/c/7d42e097607c4d246d99225bf2b195b6167a210c","https://git.kernel.org/stable/c/8a5a7611ccc7b1fba8d933a9f22a2e76859d94dc","https://git.kernel.org/stable/c/8e81cd58aee14a470891733181a47d123193ba81","https://git.kernel.org/stable/c/bb279ead42263e9fb09480f02a4247b2c287d828","https://git.kernel.org/stable/c/d03092550f526a79cf1ade7f0dfa74906f39eb71","https://git.kernel.org/stable/c/daba62d9eeddcc5b1081be7d348ca836c83c59d7","https://git.kernel.org/stable/c/0c2cf5142bfb634c0ef0a1a69cdf37950747d0be","https://git.kernel.org/stable/c/226fc408c5fcd23cc4186f05ea3a09a7a9aef2f7","https://git.kernel.org/stable/c/4ae5a97781ce7d6ecc9c7055396535815b64ca4f","https://git.kernel.org/stable/c/7d42e097607c4d246d99225bf2b195b6167a210c","https://git.kernel.org/stable/c/8a5a7611ccc7b1fba8d933a9f22a2e76859d94dc","https://git.kernel.org/stable/c/8e81cd58aee14a470891733181a47d123193ba81","https://git.kernel.org/stable/c/bb279ead42263e9fb09480f02a4247b2c287d828","https://git.kernel.org/stable/c/d03092550f526a79cf1ade7f0dfa74906f39eb71","https://git.kernel.org/stable/c/daba62d9eeddcc5b1081be7d348ca836c83c59d7","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48872
|
High |
fixed |
- 5.4.230
- 5.10.165
- 5.15.90
- 6.2
|
In the Linux kernel, the following vulnerability has been resolved:
misc: fastrpc: Fix use-after-free race condition for maps
It is possible that in between calling fastrpc_map_get() until
map->fl->lock is taken in fastrpc_free_map(), another thread can call
fastrpc_map_lookup() and get a reference to a map that is about to be
deleted.
Rewrite fastrpc_map_get() to only increase the reference count of a map
if it's non-zero. Propagate this to callers so they can know if a map is
about to be deleted.
Fixes this warning:
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 5 PID: 10100 at lib/refcount.c:25 refcount_warn_saturate
...
Call trace:
refcount_warn_saturate
[fastrpc_map_get inlined]
[fastrpc_map_lookup inlined]
fastrpc_map_create
fastrpc_internal_invoke
fastrpc_device_ioctl
__arm64_sys_ioctl
invoke_syscall |
["https://git.kernel.org/stable/c/079c78c68714f7d8d58e66c477b0243b31806907","https://git.kernel.org/stable/c/556dfdb226ce1e5231d8836159b23f8bb0395bf4","https://git.kernel.org/stable/c/61a0890cb95afec5c8a2f4a879de2b6220984ef1","https://git.kernel.org/stable/c/96b328d119eca7563c1edcc4e1039a62e6370ecb","https://git.kernel.org/stable/c/b171d0d2cf1b8387c72c8d325c5d5746fa271e39"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47747
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition
In the ether3_probe function, a timer is initialized with a callback
function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is
started, there is a risk of a race condition if the module or device
is removed, triggering the ether3_remove function to perform cleanup.
The sequence of operations that may lead to a UAF bug is as follows:
CPU0 CPU1
| ether3_ledoff
ether3_remove |
free_netdev(dev); |
put_devic |
kfree(dev); |
| ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2);
| // use dev
Fix it by ensuring that the timer is canceled before proceeding with
the cleanup in ether3_remove. |
["https://git.kernel.org/stable/c/1c57d61a43293252ad732007c7070fdb112545fd","https://git.kernel.org/stable/c/25d559ed2beec9b34045886100dac46d1ad92eba","https://git.kernel.org/stable/c/338a0582b28e69460df03af50e938b86b4206353","https://git.kernel.org/stable/c/516dbc6d16637430808c39568cbb6b841d32b55b","https://git.kernel.org/stable/c/77a77331cef0a219b8dd91361435eeef04cb741c","https://git.kernel.org/stable/c/822c7bb1f6f8b0331e8d1927151faf8db3b33afd","https://git.kernel.org/stable/c/b5109b60ee4fcb2f2bb24f589575e10cc5283ad4","https://git.kernel.org/stable/c/b5a84b6c772564c8359a9a0fbaeb2a2944aa1ee9","https://git.kernel.org/stable/c/d2abc379071881798d20e2ac1d332ad855ae22f3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56619
|
High |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential out-of-bounds memory access in nilfs_find_entry()
Syzbot reported that when searching for records in a directory where the
inode's i_size is corrupted and has a large value, memory access outside
the folio/page range may occur, or a use-after-free bug may be detected if
KASAN is enabled.
This is because nilfs_last_byte(), which is called by nilfs_find_entry()
and others to calculate the number of valid bytes of directory data in a
page from i_size and the page index, loses the upper 32 bits of the 64-bit
size information due to an inappropriate type of local variable to which
the i_size value is assigned.
This caused a large byte offset value due to underflow in the end address
calculation in the calling nilfs_find_entry(), resulting in memory access
that exceeds the folio/page size.
Fix this issue by changing the type of the local variable causing the bit
loss from "unsigned int" to "u64". The return value of nilfs_last_byte()
is also of type "unsigned int", but it is truncated so as not to exceed
PAGE_SIZE and no bit loss occurs, so no change is required. |
["https://git.kernel.org/stable/c/09d6d05579fd46e61abf6e457bb100ff11f3a9d3","https://git.kernel.org/stable/c/31f7b57a77d4c82a34ddcb6ff35b5aa577ef153e","https://git.kernel.org/stable/c/48eb6e7404948032bbe811c5affbe39f6b316951","https://git.kernel.org/stable/c/5af8366625182f01f6d8465c9a3210574673af57","https://git.kernel.org/stable/c/985ebec4ab0a28bb5910c3b1481a40fbf7f9e61d","https://git.kernel.org/stable/c/c3afea07477baccdbdec4483f8d5e59d42a3f67f","https://git.kernel.org/stable/c/e3732102a9d638d8627d14fdf7b208462f0520e0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56775
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix handling of plane refcount
[Why]
The mechanism to backup and restore plane states doesn't maintain
refcount, which can cause issues if the refcount of the plane changes
in between backup and restore operations, such as memory leaks if the
refcount was supposed to go down, or double frees / invalid memory
accesses if the refcount was supposed to go up.
[How]
Cache and re-apply current refcount when restoring plane states. |
["https://git.kernel.org/stable/c/27227a234c1487cb7a684615f0749c455218833a","https://git.kernel.org/stable/c/8cb2f6793845f135b28361ba8e96901cae3e5790"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53068
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier()
The scmi_dev->name is released prematurely in __scmi_device_destroy(),
which causes slab-use-after-free when accessing scmi_dev->name in
scmi_bus_notifier(). So move the release of scmi_dev->name to
scmi_device_release() to avoid slab-use-after-free.
| BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec
| Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1
|
| CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1
| Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT)
| Call trace:
| dump_backtrace+0x94/0x114
| show_stack+0x18/0x24
| dump_stack_lvl+0x48/0x60
| print_report+0xf4/0x5b0
| kasan_report+0xa4/0xec
| __asan_report_load1_noabort+0x20/0x2c
| strncmp+0xe4/0xec
| scmi_bus_notifier+0x5c/0x54c
| notifier_call_chain+0xb4/0x31c
| blocking_notifier_call_chain+0x68/0x9c
| bus_notify+0x54/0x78
| device_del+0x1bc/0x840
| device_unregister+0x20/0xb4
| __scmi_device_destroy+0xac/0x280
| scmi_device_destroy+0x94/0xd0
| scmi_chan_setup+0x524/0x750
| scmi_probe+0x7fc/0x1508
| platform_probe+0xc4/0x19c
| really_probe+0x32c/0x99c
| __driver_probe_device+0x15c/0x3c4
| driver_probe_device+0x5c/0x170
| __driver_attach+0x1c8/0x440
| bus_for_each_dev+0xf4/0x178
| driver_attach+0x3c/0x58
| bus_add_driver+0x234/0x4d4
| driver_register+0xf4/0x3c0
| __platform_driver_register+0x60/0x88
| scmi_driver_init+0xb0/0x104
| do_one_initcall+0xb4/0x664
| kernel_init_freeable+0x3c8/0x894
| kernel_init+0x24/0x1e8
| ret_from_fork+0x10/0x20
|
| Allocated by task 1:
| kasan_save_stack+0x2c/0x54
| kasan_set_track+0x2c/0x40
| kasan_save_alloc_info+0x24/0x34
| __kasan_kmalloc+0xa0/0xb8
| __kmalloc_node_track_caller+0x6c/0x104
| kstrdup+0x48/0x84
| kstrdup_const+0x34/0x40
| __scmi_device_create.part.0+0x8c/0x408
| scmi_device_create+0x104/0x370
| scmi_chan_setup+0x2a0/0x750
| scmi_probe+0x7fc/0x1508
| platform_probe+0xc4/0x19c
| really_probe+0x32c/0x99c
| __driver_probe_device+0x15c/0x3c4
| driver_probe_device+0x5c/0x170
| __driver_attach+0x1c8/0x440
| bus_for_each_dev+0xf4/0x178
| driver_attach+0x3c/0x58
| bus_add_driver+0x234/0x4d4
| driver_register+0xf4/0x3c0
| __platform_driver_register+0x60/0x88
| scmi_driver_init+0xb0/0x104
| do_one_initcall+0xb4/0x664
| kernel_init_freeable+0x3c8/0x894
| kernel_init+0x24/0x1e8
| ret_from_fork+0x10/0x20
|
| Freed by task 1:
| kasan_save_stack+0x2c/0x54
| kasan_set_track+0x2c/0x40
| kasan_save_free_info+0x38/0x5c
| __kasan_slab_free+0xe8/0x164
| __kmem_cache_free+0x11c/0x230
| kfree+0x70/0x130
| kfree_const+0x20/0x40
| __scmi_device_destroy+0x70/0x280
| scmi_device_destroy+0x94/0xd0
| scmi_chan_setup+0x524/0x750
| scmi_probe+0x7fc/0x1508
| platform_probe+0xc4/0x19c
| really_probe+0x32c/0x99c
| __driver_probe_device+0x15c/0x3c4
| driver_probe_device+0x5c/0x170
| __driver_attach+0x1c8/0x440
| bus_for_each_dev+0xf4/0x178
| driver_attach+0x3c/0x58
| bus_add_driver+0x234/0x4d4
| driver_register+0xf4/0x3c0
| __platform_driver_register+0x60/0x88
| scmi_driver_init+0xb0/0x104
| do_one_initcall+0xb4/0x664
| kernel_init_freeable+0x3c8/0x894
| kernel_init+0x24/0x1e8
| ret_from_fork+0x10/0x20 |
["https://git.kernel.org/stable/c/15b17bbcea07d49c43d21aa700485cbd9f9d00d8","https://git.kernel.org/stable/c/1e1f523b185a8ccdcba625b31ff0312d052900e2","https://git.kernel.org/stable/c/295416091e44806760ccf753aeafdafc0ae268f3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53095
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
smb: client: Fix use-after-free of network namespace.
Recently, we got a customer report that CIFS triggers oops while
reconnecting to a server. [0]
The workload runs on Kubernetes, and some pods mount CIFS servers
in non-root network namespaces. The problem rarely happened, but
it was always while the pod was dying.
The root cause is wrong reference counting for network namespace.
CIFS uses kernel sockets, which do not hold refcnt of the netns that
the socket belongs to. That means CIFS must ensure the socket is
always freed before its netns; otherwise, use-after-free happens.
The repro steps are roughly:
1. mount CIFS in a non-root netns
2. drop packets from the netns
3. destroy the netns
4. unmount CIFS
We can reproduce the issue quickly with the script [1] below and see
the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled.
When the socket is TCP, it is hard to guarantee the netns lifetime
without holding refcnt due to async timers.
Let's hold netns refcnt for each socket as done for SMC in commit
9744d2bf1976 ("smc: Fix use-after-free in tcp_write_timer_handler().").
Note that we need to move put_net() from cifs_put_tcp_session() to
clean_demultiplex_info(); otherwise, __sock_create() still could touch a
freed netns while cifsd tries to reconnect from cifs_demultiplex_thread().
Also, maybe_get_net() cannot be put just before __sock_create() because
the code is not under RCU and there is a small chance that the same
address happened to be reallocated to another netns.
[0]:
CIFS: VFS: \\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting...
CIFS: Serverclose failed 4 times, giving up
Unable to handle kernel paging request at virtual address 14de99e461f84a07
Mem abort info:
ESR = 0x0000000096000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
Data abort info:
ISV = 0, ISS = 0x00000004
CM = 0, WnR = 0
[14de99e461f84a07] address between user and kernel address ranges
Internal error: Oops: 0000000096000004 [#1] SMP
Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs
CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1
Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018
pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : fib_rules_lookup+0x44/0x238
lr : __fib_lookup+0x64/0xbc
sp : ffff8000265db790
x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01
x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580
x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500
x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002
x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294
x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000
x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0
x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500
Call trace:
fib_rules_lookup+0x44/0x238
__fib_lookup+0x64/0xbc
ip_route_output_key_hash_rcu+0x2c4/0x398
ip_route_output_key_hash+0x60/0x8c
tcp_v4_connect+0x290/0x488
__inet_stream_connect+0x108/0x3d0
inet_stream_connect+0x50/0x78
kernel_connect+0x6c/0xac
generic_ip_conne
---truncated--- |
["https://git.kernel.org/stable/c/c7f9282fc27fc36dbaffc8527c723de264a132f8","https://git.kernel.org/stable/c/e8c71494181153a134c96da28766a57bd1eac8cb","https://git.kernel.org/stable/c/ef7134c7fc48e1441b398e55a862232868a6f0a7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46702
|
Medium |
fixed |
- 5.10.225
- 5.15.166
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Mark XDomain as unplugged when router is removed
I noticed that when we do discrete host router NVM upgrade and it gets
hot-removed from the PCIe side as a result of NVM firmware authentication,
if there is another host connected with enabled paths we hang in tearing
them down. This is due to fact that the Thunderbolt networking driver
also tries to cleanup the paths and ends up blocking in
tb_disconnect_xdomain_paths() waiting for the domain lock.
However, at this point we already cleaned the paths in tb_stop() so
there is really no need for tb_disconnect_xdomain_paths() to do that
anymore. Furthermore it already checks if the XDomain is unplugged and
bails out early so take advantage of that and mark the XDomain as
unplugged when we remove the parent router. |
["https://git.kernel.org/stable/c/18b3ad2a3cc877dd4b16f48d84aa27b78d53bf1d","https://git.kernel.org/stable/c/23ce6ba3b95488a2b9e9f6d43b340da0c15395dc","https://git.kernel.org/stable/c/747bc154577de6e6af4bc99abfa859b8419bb4d8","https://git.kernel.org/stable/c/7ca24cf9163c112bb6b580c6fb57c04a1f8b76e1","https://git.kernel.org/stable/c/80ac8d194831eca0c2f4fd862f7925532fda320c","https://git.kernel.org/stable/c/e2006140ad2e01a02ed0aff49cc2ae3ceeb11f8d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44958
|
Medium |
fixed |
- 4.15
- 4.20
- 5.15.165
- 6.1.105
- 6.6.46
- 6.10.5
|
In the Linux kernel, the following vulnerability has been resolved:
sched/smt: Fix unbalance sched_smt_present dec/inc
I got the following warn report while doing stress test:
jump label: negative count!
WARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0
Call Trace:
<TASK>
__static_key_slow_dec_cpuslocked+0x16/0x70
sched_cpu_deactivate+0x26e/0x2a0
cpuhp_invoke_callback+0x3ad/0x10d0
cpuhp_thread_fun+0x3f5/0x680
smpboot_thread_fn+0x56d/0x8d0
kthread+0x309/0x400
ret_from_fork+0x41/0x70
ret_from_fork_asm+0x1b/0x30
</TASK>
Because when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),
the cpu offline failed, but sched_smt_present is decremented before
calling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so
fix it by incrementing sched_smt_present in the error path. |
["https://git.kernel.org/stable/c/2a3548c7ef2e135aee40e7e5e44e7d11b893e7c4","https://git.kernel.org/stable/c/2cf7665efe451e48d27953e6b5bc627d518c902b","https://git.kernel.org/stable/c/65727331b60197b742089855ac09464c22b96f66","https://git.kernel.org/stable/c/d0c87a3c6be10a57aa3463c32c3fc6b2a47c3dab","https://git.kernel.org/stable/c/e22f910a26cc2a3ac9c66b8e935ef2a7dd881117"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40912
|
Medium |
fixed |
- 4.19.317
- 5.4.297
- 5.10.221
- 5.15.162
- 6.1.95
- 6.6.35
- 6.9.6
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: Fix deadlock in ieee80211_sta_ps_deliver_wakeup()
The ieee80211_sta_ps_deliver_wakeup() function takes sta->ps_lock to
synchronizes with ieee80211_tx_h_unicast_ps_buf() which is called from
softirq context. However using only spin_lock() to get sta->ps_lock in
ieee80211_sta_ps_deliver_wakeup() does not prevent softirq to execute
on this same CPU, to run ieee80211_tx_h_unicast_ps_buf() and try to
take this same lock ending in deadlock. Below is an example of rcu stall
that arises in such situation.
rcu: INFO: rcu_sched self-detected stall on CPU
rcu: 2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996
rcu: (t=42586894 jiffies g=2057 q=362405 ncpus=4)
CPU: 2 PID: 719 Comm: wpa_supplicant Tainted: G W 6.4.0-02158-g1b062f552873 #742
Hardware name: RPT (r1) (DT)
pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : queued_spin_lock_slowpath+0x58/0x2d0
lr : invoke_tx_handlers_early+0x5b4/0x5c0
sp : ffff00001ef64660
x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8
x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000
x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000
x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000
x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80
x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da
x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440
x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880
x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8
Call trace:
queued_spin_lock_slowpath+0x58/0x2d0
ieee80211_tx+0x80/0x12c
ieee80211_tx_pending+0x110/0x278
tasklet_action_common.constprop.0+0x10c/0x144
tasklet_action+0x20/0x28
_stext+0x11c/0x284
____do_softirq+0xc/0x14
call_on_irq_stack+0x24/0x34
do_softirq_own_stack+0x18/0x20
do_softirq+0x74/0x7c
__local_bh_enable_ip+0xa0/0xa4
_ieee80211_wake_txqs+0x3b0/0x4b8
__ieee80211_wake_queue+0x12c/0x168
ieee80211_add_pending_skbs+0xec/0x138
ieee80211_sta_ps_deliver_wakeup+0x2a4/0x480
ieee80211_mps_sta_status_update.part.0+0xd8/0x11c
ieee80211_mps_sta_status_update+0x18/0x24
sta_apply_parameters+0x3bc/0x4c0
ieee80211_change_station+0x1b8/0x2dc
nl80211_set_station+0x444/0x49c
genl_family_rcv_msg_doit.isra.0+0xa4/0xfc
genl_rcv_msg+0x1b0/0x244
netlink_rcv_skb+0x38/0x10c
genl_rcv+0x34/0x48
netlink_unicast+0x254/0x2bc
netlink_sendmsg+0x190/0x3b4
____sys_sendmsg+0x1e8/0x218
___sys_sendmsg+0x68/0x8c
__sys_sendmsg+0x44/0x84
__arm64_sys_sendmsg+0x20/0x28
do_el0_svc+0x6c/0xe8
el0_svc+0x14/0x48
el0t_64_sync_handler+0xb0/0xb4
el0t_64_sync+0x14c/0x150
Using spin_lock_bh()/spin_unlock_bh() instead prevents softirq to raise
on the same CPU that is holding the lock. |
["https://git.kernel.org/stable/c/28ba44d680a30c51cf485a2f5a3b680e66ed3932","https://git.kernel.org/stable/c/44c06bbde6443de206b30f513100b5670b23fc5e","https://git.kernel.org/stable/c/456bbb8a31e425177dc0e8d4f98728a560c20e81","https://git.kernel.org/stable/c/47d176755d5c0baf284eff039560f8c1ba0ea485","https://git.kernel.org/stable/c/9c49b58b9a2bed707e7638576e54c4bccd97b9eb","https://git.kernel.org/stable/c/d90bdff79f8e40adf889b5408bfcf521528b169f","https://git.kernel.org/stable/c/e51637e0c66a6f72d134d9f95daa47ea62b43c7e","https://git.kernel.org/stable/c/e7e916d693dcb5a297f40312600a82475f2e63bc","https://git.kernel.org/stable/c/28ba44d680a30c51cf485a2f5a3b680e66ed3932","https://git.kernel.org/stable/c/44c06bbde6443de206b30f513100b5670b23fc5e","https://git.kernel.org/stable/c/456bbb8a31e425177dc0e8d4f98728a560c20e81","https://git.kernel.org/stable/c/47d176755d5c0baf284eff039560f8c1ba0ea485","https://git.kernel.org/stable/c/9c49b58b9a2bed707e7638576e54c4bccd97b9eb","https://git.kernel.org/stable/c/d90bdff79f8e40adf889b5408bfcf521528b169f","https://git.kernel.org/stable/c/e51637e0c66a6f72d134d9f95daa47ea62b43c7e","https://git.kernel.org/stable/c/e7e916d693dcb5a297f40312600a82475f2e63bc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48893
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gt: Cleanup partial engine discovery failures
If we abort driver initialisation in the middle of gt/engine discovery,
some engines will be fully setup and some not. Those incompletely setup
engines only have 'engine->release == NULL' and so will leak any of the
common objects allocated.
v2:
- Drop the destroy_pinned_context() helper for now. It's not really
worth it with just a single callsite at the moment. (Janusz) |
["https://git.kernel.org/stable/c/5c855bcc730656c4b7d30aaddcd0eafc7003e112","https://git.kernel.org/stable/c/78350c36fb15afef423404a83dcbc5c558dce795","https://git.kernel.org/stable/c/78a033433a5ae4fee85511ee075bc9a48312c79e","https://git.kernel.org/stable/c/7d21587d35bc816c85a51b8686f0f7e8e676fb14"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40977
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7921s: fix potential hung tasks during chip recovery
During chip recovery (e.g. chip reset), there is a possible situation that
kernel worker reset_work is holding the lock and waiting for kernel thread
stat_worker to be parked, while stat_worker is waiting for the release of
the same lock.
It causes a deadlock resulting in the dumping of hung tasks messages and
possible rebooting of the device.
This patch prevents the execution of stat_worker during the chip recovery. |
["https://git.kernel.org/stable/c/0b81faa05b0b9feb3ae2d69be1d21f0d126ecb08","https://git.kernel.org/stable/c/85edd783f4539a994d66c4c014d5858f490b7a02","https://git.kernel.org/stable/c/e974dd4c22a23ec3ce579fb6d31a674ac0435da9","https://git.kernel.org/stable/c/ecf0b2b8a37c8464186620bef37812a117ff6366","https://git.kernel.org/stable/c/0b81faa05b0b9feb3ae2d69be1d21f0d126ecb08","https://git.kernel.org/stable/c/85edd783f4539a994d66c4c014d5858f490b7a02","https://git.kernel.org/stable/c/e974dd4c22a23ec3ce579fb6d31a674ac0435da9","https://git.kernel.org/stable/c/ecf0b2b8a37c8464186620bef37812a117ff6366"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49727
|
Medium |
fixed |
- 4.9.320
- 4.14.285
- 4.19.249
- 5.4.200
- 5.10.124
- 5.15.49
- 5.18.6
|
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix signed integer overflow in l2tp_ip6_sendmsg
When len >= INT_MAX - transhdrlen, ulen = len + transhdrlen will be
overflow. To fix, we can follow what udpv6 does and subtract the
transhdrlen from the max. |
["https://git.kernel.org/stable/c/034246122f5c5e2e2a0b9fe04e24517920e9beb1","https://git.kernel.org/stable/c/0e818d433fc2718fe4da044ffca7431812a7e04e","https://git.kernel.org/stable/c/27a37755ceb401111ded76810359d3adc4b268a1","https://git.kernel.org/stable/c/2cf73c7cb6125083408d77f43d0e84d86aed0000","https://git.kernel.org/stable/c/2f42389d270f2304c8855b0b63498a5a4d0c053d","https://git.kernel.org/stable/c/6c4e3486d21173d60925ef52e512cae727b43d30","https://git.kernel.org/stable/c/b8879ca1fd7348b4d5db7db86dcb97f60c73d751","https://git.kernel.org/stable/c/f638a84afef3dfe10554c51820c16e39a278c915"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49731
|
Medium |
fixed |
- 4.9.320
- 4.14.285
- 4.19.249
- 5.4.200
- 5.10.124
- 5.15.49
- 5.18.6
|
In the Linux kernel, the following vulnerability has been resolved:
ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo()
In an unlikely (and probably wrong?) case that the 'ppi' parameter of
ata_host_alloc_pinfo() points to an array starting with a NULL pointer,
there's going to be a kernel oops as the 'pi' local variable won't get
reassigned from the initial value of NULL. Initialize 'pi' instead to
'&ata_dummy_port_info' to fix the possible kernel oops for good...
Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool. |
["https://git.kernel.org/stable/c/07cbdb4807d369fbda73062a91b570c4dc5ec429","https://git.kernel.org/stable/c/1ac5efee33f29e704226506d429b84575a5d66f8","https://git.kernel.org/stable/c/253334f84c81bc6a43af489f108c0bddad989eef","https://git.kernel.org/stable/c/36cd19e7d4e5571d77a2ed20c5b6ef50cf57734a","https://git.kernel.org/stable/c/a810bd5af06977a847d1f202b22d7defd5c62497","https://git.kernel.org/stable/c/bf476fe22aa1851bab4728e0c49025a6a0bea307","https://git.kernel.org/stable/c/ca4693e6e06e4fd2b240c0fec47aa2498c94848e","https://git.kernel.org/stable/c/ff128fbea720bf763fa345680dda5f050bc24a47"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-33740
|
High |
fixed |
- 4.9.322
- 4.14.287
- 4.19.251
- 5.4.204
- 5.10.129
- 5.15.53
- 5.18.10
|
Linux disk/nic frontends data leaks T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742). |
["http://www.openwall.com/lists/oss-security/2022/07/05/6","http://xenbits.xen.org/xsa/advisory-403.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-403.txt","http://www.openwall.com/lists/oss-security/2022/07/05/6","http://xenbits.xen.org/xsa/advisory-403.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-403.txt"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50106
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix race between laundromat and free_stateid
There is a race between laundromat handling of revoked delegations
and a client sending free_stateid operation. Laundromat thread
finds that delegation has expired and needs to be revoked so it
marks the delegation stid revoked and it puts it on a reaper list
but then it unlock the state lock and the actual delegation revocation
happens without the lock. Once the stid is marked revoked a racing
free_stateid processing thread does the following (1) it calls
list_del_init() which removes it from the reaper list and (2) frees
the delegation stid structure. The laundromat thread ends up not
calling the revoke_delegation() function for this particular delegation
but that means it will no release the lock lease that exists on
the file.
Now, a new open for this file comes in and ends up finding that
lease list isn't empty and calls nfsd_breaker_owns_lease() which ends
up trying to derefence a freed delegation stateid. Leading to the
followint use-after-free KASAN warning:
kernel: ==================================================================
kernel: BUG: KASAN: slab-use-after-free in nfsd_breaker_owns_lease+0x140/0x160 [nfsd]
kernel: Read of size 8 at addr ffff0000e73cd0c8 by task nfsd/6205
kernel:
kernel: CPU: 2 UID: 0 PID: 6205 Comm: nfsd Kdump: loaded Not tainted 6.11.0-rc7+ #9
kernel: Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 2069.0.0.0.0 08/03/2024
kernel: Call trace:
kernel: dump_backtrace+0x98/0x120
kernel: show_stack+0x1c/0x30
kernel: dump_stack_lvl+0x80/0xe8
kernel: print_address_description.constprop.0+0x84/0x390
kernel: print_report+0xa4/0x268
kernel: kasan_report+0xb4/0xf8
kernel: __asan_report_load8_noabort+0x1c/0x28
kernel: nfsd_breaker_owns_lease+0x140/0x160 [nfsd]
kernel: nfsd_file_do_acquire+0xb3c/0x11d0 [nfsd]
kernel: nfsd_file_acquire_opened+0x84/0x110 [nfsd]
kernel: nfs4_get_vfs_file+0x634/0x958 [nfsd]
kernel: nfsd4_process_open2+0xa40/0x1a40 [nfsd]
kernel: nfsd4_open+0xa08/0xe80 [nfsd]
kernel: nfsd4_proc_compound+0xb8c/0x2130 [nfsd]
kernel: nfsd_dispatch+0x22c/0x718 [nfsd]
kernel: svc_process_common+0x8e8/0x1960 [sunrpc]
kernel: svc_process+0x3d4/0x7e0 [sunrpc]
kernel: svc_handle_xprt+0x828/0xe10 [sunrpc]
kernel: svc_recv+0x2cc/0x6a8 [sunrpc]
kernel: nfsd+0x270/0x400 [nfsd]
kernel: kthread+0x288/0x310
kernel: ret_from_fork+0x10/0x20
This patch proposes a fixed that's based on adding 2 new additional
stid's sc_status values that help coordinate between the laundromat
and other operations (nfsd4_free_stateid() and nfsd4_delegreturn()).
First to make sure, that once the stid is marked revoked, it is not
removed by the nfsd4_free_stateid(), the laundromat take a reference
on the stateid. Then, coordinating whether the stid has been put
on the cl_revoked list or we are processing FREE_STATEID and need to
make sure to remove it from the list, each check that state and act
accordingly. If laundromat has added to the cl_revoke list before
the arrival of FREE_STATEID, then nfsd4_free_stateid() knows to remove
it from the list. If nfsd4_free_stateid() finds that operations arrived
before laundromat has placed it on cl_revoke list, it marks the state
freed and then laundromat will no longer add it to the list.
Also, for nfsd4_delegreturn() when looking for the specified stid,
we need to access stid that are marked removed or freeable, it means
the laundromat has started processing it but hasn't finished and this
delegreturn needs to return nfserr_deleg_revoked and not
nfserr_bad_stateid. The latter will not trigger a FREE_STATEID and the
lack of it will leave this stid on the cl_revoked list indefinitely. |
["https://git.kernel.org/stable/c/8dd91e8d31febf4d9cca3ae1bb4771d33ae7ee5a","https://git.kernel.org/stable/c/967faa26f313a62e7bebc55d5b8122eaee43b929"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44998
|
High |
fixed |
- 4.19.321
- 5.4.283
- 5.10.225
- 5.15.166
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
atm: idt77252: prevent use after free in dequeue_rx()
We can't dereference "skb" after calling vcc->push() because the skb
is released. |
["https://git.kernel.org/stable/c/09e086a5f72ea27c758b3f3b419a69000c32adc1","https://git.kernel.org/stable/c/1cece837e387c039225f19028df255df87a97c0d","https://git.kernel.org/stable/c/24cf390a5426aac9255205e9533cdd7b4235d518","https://git.kernel.org/stable/c/379a6a326514a3e2f71b674091dfb0e0e7522b55","https://git.kernel.org/stable/c/628ea82190a678a56d2ec38cda3addf3b3a6248d","https://git.kernel.org/stable/c/91b4850e7165a4b7180ef1e227733bcb41ccdf10","https://git.kernel.org/stable/c/a9a18e8f770c9b0703dab93580d0b02e199a4c79","https://git.kernel.org/stable/c/ef23c18ab88e33ce000d06a5c6aad0620f219bfd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50150
|
High |
fixed |
- 4.19.323
- 5.4.285
- 5.10.229
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: altmode should keep reference to parent
The altmode device release refers to its parent device, but without keeping
a reference to it.
When registering the altmode, get a reference to the parent and put it in
the release function.
Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues
like this:
[ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000)
[ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000)
[ 43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000)
[ 43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000)
[ 43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000)
[ 43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000)
[ 43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000)
[ 46.612867] ==================================================================
[ 46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129
[ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48
[ 46.614538]
[ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535
[ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
[ 46.616042] Workqueue: events kobject_delayed_cleanup
[ 46.616446] Call Trace:
[ 46.616648] <TASK>
[ 46.616820] dump_stack_lvl+0x5b/0x7c
[ 46.617112] ? typec_altmode_release+0x38/0x129
[ 46.617470] print_report+0x14c/0x49e
[ 46.617769] ? rcu_read_unlock_sched+0x56/0x69
[ 46.618117] ? __virt_addr_valid+0x19a/0x1ab
[ 46.618456] ? kmem_cache_debug_flags+0xc/0x1d
[ 46.618807] ? typec_altmode_release+0x38/0x129
[ 46.619161] kasan_report+0x8d/0xb4
[ 46.619447] ? typec_altmode_release+0x38/0x129
[ 46.619809] ? process_scheduled_works+0x3cb/0x85f
[ 46.620185] typec_altmode_release+0x38/0x129
[ 46.620537] ? process_scheduled_works+0x3cb/0x85f
[ 46.620907] device_release+0xaf/0xf2
[ 46.621206] kobject_delayed_cleanup+0x13b/0x17a
[ 46.621584] process_scheduled_works+0x4f6/0x85f
[ 46.621955] ? __pfx_process_scheduled_works+0x10/0x10
[ 46.622353] ? hlock_class+0x31/0x9a
[ 46.622647] ? lock_acquired+0x361/0x3c3
[ 46.622956] ? move_linked_works+0x46/0x7d
[ 46.623277] worker_thread+0x1ce/0x291
[ 46.623582] ? __kthread_parkme+0xc8/0xdf
[ 46.623900] ? __pfx_worker_thread+0x10/0x10
[ 46.624236] kthread+0x17e/0x190
[ 46.624501] ? kthread+0xfb/0x190
[ 46.624756] ? __pfx_kthread+0x10/0x10
[ 46.625015] ret_from_fork+0x20/0x40
[ 46.625268] ? __pfx_kthread+0x10/0x10
[ 46.625532] ret_from_fork_asm+0x1a/0x30
[ 46.625805] </TASK>
[ 46.625953]
[ 46.626056] Allocated by task 678:
[ 46.626287] kasan_save_stack+0x24/0x44
[ 46.626555] kasan_save_track+0x14/0x2d
[ 46.626811] __kasan_kmalloc+0x3f/0x4d
[ 46.627049] __kmalloc_noprof+0x1bf/0x1f0
[ 46.627362] typec_register_port+0x23/0x491
[ 46.627698] cros_typec_probe+0x634/0xbb6
[ 46.628026] platform_probe+0x47/0x8c
[ 46.628311] really_probe+0x20a/0x47d
[ 46.628605] device_driver_attach+0x39/0x72
[ 46.628940] bind_store+0x87/0xd7
[ 46.629213] kernfs_fop_write_iter+0x1aa/0x218
[ 46.629574] vfs_write+0x1d6/0x29b
[ 46.629856] ksys_write+0xcd/0x13b
[ 46.630128] do_syscall_64+0xd4/0x139
[ 46.630420] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 46.630820]
[ 46.630946] Freed by task 48:
[ 46.631182] kasan_save_stack+0x24/0x44
[ 46.631493] kasan_save_track+0x14/0x2d
[ 46.631799] kasan_save_free_info+0x3f/0x4d
[ 46.632144] __kasan_slab_free+0x37/0x45
[ 46.632474]
---truncated--- |
["https://git.kernel.org/stable/c/1ded6b12499e6dee9b0e1ceac633be36538f6fc2","https://git.kernel.org/stable/c/2b0b33e8a58388fa9078f0fbe9af1900e6b08879","https://git.kernel.org/stable/c/2c15c4133d00f5da632fce60ed013fc31aa9aa58","https://git.kernel.org/stable/c/68a7c7fe322546be1464174c8d85874b8161deda","https://git.kernel.org/stable/c/6af43ec3bf40f8b428d9134ffa7a291aecd60da8","https://git.kernel.org/stable/c/87474406056891e4fdea0794e1f632b21b3dfa27","https://git.kernel.org/stable/c/bee1b68cb8bcee4fd3a8bde3a4886e0b1375dc4d","https://git.kernel.org/stable/c/befab3a278c59db0cc88c8799638064f6d3fd6f8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50209
|
High |
fixed |
- 5.10.229
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/bnxt_re: Add a check for memory allocation
__alloc_pbl() can return error when memory allocation fails.
Driver is not checking the status on one of the instances. |
["https://git.kernel.org/stable/c/322a19baaaa25a1fe8ce9fceaed9409ad847844c","https://git.kernel.org/stable/c/76dd679c3b148d23f72dcf6c3cde3d5f746b2c07","https://git.kernel.org/stable/c/ba9045887b435a4c5551245ae034b8791b4e4aaa","https://git.kernel.org/stable/c/c5c1ae73b7741fa3b58e6e001b407825bb971225","https://git.kernel.org/stable/c/c71957271f2e8133a6aa82001c2fa671d5008129","https://git.kernel.org/stable/c/dbe51dd516e6d4e655f31c8a1cbc050dde7ba97b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-31436
|
High |
fixed |
- 4.14.314
- 4.19.282
- 5.4.242
- 5.10.179
- 5.15.109
- 6.1.26
- 6.2.13
|
qfq_change_class in net/sched/sch_qfq.c in the Linux kernel before 6.2.13 allows an out-of-bounds write because lmax can exceed QFQ_MIN_LMAX. |
["http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html","http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.13","https://github.com/torvalds/linux/commit/3037933448f60f9acb705997eae62013ecb81e0d","https://lists.debian.org/debian-lts-announce/2023/06/msg00008.html","https://security.netapp.com/advisory/ntap-20230609-0001/","https://www.debian.org/security/2023/dsa-5402","https://www.spinics.net/lists/stable-commits/msg294885.html","http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html","http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.13","https://github.com/torvalds/linux/commit/3037933448f60f9acb705997eae62013ecb81e0d","https://lists.debian.org/debian-lts-announce/2023/06/msg00008.html","https://security.netapp.com/advisory/ntap-20230609-0001/","https://www.debian.org/security/2023/dsa-5402","https://www.spinics.net/lists/stable-commits/msg294885.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53059
|
High |
fixed |
- 5.4.285
- 5.10.229
- 5.15.171
- 6.1.116
- 6.6.60
- 6.11.7
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()
1. The size of the response packet is not validated.
2. The response buffer is not freed.
Resolve these issues by switching to iwl_mvm_send_cmd_status(),
which handles both size validation and frees the buffer. |
["https://git.kernel.org/stable/c/07a6e3b78a65f4b2796a8d0d4adb1a15a81edead","https://git.kernel.org/stable/c/3eb986c64c6bfb721950f9666a3b723cf65d043f","https://git.kernel.org/stable/c/3f45d590ccbae6dfd6faef54efe74c30bd85d3da","https://git.kernel.org/stable/c/45a628911d3c68e024eed337054a0452b064f450","https://git.kernel.org/stable/c/64d63557ded6ff3ce72b18ab87a6c4b1b652161c","https://git.kernel.org/stable/c/9480c3045f302f43f9910d2d556d6cf5a62c1822","https://git.kernel.org/stable/c/9c98ee7ea463a838235e7a0e35851b38476364f2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3776
|
High |
fixed |
- 4.14.322
- 4.19.291
- 5.4.251
- 5.10.188
- 5.15.121
- 6.1.40
- 6.4.5
|
A use-after-free vulnerability in the Linux kernel's net/sched: cls_fw component can be exploited to achieve local privilege escalation.
If tcf_change_indev() fails, fw_set_parms() will immediately return an error after incrementing or decrementing the reference counter in tcf_bind_filter(). If an attacker can control the reference counter and set it to zero, they can cause the reference to be freed, leading to a use-after-free vulnerability.
We recommend upgrading past commit 0323bce598eea038714f941ce2b22541c46d488f. |
["http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=0323bce598eea038714f941ce2b22541c46d488f","https://kernel.dance/0323bce598eea038714f941ce2b22541c46d488f","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20240202-0003/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492","http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=0323bce598eea038714f941ce2b22541c46d488f","https://kernel.dance/0323bce598eea038714f941ce2b22541c46d488f","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20240202-0003/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38662
|
Medium |
fixed |
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.9.4
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Allow delete from sockmap/sockhash only if update is allowed
We have seen an influx of syzkaller reports where a BPF program attached to
a tracepoint triggers a locking rule violation by performing a map_delete
on a sockmap/sockhash.
We don't intend to support this artificial use scenario. Extend the
existing verifier allowed-program-type check for updating sockmap/sockhash
to also cover deleting from a map.
From now on only BPF programs which were previously allowed to update
sockmap/sockhash can delete from these map types. |
["https://git.kernel.org/stable/c/000a65bf1dc04fb2b65e2abf116f0bc0fc2ee7b1","https://git.kernel.org/stable/c/11e8ecc5b86037fec43d07b1c162e233e131b1d9","https://git.kernel.org/stable/c/29467edc23818dc5a33042ffb4920b49b090e63d","https://git.kernel.org/stable/c/6693b172f008846811f48a099f33effc26068e1e","https://git.kernel.org/stable/c/98e948fb60d41447fd8d2d0c3b8637fc6b6dc26d","https://git.kernel.org/stable/c/b81e1c5a3c70398cf76631ede63a03616ed1ba3c","https://git.kernel.org/stable/c/000a65bf1dc04fb2b65e2abf116f0bc0fc2ee7b1","https://git.kernel.org/stable/c/11e8ecc5b86037fec43d07b1c162e233e131b1d9","https://git.kernel.org/stable/c/29467edc23818dc5a33042ffb4920b49b090e63d","https://git.kernel.org/stable/c/6693b172f008846811f48a099f33effc26068e1e","https://git.kernel.org/stable/c/98e948fb60d41447fd8d2d0c3b8637fc6b6dc26d","https://git.kernel.org/stable/c/b81e1c5a3c70398cf76631ede63a03616ed1ba3c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-47432
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
lib/generic-radix-tree.c: Don't overflow in peek()
When we started spreading new inode numbers throughout most of the 64
bit inode space, that triggered some corner case bugs, in particular
some integer overflows related to the radix tree code. Oops. |
["https://git.kernel.org/stable/c/784d01f9bbc282abb0c5ade5beb98a87f50343ac","https://git.kernel.org/stable/c/9492261ff2460252cf2d8de89cdf854c7e2b28a0","https://git.kernel.org/stable/c/aa7f1827953100cdde0795289a80c6c077bfe437","https://git.kernel.org/stable/c/ec298b958cb0c40d70c68079da933c8f31c5134c","https://git.kernel.org/stable/c/784d01f9bbc282abb0c5ade5beb98a87f50343ac","https://git.kernel.org/stable/c/9492261ff2460252cf2d8de89cdf854c7e2b28a0","https://git.kernel.org/stable/c/aa7f1827953100cdde0795289a80c6c077bfe437","https://git.kernel.org/stable/c/ec298b958cb0c40d70c68079da933c8f31c5134c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48692
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srp: Set scmnd->result only when scmnd is not NULL
This change fixes the following kernel NULL pointer dereference
which is reproduced by blktests srp/007 occasionally.
BUG: kernel NULL pointer dereference, address: 0000000000000170
PGD 0 P4D 0
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 9 Comm: kworker/0:1H Kdump: loaded Not tainted 6.0.0-rc1+ #37
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-29-g6a62e0cb0dfe-prebuilt.qemu.org 04/01/2014
Workqueue: 0x0 (kblockd)
RIP: 0010:srp_recv_done+0x176/0x500 [ib_srp]
Code: 00 4d 85 ff 0f 84 52 02 00 00 48 c7 82 80 02 00 00 00 00 00 00 4c 89 df 4c 89 14 24 e8 53 d3 4a f6 4c 8b 14 24 41 0f b6 42 13 <41> 89 87 70 01 00 00 41 0f b6 52 12 f6 c2 02 74 44 41 8b 42 1c b9
RSP: 0018:ffffaef7c0003e28 EFLAGS: 00000282
RAX: 0000000000000000 RBX: ffff9bc9486dea60 RCX: 0000000000000000
RDX: 0000000000000102 RSI: ffffffffb76bbd0e RDI: 00000000ffffffff
RBP: ffff9bc980099a00 R08: 0000000000000001 R09: 0000000000000001
R10: ffff9bca53ef0000 R11: ffff9bc980099a10 R12: ffff9bc956e14000
R13: ffff9bc9836b9cb0 R14: ffff9bc9557b4480 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff9bc97ec00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000170 CR3: 0000000007e04000 CR4: 00000000000006f0
Call Trace:
<IRQ>
__ib_process_cq+0xb7/0x280 [ib_core]
ib_poll_handler+0x2b/0x130 [ib_core]
irq_poll_softirq+0x93/0x150
__do_softirq+0xee/0x4b8
irq_exit_rcu+0xf7/0x130
sysvec_apic_timer_interrupt+0x8e/0xc0
</IRQ> |
["https://git.kernel.org/stable/c/12f35199a2c0551187edbf8eb01379f0598659fa","https://git.kernel.org/stable/c/a8edd49c94b4b08019ed7d6dd794fca8078a4deb","https://git.kernel.org/stable/c/f022576aa03c2385ea7f2b27ee5b331e43abf624","https://git.kernel.org/stable/c/f2c70f56f762e5dc3b0d7dc438fbb137cb116413","https://git.kernel.org/stable/c/12f35199a2c0551187edbf8eb01379f0598659fa","https://git.kernel.org/stable/c/a8edd49c94b4b08019ed7d6dd794fca8078a4deb","https://git.kernel.org/stable/c/f022576aa03c2385ea7f2b27ee5b331e43abf624","https://git.kernel.org/stable/c/f2c70f56f762e5dc3b0d7dc438fbb137cb116413"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52653
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: fix a memleak in gss_import_v2_context
The ctx->mech_used.data allocated by kmemdup is not freed in neither
gss_import_v2_context nor it only caller gss_krb5_import_sec_context,
which frees ctx on error.
Thus, this patch reform the last call of gss_import_v2_context to the
gss_krb5_import_ctx_v2, preventing the memleak while keepping the return
formation. |
["https://git.kernel.org/stable/c/47ac11db93e74ac49cd6c3fc69bcbc5964c4a8b4","https://git.kernel.org/stable/c/99044c01ed5329e73651c054d8a4baacdbb1a27c","https://git.kernel.org/stable/c/d111e30d9cd846bb368faf3637dc0f71fcbcf822","https://git.kernel.org/stable/c/e67b652d8e8591d3b1e569dbcdfcee15993e91fa","https://git.kernel.org/stable/c/47ac11db93e74ac49cd6c3fc69bcbc5964c4a8b4","https://git.kernel.org/stable/c/99044c01ed5329e73651c054d8a4baacdbb1a27c","https://git.kernel.org/stable/c/d111e30d9cd846bb368faf3637dc0f71fcbcf822","https://git.kernel.org/stable/c/e67b652d8e8591d3b1e569dbcdfcee15993e91fa"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27041
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: fix NULL checks for adev->dm.dc in amdgpu_dm_fini()
Since 'adev->dm.dc' in amdgpu_dm_fini() might turn out to be NULL
before the call to dc_enable_dmub_notifications(), check
beforehand to ensure there will not be a possible NULL-ptr-deref
there.
Also, since commit 1e88eb1b2c25 ("drm/amd/display: Drop
CONFIG_DRM_AMD_DC_HDCP") there are two separate checks for NULL in
'adev->dm.dc' before dc_deinit_callbacks() and dc_dmub_srv_destroy().
Clean up by combining them all under one 'if'.
Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE. |
["https://git.kernel.org/stable/c/1c62697e4086de988b31124fb8c79c244ea05f2b","https://git.kernel.org/stable/c/2a3cfb9a24a28da9cc13d2c525a76548865e182c","https://git.kernel.org/stable/c/ca2eb375db76fd50f31afdd67d6ca4f833254957","https://git.kernel.org/stable/c/e040f1fbe9abae91b12b074cfc3bbb5367b79811","https://git.kernel.org/stable/c/1c62697e4086de988b31124fb8c79c244ea05f2b","https://git.kernel.org/stable/c/2a3cfb9a24a28da9cc13d2c525a76548865e182c","https://git.kernel.org/stable/c/ca2eb375db76fd50f31afdd67d6ca4f833254957","https://git.kernel.org/stable/c/e040f1fbe9abae91b12b074cfc3bbb5367b79811"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35865
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in smb2_is_valid_oplock_break()
Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF. |
["https://git.kernel.org/stable/c/21fed37d2bdcde33453faf61d3d4d96c355f04bd","https://git.kernel.org/stable/c/22863485a4626ec6ecf297f4cc0aef709bc862e4","https://git.kernel.org/stable/c/3dba0e5276f131e36d6d8043191d856f49238628","https://git.kernel.org/stable/c/84488466b7a69570bdbf76dd9576847ab97d54e7","https://git.kernel.org/stable/c/21fed37d2bdcde33453faf61d3d4d96c355f04bd","https://git.kernel.org/stable/c/22863485a4626ec6ecf297f4cc0aef709bc862e4","https://git.kernel.org/stable/c/3dba0e5276f131e36d6d8043191d856f49238628","https://git.kernel.org/stable/c/84488466b7a69570bdbf76dd9576847ab97d54e7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36479
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
fpga: bridge: add owner module and take its refcount
The current implementation of the fpga bridge assumes that the low-level
module registers a driver for the parent device and uses its owner pointer
to take the module's refcount. This approach is problematic since it can
lead to a null pointer dereference while attempting to get the bridge if
the parent device does not have a driver.
To address this problem, add a module owner pointer to the fpga_bridge
struct and use it to take the module's refcount. Modify the function for
registering a bridge to take an additional owner module parameter and
rename it to avoid conflicts. Use the old function name for a helper macro
that automatically sets the module that registers the bridge as the owner.
This ensures compatibility with existing low-level control modules and
reduces the chances of registering a bridge without setting the owner.
Also, update the documentation to keep it consistent with the new interface
for registering an fpga bridge.
Other changes: opportunistically move put_device() from __fpga_bridge_get()
to fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since
the bridge device is taken in these functions. |
["https://git.kernel.org/stable/c/18dc8366abb6cadcb77668b1a16434654e355d49","https://git.kernel.org/stable/c/1da11f822042eb6ef4b6064dc048f157a7852529","https://git.kernel.org/stable/c/6896b6b2e2d9ec4e1b0acb4c1698a75a4b34d125","https://git.kernel.org/stable/c/d7c4081c54a1d4068de9440957303a76f9e5c95b","https://git.kernel.org/stable/c/1da11f822042eb6ef4b6064dc048f157a7852529","https://git.kernel.org/stable/c/6896b6b2e2d9ec4e1b0acb4c1698a75a4b34d125","https://git.kernel.org/stable/c/d7c4081c54a1d4068de9440957303a76f9e5c95b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-37021
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
fpga: manager: add owner module and take its refcount
The current implementation of the fpga manager assumes that the low-level
module registers a driver for the parent device and uses its owner pointer
to take the module's refcount. This approach is problematic since it can
lead to a null pointer dereference while attempting to get the manager if
the parent device does not have a driver.
To address this problem, add a module owner pointer to the fpga_manager
struct and use it to take the module's refcount. Modify the functions for
registering the manager to take an additional owner module parameter and
rename them to avoid conflicts. Use the old function names for helper
macros that automatically set the module that registers the manager as the
owner. This ensures compatibility with existing low-level control modules
and reduces the chances of registering a manager without setting the owner.
Also, update the documentation to keep it consistent with the new interface
for registering an fpga manager.
Other changes: opportunistically move put_device() from __fpga_mgr_get() to
fpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the
manager device is taken in these functions. |
["https://git.kernel.org/stable/c/2da62a139a6221a345db4eb9f4f1c4b0937c89ad","https://git.kernel.org/stable/c/304f8032d601d4f9322ca841cd0b573bd1beb158","https://git.kernel.org/stable/c/4d4d2d4346857bf778fafaa97d6f76bb1663e3c9","https://git.kernel.org/stable/c/62ac496a01c9337a11362cea427038ba621ca9eb","https://git.kernel.org/stable/c/2da62a139a6221a345db4eb9f4f1c4b0937c89ad","https://git.kernel.org/stable/c/4d4d2d4346857bf778fafaa97d6f76bb1663e3c9","https://git.kernel.org/stable/c/62ac496a01c9337a11362cea427038ba621ca9eb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46715
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
driver: iio: add missing checks on iio_info's callback access
Some callbacks from iio_info structure are accessed without any check, so
if a driver doesn't implement them trying to access the corresponding
sysfs entries produce a kernel oops such as:
[ 2203.527791] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute
[...]
[ 2203.783416] Call trace:
[ 2203.783429] iio_read_channel_info_avail from dev_attr_show+0x18/0x48
[ 2203.789807] dev_attr_show from sysfs_kf_seq_show+0x90/0x120
[ 2203.794181] sysfs_kf_seq_show from seq_read_iter+0xd0/0x4e4
[ 2203.798555] seq_read_iter from vfs_read+0x238/0x2a0
[ 2203.802236] vfs_read from ksys_read+0xa4/0xd4
[ 2203.805385] ksys_read from ret_fast_syscall+0x0/0x54
[ 2203.809135] Exception stack(0xe0badfa8 to 0xe0badff0)
[ 2203.812880] dfa0: 00000003 b6f10f80 00000003 b6eab000 00020000 00000000
[ 2203.819746] dfc0: 00000003 b6f10f80 7ff00000 00000003 00000003 00000000 00020000 00000000
[ 2203.826619] dfe0: b6e1bc88 bed80958 b6e1bc94 b6e1bcb0
[ 2203.830363] Code: bad PC value
[ 2203.832695] ---[ end trace 0000000000000000 ]--- |
["https://git.kernel.org/stable/c/0cc7e0ee31e5c44904e98e2229d591e093282a70","https://git.kernel.org/stable/c/72f022ebb9deac28663fa4c04ba315ed5d6654d1","https://git.kernel.org/stable/c/c4ec8dedca961db056ec85cb7ca8c9f7e2e92252","https://git.kernel.org/stable/c/dc537a72f64890d883d24ae4ac58733fc5bc523d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48693
|
Medium |
fixed |
- 4.19.258
- 5.4.213
- 5.10.143
- 5.15.68
- 5.19.9
|
In the Linux kernel, the following vulnerability has been resolved:
soc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs
In brcmstb_pm_probe(), there are two kinds of leak bugs:
(1) we need to add of_node_put() when for_each__matching_node() breaks
(2) we need to add iounmap() for each iomap in fail path |
["https://git.kernel.org/stable/c/0284b4e6dec6088a41607aa3f42bf51edff01883","https://git.kernel.org/stable/c/1085f5080647f0c9f357c270a537869191f7f2a1","https://git.kernel.org/stable/c/43245c77d9efd8c9eb91bf225d07954dcf32204d","https://git.kernel.org/stable/c/57b2897ec3ffe4cbe018446be6d04432919dca6b","https://git.kernel.org/stable/c/653500b400d5576940b7429690f7197199ddcc82","https://git.kernel.org/stable/c/6dc0251638a4a1a998506dbd4627f8317e907558","https://git.kernel.org/stable/c/0284b4e6dec6088a41607aa3f42bf51edff01883","https://git.kernel.org/stable/c/1085f5080647f0c9f357c270a537869191f7f2a1","https://git.kernel.org/stable/c/43245c77d9efd8c9eb91bf225d07954dcf32204d","https://git.kernel.org/stable/c/57b2897ec3ffe4cbe018446be6d04432919dca6b","https://git.kernel.org/stable/c/653500b400d5576940b7429690f7197199ddcc82","https://git.kernel.org/stable/c/6dc0251638a4a1a998506dbd4627f8317e907558"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48708
|
Medium |
fixed |
- 4.14.306
- 4.19.273
- 5.4.232
- 5.10.168
- 5.15.94
- 6.1.12
|
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: single: fix potential NULL dereference
Added checking of pointer "function" in pcs_set_mux().
pinmux_generic_get_function() can return NULL and the pointer
"function" was dereferenced without checking against NULL.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/1177bdafe87cbe543a2dc48a9bbac265aa5864db","https://git.kernel.org/stable/c/2b763f7de108cb1a5ad5ed08e617d677341947cb","https://git.kernel.org/stable/c/6e2a0521e4e84a2698f2da3950fb5c5496a4d208","https://git.kernel.org/stable/c/71668706fbe7d20e6f172fa3287fa8aac1b56c26","https://git.kernel.org/stable/c/bcc487001a15f71f103d102cba4ac8145d7a68f2","https://git.kernel.org/stable/c/d2d73e6d4822140445ad4a7b1c6091e0f5fe703b","https://git.kernel.org/stable/c/e671e63587c92b3fd767cf82e73129f6d5feeb33","https://git.kernel.org/stable/c/1177bdafe87cbe543a2dc48a9bbac265aa5864db","https://git.kernel.org/stable/c/2b763f7de108cb1a5ad5ed08e617d677341947cb","https://git.kernel.org/stable/c/6e2a0521e4e84a2698f2da3950fb5c5496a4d208","https://git.kernel.org/stable/c/71668706fbe7d20e6f172fa3287fa8aac1b56c26","https://git.kernel.org/stable/c/bcc487001a15f71f103d102cba4ac8145d7a68f2","https://git.kernel.org/stable/c/d2d73e6d4822140445ad4a7b1c6091e0f5fe703b","https://git.kernel.org/stable/c/e671e63587c92b3fd767cf82e73129f6d5feeb33"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48836
|
Medium |
fixed |
- 4.9.308
- 4.14.273
- 4.19.236
- 5.4.187
- 5.10.108
- 5.15.31
- 5.16.17
|
In the Linux kernel, the following vulnerability has been resolved:
Input: aiptek - properly check endpoint type
Syzbot reported warning in usb_submit_urb() which is caused by wrong
endpoint type. There was a check for the number of endpoints, but not
for the type of endpoint.
Fix it by replacing old desc.bNumEndpoints check with
usb_find_common_endpoints() helper for finding endpoints
Fail log:
usb 5-1: BOGUS urb xfer, pipe 1 != type 3
WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
Modules linked in:
CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
Workqueue: usb_hub_wq hub_event
...
Call Trace:
<TASK>
aiptek_open+0xd5/0x130 drivers/input/tablet/aiptek.c:830
input_open_device+0x1bb/0x320 drivers/input/input.c:629
kbd_connect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593 |
["https://git.kernel.org/stable/c/35069e654bcab567ff8b9f0e68e1caf82c15dcd7","https://git.kernel.org/stable/c/5600f6986628dde8881734090588474f54a540a8","https://git.kernel.org/stable/c/57277a8b5d881e02051ba9d7f6cb3f915c229821","https://git.kernel.org/stable/c/6de20111cd0bb7da9b2294073ba00c7d2a6c1c4f","https://git.kernel.org/stable/c/e732b0412f8c603d1e998f3bff41b5e7d5c3914c","https://git.kernel.org/stable/c/e762f57ff255af28236cd02ca9fc5c7e5a089d31","https://git.kernel.org/stable/c/f0d43d22d24182b94d7eb78a2bf6ae7e2b33204a","https://git.kernel.org/stable/c/fc8033a55e2796d21e370260a784ac9fbb8305a6","https://git.kernel.org/stable/c/35069e654bcab567ff8b9f0e68e1caf82c15dcd7","https://git.kernel.org/stable/c/5600f6986628dde8881734090588474f54a540a8","https://git.kernel.org/stable/c/57277a8b5d881e02051ba9d7f6cb3f915c229821","https://git.kernel.org/stable/c/6de20111cd0bb7da9b2294073ba00c7d2a6c1c4f","https://git.kernel.org/stable/c/e732b0412f8c603d1e998f3bff41b5e7d5c3914c","https://git.kernel.org/stable/c/e762f57ff255af28236cd02ca9fc5c7e5a089d31","https://git.kernel.org/stable/c/f0d43d22d24182b94d7eb78a2bf6ae7e2b33204a","https://git.kernel.org/stable/c/fc8033a55e2796d21e370260a784ac9fbb8305a6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48838
|
Medium |
fixed |
- 4.9.308
- 4.14.273
- 4.19.236
- 5.4.187
- 5.10.108
- 5.15.31
- 5.16.17
|
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: Fix use-after-free bug by not setting udc->dev.driver
The syzbot fuzzer found a use-after-free bug:
BUG: KASAN: use-after-free in dev_uevent+0x712/0x780 drivers/base/core.c:2320
Read of size 8 at addr ffff88802b934098 by task udevd/3689
CPU: 2 PID: 3689 Comm: udevd Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255
__kasan_report mm/kasan/report.c:442 [inline]
kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
dev_uevent+0x712/0x780 drivers/base/core.c:2320
uevent_show+0x1b8/0x380 drivers/base/core.c:2391
dev_attr_show+0x4b/0x90 drivers/base/core.c:2094
Although the bug manifested in the driver core, the real cause was a
race with the gadget core. dev_uevent() does:
if (dev->driver)
add_uevent_var(env, "DRIVER=%s", dev->driver->name);
and between the test and the dereference of dev->driver, the gadget
core sets dev->driver to NULL.
The race wouldn't occur if the gadget core registered its devices on
a real bus, using the standard synchronization techniques of the
driver core. However, it's not necessary to make such a large change
in order to fix this bug; all we need to do is make sure that
udc->dev.driver is always NULL.
In fact, there is no reason for udc->dev.driver ever to be set to
anything, let alone to the value it currently gets: the address of the
gadget's driver. After all, a gadget driver only knows how to manage
a gadget, not how to manage a UDC.
This patch simply removes the statements in the gadget core that touch
udc->dev.driver. |
["https://git.kernel.org/stable/c/00bdd9bf1ac6d401ad926d3d8df41b9f1399f646","https://git.kernel.org/stable/c/16b1941eac2bd499f065a6739a40ce0011a3d740","https://git.kernel.org/stable/c/2015c23610cd0efadaeca4d3a8d1dae9a45aa35a","https://git.kernel.org/stable/c/2282a6eb6d4e118e294e43dcc421e0e0fe4040b5","https://git.kernel.org/stable/c/27d64436984fb8835a8b7e95993193cc478b162e","https://git.kernel.org/stable/c/4325124dde6726267813c736fee61226f1d38f0b","https://git.kernel.org/stable/c/609a7119bffe3ddd7c93f2fa65be8917e02a0b7e","https://git.kernel.org/stable/c/e2d3a7009e505e120805f449c832942660f3f7f3","https://git.kernel.org/stable/c/00bdd9bf1ac6d401ad926d3d8df41b9f1399f646","https://git.kernel.org/stable/c/16b1941eac2bd499f065a6739a40ce0011a3d740","https://git.kernel.org/stable/c/2015c23610cd0efadaeca4d3a8d1dae9a45aa35a","https://git.kernel.org/stable/c/2282a6eb6d4e118e294e43dcc421e0e0fe4040b5","https://git.kernel.org/stable/c/27d64436984fb8835a8b7e95993193cc478b162e","https://git.kernel.org/stable/c/4325124dde6726267813c736fee61226f1d38f0b","https://git.kernel.org/stable/c/609a7119bffe3ddd7c93f2fa65be8917e02a0b7e","https://git.kernel.org/stable/c/e2d3a7009e505e120805f449c832942660f3f7f3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52662
|
Medium |
fixed |
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: fix a memleak in vmw_gmrid_man_get_node
When ida_alloc_max fails, resources allocated before should be freed,
including *res allocated by kmalloc and ttm_resource_init. |
["https://git.kernel.org/stable/c/03b1072616a8f7d6e8594f643b416a9467c83fbf","https://git.kernel.org/stable/c/40624af6674745e174c754a20d7c53c250e65e7a","https://git.kernel.org/stable/c/6fc6233f6db1579b69b54b44571f1a7fde8186e6","https://git.kernel.org/stable/c/83e0f220d1e992fa074157fcf14945bf170ffbc5","https://git.kernel.org/stable/c/89709105a6091948ffb6ec2427954cbfe45358ce","https://git.kernel.org/stable/c/d1e546ab91c670e536a274a75481034ab7534876","https://git.kernel.org/stable/c/03b1072616a8f7d6e8594f643b416a9467c83fbf","https://git.kernel.org/stable/c/40624af6674745e174c754a20d7c53c250e65e7a","https://git.kernel.org/stable/c/6fc6233f6db1579b69b54b44571f1a7fde8186e6","https://git.kernel.org/stable/c/83e0f220d1e992fa074157fcf14945bf170ffbc5","https://git.kernel.org/stable/c/89709105a6091948ffb6ec2427954cbfe45358ce","https://git.kernel.org/stable/c/d1e546ab91c670e536a274a75481034ab7534876"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52826
|
Medium |
fixed |
- 5.10.202
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/panel/panel-tpo-tpg110: fix a possible null pointer dereference
In tpg110_get_modes(), the return value of drm_mode_duplicate() is
assigned to mode, which will lead to a NULL pointer dereference on
failure of drm_mode_duplicate(). Add a check to avoid npd. |
["https://git.kernel.org/stable/c/84c923d898905187ebfd4c0ef38cd1450af7e0ea","https://git.kernel.org/stable/c/9268bfd76bebc85ff221691b61498cc16d75451c","https://git.kernel.org/stable/c/9acc2bc00135e9ecd13a70ce1140e2673e504cdc","https://git.kernel.org/stable/c/d0bc9ab0a161a9745273f5bf723733a8e6c57aca","https://git.kernel.org/stable/c/eaede6900c0961b072669d6bd97fe8f90ed1900f","https://git.kernel.org/stable/c/f22def5970c423ea7f87d5247bd0ef91416b0658","https://git.kernel.org/stable/c/84c923d898905187ebfd4c0ef38cd1450af7e0ea","https://git.kernel.org/stable/c/9268bfd76bebc85ff221691b61498cc16d75451c","https://git.kernel.org/stable/c/9acc2bc00135e9ecd13a70ce1140e2673e504cdc","https://git.kernel.org/stable/c/d0bc9ab0a161a9745273f5bf723733a8e6c57aca","https://git.kernel.org/stable/c/eaede6900c0961b072669d6bd97fe8f90ed1900f","https://git.kernel.org/stable/c/f22def5970c423ea7f87d5247bd0ef91416b0658"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52833
|
Medium |
fixed |
- 5.10.202
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btusb: Add date->evt_skb is NULL check
fix crash because of null pointers
[ 6104.969662] BUG: kernel NULL pointer dereference, address: 00000000000000c8
[ 6104.969667] #PF: supervisor read access in kernel mode
[ 6104.969668] #PF: error_code(0x0000) - not-present page
[ 6104.969670] PGD 0 P4D 0
[ 6104.969673] Oops: 0000 [#1] SMP NOPTI
[ 6104.969684] RIP: 0010:btusb_mtk_hci_wmt_sync+0x144/0x220 [btusb]
[ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246
[ 6104.969689] RAX: 0000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000000000006
[ 6104.969691] RDX: 0000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000
[ 6104.969692] RBP: ffffb8d681533d70 R08: 0000000000000001 R09: 0000000000000001
[ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0
[ 6104.969695] R13: 0000000000000000 R14: ffff8ad459618c18 R15: ffffb8d681533d90
[ 6104.969697] FS: 00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000
[ 6104.969699] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0
[ 6104.969701] PKRU: 55555554
[ 6104.969702] Call Trace:
[ 6104.969708] btusb_mtk_shutdown+0x44/0x80 [btusb]
[ 6104.969732] hci_dev_do_close+0x470/0x5c0 [bluetooth]
[ 6104.969748] hci_rfkill_set_block+0x56/0xa0 [bluetooth]
[ 6104.969753] rfkill_set_block+0x92/0x160
[ 6104.969755] rfkill_fop_write+0x136/0x1e0
[ 6104.969759] __vfs_write+0x18/0x40
[ 6104.969761] vfs_write+0xdf/0x1c0
[ 6104.969763] ksys_write+0xb1/0xe0
[ 6104.969765] __x64_sys_write+0x1a/0x20
[ 6104.969769] do_syscall_64+0x51/0x180
[ 6104.969771] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 6104.969773] RIP: 0033:0x7f5a21f18fef
[ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
[ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef
[ 6104.969781] RDX: 0000000000000008 RSI: 00007ffeefe39060 RDI: 0000000000000012
[ 6104.969782] RBP: 00007ffeefe39060 R08: 0000000000000000 R09: 0000000000000017
[ 6104.969784] R10: 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002
[ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0 |
["https://git.kernel.org/stable/c/0048ddf045bddc4dacb3e783fd869a2f8fb5be30","https://git.kernel.org/stable/c/13b1ebad4c175e6a9b0748acbf133c21a15d282a","https://git.kernel.org/stable/c/624820f7c8826dd010e8b1963303c145f99816e9","https://git.kernel.org/stable/c/9f8e4d1a4ca1179aaeb43f91f3e2a386e7e616b3","https://git.kernel.org/stable/c/a556f2ef556a04790f67f2fa272f1a77336d15a0","https://git.kernel.org/stable/c/f9de14bde56dcbb0765284c6dfc35842b021733c","https://git.kernel.org/stable/c/0048ddf045bddc4dacb3e783fd869a2f8fb5be30","https://git.kernel.org/stable/c/13b1ebad4c175e6a9b0748acbf133c21a15d282a","https://git.kernel.org/stable/c/624820f7c8826dd010e8b1963303c145f99816e9","https://git.kernel.org/stable/c/9f8e4d1a4ca1179aaeb43f91f3e2a386e7e616b3","https://git.kernel.org/stable/c/a556f2ef556a04790f67f2fa272f1a77336d15a0","https://git.kernel.org/stable/c/f9de14bde56dcbb0765284c6dfc35842b021733c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52841
|
Medium |
fixed |
- 5.10.201
- 5.15.139
- 6.1.63
- 6.5.12
- 6.6.2
|
In the Linux kernel, the following vulnerability has been resolved:
media: vidtv: mux: Add check and kfree for kstrdup
Add check for the return value of kstrdup() and return the error
if it fails in order to avoid NULL pointer dereference.
Moreover, use kfree() in the later error handling in order to avoid
memory leak. |
["https://git.kernel.org/stable/c/1fd6eb12642e0c32692924ff359c07de4b781d78","https://git.kernel.org/stable/c/64863ba8e6b7651d994c6e6d506cc8aa2ac45edb","https://git.kernel.org/stable/c/980be4c3b0d51c0f873fd750117774561c66cf68","https://git.kernel.org/stable/c/a254ee1ddc592ae1efcce96b8c014e1bd2d5a2b4","https://git.kernel.org/stable/c/aae7598aff291d4d140be1355aa20930af948785","https://git.kernel.org/stable/c/cb13001411999adb158b39e76d94705eb2da100d","https://git.kernel.org/stable/c/1fd6eb12642e0c32692924ff359c07de4b781d78","https://git.kernel.org/stable/c/64863ba8e6b7651d994c6e6d506cc8aa2ac45edb","https://git.kernel.org/stable/c/980be4c3b0d51c0f873fd750117774561c66cf68","https://git.kernel.org/stable/c/a254ee1ddc592ae1efcce96b8c014e1bd2d5a2b4","https://git.kernel.org/stable/c/aae7598aff291d4d140be1355aa20930af948785","https://git.kernel.org/stable/c/cb13001411999adb158b39e76d94705eb2da100d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52863
|
Medium |
fixed |
- 5.10.201
- 5.15.139
- 6.1.63
- 6.5.12
- 6.6.2
|
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (axi-fan-control) Fix possible NULL pointer dereference
axi_fan_control_irq_handler(), dependent on the private
axi_fan_control_data structure, might be called before the hwmon
device is registered. That will cause an "Unable to handle kernel
NULL pointer dereference" error. |
["https://git.kernel.org/stable/c/2a5b3370a1d9750eca325292e291c8c7cb8cf2e0","https://git.kernel.org/stable/c/33de53a2706066d526173dc743faf43d92c62105","https://git.kernel.org/stable/c/7d870088db4863c514a7f8751cd593751983029a","https://git.kernel.org/stable/c/b3e7eb23a6e97642ff3190431c06475d9ca1e062","https://git.kernel.org/stable/c/c49f14cc1bb12c625a1c572e8a95b6adefd4d8eb","https://git.kernel.org/stable/c/f62b8969847850ba7596cb145cc47c65ea57dae0","https://git.kernel.org/stable/c/2a5b3370a1d9750eca325292e291c8c7cb8cf2e0","https://git.kernel.org/stable/c/33de53a2706066d526173dc743faf43d92c62105","https://git.kernel.org/stable/c/7d870088db4863c514a7f8751cd593751983029a","https://git.kernel.org/stable/c/b3e7eb23a6e97642ff3190431c06475d9ca1e062","https://git.kernel.org/stable/c/c49f14cc1bb12c625a1c572e8a95b6adefd4d8eb","https://git.kernel.org/stable/c/f62b8969847850ba7596cb145cc47c65ea57dae0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52873
|
Medium |
fixed |
- 5.4.261
- 5.10.201
- 5.15.139
- 6.1.63
- 6.5.12
- 6.6.2
|
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt6779: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to
avoid NULL pointer dereference. |
["https://git.kernel.org/stable/c/1f57f78fbacf630430bf954e5a84caafdfea30c0","https://git.kernel.org/stable/c/3994387ba3564976731179c4d4a6d7850ddda71a","https://git.kernel.org/stable/c/a90239551abc181687f8c0ba60b276f7d75c141e","https://git.kernel.org/stable/c/ca6d565a2319d69d9766e6ecbb5af827fc4afb2b","https://git.kernel.org/stable/c/df1c4a9efa3f5b6fb5e0ae63890230dbe2190b7e","https://git.kernel.org/stable/c/f6a7c51cf07a399ec067d39f0a22f1817c5c7d2b","https://git.kernel.org/stable/c/fbe466f06d4ea18745da0d57540539b7b36936ae","https://git.kernel.org/stable/c/1f57f78fbacf630430bf954e5a84caafdfea30c0","https://git.kernel.org/stable/c/3994387ba3564976731179c4d4a6d7850ddda71a","https://git.kernel.org/stable/c/a90239551abc181687f8c0ba60b276f7d75c141e","https://git.kernel.org/stable/c/ca6d565a2319d69d9766e6ecbb5af827fc4afb2b","https://git.kernel.org/stable/c/df1c4a9efa3f5b6fb5e0ae63890230dbe2190b7e","https://git.kernel.org/stable/c/f6a7c51cf07a399ec067d39f0a22f1817c5c7d2b","https://git.kernel.org/stable/c/fbe466f06d4ea18745da0d57540539b7b36936ae"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52876
|
Medium |
fixed |
- 5.4.261
- 5.10.201
- 5.15.139
- 6.1.63
- 6.5.12
- 6.6.2
|
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt7629-eth: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to
avoid NULL pointer dereference. |
["https://git.kernel.org/stable/c/0884393c63cc9a1772f7121a6645ba7bd76feeb9","https://git.kernel.org/stable/c/1639072f6260babd017556e9f236ca2ad589d1e7","https://git.kernel.org/stable/c/96e9544a0c4faca616b3f9f4034dcd83a14e7f22","https://git.kernel.org/stable/c/a540ca0aeae83c2f3964bcb4e383f64ce2ec1783","https://git.kernel.org/stable/c/b20cfe007a46f8c165d42a05c50a8d3d893e6592","https://git.kernel.org/stable/c/c4070ada5d5155c8d4d17ea64bd246949889f25b","https://git.kernel.org/stable/c/cfa68e0ac5dcde43577adadf6f0f26f3b365ad68","https://git.kernel.org/stable/c/0884393c63cc9a1772f7121a6645ba7bd76feeb9","https://git.kernel.org/stable/c/1639072f6260babd017556e9f236ca2ad589d1e7","https://git.kernel.org/stable/c/96e9544a0c4faca616b3f9f4034dcd83a14e7f22","https://git.kernel.org/stable/c/a540ca0aeae83c2f3964bcb4e383f64ce2ec1783","https://git.kernel.org/stable/c/b20cfe007a46f8c165d42a05c50a8d3d893e6592","https://git.kernel.org/stable/c/c4070ada5d5155c8d4d17ea64bd246949889f25b","https://git.kernel.org/stable/c/cfa68e0ac5dcde43577adadf6f0f26f3b365ad68"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26950
|
Medium |
fixed |
- 5.10.215
- 5.15.154
- 6.1.84
- 6.6.24
- 6.7.12
- 6.8.3
|
In the Linux kernel, the following vulnerability has been resolved:
wireguard: netlink: access device through ctx instead of peer
The previous commit fixed a bug that led to a NULL peer->device being
dereferenced. It's actually easier and faster performance-wise to
instead get the device from ctx->wg. This semantically makes more sense
too, since ctx->wg->peer_allowedips.seq is compared with
ctx->allowedips_seq, basing them both in ctx. This also acts as a
defence in depth provision against freed peers. |
["https://git.kernel.org/stable/c/09c3fa70f65175861ca948cb2f0f791e666c90e5","https://git.kernel.org/stable/c/493aa6bdcffd90a4f82aa614fe4f4db0641b4068","https://git.kernel.org/stable/c/4be453271a882c8ebc28df3dbf9e4d95e6ac42f5","https://git.kernel.org/stable/c/71cbd32e3db82ea4a74e3ef9aeeaa6971969c86f","https://git.kernel.org/stable/c/93bcc1752c69bb309f4d8cfaf960ef1faeb34996","https://git.kernel.org/stable/c/c991567e6c638079304cc15dff28748e4a3c4a37","https://git.kernel.org/stable/c/d44bd323d8bb8031eef4bdc44547925998a11e47","https://git.kernel.org/stable/c/09c3fa70f65175861ca948cb2f0f791e666c90e5","https://git.kernel.org/stable/c/493aa6bdcffd90a4f82aa614fe4f4db0641b4068","https://git.kernel.org/stable/c/4be453271a882c8ebc28df3dbf9e4d95e6ac42f5","https://git.kernel.org/stable/c/71cbd32e3db82ea4a74e3ef9aeeaa6971969c86f","https://git.kernel.org/stable/c/93bcc1752c69bb309f4d8cfaf960ef1faeb34996","https://git.kernel.org/stable/c/c991567e6c638079304cc15dff28748e4a3c4a37","https://git.kernel.org/stable/c/d44bd323d8bb8031eef4bdc44547925998a11e47","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26964
|
Medium |
fixed |
- 5.15.154
- 6.1.84
- 6.6.24
- 6.7.12
- 6.8.3
|
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Add error handling in xhci_map_urb_for_dma
Currently xhci_map_urb_for_dma() creates a temporary buffer and copies
the SG list to the new linear buffer. But if the kzalloc_node() fails,
then the following sg_pcopy_to_buffer() can lead to crash since it
tries to memcpy to NULL pointer.
So return -ENOMEM if kzalloc returns null pointer. |
["https://git.kernel.org/stable/c/4a49d24fdec0a802aa686a567a3989a9fdf4e5dd","https://git.kernel.org/stable/c/620b6cf2f1a270f48d38e6b8ce199c1acb3e90f4","https://git.kernel.org/stable/c/7b6cc33593d7ccfc3011b290849cfa899db46757","https://git.kernel.org/stable/c/962300a360d24c5be5a188cda48da58a37e4304d","https://git.kernel.org/stable/c/b2c898469dfc388f619c6c972a28466cbb1442ea","https://git.kernel.org/stable/c/be95cc6d71dfd0cba66e3621c65413321b398052","https://git.kernel.org/stable/c/4a49d24fdec0a802aa686a567a3989a9fdf4e5dd","https://git.kernel.org/stable/c/620b6cf2f1a270f48d38e6b8ce199c1acb3e90f4","https://git.kernel.org/stable/c/7b6cc33593d7ccfc3011b290849cfa899db46757","https://git.kernel.org/stable/c/962300a360d24c5be5a188cda48da58a37e4304d","https://git.kernel.org/stable/c/b2c898469dfc388f619c6c972a28466cbb1442ea","https://git.kernel.org/stable/c/be95cc6d71dfd0cba66e3621c65413321b398052"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26970
|
Medium |
fixed |
- 5.10.215
- 5.15.154
- 6.1.84
- 6.6.24
- 6.7.12
- 6.8.3
|
In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: gcc-ipq6018: fix terminating of frequency table arrays
The frequency table arrays are supposed to be terminated with an
empty element. Add such entry to the end of the arrays where it
is missing in order to avoid possible out-of-bound access when
the table is traversed by functions like qcom_find_freq() or
qcom_find_freq_floor().
Only compile tested. |
["https://git.kernel.org/stable/c/421b135aceace99789c982f6a77ce9476564fb52","https://git.kernel.org/stable/c/852db52b45ea96dac2720f108e7c7331cd3738bb","https://git.kernel.org/stable/c/ae60e3342296f766f88911d39199f77b05f657a6","https://git.kernel.org/stable/c/b4527ee3de365a742215773d20f07db3e2c06f3b","https://git.kernel.org/stable/c/cdbc6e2d8108bc47895e5a901cfcaf799b00ca8d","https://git.kernel.org/stable/c/db4066e3ab6b3d918ae2b92734a89c04fe82cc1d","https://git.kernel.org/stable/c/dcb13b5c9ae8743f99a96f392186527c3df89198","https://git.kernel.org/stable/c/421b135aceace99789c982f6a77ce9476564fb52","https://git.kernel.org/stable/c/852db52b45ea96dac2720f108e7c7331cd3738bb","https://git.kernel.org/stable/c/ae60e3342296f766f88911d39199f77b05f657a6","https://git.kernel.org/stable/c/b4527ee3de365a742215773d20f07db3e2c06f3b","https://git.kernel.org/stable/c/cdbc6e2d8108bc47895e5a901cfcaf799b00ca8d","https://git.kernel.org/stable/c/db4066e3ab6b3d918ae2b92734a89c04fe82cc1d","https://git.kernel.org/stable/c/dcb13b5c9ae8743f99a96f392186527c3df89198","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27037
|
Medium |
fixed |
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
clk: zynq: Prevent null pointer dereference caused by kmalloc failure
The kmalloc() in zynq_clk_setup() will return null if the
physical memory has run out. As a result, if we use snprintf()
to write data to the null address, the null pointer dereference
bug will happen.
This patch uses a stack variable to replace the kmalloc(). |
["https://git.kernel.org/stable/c/01511ac7be8e45f80e637f6bf61af2d3d2dee9db","https://git.kernel.org/stable/c/0801c893fd48cdba66a3c8f44c3fe43cc67d3b85","https://git.kernel.org/stable/c/58a946ab43501f2eba058d24d96af0ad1122475b","https://git.kernel.org/stable/c/7938e9ce39d6779d2f85d822cc930f73420e54a6","https://git.kernel.org/stable/c/8c4889a9ea861d7be37463c10846eb75e1b49c9d","https://git.kernel.org/stable/c/ca976c6a592f789700200069ef9052493c0b73d8","https://git.kernel.org/stable/c/01511ac7be8e45f80e637f6bf61af2d3d2dee9db","https://git.kernel.org/stable/c/0801c893fd48cdba66a3c8f44c3fe43cc67d3b85","https://git.kernel.org/stable/c/58a946ab43501f2eba058d24d96af0ad1122475b","https://git.kernel.org/stable/c/7938e9ce39d6779d2f85d822cc930f73420e54a6","https://git.kernel.org/stable/c/8c4889a9ea861d7be37463c10846eb75e1b49c9d","https://git.kernel.org/stable/c/ca976c6a592f789700200069ef9052493c0b73d8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27047
|
Medium |
fixed |
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
net: phy: fix phy_get_internal_delay accessing an empty array
The phy_get_internal_delay function could try to access to an empty
array in the case that the driver is calling phy_get_internal_delay
without defining delay_values and rx-internal-delay-ps or
tx-internal-delay-ps is defined to 0 in the device-tree.
This will lead to "unable to handle kernel NULL pointer dereference at
virtual address 0". To avoid this kernel oops, the test should be delay
>= 0. As there is already delay < 0 test just before, the test could
only be size == 0. |
["https://git.kernel.org/stable/c/0307cf443308ecc6be9b2ca312bb31bae5e5a7ad","https://git.kernel.org/stable/c/06dd21045a7e8bc8701b0ebedcd9a30a6325878b","https://git.kernel.org/stable/c/0e939a002c8a7d66e60bd0ea6b281fb39d713c1a","https://git.kernel.org/stable/c/2a2ff709511617de9c6c072eeee82bcbbdfecaf8","https://git.kernel.org/stable/c/4469c0c5b14a0919f5965c7ceac96b523eb57b79","https://git.kernel.org/stable/c/589ec16174dd9378953b8232ae76fad0a96e1563","https://git.kernel.org/stable/c/c0691de7df1d51482a52cac93b7fe82fd9dd296b","https://git.kernel.org/stable/c/0307cf443308ecc6be9b2ca312bb31bae5e5a7ad","https://git.kernel.org/stable/c/06dd21045a7e8bc8701b0ebedcd9a30a6325878b","https://git.kernel.org/stable/c/0e939a002c8a7d66e60bd0ea6b281fb39d713c1a","https://git.kernel.org/stable/c/2a2ff709511617de9c6c072eeee82bcbbdfecaf8","https://git.kernel.org/stable/c/4469c0c5b14a0919f5965c7ceac96b523eb57b79","https://git.kernel.org/stable/c/589ec16174dd9378953b8232ae76fad0a96e1563","https://git.kernel.org/stable/c/c0691de7df1d51482a52cac93b7fe82fd9dd296b","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27051
|
Medium |
fixed |
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value
cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it
and return 0 in case of error.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/74b84d0d71180330efe67c82f973a87f828323e5","https://git.kernel.org/stable/c/9127599c075caff234359950117018a010dd01db","https://git.kernel.org/stable/c/b25b64a241d769e932a022e5c780cf135ef56035","https://git.kernel.org/stable/c/d951cf510fb0df91d3abac0121a59ebbc63c0567","https://git.kernel.org/stable/c/e6e3e51ffba0784782b1a076d7441605697ea3c6","https://git.kernel.org/stable/c/e72160cb6e23b78b41999d6885a34ce8db536095","https://git.kernel.org/stable/c/f661017e6d326ee187db24194cabb013d81bc2a6","https://git.kernel.org/stable/c/74b84d0d71180330efe67c82f973a87f828323e5","https://git.kernel.org/stable/c/9127599c075caff234359950117018a010dd01db","https://git.kernel.org/stable/c/b25b64a241d769e932a022e5c780cf135ef56035","https://git.kernel.org/stable/c/d951cf510fb0df91d3abac0121a59ebbc63c0567","https://git.kernel.org/stable/c/e6e3e51ffba0784782b1a076d7441605697ea3c6","https://git.kernel.org/stable/c/e72160cb6e23b78b41999d6885a34ce8db536095","https://git.kernel.org/stable/c/f661017e6d326ee187db24194cabb013d81bc2a6","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27054
|
Medium |
fixed |
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: fix double module refcount decrement
Once the discipline is associated with the device, deleting the device
takes care of decrementing the module's refcount. Doing it manually on
this error path causes refcount to artificially decrease on each error
while it should just stay the same. |
["https://git.kernel.org/stable/c/9fe0562179d8fa960afca0eaed6d4ba4122a3cc6","https://git.kernel.org/stable/c/ad999aa18103fa038787b6a8a55020abcf34df1a","https://git.kernel.org/stable/c/c3116e62ddeff79cae342147753ce596f01fcf06","https://git.kernel.org/stable/c/ebc5a3bd79e54f98c885c26f0862a27a02c487c5","https://git.kernel.org/stable/c/ec09bcab32fc4765e0cc97e1b72cdd067135f37e","https://git.kernel.org/stable/c/edbdb0d94143db46edd373cc93e433832d29fe19","https://git.kernel.org/stable/c/fa18aa507ea71d8914b6acb2c94db311c757c650","https://git.kernel.org/stable/c/ad999aa18103fa038787b6a8a55020abcf34df1a","https://git.kernel.org/stable/c/c3116e62ddeff79cae342147753ce596f01fcf06","https://git.kernel.org/stable/c/ebc5a3bd79e54f98c885c26f0862a27a02c487c5","https://git.kernel.org/stable/c/ec09bcab32fc4765e0cc97e1b72cdd067135f37e","https://git.kernel.org/stable/c/edbdb0d94143db46edd373cc93e433832d29fe19","https://git.kernel.org/stable/c/fa18aa507ea71d8914b6acb2c94db311c757c650"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27393
|
Medium |
fixed |
- 5.15.154
- 6.1.85
- 6.6.26
- 6.8.5
|
In the Linux kernel, the following vulnerability has been resolved:
xen-netfront: Add missing skb_mark_for_recycle
Notice that skb_mark_for_recycle() is introduced later than fixes tag in
commit 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling").
It is believed that fixes tag were missing a call to page_pool_release_page()
between v5.9 to v5.14, after which is should have used skb_mark_for_recycle().
Since v6.6 the call page_pool_release_page() were removed (in
commit 535b9c61bdef ("net: page_pool: hide page_pool_release_page()")
and remaining callers converted (in commit 6bfef2ec0172 ("Merge branch
'net-page_pool-remove-page_pool_release_page'")).
This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool: catch
page_pool memory leaks"). |
["https://git.kernel.org/stable/c/037965402a010898d34f4e35327d22c0a95cd51f","https://git.kernel.org/stable/c/27aa3e4b3088426b7e34584274ad45b5afaf7629","https://git.kernel.org/stable/c/4143b9479caa29bb2380f3620dcbe16ea84eb3b1","https://git.kernel.org/stable/c/7c1250796b6c262b505a46192f4716b8c6a6a8c6","https://git.kernel.org/stable/c/c8b7b2f158d9d4fb89cd2f68244af154f7549bb4","http://www.openwall.com/lists/oss-security/2024/05/08/4","http://xenbits.xen.org/xsa/advisory-457.html","https://git.kernel.org/stable/c/037965402a010898d34f4e35327d22c0a95cd51f","https://git.kernel.org/stable/c/27aa3e4b3088426b7e34584274ad45b5afaf7629","https://git.kernel.org/stable/c/4143b9479caa29bb2380f3620dcbe16ea84eb3b1","https://git.kernel.org/stable/c/7c1250796b6c262b505a46192f4716b8c6a6a8c6","https://git.kernel.org/stable/c/c8b7b2f158d9d4fb89cd2f68244af154f7549bb4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35829
|
Medium |
fixed |
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
drm/lima: fix a memleak in lima_heap_alloc
When lima_vm_map_bo fails, the resources need to be deallocated, or
there will be memleaks. |
["https://git.kernel.org/stable/c/04ae3eb470e52a3c41babe85ff8cee195e4dcbea","https://git.kernel.org/stable/c/4ab14eccf5578af1dd5668a5f2d771df27683cab","https://git.kernel.org/stable/c/746606d37d662c70ae1379fc658ee9c65f06880f","https://git.kernel.org/stable/c/8e25c0ee5665e8a768b8e21445db1f86e9156eb7","https://git.kernel.org/stable/c/ec6bb037e4a35fcbb5cd7bc78242d034ed893fcd","https://git.kernel.org/stable/c/f2e80ac9344aebbff576453d5c0290b332e187ed","https://git.kernel.org/stable/c/f6d51a91b41704704e395de6839c667b0f810bbf","https://git.kernel.org/stable/c/04ae3eb470e52a3c41babe85ff8cee195e4dcbea","https://git.kernel.org/stable/c/4ab14eccf5578af1dd5668a5f2d771df27683cab","https://git.kernel.org/stable/c/746606d37d662c70ae1379fc658ee9c65f06880f","https://git.kernel.org/stable/c/8e25c0ee5665e8a768b8e21445db1f86e9156eb7","https://git.kernel.org/stable/c/ec6bb037e4a35fcbb5cd7bc78242d034ed893fcd","https://git.kernel.org/stable/c/f2e80ac9344aebbff576453d5c0290b332e187ed","https://git.kernel.org/stable/c/f6d51a91b41704704e395de6839c667b0f810bbf","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35833
|
Medium |
fixed |
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.78
- 6.6.17
- 6.7.5
|
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: fsl-qdma: Fix a memory leak related to the queue command DMA
This dma_alloc_coherent() is undone neither in the remove function, nor in
the error handling path of fsl_qdma_probe().
Switch to the managed version to fix both issues. |
["https://git.kernel.org/stable/c/15eb996d7d13cb72a16389231945ada8f0fef2c3","https://git.kernel.org/stable/c/198270de9d8eb3b5d5f030825ea303ef95285d24","https://git.kernel.org/stable/c/1c75fe450b5200c78f4a102a0eb8e15d8f1ccda8","https://git.kernel.org/stable/c/25ab4d72eb7cbfa0f3d97a139a9b2bfcaa72dd59","https://git.kernel.org/stable/c/3aa58cb51318e329d203857f7a191678e60bb714","https://git.kernel.org/stable/c/5cd8a51517ce15edbdcea4fc74c4c127ddaa1bd6","https://git.kernel.org/stable/c/ae6769ba51417c1c86fb645812d5bff455eee802","https://git.kernel.org/stable/c/15eb996d7d13cb72a16389231945ada8f0fef2c3","https://git.kernel.org/stable/c/198270de9d8eb3b5d5f030825ea303ef95285d24","https://git.kernel.org/stable/c/1c75fe450b5200c78f4a102a0eb8e15d8f1ccda8","https://git.kernel.org/stable/c/25ab4d72eb7cbfa0f3d97a139a9b2bfcaa72dd59","https://git.kernel.org/stable/c/3aa58cb51318e329d203857f7a191678e60bb714","https://git.kernel.org/stable/c/5cd8a51517ce15edbdcea4fc74c4c127ddaa1bd6","https://git.kernel.org/stable/c/ae6769ba51417c1c86fb645812d5bff455eee802","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36008
|
Medium |
fixed |
- 5.10.216
- 5.15.158
- 6.1.90
- 6.6.30
- 6.8.9
|
In the Linux kernel, the following vulnerability has been resolved:
ipv4: check for NULL idev in ip_route_use_hint()
syzbot was able to trigger a NULL deref in fib_validate_source()
in an old tree [1].
It appears the bug exists in latest trees.
All calls to __in_dev_get_rcu() must be checked for a NULL result.
[1]
general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 2 PID: 3257 Comm: syz-executor.3 Not tainted 5.10.0-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:fib_validate_source+0xbf/0x15a0 net/ipv4/fib_frontend.c:425
Code: 18 f2 f2 f2 f2 42 c7 44 20 23 f3 f3 f3 f3 48 89 44 24 78 42 c6 44 20 27 f3 e8 5d 88 48 fc 4c 89 e8 48 c1 e8 03 48 89 44 24 18 <42> 80 3c 20 00 74 08 4c 89 ef e8 d2 15 98 fc 48 89 5c 24 10 41 bf
RSP: 0018:ffffc900015fee40 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0
RDX: 0000000000000000 RSI: 0000000004001eac RDI: ffff8880160c64c0
RBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000
R10: 0000000000000002 R11: ffff88800f4f90c0 R12: dffffc0000000000
R13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000
FS: 00007f938acfe6c0(0000) GS:ffff888058c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
ip_route_use_hint+0x410/0x9b0 net/ipv4/route.c:2231
ip_rcv_finish_core+0x2c4/0x1a30 net/ipv4/ip_input.c:327
ip_list_rcv_finish net/ipv4/ip_input.c:612 [inline]
ip_sublist_rcv+0x3ed/0xe50 net/ipv4/ip_input.c:638
ip_list_rcv+0x422/0x470 net/ipv4/ip_input.c:673
__netif_receive_skb_list_ptype net/core/dev.c:5572 [inline]
__netif_receive_skb_list_core+0x6b1/0x890 net/core/dev.c:5620
__netif_receive_skb_list net/core/dev.c:5672 [inline]
netif_receive_skb_list_internal+0x9f9/0xdc0 net/core/dev.c:5764
netif_receive_skb_list+0x55/0x3e0 net/core/dev.c:5816
xdp_recv_frames net/bpf/test_run.c:257 [inline]
xdp_test_run_batch net/bpf/test_run.c:335 [inline]
bpf_test_run_xdp_live+0x1818/0x1d00 net/bpf/test_run.c:363
bpf_prog_test_run_xdp+0x81f/0x1170 net/bpf/test_run.c:1376
bpf_prog_test_run+0x349/0x3c0 kernel/bpf/syscall.c:3736
__sys_bpf+0x45c/0x710 kernel/bpf/syscall.c:5115
__do_sys_bpf kernel/bpf/syscall.c:5201 [inline]
__se_sys_bpf kernel/bpf/syscall.c:5199 [inline]
__x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5199 |
["https://git.kernel.org/stable/c/03b5a9b2b526862b21bcc31976e393a6e63785d1","https://git.kernel.org/stable/c/58a4c9b1e5a3e53c9148e80b90e1e43897ce77d1","https://git.kernel.org/stable/c/7a25bfd12733a8f38f8ca47c581f876c3d481ac0","https://git.kernel.org/stable/c/7da0f91681c4902bc5c210356fdd963b04d5d1d4","https://git.kernel.org/stable/c/8240c7308c941db4d9a0a91b54eca843c616a655","https://git.kernel.org/stable/c/c71ea3534ec0936fc57e6fb271c7cc6a2f68c295","https://git.kernel.org/stable/c/03b5a9b2b526862b21bcc31976e393a6e63785d1","https://git.kernel.org/stable/c/58a4c9b1e5a3e53c9148e80b90e1e43897ce77d1","https://git.kernel.org/stable/c/7a25bfd12733a8f38f8ca47c581f876c3d481ac0","https://git.kernel.org/stable/c/7da0f91681c4902bc5c210356fdd963b04d5d1d4","https://git.kernel.org/stable/c/8240c7308c941db4d9a0a91b54eca843c616a655","https://git.kernel.org/stable/c/c71ea3534ec0936fc57e6fb271c7cc6a2f68c295","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36965
|
Medium |
|
N/A
|
In the Linux kernel, the following vulnerability has been resolved:
remoteproc: mediatek: Make sure IPI buffer fits in L2TCM
The IPI buffer location is read from the firmware that we load to the
System Companion Processor, and it's not granted that both the SRAM
(L2TCM) size that is defined in the devicetree node is large enough
for that, and while this is especially true for multi-core SCP, it's
still useful to check on single-core variants as well.
Failing to perform this check may make this driver perform R/W
operations out of the L2TCM boundary, resulting (at best) in a
kernel panic.
To fix that, check that the IPI buffer fits, otherwise return a
failure and refuse to boot the relevant SCP core (or the SCP at
all, if this is single core). |
["https://git.kernel.org/stable/c/00548ac6b14428719c970ef90adae2b3b48c0cdf","https://git.kernel.org/stable/c/1d9e2de24533daca36cbf09e8d8596bf72b526b2","https://git.kernel.org/stable/c/26c6d7dc8c6a9fde9d362ab2eef6390efeff145e","https://git.kernel.org/stable/c/331f91d86f71d0bb89a44217cc0b2a22810bbd42","https://git.kernel.org/stable/c/36c79eb4845551e9f6d28c663b38ce0ab03b84a9","https://git.kernel.org/stable/c/838b49e211d59fa827ff9df062d4020917cffbdf","https://git.kernel.org/stable/c/00548ac6b14428719c970ef90adae2b3b48c0cdf","https://git.kernel.org/stable/c/1d9e2de24533daca36cbf09e8d8596bf72b526b2","https://git.kernel.org/stable/c/26c6d7dc8c6a9fde9d362ab2eef6390efeff145e","https://git.kernel.org/stable/c/331f91d86f71d0bb89a44217cc0b2a22810bbd42","https://git.kernel.org/stable/c/36c79eb4845551e9f6d28c663b38ce0ab03b84a9","https://git.kernel.org/stable/c/838b49e211d59fa827ff9df062d4020917cffbdf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36967
|
Medium |
fixed |
- 5.15.160
- 6.1.92
- 6.6.32
- 6.8.11
- 6.9.2
|
In the Linux kernel, the following vulnerability has been resolved:
KEYS: trusted: Fix memory leak in tpm2_key_encode()
'scratch' is never freed. Fix this by calling kfree() in the success, and
in the error case. |
["https://git.kernel.org/stable/c/189c768932d435045b1fae12bf63e53866f06a28","https://git.kernel.org/stable/c/1e6914fa8e7798bcf3ce4a5b96ea4ac1d5571cdf","https://git.kernel.org/stable/c/5d91238b590bd883c86ba7707c5c9096469c08b7","https://git.kernel.org/stable/c/cf26a92f560eed5d6ddc3d441cc645950cbabc56","https://git.kernel.org/stable/c/e62835264d0352be6086975f18fdfed2b5520b13","https://git.kernel.org/stable/c/ffcaa2172cc1a85ddb8b783de96d38ca8855e248","https://git.kernel.org/stable/c/189c768932d435045b1fae12bf63e53866f06a28","https://git.kernel.org/stable/c/1e6914fa8e7798bcf3ce4a5b96ea4ac1d5571cdf","https://git.kernel.org/stable/c/5d91238b590bd883c86ba7707c5c9096469c08b7","https://git.kernel.org/stable/c/cf26a92f560eed5d6ddc3d441cc645950cbabc56","https://git.kernel.org/stable/c/e62835264d0352be6086975f18fdfed2b5520b13","https://git.kernel.org/stable/c/ffcaa2172cc1a85ddb8b783de96d38ca8855e248"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38571
|
Medium |
fixed |
- 5.15.161
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
thermal/drivers/tsens: Fix null pointer dereference
compute_intercept_slope() is called from calibrate_8960() (in tsens-8960.c)
as compute_intercept_slope(priv, p1, NULL, ONE_PT_CALIB) which lead to null
pointer dereference (if DEBUG or DYNAMIC_DEBUG set).
Fix this bug by adding null pointer check.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/06d17744b77bc6cb29a6c785f4fad8c4163ee653","https://git.kernel.org/stable/c/11c731386ed82053c2759b6fea1a82ae946e5e0f","https://git.kernel.org/stable/c/27600e0c5272a262b0903e35ae1df37d33c5c1ad","https://git.kernel.org/stable/c/2d5ca6e4a2872e92a32fdfd87e04dd7d3ced7278","https://git.kernel.org/stable/c/d998ddc86a27c92140b9f7984ff41e3d1d07a48f","https://git.kernel.org/stable/c/fcf5f1b5f308f2eb422f6aca55d295b25890906b","https://git.kernel.org/stable/c/06d17744b77bc6cb29a6c785f4fad8c4163ee653","https://git.kernel.org/stable/c/11c731386ed82053c2759b6fea1a82ae946e5e0f","https://git.kernel.org/stable/c/27600e0c5272a262b0903e35ae1df37d33c5c1ad","https://git.kernel.org/stable/c/2d5ca6e4a2872e92a32fdfd87e04dd7d3ced7278","https://git.kernel.org/stable/c/d998ddc86a27c92140b9f7984ff41e3d1d07a48f","https://git.kernel.org/stable/c/fcf5f1b5f308f2eb422f6aca55d295b25890906b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41097
|
Medium |
fixed |
- 4.19.317
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.97
- 6.6.37
- 6.9.8
|
In the Linux kernel, the following vulnerability has been resolved:
usb: atm: cxacru: fix endpoint checking in cxacru_bind()
Syzbot is still reporting quite an old issue [1] that occurs due to
incomplete checking of present usb endpoints. As such, wrong
endpoints types may be used at urb sumbitting stage which in turn
triggers a warning in usb_submit_urb().
Fix the issue by verifying that required endpoint types are present
for both in and out endpoints, taking into account cmd endpoint type.
Unfortunately, this patch has not been tested on real hardware.
[1] Syzbot report:
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
Modules linked in:
CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
...
Call Trace:
cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649
cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760
cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209
usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055
cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363
usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396
call_driver_probe drivers/base/dd.c:517 [inline]
really_probe+0x23c/0xcd0 drivers/base/dd.c:595
__driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747
driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777
__device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894
bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427
__device_attach+0x228/0x4a0 drivers/base/dd.c:965
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487
device_add+0xc2f/0x2180 drivers/base/core.c:3354
usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170
usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238
usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293 |
["https://git.kernel.org/stable/c/1aac4be1aaa5177506219f01dce5e29194e5e95a","https://git.kernel.org/stable/c/23926d316d2836315cb113569f91393266eb5b47","https://git.kernel.org/stable/c/2eabb655a968b862bc0c31629a09f0fbf3c80d51","https://git.kernel.org/stable/c/5159a81924311c1ec786ad9fdef784ead8676a6a","https://git.kernel.org/stable/c/5584c776a1af7807ca815ee6265f2c1429fc5727","https://git.kernel.org/stable/c/75ddbf776dd04a09fb9e5267ead5d0c989f84506","https://git.kernel.org/stable/c/ac9007520e392541a29daebaae8b9109007bc781","https://git.kernel.org/stable/c/f536f09eb45e4de8d1b9accee9d992aa1846f1d4","https://git.kernel.org/stable/c/1aac4be1aaa5177506219f01dce5e29194e5e95a","https://git.kernel.org/stable/c/23926d316d2836315cb113569f91393266eb5b47","https://git.kernel.org/stable/c/2eabb655a968b862bc0c31629a09f0fbf3c80d51","https://git.kernel.org/stable/c/5159a81924311c1ec786ad9fdef784ead8676a6a","https://git.kernel.org/stable/c/5584c776a1af7807ca815ee6265f2c1429fc5727","https://git.kernel.org/stable/c/75ddbf776dd04a09fb9e5267ead5d0c989f84506","https://git.kernel.org/stable/c/ac9007520e392541a29daebaae8b9109007bc781","https://git.kernel.org/stable/c/f536f09eb45e4de8d1b9accee9d992aa1846f1d4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42089
|
Medium |
fixed |
- 4.19.317
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.97
- 6.6.37
- 6.9.8
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: fsl-asoc-card: set priv->pdev before using it
priv->pdev pointer was set after being used in
fsl_asoc_card_audmux_init().
Move this assignment at the start of the probe function, so
sub-functions can correctly use pdev through priv.
fsl_asoc_card_audmux_init() dereferences priv->pdev to get access to the
dev struct, used with dev_err macros.
As priv is zero-initialised, there would be a NULL pointer dereference.
Note that if priv->dev is dereferenced before assignment but never used,
for example if there is no error to be printed, the driver won't crash
probably due to compiler optimisations. |
["https://git.kernel.org/stable/c/29bc9e7c75398b0d12fc30955f2e9b2dd29ffaed","https://git.kernel.org/stable/c/3662eb2170e59b58ad479982dc1084889ba757b9","https://git.kernel.org/stable/c/544ab46b7ece6d6bebbdee5d5659c0a0f804a99a","https://git.kernel.org/stable/c/7c18b4d89ff9c810b6e562408afda5ce165c4ea6","https://git.kernel.org/stable/c/8896e18b7c366f8faf9344abfd0971435f1c723a","https://git.kernel.org/stable/c/8faf91e58425c2f6ce773250dfd995f1c2d461ac","https://git.kernel.org/stable/c/90f3feb24172185f1832636264943e8b5e289245","https://git.kernel.org/stable/c/ae81535ce2503aabc4adab3472f4338070cdeb6a","https://git.kernel.org/stable/c/29bc9e7c75398b0d12fc30955f2e9b2dd29ffaed","https://git.kernel.org/stable/c/3662eb2170e59b58ad479982dc1084889ba757b9","https://git.kernel.org/stable/c/544ab46b7ece6d6bebbdee5d5659c0a0f804a99a","https://git.kernel.org/stable/c/7c18b4d89ff9c810b6e562408afda5ce165c4ea6","https://git.kernel.org/stable/c/8896e18b7c366f8faf9344abfd0971435f1c723a","https://git.kernel.org/stable/c/8faf91e58425c2f6ce773250dfd995f1c2d461ac","https://git.kernel.org/stable/c/90f3feb24172185f1832636264943e8b5e289245","https://git.kernel.org/stable/c/ae81535ce2503aabc4adab3472f4338070cdeb6a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52674
|
Medium |
fixed |
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: scarlett2: Add clamp() in scarlett2_mixer_ctl_put()
Ensure the value passed to scarlett2_mixer_ctl_put() is between 0 and
SCARLETT2_MIXER_MAX_VALUE so we don't attempt to access outside
scarlett2_mixer_values[]. |
["https://git.kernel.org/stable/c/03035872e17897ba89866940bbc9cefca601e572","https://git.kernel.org/stable/c/04f8f053252b86c7583895c962d66747ecdc61b7","https://git.kernel.org/stable/c/ad945ea8d47dd4454c271510bea24850119847c2","https://git.kernel.org/stable/c/d8d8897d65061cbe36bf2909057338303a904810","https://git.kernel.org/stable/c/e517645ead5ea22c69d2a44694baa23fe1ce7c2b","https://git.kernel.org/stable/c/03035872e17897ba89866940bbc9cefca601e572","https://git.kernel.org/stable/c/04f8f053252b86c7583895c962d66747ecdc61b7","https://git.kernel.org/stable/c/ad945ea8d47dd4454c271510bea24850119847c2","https://git.kernel.org/stable/c/d8d8897d65061cbe36bf2909057338303a904810","https://git.kernel.org/stable/c/e517645ead5ea22c69d2a44694baa23fe1ce7c2b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52708
|
Medium |
fixed |
- 5.4.232
- 5.10.169
- 5.15.95
- 6.1.13
|
In the Linux kernel, the following vulnerability has been resolved:
mmc: mmc_spi: fix error handling in mmc_spi_probe()
If mmc_add_host() fails, it doesn't need to call mmc_remove_host(),
or it will cause null-ptr-deref, because of deleting a not added
device in mmc_remove_host().
To fix this, goto label 'fail_glue_init', if mmc_add_host() fails,
and change the label 'fail_add_host' to 'fail_gpiod_request'. |
["https://git.kernel.org/stable/c/0b3edcb24bd81b3b2e3dac89f4733bfd47d283be","https://git.kernel.org/stable/c/82645bf4ed02abe930a659c5fe16d593a6dbd93f","https://git.kernel.org/stable/c/cf4c9d2ac1e42c7d18b921bec39486896645b714","https://git.kernel.org/stable/c/e9b488d60f51ae312006e224e03a30a151c28bdd","https://git.kernel.org/stable/c/ecad2fafd424ffdc203b2748ded0b37e4bbecef3","https://git.kernel.org/stable/c/0b3edcb24bd81b3b2e3dac89f4733bfd47d283be","https://git.kernel.org/stable/c/82645bf4ed02abe930a659c5fe16d593a6dbd93f","https://git.kernel.org/stable/c/cf4c9d2ac1e42c7d18b921bec39486896645b714","https://git.kernel.org/stable/c/e9b488d60f51ae312006e224e03a30a151c28bdd","https://git.kernel.org/stable/c/ecad2fafd424ffdc203b2748ded0b37e4bbecef3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52808
|
Medium |
fixed |
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: hisi_sas: Set debugfs_dir pointer to NULL after removing debugfs
If init debugfs failed during device registration due to memory allocation
failure, debugfs_remove_recursive() is called, after which debugfs_dir is
not set to NULL. debugfs_remove_recursive() will be called again during
device removal. As a result, illegal pointer is accessed.
[ 1665.467244] hisi_sas_v3_hw 0000:b4:02.0: failed to init debugfs!
...
[ 1669.836708] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0
[ 1669.872669] pc : down_write+0x24/0x70
[ 1669.876315] lr : down_write+0x1c/0x70
[ 1669.879961] sp : ffff000036f53a30
[ 1669.883260] x29: ffff000036f53a30 x28: ffffa027c31549f8
[ 1669.888547] x27: ffffa027c3140000 x26: 0000000000000000
[ 1669.893834] x25: ffffa027bf37c270 x24: ffffa027bf37c270
[ 1669.899122] x23: ffff0000095406b8 x22: ffff0000095406a8
[ 1669.904408] x21: 0000000000000000 x20: ffffa027bf37c310
[ 1669.909695] x19: 00000000000000a0 x18: ffff8027dcd86f10
[ 1669.914982] x17: 0000000000000000 x16: 0000000000000000
[ 1669.920268] x15: 0000000000000000 x14: ffffa0274014f870
[ 1669.925555] x13: 0000000000000040 x12: 0000000000000228
[ 1669.930842] x11: 0000000000000020 x10: 0000000000000bb0
[ 1669.936129] x9 : ffff000036f537f0 x8 : ffff80273088ca10
[ 1669.941416] x7 : 000000000000001d x6 : 00000000ffffffff
[ 1669.946702] x5 : ffff000008a36310 x4 : ffff80273088be00
[ 1669.951989] x3 : ffff000009513e90 x2 : 0000000000000000
[ 1669.957276] x1 : 00000000000000a0 x0 : ffffffff00000001
[ 1669.962563] Call trace:
[ 1669.965000] down_write+0x24/0x70
[ 1669.968301] debugfs_remove_recursive+0x5c/0x1b0
[ 1669.972905] hisi_sas_debugfs_exit+0x24/0x30 [hisi_sas_main]
[ 1669.978541] hisi_sas_v3_remove+0x130/0x150 [hisi_sas_v3_hw]
[ 1669.984175] pci_device_remove+0x48/0xd8
[ 1669.988082] device_release_driver_internal+0x1b4/0x250
[ 1669.993282] device_release_driver+0x28/0x38
[ 1669.997534] pci_stop_bus_device+0x84/0xb8
[ 1670.001611] pci_stop_and_remove_bus_device_locked+0x24/0x40
[ 1670.007244] remove_store+0xfc/0x140
[ 1670.010802] dev_attr_store+0x44/0x60
[ 1670.014448] sysfs_kf_write+0x58/0x80
[ 1670.018095] kernfs_fop_write+0xe8/0x1f0
[ 1670.022000] __vfs_write+0x60/0x190
[ 1670.025472] vfs_write+0xac/0x1c0
[ 1670.028771] ksys_write+0x6c/0xd8
[ 1670.032071] __arm64_sys_write+0x24/0x30
[ 1670.035977] el0_svc_common+0x78/0x130
[ 1670.039710] el0_svc_handler+0x38/0x78
[ 1670.043442] el0_svc+0x8/0xc
To fix this, set debugfs_dir to NULL after debugfs_remove_recursive(). |
["https://git.kernel.org/stable/c/33331b265aac9441ac0c1a5442e3f05d038240ec","https://git.kernel.org/stable/c/6de426f9276c448e2db7238911c97fb157cb23be","https://git.kernel.org/stable/c/75a2656260fe8c7eeabda6ff4600b29e183f48db","https://git.kernel.org/stable/c/b4465009e7d60c6111946db4c8f1e50d401ed7be","https://git.kernel.org/stable/c/f0bfc8a5561fb0b2c48183dcbfe00bdd6d973bd3","https://git.kernel.org/stable/c/33331b265aac9441ac0c1a5442e3f05d038240ec","https://git.kernel.org/stable/c/6de426f9276c448e2db7238911c97fb157cb23be","https://git.kernel.org/stable/c/75a2656260fe8c7eeabda6ff4600b29e183f48db","https://git.kernel.org/stable/c/b4465009e7d60c6111946db4c8f1e50d401ed7be","https://git.kernel.org/stable/c/f0bfc8a5561fb0b2c48183dcbfe00bdd6d973bd3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52811
|
Medium |
fixed |
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: ibmvfc: Remove BUG_ON in the case of an empty event pool
In practice the driver should never send more commands than are allocated
to a queue's event pool. In the unlikely event that this happens, the code
asserts a BUG_ON, and in the case that the kernel is not configured to
crash on panic returns a junk event pointer from the empty event list
causing things to spiral from there. This BUG_ON is a historical artifact
of the ibmvfc driver first being upstreamed, and it is well known now that
the use of BUG_ON is bad practice except in the most unrecoverable
scenario. There is nothing about this scenario that prevents the driver
from recovering and carrying on.
Remove the BUG_ON in question from ibmvfc_get_event() and return a NULL
pointer in the case of an empty event pool. Update all call sites to
ibmvfc_get_event() to check for a NULL pointer and perfrom the appropriate
failure or recovery action. |
["https://git.kernel.org/stable/c/88984ec4792766df5a9de7a2ff2b5f281f94c7d4","https://git.kernel.org/stable/c/8bbe784c2ff28d56ca0c548aaf3e584edc77052d","https://git.kernel.org/stable/c/b39f2d10b86d0af353ea339e5815820026bca48f","https://git.kernel.org/stable/c/d2af4ef80601224b90630c1ddc7cd2c7c8ab4dd8","https://git.kernel.org/stable/c/e1d1f79b1929dce470a5dc9281c574cd58e8c6c0","https://git.kernel.org/stable/c/88984ec4792766df5a9de7a2ff2b5f281f94c7d4","https://git.kernel.org/stable/c/8bbe784c2ff28d56ca0c548aaf3e584edc77052d","https://git.kernel.org/stable/c/b39f2d10b86d0af353ea339e5815820026bca48f","https://git.kernel.org/stable/c/d2af4ef80601224b90630c1ddc7cd2c7c8ab4dd8","https://git.kernel.org/stable/c/e1d1f79b1929dce470a5dc9281c574cd58e8c6c0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52849
|
Medium |
fixed |
- 5.15.139
- 6.1.63
- 6.5.12
- 6.6.2
|
In the Linux kernel, the following vulnerability has been resolved:
cxl/mem: Fix shutdown order
Ira reports that removing cxl_mock_mem causes a crash with the following
trace:
BUG: kernel NULL pointer dereference, address: 0000000000000044
[..]
RIP: 0010:cxl_region_decode_reset+0x7f/0x180 [cxl_core]
[..]
Call Trace:
<TASK>
cxl_region_detach+0xe8/0x210 [cxl_core]
cxl_decoder_kill_region+0x27/0x40 [cxl_core]
cxld_unregister+0x29/0x40 [cxl_core]
devres_release_all+0xb8/0x110
device_unbind_cleanup+0xe/0x70
device_release_driver_internal+0x1d2/0x210
bus_remove_device+0xd7/0x150
device_del+0x155/0x3e0
device_unregister+0x13/0x60
devm_release_action+0x4d/0x90
? __pfx_unregister_port+0x10/0x10 [cxl_core]
delete_endpoint+0x121/0x130 [cxl_core]
devres_release_all+0xb8/0x110
device_unbind_cleanup+0xe/0x70
device_release_driver_internal+0x1d2/0x210
bus_remove_device+0xd7/0x150
device_del+0x155/0x3e0
? lock_release+0x142/0x290
cdev_device_del+0x15/0x50
cxl_memdev_unregister+0x54/0x70 [cxl_core]
This crash is due to the clearing out the cxl_memdev's driver context
(@cxlds) before the subsystem is done with it. This is ultimately due to
the region(s), that this memdev is a member, being torn down and expecting
to be able to de-reference @cxlds, like here:
static int cxl_region_decode_reset(struct cxl_region *cxlr, int count)
...
if (cxlds->rcd)
goto endpoint_reset;
...
Fix it by keeping the driver context valid until memdev-device
unregistration, and subsequently the entire stack of related
dependencies, unwinds. |
["https://git.kernel.org/stable/c/0ca074f7d788627a4e0b047ca5fbdb5fc567220c","https://git.kernel.org/stable/c/20bd0198bebdd706bd4614b3933ef70d7c19618f","https://git.kernel.org/stable/c/7c7371b41a14e86f53e7dbe5baa7b1d3e0ab324b","https://git.kernel.org/stable/c/88d3917f82ed4215a2154432c26de1480a61b209","https://git.kernel.org/stable/c/cad22a757029c3a1985c221a2d4a6491ad4035ae","https://git.kernel.org/stable/c/0ca074f7d788627a4e0b047ca5fbdb5fc567220c","https://git.kernel.org/stable/c/20bd0198bebdd706bd4614b3933ef70d7c19618f","https://git.kernel.org/stable/c/7c7371b41a14e86f53e7dbe5baa7b1d3e0ab324b","https://git.kernel.org/stable/c/88d3917f82ed4215a2154432c26de1480a61b209","https://git.kernel.org/stable/c/cad22a757029c3a1985c221a2d4a6491ad4035ae"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52856
|
Medium |
fixed |
- 5.15.139
- 6.1.63
- 6.5.12
- 6.6.2
|
In the Linux kernel, the following vulnerability has been resolved:
drm/bridge: lt8912b: Fix crash on bridge detach
The lt8912b driver, in its bridge detach function, calls
drm_connector_unregister() and drm_connector_cleanup().
drm_connector_unregister() should be called only for connectors
explicitly registered with drm_connector_register(), which is not the
case in lt8912b.
The driver's drm_connector_funcs.destroy hook is set to
drm_connector_cleanup().
Thus the driver should not call either drm_connector_unregister() nor
drm_connector_cleanup() in its lt8912_bridge_detach(), as they cause a
crash on bridge detach:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
Mem abort info:
ESR = 0x0000000096000006
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x06: level 2 translation fault
Data abort info:
ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=00000000858f3000
[0000000000000000] pgd=0800000085918003, p4d=0800000085918003, pud=0800000085431003, pmd=0000000000000000
Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP
Modules linked in: tidss(-) display_connector lontium_lt8912b tc358768 panel_lvds panel_simple drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks
CPU: 3 PID: 462 Comm: rmmod Tainted: G W 6.5.0-rc2+ #2
Hardware name: Toradex Verdin AM62 on Verdin Development Board (DT)
pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drm_connector_cleanup+0x78/0x2d4 [drm]
lr : lt8912_bridge_detach+0x54/0x6c [lontium_lt8912b]
sp : ffff800082ed3a90
x29: ffff800082ed3a90 x28: ffff0000040c1940 x27: 0000000000000000
x26: 0000000000000000 x25: dead000000000122 x24: dead000000000122
x23: dead000000000100 x22: ffff000003fb6388 x21: 0000000000000000
x20: 0000000000000000 x19: ffff000003fb6260 x18: fffffffffffe56e8
x17: 0000000000000000 x16: 0010000000000000 x15: 0000000000000038
x14: 0000000000000000 x13: ffff800081914b48 x12: 000000000000040e
x11: 000000000000015a x10: ffff80008196ebb8 x9 : ffff800081914b48
x8 : 00000000ffffefff x7 : ffff0000040c1940 x6 : ffff80007aa649d0
x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffff80008159e008
x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
Call trace:
drm_connector_cleanup+0x78/0x2d4 [drm]
lt8912_bridge_detach+0x54/0x6c [lontium_lt8912b]
drm_bridge_detach+0x44/0x84 [drm]
drm_encoder_cleanup+0x40/0xb8 [drm]
drmm_encoder_alloc_release+0x1c/0x30 [drm]
drm_managed_release+0xac/0x148 [drm]
drm_dev_put.part.0+0x88/0xb8 [drm]
devm_drm_dev_init_release+0x14/0x24 [drm]
devm_action_release+0x14/0x20
release_nodes+0x5c/0x90
devres_release_all+0x8c/0xe0
device_unbind_cleanup+0x18/0x68
device_release_driver_internal+0x208/0x23c
driver_detach+0x4c/0x94
bus_remove_driver+0x70/0xf4
driver_unregister+0x30/0x60
platform_driver_unregister+0x14/0x20
tidss_platform_driver_exit+0x18/0xb2c [tidss]
__arm64_sys_delete_module+0x1a0/0x2b4
invoke_syscall+0x48/0x110
el0_svc_common.constprop.0+0x60/0x10c
do_el0_svc_compat+0x1c/0x40
el0_svc_compat+0x40/0xac
el0t_32_sync_handler+0xb0/0x138
el0t_32_sync+0x194/0x198
Code: 9104a276 f2fbd5b7 aa0203e1 91008af8 (f85c0420) |
["https://git.kernel.org/stable/c/42071feab712ba2a139b8928f7e0f8d3a6fc719e","https://git.kernel.org/stable/c/44283993144a03af9df31934d6c32bbd42d1a347","https://git.kernel.org/stable/c/7bf0cb8f40280a85034990dfe42be8ca8f80f37a","https://git.kernel.org/stable/c/b65e3249f3ca96e3c736af889461d80d675feab6","https://git.kernel.org/stable/c/fcd9895e365474709844eeb31cfe53d912c3596e","https://git.kernel.org/stable/c/42071feab712ba2a139b8928f7e0f8d3a6fc719e","https://git.kernel.org/stable/c/44283993144a03af9df31934d6c32bbd42d1a347","https://git.kernel.org/stable/c/7bf0cb8f40280a85034990dfe42be8ca8f80f37a","https://git.kernel.org/stable/c/b65e3249f3ca96e3c736af889461d80d675feab6","https://git.kernel.org/stable/c/fcd9895e365474709844eeb31cfe53d912c3596e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35851
|
Medium |
fixed |
- 5.15.158
- 6.1.90
- 6.6.30
- 6.8.9
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: qca: fix NULL-deref on non-serdev suspend
Qualcomm ROME controllers can be registered from the Bluetooth line
discipline and in this case the HCI UART serdev pointer is NULL.
Add the missing sanity check to prevent a NULL-pointer dereference when
wakeup() is called for a non-serdev controller during suspend.
Just return true for now to restore the original behaviour and address
the crash with pre-6.2 kernels, which do not have commit e9b3e5b8c657
("Bluetooth: hci_qca: only assign wakeup with serial port support") that
causes the crash to happen already at setup() time. |
["https://git.kernel.org/stable/c/52f9041deaca3fc5c40ef3b9cb943993ec7d2489","https://git.kernel.org/stable/c/6b47cdeb786c38e4174319218db3fa6d7b4bba88","https://git.kernel.org/stable/c/73e87c0a49fda31d7b589edccf4c72e924411371","https://git.kernel.org/stable/c/b64092d2f108f0cd1d7fd7e176f5fb2a67a2f189","https://git.kernel.org/stable/c/e60502b907be350c518819297b565007a94c706d","https://git.kernel.org/stable/c/52f9041deaca3fc5c40ef3b9cb943993ec7d2489","https://git.kernel.org/stable/c/6b47cdeb786c38e4174319218db3fa6d7b4bba88","https://git.kernel.org/stable/c/73e87c0a49fda31d7b589edccf4c72e924411371","https://git.kernel.org/stable/c/b64092d2f108f0cd1d7fd7e176f5fb2a67a2f189","https://git.kernel.org/stable/c/e60502b907be350c518819297b565007a94c706d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35907
|
Medium |
fixed |
- 5.15.154
- 6.1.85
- 6.6.26
- 6.8.5
|
In the Linux kernel, the following vulnerability has been resolved:
mlxbf_gige: call request_irq() after NAPI initialized
The mlxbf_gige driver encounters a NULL pointer exception in
mlxbf_gige_open() when kdump is enabled. The sequence to reproduce
the exception is as follows:
a) enable kdump
b) trigger kdump via "echo c > /proc/sysrq-trigger"
c) kdump kernel executes
d) kdump kernel loads mlxbf_gige module
e) the mlxbf_gige module runs its open() as the
the "oob_net0" interface is brought up
f) mlxbf_gige module will experience an exception
during its open(), something like:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
Mem abort info:
ESR = 0x0000000086000004
EC = 0x21: IABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
user pgtable: 4k pages, 48-bit VAs, pgdp=00000000e29a4000
[0000000000000000] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 0000000086000004 [#1] SMP
CPU: 0 PID: 812 Comm: NetworkManager Tainted: G OE 5.15.0-1035-bluefield #37-Ubuntu
Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.6.0.13024 Jan 19 2024
pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : 0x0
lr : __napi_poll+0x40/0x230
sp : ffff800008003e00
x29: ffff800008003e00 x28: 0000000000000000 x27: 00000000ffffffff
x26: ffff000066027238 x25: ffff00007cedec00 x24: ffff800008003ec8
x23: 000000000000012c x22: ffff800008003eb7 x21: 0000000000000000
x20: 0000000000000001 x19: ffff000066027238 x18: 0000000000000000
x17: ffff578fcb450000 x16: ffffa870b083c7c0 x15: 0000aaab010441d0
x14: 0000000000000001 x13: 00726f7272655f65 x12: 6769675f6662786c
x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa870b0842398
x8 : 0000000000000004 x7 : fe5a48b9069706ea x6 : 17fdb11fc84ae0d2
x5 : d94a82549d594f35 x4 : 0000000000000000 x3 : 0000000000400100
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000066027238
Call trace:
0x0
net_rx_action+0x178/0x360
__do_softirq+0x15c/0x428
__irq_exit_rcu+0xac/0xec
irq_exit+0x18/0x2c
handle_domain_irq+0x6c/0xa0
gic_handle_irq+0xec/0x1b0
call_on_irq_stack+0x20/0x2c
do_interrupt_handler+0x5c/0x70
el1_interrupt+0x30/0x50
el1h_64_irq_handler+0x18/0x2c
el1h_64_irq+0x7c/0x80
__setup_irq+0x4c0/0x950
request_threaded_irq+0xf4/0x1bc
mlxbf_gige_request_irqs+0x68/0x110 [mlxbf_gige]
mlxbf_gige_open+0x5c/0x170 [mlxbf_gige]
__dev_open+0x100/0x220
__dev_change_flags+0x16c/0x1f0
dev_change_flags+0x2c/0x70
do_setlink+0x220/0xa40
__rtnl_newlink+0x56c/0x8a0
rtnl_newlink+0x58/0x84
rtnetlink_rcv_msg+0x138/0x3c4
netlink_rcv_skb+0x64/0x130
rtnetlink_rcv+0x20/0x30
netlink_unicast+0x2ec/0x360
netlink_sendmsg+0x278/0x490
__sock_sendmsg+0x5c/0x6c
____sys_sendmsg+0x290/0x2d4
___sys_sendmsg+0x84/0xd0
__sys_sendmsg+0x70/0xd0
__arm64_sys_sendmsg+0x2c/0x40
invoke_syscall+0x78/0x100
el0_svc_common.constprop.0+0x54/0x184
do_el0_svc+0x30/0xac
el0_svc+0x48/0x160
el0t_64_sync_handler+0xa4/0x12c
el0t_64_sync+0x1a4/0x1a8
Code: bad PC value
---[ end trace 7d1c3f3bf9d81885 ]---
Kernel panic - not syncing: Oops: Fatal exception in interrupt
Kernel Offset: 0x2870a7a00000 from 0xffff800008000000
PHYS_OFFSET: 0x80000000
CPU features: 0x0,000005c1,a3332a5a
Memory Limit: none
---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---
The exception happens because there is a pending RX interrupt before the
call to request_irq(RX IRQ) executes. Then, the RX IRQ handler fires
immediately after this request_irq() completes. The
---truncated--- |
["https://git.kernel.org/stable/c/24444af5ddf729376b90db0f135fa19973cb5dab","https://git.kernel.org/stable/c/867a2f598af6a645c865d1101b58c5e070c6dd9e","https://git.kernel.org/stable/c/8feb1652afe9c5d019059a55c90f70690dce0f52","https://git.kernel.org/stable/c/a583117668ddb86e98f2e11c7caa3db0e6df52a3","https://git.kernel.org/stable/c/f7442a634ac06b953fc1f7418f307b25acd4cfbc","https://git.kernel.org/stable/c/24444af5ddf729376b90db0f135fa19973cb5dab","https://git.kernel.org/stable/c/867a2f598af6a645c865d1101b58c5e070c6dd9e","https://git.kernel.org/stable/c/8feb1652afe9c5d019059a55c90f70690dce0f52","https://git.kernel.org/stable/c/a583117668ddb86e98f2e11c7caa3db0e6df52a3","https://git.kernel.org/stable/c/f7442a634ac06b953fc1f7418f307b25acd4cfbc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38543
|
Medium |
fixed |
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
lib/test_hmm.c: handle src_pfns and dst_pfns allocation failure
The kcalloc() in dmirror_device_evict_chunk() will return null if the
physical memory has run out. As a result, if src_pfns or dst_pfns is
dereferenced, the null pointer dereference bug will happen.
Moreover, the device is going away. If the kcalloc() fails, the pages
mapping a chunk could not be evicted. So add a __GFP_NOFAIL flag in
kcalloc().
Finally, as there is no need to have physically contiguous memory, Switch
kcalloc() to kvcalloc() in order to avoid failing allocations. |
["https://git.kernel.org/stable/c/1a21fdeea502658e315bd939409b755974f4fb64","https://git.kernel.org/stable/c/3b20d18f475bd17309db640dbe7d7c7ebb5bc2bc","https://git.kernel.org/stable/c/65e528a69cb3ed4a286c45b4afba57461c8b5b33","https://git.kernel.org/stable/c/c2af060d1c18beaec56351cf9c9bcbbc5af341a3","https://git.kernel.org/stable/c/ce47e8ead9a72834cc68431d53f8092ce69bebb7","https://git.kernel.org/stable/c/1a21fdeea502658e315bd939409b755974f4fb64","https://git.kernel.org/stable/c/3b20d18f475bd17309db640dbe7d7c7ebb5bc2bc","https://git.kernel.org/stable/c/65e528a69cb3ed4a286c45b4afba57461c8b5b33","https://git.kernel.org/stable/c/c2af060d1c18beaec56351cf9c9bcbbc5af341a3","https://git.kernel.org/stable/c/ce47e8ead9a72834cc68431d53f8092ce69bebb7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39466
|
Medium |
fixed |
- 5.15.161
- 6.1.94
- 6.6.34
- 6.9.5
|
In the Linux kernel, the following vulnerability has been resolved:
thermal/drivers/qcom/lmh: Check for SCM availability at probe
Up until now, the necessary scm availability check has not been
performed, leading to possible null pointer dereferences (which did
happen for me on RB1).
Fix that. |
["https://git.kernel.org/stable/c/0a47ba94ec3d8f782b33e3d970cfcb769b962464","https://git.kernel.org/stable/c/2226b145afa5e13cb60dbe77fb20fb0666a1caf3","https://git.kernel.org/stable/c/560d69c975072974c11434ca6953891e74c1a665","https://git.kernel.org/stable/c/aa1a0807b4a76b44fb6b58a7e9087cd4b18ab41b","https://git.kernel.org/stable/c/d9d3490c48df572edefc0b64655259eefdcbb9be","https://git.kernel.org/stable/c/0a47ba94ec3d8f782b33e3d970cfcb769b962464","https://git.kernel.org/stable/c/2226b145afa5e13cb60dbe77fb20fb0666a1caf3","https://git.kernel.org/stable/c/560d69c975072974c11434ca6953891e74c1a665","https://git.kernel.org/stable/c/aa1a0807b4a76b44fb6b58a7e9087cd4b18ab41b","https://git.kernel.org/stable/c/d9d3490c48df572edefc0b64655259eefdcbb9be"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41048
|
Medium |
fixed |
- 5.15.163
- 6.1.100
- 6.6.41
- 6.9.10
|
In the Linux kernel, the following vulnerability has been resolved:
skmsg: Skip zero length skb in sk_msg_recvmsg
When running BPF selftests (./test_progs -t sockmap_basic) on a Loongarch
platform, the following kernel panic occurs:
[...]
Oops[#1]:
CPU: 22 PID: 2824 Comm: test_progs Tainted: G OE 6.10.0-rc2+ #18
Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018
... ...
ra: 90000000048bf6c0 sk_msg_recvmsg+0x120/0x560
ERA: 9000000004162774 copy_page_to_iter+0x74/0x1c0
CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
PRMD: 0000000c (PPLV0 +PIE +PWE)
EUEN: 00000007 (+FPE +SXE +ASXE -BTE)
ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
BADV: 0000000000000040
PRID: 0014c011 (Loongson-64bit, Loongson-3C5000)
Modules linked in: bpf_testmod(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack
Process test_progs (pid: 2824, threadinfo=0000000000863a31, task=...)
Stack : ...
Call Trace:
[<9000000004162774>] copy_page_to_iter+0x74/0x1c0
[<90000000048bf6c0>] sk_msg_recvmsg+0x120/0x560
[<90000000049f2b90>] tcp_bpf_recvmsg_parser+0x170/0x4e0
[<90000000049aae34>] inet_recvmsg+0x54/0x100
[<900000000481ad5c>] sock_recvmsg+0x7c/0xe0
[<900000000481e1a8>] __sys_recvfrom+0x108/0x1c0
[<900000000481e27c>] sys_recvfrom+0x1c/0x40
[<9000000004c076ec>] do_syscall+0x8c/0xc0
[<9000000003731da4>] handle_syscall+0xc4/0x160
Code: ...
---[ end trace 0000000000000000 ]---
Kernel panic - not syncing: Fatal exception
Kernel relocated by 0x3510000
.text @ 0x9000000003710000
.data @ 0x9000000004d70000
.bss @ 0x9000000006469400
---[ end Kernel panic - not syncing: Fatal exception ]---
[...]
This crash happens every time when running sockmap_skb_verdict_shutdown
subtest in sockmap_basic.
This crash is because a NULL pointer is passed to page_address() in the
sk_msg_recvmsg(). Due to the different implementations depending on the
architecture, page_address(NULL) will trigger a panic on Loongarch
platform but not on x86 platform. So this bug was hidden on x86 platform
for a while, but now it is exposed on Loongarch platform. The root cause
is that a zero length skb (skb->len == 0) was put on the queue.
This zero length skb is a TCP FIN packet, which was sent by shutdown(),
invoked in test_sockmap_skb_verdict_shutdown():
shutdown(p1, SHUT_WR);
In this case, in sk_psock_skb_ingress_enqueue(), num_sge is zero, and no
page is put to this sge (see sg_set_page in sg_set_page), but this empty
sge is queued into ingress_msg list.
And in sk_msg_recvmsg(), this empty sge is used, and a NULL page is got by
sg_page(sge). Pass this NULL page to copy_page_to_iter(), which passes it
to kmap_local_page() and to page_address(), then kernel panics.
To solve this, we should skip this zero length skb. So in sk_msg_recvmsg(),
if copy is zero, that means it's a zero length skb, skip invoking
copy_page_to_iter(). We are using the EFAULT return triggered by
copy_page_to_iter to check for is_fin in tcp_bpf.c. |
["https://git.kernel.org/stable/c/195b7bcdfc5adc5b2468f279dd9eb7eebd2e7632","https://git.kernel.org/stable/c/b180739b45a38b4caa88fe16bb5273072e6613dc","https://git.kernel.org/stable/c/f0c18025693707ec344a70b6887f7450bf4c826b","https://git.kernel.org/stable/c/f8bd689f37f4198a4c61c4684f591ba639595b97","https://git.kernel.org/stable/c/fb61d7b9fb6ef0032de469499a54dab4c7260d0d","https://git.kernel.org/stable/c/195b7bcdfc5adc5b2468f279dd9eb7eebd2e7632","https://git.kernel.org/stable/c/b180739b45a38b4caa88fe16bb5273072e6613dc","https://git.kernel.org/stable/c/f0c18025693707ec344a70b6887f7450bf4c826b","https://git.kernel.org/stable/c/f8bd689f37f4198a4c61c4684f591ba639595b97","https://git.kernel.org/stable/c/fb61d7b9fb6ef0032de469499a54dab4c7260d0d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42297
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to don't dirty inode for readonly filesystem
syzbot reports f2fs bug as below:
kernel BUG at fs/f2fs/inode.c:933!
RIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933
Call Trace:
evict+0x2a4/0x620 fs/inode.c:664
dispose_list fs/inode.c:697 [inline]
evict_inodes+0x5f8/0x690 fs/inode.c:747
generic_shutdown_super+0x9d/0x2c0 fs/super.c:675
kill_block_super+0x44/0x90 fs/super.c:1667
kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894
deactivate_locked_super+0xc1/0x130 fs/super.c:484
cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256
task_work_run+0x24a/0x300 kernel/task_work.c:180
ptrace_notify+0x2cd/0x380 kernel/signal.c:2399
ptrace_report_syscall include/linux/ptrace.h:411 [inline]
ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline]
syscall_exit_work kernel/entry/common.c:251 [inline]
syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline]
__syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline]
syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296
do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88
entry_SYSCALL_64_after_hwframe+0x63/0x6b
The root cause is:
- do_sys_open
- f2fs_lookup
- __f2fs_find_entry
- f2fs_i_depth_write
- f2fs_mark_inode_dirty_sync
- f2fs_dirty_inode
- set_inode_flag(inode, FI_DIRTY_INODE)
- umount
- kill_f2fs_super
- kill_block_super
- generic_shutdown_super
- sync_filesystem
: sb is readonly, skip sync_filesystem()
- evict_inodes
- iput
- f2fs_evict_inode
- f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE))
: trigger kernel panic
When we try to repair i_current_depth in readonly filesystem, let's
skip dirty inode to avoid panic in later f2fs_evict_inode(). |
["https://git.kernel.org/stable/c/192b8fb8d1c8ca3c87366ebbef599fa80bb626b8","https://git.kernel.org/stable/c/2434344559f6743efb3ac15d11af9a0db9543bd3","https://git.kernel.org/stable/c/2d2916516577f2239b3377d9e8d12da5e6ccdfcf","https://git.kernel.org/stable/c/54162974aea37a8cae00742470a78c7f6bd6f915","https://git.kernel.org/stable/c/54bc4e88447e385c4d4ffa85d93e0dce628fcfa6","https://git.kernel.org/stable/c/9ce8135accf103f7333af472709125878704fdd4","https://git.kernel.org/stable/c/e62ff092a42f4a1bae3b310cf46673b4f3aac3b5","https://git.kernel.org/stable/c/ec56571b4b146a1cfbedab49d5fcaf19fe8bf4f1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43908
|
Medium |
fixed |
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.105
- 6.6.46
- 6.10.5
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix the null pointer dereference to ras_manager
Check ras_manager before using it |
["https://git.kernel.org/stable/c/033187a70ba9743c73a810a006816e5553d1e7d4","https://git.kernel.org/stable/c/48cada0ac79e4775236d642e9ec5998a7c7fb7a4","https://git.kernel.org/stable/c/4c11d30c95576937c6c35e6f29884761f2dddb43","https://git.kernel.org/stable/c/56e848034ccabe44e8f22ffcf49db771c17b0d0a","https://git.kernel.org/stable/c/b89616333979114bb0da5fa40fb6e4a2f5294ca2","https://git.kernel.org/stable/c/d81c1eeb333d84b3012a91c0500189dc1d71e46c","https://git.kernel.org/stable/c/ff5c4eb71ee8951c789b079f6e948f86708b04ed"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48688
|
Medium |
fixed |
- 4.19.258
- 5.4.213
- 5.10.143
- 5.15.68
- 5.19.9
|
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix kernel crash during module removal
The driver incorrectly frees client instance and subsequent
i40e module removal leads to kernel crash.
Reproducer:
1. Do ethtool offline test followed immediately by another one
host# ethtool -t eth0 offline; ethtool -t eth0 offline
2. Remove recursively irdma module that also removes i40e module
host# modprobe -r irdma
Result:
[ 8675.035651] i40e 0000:3d:00.0 eno1: offline testing starting
[ 8675.193774] i40e 0000:3d:00.0 eno1: testing finished
[ 8675.201316] i40e 0000:3d:00.0 eno1: offline testing starting
[ 8675.358921] i40e 0000:3d:00.0 eno1: testing finished
[ 8675.496921] i40e 0000:3d:00.0: IRDMA hardware initialization FAILED init_state=2 status=-110
[ 8686.188955] i40e 0000:3d:00.1: i40e_ptp_stop: removed PHC on eno2
[ 8686.943890] i40e 0000:3d:00.1: Deleted LAN device PF1 bus=0x3d dev=0x00 func=0x01
[ 8686.952669] i40e 0000:3d:00.0: i40e_ptp_stop: removed PHC on eno1
[ 8687.761787] BUG: kernel NULL pointer dereference, address: 0000000000000030
[ 8687.768755] #PF: supervisor read access in kernel mode
[ 8687.773895] #PF: error_code(0x0000) - not-present page
[ 8687.779034] PGD 0 P4D 0
[ 8687.781575] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 8687.785935] CPU: 51 PID: 172891 Comm: rmmod Kdump: loaded Tainted: G W I 5.19.0+ #2
[ 8687.794800] Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS SE5C620.86B.0X.02.0001.051420190324 05/14/2019
[ 8687.805222] RIP: 0010:i40e_lan_del_device+0x13/0xb0 [i40e]
[ 8687.810719] Code: d4 84 c0 0f 84 b8 25 01 00 e9 9c 25 01 00 41 bc f4 ff ff ff eb 91 90 0f 1f 44 00 00 41 54 55 53 48 8b 87 58 08 00 00 48 89 fb <48> 8b 68 30 48 89 ef e8 21 8a 0f d5 48 89 ef e8 a9 78 0f d5 48 8b
[ 8687.829462] RSP: 0018:ffffa604072efce0 EFLAGS: 00010202
[ 8687.834689] RAX: 0000000000000000 RBX: ffff8f43833b2000 RCX: 0000000000000000
[ 8687.841821] RDX: 0000000000000000 RSI: ffff8f4b0545b298 RDI: ffff8f43833b2000
[ 8687.848955] RBP: ffff8f43833b2000 R08: 0000000000000001 R09: 0000000000000000
[ 8687.856086] R10: 0000000000000000 R11: 000ffffffffff000 R12: ffff8f43833b2ef0
[ 8687.863218] R13: ffff8f43833b2ef0 R14: ffff915103966000 R15: ffff8f43833b2008
[ 8687.870342] FS: 00007f79501c3740(0000) GS:ffff8f4adffc0000(0000) knlGS:0000000000000000
[ 8687.878427] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 8687.884174] CR2: 0000000000000030 CR3: 000000014276e004 CR4: 00000000007706e0
[ 8687.891306] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 8687.898441] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 8687.905572] PKRU: 55555554
[ 8687.908286] Call Trace:
[ 8687.910737] <TASK>
[ 8687.912843] i40e_remove+0x2c0/0x330 [i40e]
[ 8687.917040] pci_device_remove+0x33/0xa0
[ 8687.920962] device_release_driver_internal+0x1aa/0x230
[ 8687.926188] driver_detach+0x44/0x90
[ 8687.929770] bus_remove_driver+0x55/0xe0
[ 8687.933693] pci_unregister_driver+0x2a/0xb0
[ 8687.937967] i40e_exit_module+0xc/0xf48 [i40e]
Two offline tests cause IRDMA driver failure (ETIMEDOUT) and this
failure is indicated back to i40e_client_subtask() that calls
i40e_client_del_instance() to free client instance referenced
by pf->cinst and sets this pointer to NULL. During the module
removal i40e_remove() calls i40e_lan_del_device() that dereferences
pf->cinst that is NULL -> crash.
Do not remove client instance when client open callbacks fails and
just clear __I40E_CLIENT_INSTANCE_OPENED bit. The driver also needs
to take care about this situation (when netdev is up and client
is NOT opened) in i40e_notify_client_of_netdev_close() and
calls client close callback only when __I40E_CLIENT_INSTANCE_OPENED
is set. |
["https://git.kernel.org/stable/c/2ed94383f3a2693dbf5bc47c514b42524bd8f9ae","https://git.kernel.org/stable/c/342d77769a6cceb3df7720a1e18baa4339eee3fc","https://git.kernel.org/stable/c/38af35bec59a8431a1eb29da994a0a45cba275d9","https://git.kernel.org/stable/c/5332a094514852d5e58c278cf4193adb937337fc","https://git.kernel.org/stable/c/c49f320e2492738d478bc427dcd54ccfe0cba746","https://git.kernel.org/stable/c/fb8396aeda5872369a8ed6d2301e2c86e303c520","https://git.kernel.org/stable/c/2ed94383f3a2693dbf5bc47c514b42524bd8f9ae","https://git.kernel.org/stable/c/342d77769a6cceb3df7720a1e18baa4339eee3fc","https://git.kernel.org/stable/c/38af35bec59a8431a1eb29da994a0a45cba275d9","https://git.kernel.org/stable/c/5332a094514852d5e58c278cf4193adb937337fc","https://git.kernel.org/stable/c/c49f320e2492738d478bc427dcd54ccfe0cba746","https://git.kernel.org/stable/c/fb8396aeda5872369a8ed6d2301e2c86e303c520"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52646
|
Medium |
fixed |
- 4.14.306
- 4.19.273
- 5.4.232
- 5.10.169
- 5.15.95
- 6.1.13
|
In the Linux kernel, the following vulnerability has been resolved:
aio: fix mremap after fork null-deref
Commit e4a0d3e720e7 ("aio: Make it possible to remap aio ring") introduced
a null-deref if mremap is called on an old aio mapping after fork as
mm->ioctx_table will be set to NULL.
[jmoyer@redhat.com: fix 80 column issue] |
["https://git.kernel.org/stable/c/178993157e8c50aef7f35d7d6d3b44bb428199e1","https://git.kernel.org/stable/c/4326d0080f7e84fba775da41d158f46cf9d3f1c2","https://git.kernel.org/stable/c/808f1e4b5723ae4eda724d2ad6f6638905eefd95","https://git.kernel.org/stable/c/81e9d6f8647650a7bead74c5f926e29970e834d1","https://git.kernel.org/stable/c/af126acf01a12bdb04986fd26fc2eb3b40249e0d","https://git.kernel.org/stable/c/c261f798f7baa8080cf0214081d43d5f86bb073f","https://git.kernel.org/stable/c/d8dca1bfe9adcae38b35add64977818c0c13dd22","https://git.kernel.org/stable/c/178993157e8c50aef7f35d7d6d3b44bb428199e1","https://git.kernel.org/stable/c/4326d0080f7e84fba775da41d158f46cf9d3f1c2","https://git.kernel.org/stable/c/808f1e4b5723ae4eda724d2ad6f6638905eefd95","https://git.kernel.org/stable/c/81e9d6f8647650a7bead74c5f926e29970e834d1","https://git.kernel.org/stable/c/af126acf01a12bdb04986fd26fc2eb3b40249e0d","https://git.kernel.org/stable/c/c261f798f7baa8080cf0214081d43d5f86bb073f","https://git.kernel.org/stable/c/d8dca1bfe9adcae38b35add64977818c0c13dd22"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52705
|
Medium |
fixed |
- 4.14.306
- 4.19.273
- 5.4.232
- 5.10.169
- 5.15.95
- 6.1.13
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix underflow in second superblock position calculations
Macro NILFS_SB2_OFFSET_BYTES, which computes the position of the second
superblock, underflows when the argument device size is less than 4096
bytes. Therefore, when using this macro, it is necessary to check in
advance that the device size is not less than a lower limit, or at least
that underflow does not occur.
The current nilfs2 implementation lacks this check, causing out-of-bound
block access when mounting devices smaller than 4096 bytes:
I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0
phys_seg 1 prio class 2
NILFS (loop0): unable to read secondary superblock (blocksize = 1024)
In addition, when trying to resize the filesystem to a size below 4096
bytes, this underflow occurs in nilfs_resize_fs(), passing a huge number
of segments to nilfs_sufile_resize(), corrupting parameters such as the
number of segments in superblocks. This causes excessive loop iterations
in nilfs_sufile_resize() during a subsequent resize ioctl, causing
semaphore ns_segctor_sem to block for a long time and hang the writer
thread:
INFO: task segctord:5067 blocked for more than 143 seconds.
Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:segctord state:D stack:23456 pid:5067 ppid:2
flags:0x00004000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5293 [inline]
__schedule+0x1409/0x43f0 kernel/sched/core.c:6606
schedule+0xc3/0x190 kernel/sched/core.c:6682
rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190
nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357
nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline]
nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570
kthread+0x270/0x300 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
</TASK>
...
Call Trace:
<TASK>
folio_mark_accessed+0x51c/0xf00 mm/swap.c:515
__nilfs_get_page_block fs/nilfs2/page.c:42 [inline]
nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61
nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121
nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176
nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251
nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline]
nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline]
nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777
nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422
nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline]
nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301
...
This fixes these issues by inserting appropriate minimum device size
checks or anti-underflow checks, depending on where the macro is used. |
["https://git.kernel.org/stable/c/0ee5ed0126a2211f7174492da2ca2c29f43755c5","https://git.kernel.org/stable/c/2f7a1135b202977b82457adde7db6c390056863b","https://git.kernel.org/stable/c/52844d8382cd9166d708032def8905ffc3ae550f","https://git.kernel.org/stable/c/99b9402a36f0799f25feee4465bfa4b8dfa74b4d","https://git.kernel.org/stable/c/a158782b56b070485d54d25fc9aaf2c8f3752205","https://git.kernel.org/stable/c/a8ef5109f93cea9933bbac0455d8c18757b3fcb4","https://git.kernel.org/stable/c/b96591e2c35c8b47db0ec816b5fc6cb8868000ff","https://git.kernel.org/stable/c/0ee5ed0126a2211f7174492da2ca2c29f43755c5","https://git.kernel.org/stable/c/2f7a1135b202977b82457adde7db6c390056863b","https://git.kernel.org/stable/c/52844d8382cd9166d708032def8905ffc3ae550f","https://git.kernel.org/stable/c/99b9402a36f0799f25feee4465bfa4b8dfa74b4d","https://git.kernel.org/stable/c/a158782b56b070485d54d25fc9aaf2c8f3752205","https://git.kernel.org/stable/c/a8ef5109f93cea9933bbac0455d8c18757b3fcb4","https://git.kernel.org/stable/c/b96591e2c35c8b47db0ec816b5fc6cb8868000ff"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52869
|
Medium |
fixed |
- 5.10.201
- 5.15.139
- 6.1.63
- 6.5.12
- 6.6.2
|
In the Linux kernel, the following vulnerability has been resolved:
pstore/platform: Add check for kstrdup
Add check for the return value of kstrdup() and return the error
if it fails in order to avoid NULL pointer dereference. |
["https://git.kernel.org/stable/c/1c426da79f9fc7b761021b5eb44185ba119cd44a","https://git.kernel.org/stable/c/379b120e4f27fd1cf636a5f85570c4d240a3f688","https://git.kernel.org/stable/c/63f637309baadf81a095f2653e3b807d4b5814b9","https://git.kernel.org/stable/c/a19d48f7c5d57c0f0405a7d4334d1d38fe9d3c1c","https://git.kernel.org/stable/c/ad5cb6deb41417ef41b9d6ff54f789212108606f","https://git.kernel.org/stable/c/bb166bdae1a7d7db30e9be7e6ccaba606debc05f","https://git.kernel.org/stable/c/1c426da79f9fc7b761021b5eb44185ba119cd44a","https://git.kernel.org/stable/c/379b120e4f27fd1cf636a5f85570c4d240a3f688","https://git.kernel.org/stable/c/63f637309baadf81a095f2653e3b807d4b5814b9","https://git.kernel.org/stable/c/a19d48f7c5d57c0f0405a7d4334d1d38fe9d3c1c","https://git.kernel.org/stable/c/ad5cb6deb41417ef41b9d6ff54f789212108606f","https://git.kernel.org/stable/c/bb166bdae1a7d7db30e9be7e6ccaba606debc05f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2014-8171
|
Medium |
|
N/A
|
The memory resource controller (aka memcg) in the Linux kernel allows local users to cause a denial of service (deadlock) by spawning new processes within a memory-constrained cgroup. |
["http://rhn.redhat.com/errata/RHSA-2015-0864.html","http://rhn.redhat.com/errata/RHSA-2015-2152.html","http://rhn.redhat.com/errata/RHSA-2015-2411.html","http://rhn.redhat.com/errata/RHSA-2016-0068.html","http://www.securityfocus.com/bid/74293","https://bugzilla.redhat.com/show_bug.cgi?id=1198109","http://rhn.redhat.com/errata/RHSA-2015-0864.html","http://rhn.redhat.com/errata/RHSA-2015-2152.html","http://rhn.redhat.com/errata/RHSA-2015-2411.html","http://rhn.redhat.com/errata/RHSA-2016-0068.html","http://www.securityfocus.com/bid/74293","https://bugzilla.redhat.com/show_bug.cgi?id=1198109"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-21803
|
High |
fixed |
|
Use After Free vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (bluetooth modules) allows Local Execution of Code. This vulnerability is associated with program files https://gitee.Com/anolis/cloud-kernel/blob/devel-5.10/net/bluetooth/af_bluetooth.C.
This issue affects Linux kernel: from v2.6.12-rc2 before v6.8-rc1. |
["https://bugzilla.openanolis.cn/show_bug.cgi?id=8081","https://bugzilla.openanolis.cn/show_bug.cgi?id=8081"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42114
|
Medium |
fixed |
- 5.10.244
- 5.15.165
- 6.1.106
- 6.6.47
- 6.9.9
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values
syzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM
to 2^31.
We had a similar issue in sch_fq, fixed with commit
d9e15a273306 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM")
watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]
Modules linked in:
irq event stamp: 131135
hardirqs last enabled at (131134): [<ffff80008ae8778c>] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline]
hardirqs last enabled at (131134): [<ffff80008ae8778c>] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95
hardirqs last disabled at (131135): [<ffff80008ae85378>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
hardirqs last disabled at (131135): [<ffff80008ae85378>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
softirqs last enabled at (125892): [<ffff80008907e82c>] neigh_hh_init net/core/neighbour.c:1538 [inline]
softirqs last enabled at (125892): [<ffff80008907e82c>] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553
softirqs last disabled at (125896): [<ffff80008904166c>] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19
CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Workqueue: mld mld_ifc_work
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __list_del include/linux/list.h:195 [inline]
pc : __list_del_entry include/linux/list.h:218 [inline]
pc : list_move_tail include/linux/list.h:310 [inline]
pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline]
pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854
lr : __list_del_entry include/linux/list.h:218 [inline]
lr : list_move_tail include/linux/list.h:310 [inline]
lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline]
lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854
sp : ffff800093d36700
x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000
x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0
x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0
x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0
x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8
x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff
x11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc
x2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470
Call trace:
__list_del include/linux/list.h:195 [inline]
__list_del_entry include/linux/list.h:218 [inline]
list_move_tail include/linux/list.h:310 [inline]
fq_tin_dequeue include/net/fq_impl.h:112 [inline]
ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854
wake_tx_push_queue net/mac80211/util.c:294 [inline]
ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315
drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline]
schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline]
ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664
ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966
ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062
__ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338
ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532
__netdev_start_xmit include/linux/netdevice.h:4903 [inline]
netdev_start_xmit include/linux/netdevice.h:4917 [inline]
xmit_one net/core/dev.c:3531 [inline]
dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547
__dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563
neigh_output include/net/neighbour.h:542 [inline]
ip6_fini
---truncated--- |
["https://git.kernel.org/stable/c/33ac5a4eb3d4bea2146658f1b6d1fa86d62d2b22","https://git.kernel.org/stable/c/3fc06f6d142d2840735543216a60d0a8c345bdec","https://git.kernel.org/stable/c/80ac0cc9c0bef984e29637b1efa93d7214b42f53","https://git.kernel.org/stable/c/8a3ac7fb36962c34698f884bd697938054ff2afa","https://git.kernel.org/stable/c/d1cba2ea8121e7fdbe1328cea782876b1dd80993","https://git.kernel.org/stable/c/e87c2f098f52aa2fe20258a5bb1738d6a74e9ed7","https://git.kernel.org/stable/c/d1cba2ea8121e7fdbe1328cea782876b1dd80993","https://git.kernel.org/stable/c/e87c2f098f52aa2fe20258a5bb1738d6a74e9ed7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42131
|
Medium |
fixed |
- 4.19.320
- 5.4.282
- 5.10.222
- 5.15.163
- 6.1.98
- 6.6.39
- 6.9.9
|
In the Linux kernel, the following vulnerability has been resolved:
mm: avoid overflows in dirty throttling logic
The dirty throttling logic is interspersed with assumptions that dirty
limits in PAGE_SIZE units fit into 32-bit (so that various multiplications
fit into 64-bits). If limits end up being larger, we will hit overflows,
possible divisions by 0 etc. Fix these problems by never allowing so
large dirty limits as they have dubious practical value anyway. For
dirty_bytes / dirty_background_bytes interfaces we can just refuse to set
so large limits. For dirty_ratio / dirty_background_ratio it isn't so
simple as the dirty limit is computed from the amount of available memory
which can change due to memory hotplug etc. So when converting dirty
limits from ratios to numbers of pages, we just don't allow the result to
exceed UINT_MAX.
This is root-only triggerable problem which occurs when the operator
sets dirty limits to >16 TB. |
["https://git.kernel.org/stable/c/2b2d2b8766db028bd827af34075f221ae9e9efff","https://git.kernel.org/stable/c/385d838df280eba6c8680f9777bfa0d0bfe7e8b2","https://git.kernel.org/stable/c/4d3817b64eda07491bdd86a234629fe0764fb42a","https://git.kernel.org/stable/c/7a49389771ae7666f4dc3426e2a4594bf23ae290","https://git.kernel.org/stable/c/8e0b5e7f2895eccef5c2a0018b589266f90c4805","https://git.kernel.org/stable/c/a25e8536184516b55ef89ab91dd2eea429de28d2","https://git.kernel.org/stable/c/bd16a7ee339aef3ee4c90cb23902afb6af379ea0","https://git.kernel.org/stable/c/c83ed422c24f0d4b264f89291d4fabe285f80dbc","https://git.kernel.org/stable/c/385d838df280eba6c8680f9777bfa0d0bfe7e8b2","https://git.kernel.org/stable/c/7a49389771ae7666f4dc3426e2a4594bf23ae290","https://git.kernel.org/stable/c/8e0b5e7f2895eccef5c2a0018b589266f90c4805","https://git.kernel.org/stable/c/a25e8536184516b55ef89ab91dd2eea429de28d2","https://git.kernel.org/stable/c/bd16a7ee339aef3ee4c90cb23902afb6af379ea0","https://git.kernel.org/stable/c/c83ed422c24f0d4b264f89291d4fabe285f80dbc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50247
|
High |
fixed |
- 5.15.171
- 6.1.116
- 6.6.60
- 6.11.7
|
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Check if more than chunk-size bytes are written
A incorrectly formatted chunk may decompress into
more than LZNT_CHUNK_SIZE bytes and a index out of bounds
will occur in s_max_off. |
["https://git.kernel.org/stable/c/1b6bc5f7212181093b6c5310eea216fc09c721a9","https://git.kernel.org/stable/c/4a4727bc582832f354e0d3d49838a401a28ae25e","https://git.kernel.org/stable/c/5f21e3e60982cd7353998b4f59f052134fd47d64","https://git.kernel.org/stable/c/9931122d04c6d431b2c11b5bb7b10f28584067f0","https://git.kernel.org/stable/c/e5ae7859008688626b4d2fa6139eeaa08e255053"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2006-2932
|
Medium |
|
N/A
|
A regression error in the restore_all code path of the 4/4GB split support for non-hugemem Linux kernels on Red Hat Linux Desktop and Enterprise Linux 4 allows local users to cause a denial of service (panic) via unspecified vectors. |
["http://secunia.com/advisories/21605","http://secunia.com/advisories/22174","http://support.avaya.com/elmodocs2/security/ASA-2006-203.htm","http://www.osvdb.org/28120","http://www.redhat.com/support/errata/RHSA-2006-0617.html","http://www.securityfocus.com/bid/19664","https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A11410","http://secunia.com/advisories/21605","http://secunia.com/advisories/22174","http://support.avaya.com/elmodocs2/security/ASA-2006-203.htm","http://www.osvdb.org/28120","http://www.redhat.com/support/errata/RHSA-2006-0617.html","http://www.securityfocus.com/bid/19664","https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A11410"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-45003
|
Medium |
fixed |
- 5.4.283
- 5.10.225
- 5.15.166
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
vfs: Don't evict inode under the inode lru traversing context
The inode reclaiming process(See function prune_icache_sb) collects all
reclaimable inodes and mark them with I_FREEING flag at first, at that
time, other processes will be stuck if they try getting these inodes
(See function find_inode_fast), then the reclaiming process destroy the
inodes by function dispose_list(). Some filesystems(eg. ext4 with
ea_inode feature, ubifs with xattr) may do inode lookup in the inode
evicting callback function, if the inode lookup is operated under the
inode lru traversing context, deadlock problems may happen.
Case 1: In function ext4_evict_inode(), the ea inode lookup could happen
if ea_inode feature is enabled, the lookup process will be stuck
under the evicting context like this:
1. File A has inode i_reg and an ea inode i_ea
2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea
3. Then, following three processes running like this:
PA PB
echo 2 > /proc/sys/vm/drop_caches
shrink_slab
prune_dcache_sb
// i_reg is added into lru, lru->i_ea->i_reg
prune_icache_sb
list_lru_walk_one
inode_lru_isolate
i_ea->i_state |= I_FREEING // set inode state
inode_lru_isolate
__iget(i_reg)
spin_unlock(&i_reg->i_lock)
spin_unlock(lru_lock)
rm file A
i_reg->nlink = 0
iput(i_reg) // i_reg->nlink is 0, do evict
ext4_evict_inode
ext4_xattr_delete_inode
ext4_xattr_inode_dec_ref_all
ext4_xattr_inode_iget
ext4_iget(i_ea->i_ino)
iget_locked
find_inode_fast
__wait_on_freeing_inode(i_ea) ----→ AA deadlock
dispose_list // cannot be executed by prune_icache_sb
wake_up_bit(&i_ea->i_state)
Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file
deleting process holds BASEHD's wbuf->io_mutex while getting the
xattr inode, which could race with inode reclaiming process(The
reclaiming process could try locking BASEHD's wbuf->io_mutex in
inode evicting function), then an ABBA deadlock problem would
happen as following:
1. File A has inode ia and a xattr(with inode ixa), regular file B has
inode ib and a xattr.
2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa
3. Then, following three processes running like this:
PA PB PC
echo 2 > /proc/sys/vm/drop_caches
shrink_slab
prune_dcache_sb
// ib and ia are added into lru, lru->ixa->ib->ia
prune_icache_sb
list_lru_walk_one
inode_lru_isolate
ixa->i_state |= I_FREEING // set inode state
inode_lru_isolate
__iget(ib)
spin_unlock(&ib->i_lock)
spin_unlock(lru_lock)
rm file B
ib->nlink = 0
rm file A
iput(ia)
ubifs_evict_inode(ia)
ubifs_jnl_delete_inode(ia)
ubifs_jnl_write_inode(ia)
make_reservation(BASEHD) // Lock wbuf->io_mutex
ubifs_iget(ixa->i_ino)
iget_locked
find_inode_fast
__wait_on_freeing_inode(ixa)
| iput(ib) // ib->nlink is 0, do evict
| ubifs_evict_inode
| ubifs_jnl_delete_inode(ib)
↓ ubifs_jnl_write_inode
ABBA deadlock ←-----make_reservation(BASEHD)
dispose_list // cannot be executed by prune_icache_sb
wake_up_bit(&ixa->i_state)
Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING
to pin the inode in memory while inode_lru_isolate(
---truncated--- |
["https://git.kernel.org/stable/c/03880af02a78bc9a98b5a581f529cf709c88a9b8","https://git.kernel.org/stable/c/2a0629834cd82f05d424bbc193374f9a43d1f87d","https://git.kernel.org/stable/c/3525ad25240dfdd8c78f3470911ed10aa727aa72","https://git.kernel.org/stable/c/437741eba63bf4e437e2beb5583f8633556a2b98","https://git.kernel.org/stable/c/9063ab49c11e9518a3f2352434bb276cc8134c5f","https://git.kernel.org/stable/c/b9bda5f6012dd00372f3a06a82ed8971a4c57c32","https://git.kernel.org/stable/c/cda54ec82c0f9d05393242b20b13f69b083f7e88"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39474
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mm/vmalloc: fix vmalloc which may return null if called with __GFP_NOFAIL
commit a421ef303008 ("mm: allow !GFP_KERNEL allocations for kvmalloc")
includes support for __GFP_NOFAIL, but it presents a conflict with commit
dd544141b9eb ("vmalloc: back off when the current task is OOM-killed"). A
possible scenario is as follows:
process-a
__vmalloc_node_range(GFP_KERNEL | __GFP_NOFAIL)
__vmalloc_area_node()
vm_area_alloc_pages()
--> oom-killer send SIGKILL to process-a
if (fatal_signal_pending(current)) break;
--> return NULL;
To fix this, do not check fatal_signal_pending() in vm_area_alloc_pages()
if __GFP_NOFAIL set.
This issue occurred during OPLUS KASAN TEST. Below is part of the log
-> oom-killer sends signal to process
[65731.222840] [ T1308] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/apps/uid_10198,task=gs.intelligence,pid=32454,uid=10198
[65731.259685] [T32454] Call trace:
[65731.259698] [T32454] dump_backtrace+0xf4/0x118
[65731.259734] [T32454] show_stack+0x18/0x24
[65731.259756] [T32454] dump_stack_lvl+0x60/0x7c
[65731.259781] [T32454] dump_stack+0x18/0x38
[65731.259800] [T32454] mrdump_common_die+0x250/0x39c [mrdump]
[65731.259936] [T32454] ipanic_die+0x20/0x34 [mrdump]
[65731.260019] [T32454] atomic_notifier_call_chain+0xb4/0xfc
[65731.260047] [T32454] notify_die+0x114/0x198
[65731.260073] [T32454] die+0xf4/0x5b4
[65731.260098] [T32454] die_kernel_fault+0x80/0x98
[65731.260124] [T32454] __do_kernel_fault+0x160/0x2a8
[65731.260146] [T32454] do_bad_area+0x68/0x148
[65731.260174] [T32454] do_mem_abort+0x151c/0x1b34
[65731.260204] [T32454] el1_abort+0x3c/0x5c
[65731.260227] [T32454] el1h_64_sync_handler+0x54/0x90
[65731.260248] [T32454] el1h_64_sync+0x68/0x6c
[65731.260269] [T32454] z_erofs_decompress_queue+0x7f0/0x2258
--> be->decompressed_pages = kvcalloc(be->nr_pages, sizeof(struct page *), GFP_KERNEL | __GFP_NOFAIL);
kernel panic by NULL pointer dereference.
erofs assume kvmalloc with __GFP_NOFAIL never return NULL.
[65731.260293] [T32454] z_erofs_runqueue+0xf30/0x104c
[65731.260314] [T32454] z_erofs_readahead+0x4f0/0x968
[65731.260339] [T32454] read_pages+0x170/0xadc
[65731.260364] [T32454] page_cache_ra_unbounded+0x874/0xf30
[65731.260388] [T32454] page_cache_ra_order+0x24c/0x714
[65731.260411] [T32454] filemap_fault+0xbf0/0x1a74
[65731.260437] [T32454] __do_fault+0xd0/0x33c
[65731.260462] [T32454] handle_mm_fault+0xf74/0x3fe0
[65731.260486] [T32454] do_mem_abort+0x54c/0x1b34
[65731.260509] [T32454] el0_da+0x44/0x94
[65731.260531] [T32454] el0t_64_sync_handler+0x98/0xb4
[65731.260553] [T32454] el0t_64_sync+0x198/0x19c |
["https://git.kernel.org/stable/c/198a80833e3421d4c9820a4ae907120adf598c91","https://git.kernel.org/stable/c/758678b65164b2158fc1de411092191cb3c394d4","https://git.kernel.org/stable/c/8e0545c83d672750632f46e3f9ad95c48c91a0fc","https://git.kernel.org/stable/c/c55d3564ad25ce87ab7cc6af251f9574faebd8da","https://git.kernel.org/stable/c/198a80833e3421d4c9820a4ae907120adf598c91","https://git.kernel.org/stable/c/758678b65164b2158fc1de411092191cb3c394d4","https://git.kernel.org/stable/c/8e0545c83d672750632f46e3f9ad95c48c91a0fc","https://git.kernel.org/stable/c/c55d3564ad25ce87ab7cc6af251f9574faebd8da"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40973
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
media: mtk-vcodec: potential null pointer deference in SCP
The return value of devm_kzalloc() needs to be checked to avoid
NULL pointer deference. This is similar to CVE-2022-3113. |
["https://git.kernel.org/stable/c/3a693c7e243b932faee5c1fb728efa73f0abc39b","https://git.kernel.org/stable/c/53dbe08504442dc7ba4865c09b3bbf5fe849681b","https://git.kernel.org/stable/c/eeb62bb4ca22db17f7dfe8fb8472e0442df3d92f","https://git.kernel.org/stable/c/f066882293b5ad359e44c4ed24ab1811ffb0b354","https://git.kernel.org/stable/c/3a693c7e243b932faee5c1fb728efa73f0abc39b","https://git.kernel.org/stable/c/53dbe08504442dc7ba4865c09b3bbf5fe849681b","https://git.kernel.org/stable/c/f066882293b5ad359e44c4ed24ab1811ffb0b354"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41001
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
io_uring/sqpoll: work around a potential audit memory leak
kmemleak complains that there's a memory leak related to connect
handling:
unreferenced object 0xffff0001093bdf00 (size 128):
comm "iou-sqp-455", pid 457, jiffies 4294894164
hex dump (first 32 bytes):
02 00 fa ea 7f 00 00 01 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 2e481b1a):
[<00000000c0a26af4>] kmemleak_alloc+0x30/0x38
[<000000009c30bb45>] kmalloc_trace+0x228/0x358
[<000000009da9d39f>] __audit_sockaddr+0xd0/0x138
[<0000000089a93e34>] move_addr_to_kernel+0x1a0/0x1f8
[<000000000b4e80e6>] io_connect_prep+0x1ec/0x2d4
[<00000000abfbcd99>] io_submit_sqes+0x588/0x1e48
[<00000000e7c25e07>] io_sq_thread+0x8a4/0x10e4
[<00000000d999b491>] ret_from_fork+0x10/0x20
which can can happen if:
1) The command type does something on the prep side that triggers an
audit call.
2) The thread hasn't done any operations before this that triggered
an audit call inside ->issue(), where we have audit_uring_entry()
and audit_uring_exit().
Work around this by issuing a blanket NOP operation before the SQPOLL
does anything. |
["https://git.kernel.org/stable/c/55c22375cbaa24f77dd13f9ae0642915444a1227","https://git.kernel.org/stable/c/9e810bd995823786ea30543e480e8a573e5e5667","https://git.kernel.org/stable/c/a40e90d9304629002fb17200f7779823a81191d3","https://git.kernel.org/stable/c/c4ce0ab27646f4206a9eb502d6fe45cb080e1cae","https://git.kernel.org/stable/c/55c22375cbaa24f77dd13f9ae0642915444a1227","https://git.kernel.org/stable/c/9e810bd995823786ea30543e480e8a573e5e5667","https://git.kernel.org/stable/c/a40e90d9304629002fb17200f7779823a81191d3","https://git.kernel.org/stable/c/c4ce0ab27646f4206a9eb502d6fe45cb080e1cae"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36288
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix loop termination condition in gss_free_in_token_pages()
The in_token->pages[] array is not NULL terminated. This results in
the following KASAN splat:
KASAN: maybe wild-memory-access in range [0x04a2013400000008-0x04a201340000000f] |
["https://git.kernel.org/stable/c/0a1cb0c6102bb4fd310243588d39461da49497ad","https://git.kernel.org/stable/c/4a77c3dead97339478c7422eb07bf4bf63577008","https://git.kernel.org/stable/c/4cefcd0af7458bdeff56a9d8dfc6868ce23d128a","https://git.kernel.org/stable/c/57ff6c0a175930856213b2aa39f8c845a53e5b1c","https://git.kernel.org/stable/c/6ed45d20d30005bed94c8c527ce51d5ad8121018","https://git.kernel.org/stable/c/af628d43a822b78ad8d4a58d8259f8bf8bc71115","https://git.kernel.org/stable/c/b4878ea99f2b40ef1925720b1b4ca7f4af1ba785","https://git.kernel.org/stable/c/f9977e4e0cd98a5f06f2492b4f3547db58deabf5","https://git.kernel.org/stable/c/0a1cb0c6102bb4fd310243588d39461da49497ad","https://git.kernel.org/stable/c/4a77c3dead97339478c7422eb07bf4bf63577008","https://git.kernel.org/stable/c/4cefcd0af7458bdeff56a9d8dfc6868ce23d128a","https://git.kernel.org/stable/c/57ff6c0a175930856213b2aa39f8c845a53e5b1c","https://git.kernel.org/stable/c/6ed45d20d30005bed94c8c527ce51d5ad8121018","https://git.kernel.org/stable/c/af628d43a822b78ad8d4a58d8259f8bf8bc71115","https://git.kernel.org/stable/c/b4878ea99f2b40ef1925720b1b4ca7f4af1ba785","https://git.kernel.org/stable/c/f9977e4e0cd98a5f06f2492b4f3547db58deabf5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49963
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
mailbox: bcm2835: Fix timeout during suspend mode
During noirq suspend phase the Raspberry Pi power driver suffer of
firmware property timeouts. The reason is that the IRQ of the underlying
BCM2835 mailbox is disabled and rpi_firmware_property_list() will always
run into a timeout [1].
Since the VideoCore side isn't consider as a wakeup source, set the
IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled
during suspend-resume cycle.
[1]
PM: late suspend of devices complete after 1.754 msecs
WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128
rpi_firmware_property_list+0x204/0x22c
Firmware transaction 0x00028001 timeout
Modules linked in:
CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17
Hardware name: BCM2835
Call trace:
unwind_backtrace from show_stack+0x18/0x1c
show_stack from dump_stack_lvl+0x34/0x44
dump_stack_lvl from __warn+0x88/0xec
__warn from warn_slowpath_fmt+0x7c/0xb0
warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c
rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c
rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0
rpi_firmware_set_power from _genpd_power_off+0xe4/0x148
_genpd_power_off from genpd_sync_power_off+0x7c/0x11c
genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0
genpd_finish_suspend from dpm_run_callback+0x78/0xd0
dpm_run_callback from device_suspend_noirq+0xc0/0x238
device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168
dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac
suspend_devices_and_enter from pm_suspend+0x254/0x2e4
pm_suspend from state_store+0xa8/0xd4
state_store from kernfs_fop_write_iter+0x154/0x1a0
kernfs_fop_write_iter from vfs_write+0x12c/0x184
vfs_write from ksys_write+0x78/0xc0
ksys_write from ret_fast_syscall+0x0/0x54
Exception stack(0xcc93dfa8 to 0xcc93dff0)
[...]
PM: noirq suspend of devices complete after 3095.584 msecs |
["https://git.kernel.org/stable/c/10a58555e0bb5cc4673c8bb73b8afc5fa651f0ac","https://git.kernel.org/stable/c/32ee78823dea2d54adaf6e05f86622eba359e091","https://git.kernel.org/stable/c/4e1e03760ee7cc4779b6306867fe0fc02921b963","https://git.kernel.org/stable/c/90320cfc07b7d6e7a58fd8168f6380ec52ff0251","https://git.kernel.org/stable/c/b0de20de29b13950493a36bd4cf531200eb0e807","https://git.kernel.org/stable/c/dc09f007caed3b2f6a3b6bd7e13777557ae22bfd","https://git.kernel.org/stable/c/df293ea78740a41384d648041f38f645700288e1","https://git.kernel.org/stable/c/dfeb67b2194ecc55ef8065468c5adda3cdf59114","https://git.kernel.org/stable/c/e65a9af05a0b59ebeba28e5e82265a233db7bc27"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50233
|
Medium |
fixed |
- 5.4.285
- 5.10.229
- 5.15.171
- 6.1.116
- 6.6.60
- 6.11.7
|
In the Linux kernel, the following vulnerability has been resolved:
staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg()
In the ad9832_write_frequency() function, clk_get_rate() might return 0.
This can lead to a division by zero when calling ad9832_calc_freqreg().
The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect
against the case when fout is 0. The ad9832_write_frequency() function
is called from ad9832_write(), and fout is derived from a text buffer,
which can contain any value. |
["https://git.kernel.org/stable/c/2f39548f45693d86e950647012a214da6917dc9f","https://git.kernel.org/stable/c/442f786c5bff8cfd756ebdeaa4aadbf05c22aa5a","https://git.kernel.org/stable/c/6bd301819f8f69331a55ae2336c8b111fc933f3d","https://git.kernel.org/stable/c/adfbc08b94e7df08b9ed5fa26b969cc1b54c84ec","https://git.kernel.org/stable/c/ccbc10647aafe2b7506edb4b10e19c6c2416c162","https://git.kernel.org/stable/c/dd9e1cf619c945f320e686dcaf13e37ef0b05fdd","https://git.kernel.org/stable/c/fcd6b59f7a774558e2525251c68aa37aff748e55"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50292
|
Medium |
fixed |
- 5.10.230
- 5.15.172
- 6.1.117
- 6.6.61
- 6.11.8
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove
In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not
null. So the release of the dma channel leads to the following issue:
[ 4.879000] st,stm32-spdifrx 500d0000.audio-controller:
dma_request_slave_channel error -19
[ 4.888975] Unable to handle kernel NULL pointer dereference
at virtual address 000000000000003d
[...]
[ 5.096577] Call trace:
[ 5.099099] dma_release_channel+0x24/0x100
[ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx]
[ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx]
To avoid this issue, release channel only if the pointer is valid. |
["https://git.kernel.org/stable/c/0d75f887aabd80cf37ea48d28f159afa7850ea28","https://git.kernel.org/stable/c/22ae9321054cf7f36c537702af133659f51a0b88","https://git.kernel.org/stable/c/23bdbd1ef3e063e03d3c50c15a591b005ebbae39","https://git.kernel.org/stable/c/3a977b554f668382dfba31fd62e4cce4fe5643db","https://git.kernel.org/stable/c/4f1d74f74752eab8af6b8b28797dc6490d57374c","https://git.kernel.org/stable/c/9bb4af400c386374ab1047df44c508512c08c31f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35790
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute group
The DisplayPort driver's sysfs nodes may be present to the userspace before
typec_altmode_set_drvdata() completes in dp_altmode_probe. This means that
a sysfs read can trigger a NULL pointer error by deferencing dp->hpd in
hpd_show or dp->lock in pin_assignment_show, as dev_get_drvdata() returns
NULL in those cases.
Remove manual sysfs node creation in favor of adding attribute group as
default for devices bound to the driver. The ATTRIBUTE_GROUPS() macro is
not used here otherwise the path to the sysfs nodes is no longer compliant
with the ABI. |
["https://git.kernel.org/stable/c/0ad011776c057ce881b7fd6d8c79ecd459c087e9","https://git.kernel.org/stable/c/165376f6b23e9a779850e750fb2eb06622e5a531","https://git.kernel.org/stable/c/4a22aeac24d0d5f26ba741408e8b5a4be6dc5dc0","https://git.kernel.org/stable/c/9794ffd9d0c39ee070fbd733f862bbe89b28ba33","https://git.kernel.org/stable/c/f1c5ddaef506e3517dce338c08a60663b1521920","https://git.kernel.org/stable/c/0ad011776c057ce881b7fd6d8c79ecd459c087e9","https://git.kernel.org/stable/c/165376f6b23e9a779850e750fb2eb06622e5a531","https://git.kernel.org/stable/c/4a22aeac24d0d5f26ba741408e8b5a4be6dc5dc0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35904
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
selinux: avoid dereference of garbage after mount failure
In case kern_mount() fails and returns an error pointer return in the
error branch instead of continuing and dereferencing the error pointer.
While on it drop the never read static variable selinuxfs_mount. |
["https://git.kernel.org/stable/c/37801a36b4d68892ce807264f784d818f8d0d39b","https://git.kernel.org/stable/c/477ed6789eb9f3f4d3568bb977f90c863c12724e","https://git.kernel.org/stable/c/68784a5d01b8868ff85a7926676b6729715fff3c","http://www.openwall.com/lists/oss-security/2024/05/30/1","http://www.openwall.com/lists/oss-security/2024/05/30/2","https://git.kernel.org/stable/c/37801a36b4d68892ce807264f784d818f8d0d39b","https://git.kernel.org/stable/c/477ed6789eb9f3f4d3568bb977f90c863c12724e","https://git.kernel.org/stable/c/68784a5d01b8868ff85a7926676b6729715fff3c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48673
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Fix possible access to freed memory in link clear
After modifying the QP to the Error state, all RX WR would be completed
with WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not
wait for it is done, but destroy the QP and free the link group directly.
So there is a risk that accessing the freed memory in tasklet context.
Here is a crash example:
BUG: unable to handle page fault for address: ffffffff8f220860
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060
Oops: 0002 [#1] SMP PTI
CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S OE 5.10.0-0607+ #23
Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018
RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0
Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e <48> 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32
RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086
RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000
RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00
RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b
R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010
R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040
FS: 0000000000000000(0000) GS:ffff91db1f840000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffff8f220860 CR3: 00000001f9580004 CR4: 00000000003706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<IRQ>
_raw_spin_lock_irqsave+0x30/0x40
mlx5_ib_poll_cq+0x4c/0xc50 [mlx5_ib]
smc_wr_rx_tasklet_fn+0x56/0xa0 [smc]
tasklet_action_common.isra.21+0x66/0x100
__do_softirq+0xd5/0x29c
asm_call_irq_on_stack+0x12/0x20
</IRQ>
do_softirq_own_stack+0x37/0x40
irq_exit_rcu+0x9d/0xa0
sysvec_call_function_single+0x34/0x80
asm_sysvec_call_function_single+0x12/0x20 |
["https://git.kernel.org/stable/c/89fcb70f1acd6b0bbf2f7bfbf45d7aa75a9bdcde","https://git.kernel.org/stable/c/e9b1a4f867ae9c1dbd1d71cd09cbdb3239fb4968","https://git.kernel.org/stable/c/89fcb70f1acd6b0bbf2f7bfbf45d7aa75a9bdcde","https://git.kernel.org/stable/c/e9b1a4f867ae9c1dbd1d71cd09cbdb3239fb4968"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48703
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR
In some case, the GDDV returns a package with a buffer which has
zero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10).
Then the data_vault_read() got NULL point dereference problem when
accessing the 0x10 value in data_vault.
[ 71.024560] BUG: kernel NULL pointer dereference, address:
0000000000000010
This patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or
NULL value in data_vault. |
["https://git.kernel.org/stable/c/7931e28098a4c1a2a6802510b0cbe57546d2049d","https://git.kernel.org/stable/c/dae42083b045a4ddf71c57cf350cb2412b5915c2","https://git.kernel.org/stable/c/7931e28098a4c1a2a6802510b0cbe57546d2049d","https://git.kernel.org/stable/c/dae42083b045a4ddf71c57cf350cb2412b5915c2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48706
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
vdpa: ifcvf: Do proper cleanup if IFCVF init fails
ifcvf_mgmt_dev leaks memory if it is not freed before
returning. Call is made to correct return statement
so memory does not leak. ifcvf_init_hw does not take
care of this so it is needed to do it here. |
["https://git.kernel.org/stable/c/5d2cc32c1c10bd889125d2adc16a6bc3338dcd3e","https://git.kernel.org/stable/c/6b04456e248761cf68f562f2fd7c04e591fcac94","https://git.kernel.org/stable/c/5d2cc32c1c10bd889125d2adc16a6bc3338dcd3e","https://git.kernel.org/stable/c/6b04456e248761cf68f562f2fd7c04e591fcac94"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42139
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ice: Fix improper extts handling
Extts events are disabled and enabled by the application ts2phc.
However, in case where the driver is removed when the application is
running, a specific extts event remains enabled and can cause a kernel
crash.
As a side effect, when the driver is reloaded and application is started
again, remaining extts event for the channel from a previous run will
keep firing and the message "extts on unexpected channel" might be
printed to the user.
To avoid that, extts events shall be disabled when PTP is released. |
["https://git.kernel.org/stable/c/00d3b4f54582d4e4a02cda5886bb336eeab268cc","https://git.kernel.org/stable/c/9f69b31ae9e25dec27ad31fbc64dd99af16ee3d3","https://git.kernel.org/stable/c/00d3b4f54582d4e4a02cda5886bb336eeab268cc","https://git.kernel.org/stable/c/9f69b31ae9e25dec27ad31fbc64dd99af16ee3d3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43905
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: Fix the null pointer dereference for vega10_hwmgr
Check return value and conduct null pointer handling to avoid null pointer dereference. |
["https://git.kernel.org/stable/c/0fa11f9df96217c2785b040629ff1a16900fb51c","https://git.kernel.org/stable/c/2ac9deb7e087f0b461c3559d9eaa6b9cf19d3fa8","https://git.kernel.org/stable/c/2e538944996d0dd497faf8ee81f8bfcd3aca7d80","https://git.kernel.org/stable/c/50151b7f1c79a09117837eb95b76c2de76841dab","https://git.kernel.org/stable/c/69a441473fec2fc2aa2cf56122d6c42c4266a239","https://git.kernel.org/stable/c/c2629daf218a325f4d69754452cd42fe8451c15b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27002
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: Do a runtime PM get on controllers during probe
mt8183-mfgcfg has a mutual dependency with genpd during the probing
stage, which leads to a deadlock in the following call stack:
CPU0: genpd_lock --> clk_prepare_lock
genpd_power_off_work_fn()
genpd_lock()
generic_pm_domain::power_off()
clk_unprepare()
clk_prepare_lock()
CPU1: clk_prepare_lock --> genpd_lock
clk_register()
__clk_core_init()
clk_prepare_lock()
clk_pm_runtime_get()
genpd_lock()
Do a runtime PM get at the probe function to make sure clk_register()
won't acquire the genpd lock. Instead of only modifying mt8183-mfgcfg,
do this on all mediatek clock controller probings because we don't
believe this would cause any regression.
Verified on MT8183 and MT8192 Chromebooks. |
["https://git.kernel.org/stable/c/165d226472575b213dd90dfda19d1605dd7c19a8","https://git.kernel.org/stable/c/2f7b1d8b5505efb0057cd1ab85fca206063ea4c3","https://git.kernel.org/stable/c/b62ed25feb342eab052822eff0c554873799a4f5","https://git.kernel.org/stable/c/c0dcd5c072e2a3fff886f673e6a5d9bf8090c4cc","https://git.kernel.org/stable/c/165d226472575b213dd90dfda19d1605dd7c19a8","https://git.kernel.org/stable/c/2f7b1d8b5505efb0057cd1ab85fca206063ea4c3","https://git.kernel.org/stable/c/b62ed25feb342eab052822eff0c554873799a4f5","https://git.kernel.org/stable/c/c0dcd5c072e2a3fff886f673e6a5d9bf8090c4cc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27014
|
Medium |
fixed |
- 5.15.157
- 6.1.88
- 6.6.29
- 6.8.8
|
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Prevent deadlock while disabling aRFS
When disabling aRFS under the `priv->state_lock`, any scheduled
aRFS works are canceled using the `cancel_work_sync` function,
which waits for the work to end if it has already started.
However, while waiting for the work handler, the handler will
try to acquire the `state_lock` which is already acquired.
The worker acquires the lock to delete the rules if the state
is down, which is not the worker's responsibility since
disabling aRFS deletes the rules.
Add an aRFS state variable, which indicates whether the aRFS is
enabled and prevent adding rules when the aRFS is disabled.
Kernel log:
======================================================
WARNING: possible circular locking dependency detected
6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I
------------------------------------------------------
ethtool/386089 is trying to acquire lock:
ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0
but task is already holding lock:
ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&priv->state_lock){+.+.}-{3:3}:
__mutex_lock+0x80/0xc90
arfs_handle_work+0x4b/0x3b0 [mlx5_core]
process_one_work+0x1dc/0x4a0
worker_thread+0x1bf/0x3c0
kthread+0xd7/0x100
ret_from_fork+0x2d/0x50
ret_from_fork_asm+0x11/0x20
-> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}:
__lock_acquire+0x17b4/0x2c80
lock_acquire+0xd0/0x2b0
__flush_work+0x7a/0x4e0
__cancel_work_timer+0x131/0x1c0
arfs_del_rules+0x143/0x1e0 [mlx5_core]
mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]
mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]
ethnl_set_channels+0x28f/0x3b0
ethnl_default_set_doit+0xec/0x240
genl_family_rcv_msg_doit+0xd0/0x120
genl_rcv_msg+0x188/0x2c0
netlink_rcv_skb+0x54/0x100
genl_rcv+0x24/0x40
netlink_unicast+0x1a1/0x270
netlink_sendmsg+0x214/0x460
__sock_sendmsg+0x38/0x60
__sys_sendto+0x113/0x170
__x64_sys_sendto+0x20/0x30
do_syscall_64+0x40/0xe0
entry_SYSCALL_64_after_hwframe+0x46/0x4e
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&priv->state_lock);
lock((work_completion)(&rule->arfs_work));
lock(&priv->state_lock);
lock((work_completion)(&rule->arfs_work));
*** DEADLOCK ***
3 locks held by ethtool/386089:
#0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40
#1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240
#2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
stack backtrace:
CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x60/0xa0
check_noncircular+0x144/0x160
__lock_acquire+0x17b4/0x2c80
lock_acquire+0xd0/0x2b0
? __flush_work+0x74/0x4e0
? save_trace+0x3e/0x360
? __flush_work+0x74/0x4e0
__flush_work+0x7a/0x4e0
? __flush_work+0x74/0x4e0
? __lock_acquire+0xa78/0x2c80
? lock_acquire+0xd0/0x2b0
? mark_held_locks+0x49/0x70
__cancel_work_timer+0x131/0x1c0
? mark_held_locks+0x49/0x70
arfs_del_rules+0x143/0x1e0 [mlx5_core]
mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]
mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]
ethnl_set_channels+0x28f/0x3b0
ethnl_default_set_doit+0xec/0x240
genl_family_rcv_msg_doit+0xd0/0x120
genl_rcv_msg+0x188/0x2c0
? ethn
---truncated--- |
["https://git.kernel.org/stable/c/0080bf99499468030248ebd25dd645e487dcecdc","https://git.kernel.org/stable/c/46efa4d5930cf3c2af8c01f75e0a47e4fc045e3b","https://git.kernel.org/stable/c/48c4bb81df19402d4346032353d0795260255e3b","https://git.kernel.org/stable/c/fef965764cf562f28afb997b626fc7c3cec99693","https://git.kernel.org/stable/c/0080bf99499468030248ebd25dd645e487dcecdc","https://git.kernel.org/stable/c/46efa4d5930cf3c2af8c01f75e0a47e4fc045e3b","https://git.kernel.org/stable/c/48c4bb81df19402d4346032353d0795260255e3b","https://git.kernel.org/stable/c/fef965764cf562f28afb997b626fc7c3cec99693"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48675
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
IB/core: Fix a nested dead lock as part of ODP flow
Fix a nested dead lock as part of ODP flow by using mmput_async().
From the below call trace [1] can see that calling mmput() once we have
the umem_odp->umem_mutex locked as required by
ib_umem_odp_map_dma_and_lock() might trigger in the same task the
exit_mmap()->__mmu_notifier_release()->mlx5_ib_invalidate_range() which
may dead lock when trying to lock the same mutex.
Moving to use mmput_async() will solve the problem as the above
exit_mmap() flow will be called in other task and will be executed once
the lock will be available.
[1]
[64843.077665] task:kworker/u133:2 state:D stack: 0 pid:80906 ppid:
2 flags:0x00004000
[64843.077672] Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib]
[64843.077719] Call Trace:
[64843.077722] <TASK>
[64843.077724] __schedule+0x23d/0x590
[64843.077729] schedule+0x4e/0xb0
[64843.077735] schedule_preempt_disabled+0xe/0x10
[64843.077740] __mutex_lock.constprop.0+0x263/0x490
[64843.077747] __mutex_lock_slowpath+0x13/0x20
[64843.077752] mutex_lock+0x34/0x40
[64843.077758] mlx5_ib_invalidate_range+0x48/0x270 [mlx5_ib]
[64843.077808] __mmu_notifier_release+0x1a4/0x200
[64843.077816] exit_mmap+0x1bc/0x200
[64843.077822] ? walk_page_range+0x9c/0x120
[64843.077828] ? __cond_resched+0x1a/0x50
[64843.077833] ? mutex_lock+0x13/0x40
[64843.077839] ? uprobe_clear_state+0xac/0x120
[64843.077860] mmput+0x5f/0x140
[64843.077867] ib_umem_odp_map_dma_and_lock+0x21b/0x580 [ib_core]
[64843.077931] pagefault_real_mr+0x9a/0x140 [mlx5_ib]
[64843.077962] pagefault_mr+0xb4/0x550 [mlx5_ib]
[64843.077992] pagefault_single_data_segment.constprop.0+0x2ac/0x560
[mlx5_ib]
[64843.078022] mlx5_ib_eqe_pf_action+0x528/0x780 [mlx5_ib]
[64843.078051] process_one_work+0x22b/0x3d0
[64843.078059] worker_thread+0x53/0x410
[64843.078065] ? process_one_work+0x3d0/0x3d0
[64843.078073] kthread+0x12a/0x150
[64843.078079] ? set_kthread_struct+0x50/0x50
[64843.078085] ret_from_fork+0x22/0x30
[64843.078093] </TASK> |
["https://git.kernel.org/stable/c/819110054b14d7272b4188db997a3d80f75ab785","https://git.kernel.org/stable/c/83c43fd872e32c8071d5582eb7c40f573a8342f3","https://git.kernel.org/stable/c/85eaeb5058f0f04dffb124c97c86b4f18db0b833","https://git.kernel.org/stable/c/e8de6cb5755eae7b793d8c00c8696c8667d44a7f","https://git.kernel.org/stable/c/819110054b14d7272b4188db997a3d80f75ab785","https://git.kernel.org/stable/c/83c43fd872e32c8071d5582eb7c40f573a8342f3","https://git.kernel.org/stable/c/85eaeb5058f0f04dffb124c97c86b4f18db0b833","https://git.kernel.org/stable/c/e8de6cb5755eae7b793d8c00c8696c8667d44a7f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50154
|
High |
fixed |
- 4.2
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().
Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler().
"""
We are seeing a use-after-free from a bpf prog attached to
trace_tcp_retransmit_synack. The program passes the req->sk to the
bpf_sk_storage_get_tracing kernel helper which does check for null
before using it.
"""
The commit 83fccfc3940c ("inet: fix potential deadlock in
reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not
to call del_timer_sync() from reqsk_timer_handler(), but it introduced a
small race window.
Before the timer is called, expire_timers() calls detach_timer(timer, true)
to clear timer->entry.pprev and marks it as not pending.
If reqsk_queue_unlink() checks timer_pending() just after expire_timers()
calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will
continue running and send multiple SYN+ACKs until it expires.
The reported UAF could happen if req->sk is close()d earlier than the timer
expiration, which is 63s by default.
The scenario would be
1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(),
but del_timer_sync() is missed
2. reqsk timer is executed and scheduled again
3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but
reqsk timer still has another one, and inet_csk_accept() does not
clear req->sk for non-TFO sockets
4. sk is close()d
5. reqsk timer is executed again, and BPF touches req->sk
Let's not use timer_pending() by passing the caller context to
__inet_csk_reqsk_queue_drop().
Note that reqsk timer is pinned, so the issue does not happen in most
use cases. [1]
[0]
BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0
Use-after-free read at 0x00000000a891fb3a (in kfence-#1):
bpf_sk_storage_get_tracing+0x2e/0x1b0
bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda
bpf_trace_run2+0x4c/0xc0
tcp_rtx_synack+0xf9/0x100
reqsk_timer_handler+0xda/0x3d0
run_timer_softirq+0x292/0x8a0
irq_exit_rcu+0xf5/0x320
sysvec_apic_timer_interrupt+0x6d/0x80
asm_sysvec_apic_timer_interrupt+0x16/0x20
intel_idle_irq+0x5a/0xa0
cpuidle_enter_state+0x94/0x273
cpu_startup_entry+0x15e/0x260
start_secondary+0x8a/0x90
secondary_startup_64_no_verify+0xfa/0xfb
kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6
allocated by task 0 on cpu 9 at 260507.901592s:
sk_prot_alloc+0x35/0x140
sk_clone_lock+0x1f/0x3f0
inet_csk_clone_lock+0x15/0x160
tcp_create_openreq_child+0x1f/0x410
tcp_v6_syn_recv_sock+0x1da/0x700
tcp_check_req+0x1fb/0x510
tcp_v6_rcv+0x98b/0x1420
ipv6_list_rcv+0x2258/0x26e0
napi_complete_done+0x5b1/0x2990
mlx5e_napi_poll+0x2ae/0x8d0
net_rx_action+0x13e/0x590
irq_exit_rcu+0xf5/0x320
common_interrupt+0x80/0x90
asm_common_interrupt+0x22/0x40
cpuidle_enter_state+0xfb/0x273
cpu_startup_entry+0x15e/0x260
start_secondary+0x8a/0x90
secondary_startup_64_no_verify+0xfa/0xfb
freed by task 0 on cpu 9 at 260507.927527s:
rcu_core_si+0x4ff/0xf10
irq_exit_rcu+0xf5/0x320
sysvec_apic_timer_interrupt+0x6d/0x80
asm_sysvec_apic_timer_interrupt+0x16/0x20
cpuidle_enter_state+0xfb/0x273
cpu_startup_entry+0x15e/0x260
start_secondary+0x8a/0x90
secondary_startup_64_no_verify+0xfa/0xfb |
["https://git.kernel.org/stable/c/106e457953315e476b3642ef24be25ed862aaba3","https://git.kernel.org/stable/c/5071beb59ee416e8ab456ac8647a4dabcda823b1","https://git.kernel.org/stable/c/51e34db64f4e43c7b055ccf881b7f3e0c31bb26d","https://git.kernel.org/stable/c/8459d61fbf24967839a70235165673148c7c7f17","https://git.kernel.org/stable/c/997ae8da14f1639ce6fb66a063dab54031cd61b3","https://git.kernel.org/stable/c/c964bf65f80a14288d767023a1b300b30f5b9cd0","https://git.kernel.org/stable/c/e8c526f2bdf1845bedaf6a478816a3d06fa78b8f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2019-3016
|
Medium |
|
N/A
|
In a Linux KVM guest that has PV TLB enabled, a process in the guest kernel may be able to read memory locations from another process in the same guest. This problem is limit to the host running linux kernel 4.10 with a guest running linux kernel 4.16 or later. The problem mainly affects AMD processors but Intel CPUs cannot be ruled out. |
["http://packetstormsecurity.com/files/157233/Kernel-Live-Patch-Security-Notice-LSN-0065-1.html","http://www.openwall.com/lists/oss-security/2020/01/30/4","https://bugzilla.redhat.com/show_bug.cgi?id=1792167","https://git.kernel.org/linus/1eff70a9abd46f175defafd29bc17ad456f398a7","https://git.kernel.org/linus/8c6de56a42e0c657955e12b882a81ef07d1d073e","https://git.kernel.org/linus/917248144db5d7320655dbb41d3af0b8a0f3d589","https://git.kernel.org/linus/a6bd811f1209fe1c64c9f6fd578101d6436c6b6e","https://git.kernel.org/linus/b043138246a41064527cf019a3d51d9f015e9796","https://lore.kernel.org/lkml/1580407316-11391-1-git-send-email-pbonzini%40redhat.com/","https://security.netapp.com/advisory/ntap-20200313-0003/","https://usn.ubuntu.com/4300-1/","https://usn.ubuntu.com/4301-1/","https://www.debian.org/security/2020/dsa-4699","http://packetstormsecurity.com/files/157233/Kernel-Live-Patch-Security-Notice-LSN-0065-1.html","http://www.openwall.com/lists/oss-security/2020/01/30/4","https://bugzilla.redhat.com/show_bug.cgi?id=1792167","https://git.kernel.org/linus/1eff70a9abd46f175defafd29bc17ad456f398a7","https://git.kernel.org/linus/8c6de56a42e0c657955e12b882a81ef07d1d073e","https://git.kernel.org/linus/917248144db5d7320655dbb41d3af0b8a0f3d589","https://git.kernel.org/linus/a6bd811f1209fe1c64c9f6fd578101d6436c6b6e","https://git.kernel.org/linus/b043138246a41064527cf019a3d51d9f015e9796","https://lore.kernel.org/lkml/1580407316-11391-1-git-send-email-pbonzini%40redhat.com/","https://security.netapp.com/advisory/ntap-20200313-0003/","https://usn.ubuntu.com/4300-1/","https://usn.ubuntu.com/4301-1/","https://www.debian.org/security/2020/dsa-4699"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46833
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: void array out of bound when loop tnl_num
When query reg inf of SSU, it loops tnl_num times. However, tnl_num comes
from hardware and the length of array is a fixed value. To void array out
of bound, make sure the loop time is not greater than the length of array |
["https://git.kernel.org/stable/c/86db7bfb06704ef17340eeae71c832f21cfce35c","https://git.kernel.org/stable/c/c33a9806dc806bcb4a31dc71fb06979219181ad4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46836
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: aspeed_udc: validate endpoint index for ast udc
We should verify the bound of the array to assure that host
may not manipulate the index to point past endpoint array.
Found by static analysis. |
["https://git.kernel.org/stable/c/31bd4fab49c0adc6228848357c1b1df9395858af","https://git.kernel.org/stable/c/6fe9ca2ca389114c8da66e534c18273497843e8a","https://git.kernel.org/stable/c/b2a50ffdd1a079869a62198a8d1441355c513c7c","https://git.kernel.org/stable/c/ee0d382feb44ec0f445e2ad63786cd7f3f6a8199"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53098
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/ufence: Prefetch ufence addr to catch bogus address
access_ok() only checks for addr overflow so also try to read the addr
to catch invalid addr sent from userspace.
(cherry picked from commit 9408c4508483ffc60811e910a93d6425b8e63928) |
["https://git.kernel.org/stable/c/5d623ffbae96b23f1fc43a3d5a267aabdb07583d","https://git.kernel.org/stable/c/9c1813b3253480b30604c680026c7dc721ce86d1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53133
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Handle dml allocation failure to avoid crash
[Why]
In the case where a dml allocation fails for any reason, the
current state's dml contexts would no longer be valid. Then
subsequent calls dc_state_copy_internal would shallow copy
invalid memory and if the new state was released, a double
free would occur.
[How]
Reset dml pointers in new_state to NULL and avoid invalid
pointer
(cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c) |
["https://git.kernel.org/stable/c/6825cb07b79ffeb1d90ffaa7a1227462cdca34ae","https://git.kernel.org/stable/c/874ff59cde8fc525112dda26b501a1bac17dde9f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4273
|
Medium |
fixed |
|
A flaw was found in the exFAT driver of the Linux kernel. The vulnerability exists in the implementation of the file name reconstruction function, which is responsible for reading file name entries from a directory index and merging file name parts belonging to one file into a single long file name. Since the file name characters are copied into a stack variable, a local privileged attacker could use this flaw to overflow the kernel stack. |
["https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/security/cve/CVE-2023-4273","https://bugzilla.redhat.com/show_bug.cgi?id=2221609","https://dfir.ru/2023/08/23/cve-2023-4273-a-vulnerability-in-the-linux-exfat-driver/","https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/security/cve/CVE-2023-4273","https://bugzilla.redhat.com/show_bug.cgi?id=2221609","https://dfir.ru/2023/08/23/cve-2023-4273-a-vulnerability-in-the-linux-exfat-driver/","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/344H6HO6SSC4KT7PDFXSDIXKMKHISSGF/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/3TYLSJ2SAI7RF56ZLQ5CQWCJLVJSD73Q/","https://security.netapp.com/advisory/ntap-20231027-0002/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48697
|
Medium |
fixed |
- 4.19.260
- 5.4.213
- 5.10.143
- 5.15.68
- 5.19.9
|
In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix a use-after-free
Fix the following use-after-free complaint triggered by blktests nvme/004:
BUG: KASAN: user-memory-access in blk_mq_complete_request_remote+0xac/0x350
Read of size 4 at addr 0000607bd1835943 by task kworker/13:1/460
Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop]
Call Trace:
show_stack+0x52/0x58
dump_stack_lvl+0x49/0x5e
print_report.cold+0x36/0x1e2
kasan_report+0xb9/0xf0
__asan_load4+0x6b/0x80
blk_mq_complete_request_remote+0xac/0x350
nvme_loop_queue_response+0x1df/0x275 [nvme_loop]
__nvmet_req_complete+0x132/0x4f0 [nvmet]
nvmet_req_complete+0x15/0x40 [nvmet]
nvmet_execute_io_connect+0x18a/0x1f0 [nvmet]
nvme_loop_execute_work+0x20/0x30 [nvme_loop]
process_one_work+0x56e/0xa70
worker_thread+0x2d1/0x640
kthread+0x183/0x1c0
ret_from_fork+0x1f/0x30 |
["https://git.kernel.org/stable/c/17f121ca3ec6be0fb32d77c7f65362934a38cc8e","https://git.kernel.org/stable/c/4484ce97a78171668c402e0c45db7f760aea8060","https://git.kernel.org/stable/c/6a02a61e81c231cc5c680c5dbf8665275147ac52","https://git.kernel.org/stable/c/8d66989b5f7bb28bba2f8e1e2ffc8bfef4a10717","https://git.kernel.org/stable/c/be01f1c988757b95f11f090a9f491365670a522b","https://git.kernel.org/stable/c/ebf46da50beb78066674354ad650606a467e33fa","https://git.kernel.org/stable/c/17f121ca3ec6be0fb32d77c7f65362934a38cc8e","https://git.kernel.org/stable/c/4484ce97a78171668c402e0c45db7f760aea8060","https://git.kernel.org/stable/c/6a02a61e81c231cc5c680c5dbf8665275147ac52","https://git.kernel.org/stable/c/8d66989b5f7bb28bba2f8e1e2ffc8bfef4a10717","https://git.kernel.org/stable/c/be01f1c988757b95f11f090a9f491365670a522b","https://git.kernel.org/stable/c/ebf46da50beb78066674354ad650606a467e33fa"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49532
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes
drm_cvt_mode may return NULL and we should check it.
This bug is found by syzkaller:
FAULT_INJECTION stacktrace:
[ 168.567394] FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 1
[ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1
[ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 168.567408] Call trace:
[ 168.567414] dump_backtrace+0x0/0x310
[ 168.567418] show_stack+0x28/0x38
[ 168.567423] dump_stack+0xec/0x15c
[ 168.567427] should_fail+0x3ac/0x3d0
[ 168.567437] __should_failslab+0xb8/0x120
[ 168.567441] should_failslab+0x28/0xc0
[ 168.567445] kmem_cache_alloc_trace+0x50/0x640
[ 168.567454] drm_mode_create+0x40/0x90
[ 168.567458] drm_cvt_mode+0x48/0xc78
[ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu]
[ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80
[ 168.567492] drm_mode_getconnector+0x2e0/0xa70
[ 168.567496] drm_ioctl_kernel+0x11c/0x1d8
[ 168.567514] drm_ioctl+0x558/0x6d0
[ 168.567522] do_vfs_ioctl+0x160/0xf30
[ 168.567525] ksys_ioctl+0x98/0xd8
[ 168.567530] __arm64_sys_ioctl+0x50/0xc8
[ 168.567536] el0_svc_common+0xc8/0x320
[ 168.567540] el0_svc_handler+0xf8/0x160
[ 168.567544] el0_svc+0x10/0x218
KASAN stacktrace:
[ 168.567561] BUG: KASAN: null-ptr-deref in virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]
[ 168.567565] Read of size 4 at addr 0000000000000054 by task syz/6425
[ 168.567566]
[ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1
[ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 168.567575] Call trace:
[ 168.567578] dump_backtrace+0x0/0x310
[ 168.567582] show_stack+0x28/0x38
[ 168.567586] dump_stack+0xec/0x15c
[ 168.567591] kasan_report+0x244/0x2f0
[ 168.567594] __asan_load4+0x58/0xb0
[ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]
[ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80
[ 168.567617] drm_mode_getconnector+0x2e0/0xa70
[ 168.567621] drm_ioctl_kernel+0x11c/0x1d8
[ 168.567624] drm_ioctl+0x558/0x6d0
[ 168.567628] do_vfs_ioctl+0x160/0xf30
[ 168.567632] ksys_ioctl+0x98/0xd8
[ 168.567636] __arm64_sys_ioctl+0x50/0xc8
[ 168.567641] el0_svc_common+0xc8/0x320
[ 168.567645] el0_svc_handler+0xf8/0x160
[ 168.567649] el0_svc+0x10/0x218 |
["https://git.kernel.org/stable/c/0f8bc147a963686b7351aa35d1701124ffacac08","https://git.kernel.org/stable/c/194d250cdc4a40ccbd179afd522a9e9846957402","https://git.kernel.org/stable/c/32e10aabc287f09a148ff759bb9ce70b01b0012c","https://git.kernel.org/stable/c/848dd072744ea662ab3097e3c8282bee552df218","https://git.kernel.org/stable/c/c51d00472fa54b9b05c17789ed665c17adf3a25d","https://git.kernel.org/stable/c/e0828456578cc8ba0a69147f7ae3428392eec287","https://git.kernel.org/stable/c/edafcad84c4134ebec4bc24b29ca4497a1184eea","https://git.kernel.org/stable/c/f85cb059fad03a3b33a50023be91e944bb065ae8","https://git.kernel.org/stable/c/fadc626cae99aaa1325094edc6a9e2b883f3e562"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1263
|
Medium |
fixed |
|
A NULL pointer dereference issue was found in KVM when releasing a vCPU with dirty ring support enabled. This flaw allows an unprivileged local attacker on the host to issue specific ioctl calls, causing a kernel oops condition that results in a denial of service. |
["https://access.redhat.com/security/cve/CVE-2022-1263","https://bugzilla.redhat.com/show_bug.cgi?id=2072698","https://github.com/torvalds/linux/commit/5593473a1e6c743764b08e3b6071cb43b5cfa6c4","https://www.openwall.com/lists/oss-security/2022/04/07/1","https://access.redhat.com/security/cve/CVE-2022-1263","https://bugzilla.redhat.com/show_bug.cgi?id=2072698","https://github.com/torvalds/linux/commit/5593473a1e6c743764b08e3b6071cb43b5cfa6c4","https://www.openwall.com/lists/oss-security/2022/04/07/1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48766
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Wrap dcn301_calculate_wm_and_dlg for FPU.
Mirrors the logic for dcn30. Cue lots of WARNs and some
kernel panics without this fix. |
["https://git.kernel.org/stable/c/25f1488bdbba63415239ff301fe61a8546140d9f","https://git.kernel.org/stable/c/456ba2433844a6483cc4c933aa8f43d24575e341","https://git.kernel.org/stable/c/25f1488bdbba63415239ff301fe61a8546140d9f","https://git.kernel.org/stable/c/456ba2433844a6483cc4c933aa8f43d24575e341"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48915
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
thermal: core: Fix TZ_GET_TRIP NULL pointer dereference
Do not call get_trip_hyst() from thermal_genl_cmd_tz_get_trip() if
the thermal zone does not define one. |
["https://git.kernel.org/stable/c/1c0b51e62a50e9291764d022ed44549e65d6ab9c","https://git.kernel.org/stable/c/3dafbf915c05f83469e791949b5590da2aca2afb","https://git.kernel.org/stable/c/4c294285cec3964b3291772ac0642c2bf440bd1b","https://git.kernel.org/stable/c/5838a14832d447990827d85e90afe17e6fb9c175"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48710
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: fix a possible null pointer dereference
In radeon_fp_native_mode(), the return value of drm_mode_duplicate()
is assigned to mode, which will lead to a NULL pointer dereference
on failure of drm_mode_duplicate(). Add a check to avoid npd.
The failure status of drm_cvt_mode() on the other path is checked too. |
["https://git.kernel.org/stable/c/140d9807b96e1303f6f2675a7ae8710a2094bd17","https://git.kernel.org/stable/c/16a0f0b63c4c7eb46fc4c3f00bf2836e6ee46a9f","https://git.kernel.org/stable/c/28fd384c78d7d8ed8af0d086d778c3e438ba7f60","https://git.kernel.org/stable/c/7b7fba107b2c4ec7673d0f45bdbb9d1af697d9b9","https://git.kernel.org/stable/c/8a89bfeef9abe93371e3ea8796377f2d132eee29","https://git.kernel.org/stable/c/a2b28708b645c5632dc93669ab06e97874c8244f","https://git.kernel.org/stable/c/b33f7d99c9226892c7794dc2500fae35966020c9","https://git.kernel.org/stable/c/e938d24f0b7392e142b8aa434f18590d99dbe479","https://git.kernel.org/stable/c/fee8ae0a0bb66eb7730c22f44fbd7203f63c2eab","https://git.kernel.org/stable/c/140d9807b96e1303f6f2675a7ae8710a2094bd17","https://git.kernel.org/stable/c/16a0f0b63c4c7eb46fc4c3f00bf2836e6ee46a9f","https://git.kernel.org/stable/c/28fd384c78d7d8ed8af0d086d778c3e438ba7f60","https://git.kernel.org/stable/c/7b7fba107b2c4ec7673d0f45bdbb9d1af697d9b9","https://git.kernel.org/stable/c/8a89bfeef9abe93371e3ea8796377f2d132eee29","https://git.kernel.org/stable/c/a2b28708b645c5632dc93669ab06e97874c8244f","https://git.kernel.org/stable/c/b33f7d99c9226892c7794dc2500fae35966020c9","https://git.kernel.org/stable/c/e938d24f0b7392e142b8aa434f18590d99dbe479","https://git.kernel.org/stable/c/fee8ae0a0bb66eb7730c22f44fbd7203f63c2eab"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52789
|
Medium |
fixed |
- 4.14.331
- 4.19.300
- 5.4.262
- 5.10.202
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
tty: vcc: Add check for kstrdup() in vcc_probe()
Add check for the return value of kstrdup() and return the error, if it
fails in order to avoid NULL pointer dereference. |
["https://git.kernel.org/stable/c/38cd56fc9de78bf3c878790785e8c231116ef9d3","https://git.kernel.org/stable/c/460284dfb10b207980c6f3f7046e33446ceb38ac","https://git.kernel.org/stable/c/4a24a31826246b15477399febd13292b0c9f0ee9","https://git.kernel.org/stable/c/4ef41a7f33ffe1a335e7db7e1564ddc6afad47cc","https://git.kernel.org/stable/c/6c80f48912b5bd4965352d1a9a989e21743a4a06","https://git.kernel.org/stable/c/7cebc86481bf16049e266f6774d90f2fd4f8d5d2","https://git.kernel.org/stable/c/8f8771757b130383732195497e47fba2aba76d3a","https://git.kernel.org/stable/c/909963e0c16778cec28efb1affc21558825f4200","https://git.kernel.org/stable/c/d81ffb87aaa75f842cd7aa57091810353755b3e6","https://git.kernel.org/stable/c/38cd56fc9de78bf3c878790785e8c231116ef9d3","https://git.kernel.org/stable/c/460284dfb10b207980c6f3f7046e33446ceb38ac","https://git.kernel.org/stable/c/4a24a31826246b15477399febd13292b0c9f0ee9","https://git.kernel.org/stable/c/4ef41a7f33ffe1a335e7db7e1564ddc6afad47cc","https://git.kernel.org/stable/c/6c80f48912b5bd4965352d1a9a989e21743a4a06","https://git.kernel.org/stable/c/7cebc86481bf16049e266f6774d90f2fd4f8d5d2","https://git.kernel.org/stable/c/8f8771757b130383732195497e47fba2aba76d3a","https://git.kernel.org/stable/c/909963e0c16778cec28efb1affc21558825f4200","https://git.kernel.org/stable/c/d81ffb87aaa75f842cd7aa57091810353755b3e6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52865
|
Medium |
fixed |
- 4.14.330
- 4.19.299
- 5.4.261
- 5.10.201
- 5.15.139
- 6.1.63
- 6.5.12
- 6.6.2
|
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to
avoid NULL pointer dereference. |
["https://git.kernel.org/stable/c/122ac6496e4975ddd7ec1edba4f6fc1e15e39478","https://git.kernel.org/stable/c/2705c5b97f504e831ae1935c05f0e44f80dfa6b3","https://git.kernel.org/stable/c/357df1c2f6ace96defd557fad709ed1f9f70e16c","https://git.kernel.org/stable/c/3aefc6fcfbada57fac27f470602d5565e5b76cb4","https://git.kernel.org/stable/c/4c79cbfb8e9e2311be77182893fda5ea4068c836","https://git.kernel.org/stable/c/606f6366a35a3329545e38129804d65ef26ed7d2","https://git.kernel.org/stable/c/81b16286110728674dcf81137be0687c5055e7bf","https://git.kernel.org/stable/c/be3f12f16038a558f08fa93cc32fa715746a5235","https://git.kernel.org/stable/c/c26feedbc561f2a3cee1a4f717e61bdbdfb4fa92","https://git.kernel.org/stable/c/122ac6496e4975ddd7ec1edba4f6fc1e15e39478","https://git.kernel.org/stable/c/2705c5b97f504e831ae1935c05f0e44f80dfa6b3","https://git.kernel.org/stable/c/357df1c2f6ace96defd557fad709ed1f9f70e16c","https://git.kernel.org/stable/c/3aefc6fcfbada57fac27f470602d5565e5b76cb4","https://git.kernel.org/stable/c/4c79cbfb8e9e2311be77182893fda5ea4068c836","https://git.kernel.org/stable/c/606f6366a35a3329545e38129804d65ef26ed7d2","https://git.kernel.org/stable/c/81b16286110728674dcf81137be0687c5055e7bf","https://git.kernel.org/stable/c/be3f12f16038a558f08fa93cc32fa715746a5235","https://git.kernel.org/stable/c/c26feedbc561f2a3cee1a4f717e61bdbdfb4fa92"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52875
|
Medium |
fixed |
- 4.14.330
- 4.19.299
- 5.4.261
- 5.10.201
- 5.15.139
- 6.1.63
- 6.5.12
- 6.6.2
|
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to
avoid NULL pointer dereference. |
["https://git.kernel.org/stable/c/001e5def774fa1a8f2b29567c0b0cd3e3a859a96","https://git.kernel.org/stable/c/0d6e24b422a2166a9297a8286ff2e6ab9a5e8cd3","https://git.kernel.org/stable/c/1953e62366da5460dc712e045f94fb0d8918999d","https://git.kernel.org/stable/c/1bf9c204aef4cc55ce46a7ff2d4dc7e5f86551a7","https://git.kernel.org/stable/c/2a18dd653284550900b02107c3c7b3ac5e0eb802","https://git.kernel.org/stable/c/6fccee2af400edaed9cf349d506c5971d4762739","https://git.kernel.org/stable/c/d1175cf4bd2b4c5f7c43f677ea1ce9ad2c18d055","https://git.kernel.org/stable/c/d1461f0c9ca0827c03730fe9652ebbf6316a2a95","https://git.kernel.org/stable/c/e61934720af4a58ffd43a63ffdd6f3a0bd7d7b47","https://git.kernel.org/stable/c/001e5def774fa1a8f2b29567c0b0cd3e3a859a96","https://git.kernel.org/stable/c/0d6e24b422a2166a9297a8286ff2e6ab9a5e8cd3","https://git.kernel.org/stable/c/1953e62366da5460dc712e045f94fb0d8918999d","https://git.kernel.org/stable/c/1bf9c204aef4cc55ce46a7ff2d4dc7e5f86551a7","https://git.kernel.org/stable/c/2a18dd653284550900b02107c3c7b3ac5e0eb802","https://git.kernel.org/stable/c/6fccee2af400edaed9cf349d506c5971d4762739","https://git.kernel.org/stable/c/d1175cf4bd2b4c5f7c43f677ea1ce9ad2c18d055","https://git.kernel.org/stable/c/d1461f0c9ca0827c03730fe9652ebbf6316a2a95","https://git.kernel.org/stable/c/e61934720af4a58ffd43a63ffdd6f3a0bd7d7b47"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27044
|
Medium |
fixed |
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix potential NULL pointer dereferences in 'dcn10_set_output_transfer_func()'
The 'stream' pointer is used in dcn10_set_output_transfer_func() before
the check if 'stream' is NULL.
Fixes the below:
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check 'stream' (see line 1875) |
["https://git.kernel.org/stable/c/14613d52bc7fc180df6d2c65ba65fc921fc1dda7","https://git.kernel.org/stable/c/29fde8895b2fcc33f44aea28c644ce2d9b62f9e0","https://git.kernel.org/stable/c/2d9fe7787af01188dc470a649bdbb842d6511fd7","https://git.kernel.org/stable/c/330caa061af53ea6d287d7c43d0703714e510e08","https://git.kernel.org/stable/c/6ac7c7a3a9ab57aba0fe78ecb922d2b20e16efeb","https://git.kernel.org/stable/c/7874ab3105ca4657102fee1cc14b0af70883c484","https://git.kernel.org/stable/c/9ccfe80d022df7c595f1925afb31de2232900656","https://git.kernel.org/stable/c/e019d87e02f1e539ae48b99187f253847744ca7a","https://git.kernel.org/stable/c/14613d52bc7fc180df6d2c65ba65fc921fc1dda7","https://git.kernel.org/stable/c/29fde8895b2fcc33f44aea28c644ce2d9b62f9e0","https://git.kernel.org/stable/c/2d9fe7787af01188dc470a649bdbb842d6511fd7","https://git.kernel.org/stable/c/330caa061af53ea6d287d7c43d0703714e510e08","https://git.kernel.org/stable/c/6ac7c7a3a9ab57aba0fe78ecb922d2b20e16efeb","https://git.kernel.org/stable/c/7874ab3105ca4657102fee1cc14b0af70883c484","https://git.kernel.org/stable/c/9ccfe80d022df7c595f1925afb31de2232900656","https://git.kernel.org/stable/c/e019d87e02f1e539ae48b99187f253847744ca7a","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27059
|
Medium |
fixed |
- 4.19.312
- 5.4.274
- 5.10.215
- 5.15.154
- 6.1.84
- 6.6.64
- 6.7.12
|
In the Linux kernel, the following vulnerability has been resolved:
USB: usb-storage: Prevent divide-by-0 error in isd200_ata_command
The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values
in the ATA ID information to calculate cylinder and head values when
creating a CDB for READ or WRITE commands. The calculation involves
division and modulus operations, which will cause a crash if either of
these values is 0. While this never happens with a genuine device, it
could happen with a flawed or subversive emulation, as reported by the
syzbot fuzzer.
Protect against this possibility by refusing to bind to the device if
either the ATA_ID_HEADS or ATA_ID_SECTORS value in the device's ID
information is 0. This requires isd200_Initialization() to return a
negative error code when initialization fails; currently it always
returns 0 (even when there is an error). |
["https://git.kernel.org/stable/c/014bcf41d946b36a8f0b8e9b5d9529efbb822f49","https://git.kernel.org/stable/c/284fb1003d5da111019b9e0bf99b084fd71ac133","https://git.kernel.org/stable/c/3a67d4ab9e730361d183086dfb0ddd8c61f01636","https://git.kernel.org/stable/c/6c1f36d92c0a8799569055012665d2bb066fb964","https://git.kernel.org/stable/c/871fd7b10b56d280990b7e754f43d888382ca325","https://git.kernel.org/stable/c/9968c701cba7eda42e5f0052b040349d6222ae34","https://git.kernel.org/stable/c/eb7b01ca778170654e1c76950024270ba74b121f","https://git.kernel.org/stable/c/f42ba916689f5c7b1642092266d2f53cf527aaaa","https://git.kernel.org/stable/c/014bcf41d946b36a8f0b8e9b5d9529efbb822f49","https://git.kernel.org/stable/c/284fb1003d5da111019b9e0bf99b084fd71ac133","https://git.kernel.org/stable/c/3a67d4ab9e730361d183086dfb0ddd8c61f01636","https://git.kernel.org/stable/c/6c1f36d92c0a8799569055012665d2bb066fb964","https://git.kernel.org/stable/c/871fd7b10b56d280990b7e754f43d888382ca325","https://git.kernel.org/stable/c/9968c701cba7eda42e5f0052b040349d6222ae34","https://git.kernel.org/stable/c/eb7b01ca778170654e1c76950024270ba74b121f","https://git.kernel.org/stable/c/f42ba916689f5c7b1642092266d2f53cf527aaaa","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27073
|
Medium |
fixed |
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
media: ttpci: fix two memleaks in budget_av_attach
When saa7146_register_device and saa7146_vv_init fails, budget_av_attach
should free the resources it allocates, like the error-handling of
ttpci_budget_init does. Besides, there are two fixme comment refers to
such deallocations. |
["https://git.kernel.org/stable/c/1597cd1a88cfcdc4bf8b1b44cd458fed9a5a5d63","https://git.kernel.org/stable/c/24e51d6eb578b82ff292927f14b9f5ec05a46beb","https://git.kernel.org/stable/c/55ca0c7eae8499bb96f4e5d9b26af95e89c4e6a0","https://git.kernel.org/stable/c/656b8cc123d7635dd399d9f02594f27aa797ac3c","https://git.kernel.org/stable/c/7393c681f9aa05ffe2385e8716989565eed2fe06","https://git.kernel.org/stable/c/910363473e4bf97da3c350e08d915546dd6cc30b","https://git.kernel.org/stable/c/af37aed04997e644f7e1b52b696b62dcae3cc016","https://git.kernel.org/stable/c/d0b07f712bf61e1a3cf23c87c663791c42e50837","https://git.kernel.org/stable/c/1597cd1a88cfcdc4bf8b1b44cd458fed9a5a5d63","https://git.kernel.org/stable/c/24e51d6eb578b82ff292927f14b9f5ec05a46beb","https://git.kernel.org/stable/c/55ca0c7eae8499bb96f4e5d9b26af95e89c4e6a0","https://git.kernel.org/stable/c/656b8cc123d7635dd399d9f02594f27aa797ac3c","https://git.kernel.org/stable/c/7393c681f9aa05ffe2385e8716989565eed2fe06","https://git.kernel.org/stable/c/910363473e4bf97da3c350e08d915546dd6cc30b","https://git.kernel.org/stable/c/af37aed04997e644f7e1b52b696b62dcae3cc016","https://git.kernel.org/stable/c/d0b07f712bf61e1a3cf23c87c663791c42e50837","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27076
|
Medium |
fixed |
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
media: imx: csc/scaler: fix v4l2_ctrl_handler memory leak
Free the memory allocated in v4l2_ctrl_handler_init on release. |
["https://git.kernel.org/stable/c/42492b00156c03a79fd4851190aa63045d6a15ce","https://git.kernel.org/stable/c/4797a3dd46f220e6d83daf54d70c5b33db6deb01","https://git.kernel.org/stable/c/5d9fe604bf9b5b09d2215225df55f22a4cbbc684","https://git.kernel.org/stable/c/6c92224721a439d6350db5933a1060768dcd565e","https://git.kernel.org/stable/c/8c2e4efe1278cd2b230cdbf90a6cefbf00acc282","https://git.kernel.org/stable/c/8df9a3c7044b847e9c4dc7e683fd64c6b873f328","https://git.kernel.org/stable/c/b1d0eebaf87cc9ccd05f779ec4a0589f95d6c18b","https://git.kernel.org/stable/c/d164ddc21e986dd9ad614b4b01746e5457aeb24f","https://git.kernel.org/stable/c/42492b00156c03a79fd4851190aa63045d6a15ce","https://git.kernel.org/stable/c/4797a3dd46f220e6d83daf54d70c5b33db6deb01","https://git.kernel.org/stable/c/5d9fe604bf9b5b09d2215225df55f22a4cbbc684","https://git.kernel.org/stable/c/6c92224721a439d6350db5933a1060768dcd565e","https://git.kernel.org/stable/c/8c2e4efe1278cd2b230cdbf90a6cefbf00acc282","https://git.kernel.org/stable/c/8df9a3c7044b847e9c4dc7e683fd64c6b873f328","https://git.kernel.org/stable/c/b1d0eebaf87cc9ccd05f779ec4a0589f95d6c18b","https://git.kernel.org/stable/c/d164ddc21e986dd9ad614b4b01746e5457aeb24f","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35915
|
Medium |
fixed |
- 4.19.312
- 5.4.274
- 5.10.215
- 5.15.154
- 6.1.85
- 6.6.26
- 6.8.5
|
In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet
syzbot reported the following uninit-value access issue [1][2]:
nci_rx_work() parses and processes received packet. When the payload
length is zero, each message type handler reads uninitialized payload
and KMSAN detects this issue. The receipt of a packet with a zero-size
payload is considered unexpected, and therefore, such packets should be
silently discarded.
This patch resolved this issue by checking payload size before calling
each message type handler codes. |
["https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff","https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240","https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c","https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f6008f5a83a","https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a","https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16","https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7","https://git.kernel.org/stable/c/d24b03535e5eb82e025219c2f632b485409c898f","https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff","https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240","https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c","https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f6008f5a83a","https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a","https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16","https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7","https://git.kernel.org/stable/c/d24b03535e5eb82e025219c2f632b485409c898f","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35922
|
Medium |
fixed |
- 4.19.312
- 5.4.274
- 5.10.215
- 5.15.155
- 6.1.86
- 6.6.27
- 6.8.6
|
In the Linux kernel, the following vulnerability has been resolved:
fbmon: prevent division by zero in fb_videomode_from_videomode()
The expression htotal * vtotal can have a zero value on
overflow. It is necessary to prevent division by zero like in
fb_var_to_videomode().
Found by Linux Verification Center (linuxtesting.org) with Svace. |
["https://git.kernel.org/stable/c/1b107d637fed68a787da77a3514ad06e57abd0b4","https://git.kernel.org/stable/c/1fb52bc1de55e9e0bdf71fe078efd4da0889710f","https://git.kernel.org/stable/c/3d4b909704bf2114f64f87363fa22b5ef8ac4a33","https://git.kernel.org/stable/c/48d6bcfc31751ca2e753d901a2d82f27edf8a029","https://git.kernel.org/stable/c/664206ff8b019bcd1e55b10b2eea3add8761b971","https://git.kernel.org/stable/c/72d091b7515e0532ee015e144c906f3bcfdd6270","https://git.kernel.org/stable/c/951838fee462aa01fa2a6a91d56f9a495082e7f0","https://git.kernel.org/stable/c/c2d953276b8b27459baed1277a4fdd5dd9bd4126","https://git.kernel.org/stable/c/1b107d637fed68a787da77a3514ad06e57abd0b4","https://git.kernel.org/stable/c/1fb52bc1de55e9e0bdf71fe078efd4da0889710f","https://git.kernel.org/stable/c/3d4b909704bf2114f64f87363fa22b5ef8ac4a33","https://git.kernel.org/stable/c/48d6bcfc31751ca2e753d901a2d82f27edf8a029","https://git.kernel.org/stable/c/664206ff8b019bcd1e55b10b2eea3add8761b971","https://git.kernel.org/stable/c/72d091b7515e0532ee015e144c906f3bcfdd6270","https://git.kernel.org/stable/c/951838fee462aa01fa2a6a91d56f9a495082e7f0","https://git.kernel.org/stable/c/c2d953276b8b27459baed1277a4fdd5dd9bd4126","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35925
|
Medium |
fixed |
- 4.19.312
- 5.4.274
- 5.10.215
- 5.15.155
- 6.1.86
- 6.6.27
- 6.8.6
|
In the Linux kernel, the following vulnerability has been resolved:
block: prevent division by zero in blk_rq_stat_sum()
The expression dst->nr_samples + src->nr_samples may
have zero value on overflow. It is necessary to add
a check to avoid division by zero.
Found by Linux Verification Center (linuxtesting.org) with Svace. |
["https://git.kernel.org/stable/c/21e7d72d0cfcbae6042d498ea2e6f395311767f8","https://git.kernel.org/stable/c/512a01da7134bac8f8b373506011e8aaa3283854","https://git.kernel.org/stable/c/5f7fd6aa4c4877d77133ea86c14cf256f390b2fe","https://git.kernel.org/stable/c/6a55dab4ac956deb23690eedd74e70b892a378e7","https://git.kernel.org/stable/c/93f52fbeaf4b676b21acfe42a5152620e6770d02","https://git.kernel.org/stable/c/98ddf2604ade2d954bf5ec193600d5274a43fd68","https://git.kernel.org/stable/c/b0cb5564c3e8e0ee0a2d28c86fa7f02e82d64c3c","https://git.kernel.org/stable/c/edd073c78d2bf48c5b8bf435bbc3d61d6e7c6c14","https://git.kernel.org/stable/c/21e7d72d0cfcbae6042d498ea2e6f395311767f8","https://git.kernel.org/stable/c/512a01da7134bac8f8b373506011e8aaa3283854","https://git.kernel.org/stable/c/5f7fd6aa4c4877d77133ea86c14cf256f390b2fe","https://git.kernel.org/stable/c/6a55dab4ac956deb23690eedd74e70b892a378e7","https://git.kernel.org/stable/c/93f52fbeaf4b676b21acfe42a5152620e6770d02","https://git.kernel.org/stable/c/98ddf2604ade2d954bf5ec193600d5274a43fd68","https://git.kernel.org/stable/c/b0cb5564c3e8e0ee0a2d28c86fa7f02e82d64c3c","https://git.kernel.org/stable/c/edd073c78d2bf48c5b8bf435bbc3d61d6e7c6c14","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35930
|
Medium |
fixed |
- 4.19.312
- 5.4.274
- 5.10.215
- 5.15.155
- 6.1.86
- 6.6.27
- 6.8.6
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()
The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an
unsuccessful status. In such cases, the elsiocb is not issued, the
completion is not called, and thus the elsiocb resource is leaked.
Check return value after calling lpfc_sli4_resume_rpi() and conditionally
release the elsiocb resource. |
["https://git.kernel.org/stable/c/07a2aa674fca679316b8ac51440adb895b53a7cf","https://git.kernel.org/stable/c/2ae917d4bcab80ab304b774d492e2fcd6c52c06b","https://git.kernel.org/stable/c/3320126ed3afbc11934502319b340f91a4d61c8f","https://git.kernel.org/stable/c/7849e6f8410da96384e3d1f6b6d730f095142dc7","https://git.kernel.org/stable/c/c473288f27d15014447de5a891bdf22a0695847a","https://git.kernel.org/stable/c/e2cd32435b1dff3d63759476a3abc878e02fb6c8","https://git.kernel.org/stable/c/edf82aa7e9eb864a09229392054d131b34a5c9e8","https://git.kernel.org/stable/c/ee0b5f96b6d66a1e6698228dcb41df11ec7f352f","https://git.kernel.org/stable/c/07a2aa674fca679316b8ac51440adb895b53a7cf","https://git.kernel.org/stable/c/2ae917d4bcab80ab304b774d492e2fcd6c52c06b","https://git.kernel.org/stable/c/3320126ed3afbc11934502319b340f91a4d61c8f","https://git.kernel.org/stable/c/7849e6f8410da96384e3d1f6b6d730f095142dc7","https://git.kernel.org/stable/c/c473288f27d15014447de5a891bdf22a0695847a","https://git.kernel.org/stable/c/e2cd32435b1dff3d63759476a3abc878e02fb6c8","https://git.kernel.org/stable/c/edf82aa7e9eb864a09229392054d131b34a5c9e8","https://git.kernel.org/stable/c/ee0b5f96b6d66a1e6698228dcb41df11ec7f352f","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35933
|
Medium |
fixed |
- 4.19.312
- 5.4.274
- 5.10.215
- 5.15.155
- 6.1.86
- 6.6.27
- 6.8.6
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btintel: Fix null ptr deref in btintel_read_version
If hci_cmd_sync_complete() is triggered and skb is NULL, then
hdev->req_skb is NULL, which will cause this issue. |
["https://git.kernel.org/stable/c/006936ecb4edfc3102464044f75858c714e34d28","https://git.kernel.org/stable/c/22d3053ef05f0b5045e45bd91e7473846261d65e","https://git.kernel.org/stable/c/68a69bb2ecafaacdb998a87783068fb51736f43b","https://git.kernel.org/stable/c/86e9b47e8a75c74b1bd83a479979b425c5dc8bd9","https://git.kernel.org/stable/c/b19fe5eea619d54eea59bb8a37c0f8d00ef0e912","https://git.kernel.org/stable/c/b79e040910101b020931ba0c9a6b77e81ab7f645","https://git.kernel.org/stable/c/ec2049fb2b8be3e108fe2ef1f1040f91e72c9990","https://git.kernel.org/stable/c/ffdca0a62abaf8c41d8d9ea132000fd808de329b","https://git.kernel.org/stable/c/006936ecb4edfc3102464044f75858c714e34d28","https://git.kernel.org/stable/c/22d3053ef05f0b5045e45bd91e7473846261d65e","https://git.kernel.org/stable/c/68a69bb2ecafaacdb998a87783068fb51736f43b","https://git.kernel.org/stable/c/86e9b47e8a75c74b1bd83a479979b425c5dc8bd9","https://git.kernel.org/stable/c/b19fe5eea619d54eea59bb8a37c0f8d00ef0e912","https://git.kernel.org/stable/c/b79e040910101b020931ba0c9a6b77e81ab7f645","https://git.kernel.org/stable/c/ec2049fb2b8be3e108fe2ef1f1040f91e72c9990","https://git.kernel.org/stable/c/ffdca0a62abaf8c41d8d9ea132000fd808de329b","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35969
|
Medium |
fixed |
- 4.19.313
- 5.4.275
- 5.10.216
- 5.15.156
- 6.1.87
- 6.6.28
- 6.8.7
|
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr
Although ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it
still means hlist_for_each_entry_rcu can return an item that got removed
from the list. The memory itself of such item is not freed thanks to RCU
but nothing guarantees the actual content of the memory is sane.
In particular, the reference count can be zero. This can happen if
ipv6_del_addr is called in parallel. ipv6_del_addr removes the entry
from inet6_addr_lst (hlist_del_init_rcu(&ifp->addr_lst)) and drops all
references (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enough
timing, this can happen:
1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry.
2. Then, the whole ipv6_del_addr is executed for the given entry. The
reference count drops to zero and kfree_rcu is scheduled.
3. ipv6_get_ifaddr continues and tries to increments the reference count
(in6_ifa_hold).
4. The rcu is unlocked and the entry is freed.
5. The freed entry is returned.
Prevent increasing of the reference count in such case. The name
in6_ifa_hold_safe is chosen to mimic the existing fib6_info_hold_safe.
[ 41.506330] refcount_t: addition on 0; use-after-free.
[ 41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcount_warn_saturate+0xa5/0x130
[ 41.507413] Modules linked in: veth bridge stp llc
[ 41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14
[ 41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
[ 41.509163] RIP: 0010:refcount_warn_saturate+0xa5/0x130
[ 41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 <0f> 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff
[ 41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282
[ 41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000
[ 41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900
[ 41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff
[ 41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000
[ 41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48
[ 41.514086] FS: 00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000
[ 41.514726] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0
[ 41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 41.516799] Call Trace:
[ 41.517037] <TASK>
[ 41.517249] ? __warn+0x7b/0x120
[ 41.517535] ? refcount_warn_saturate+0xa5/0x130
[ 41.517923] ? report_bug+0x164/0x190
[ 41.518240] ? handle_bug+0x3d/0x70
[ 41.518541] ? exc_invalid_op+0x17/0x70
[ 41.520972] ? asm_exc_invalid_op+0x1a/0x20
[ 41.521325] ? refcount_warn_saturate+0xa5/0x130
[ 41.521708] ipv6_get_ifaddr+0xda/0xe0
[ 41.522035] inet6_rtm_getaddr+0x342/0x3f0
[ 41.522376] ? __pfx_inet6_rtm_getaddr+0x10/0x10
[ 41.522758] rtnetlink_rcv_msg+0x334/0x3d0
[ 41.523102] ? netlink_unicast+0x30f/0x390
[ 41.523445] ? __pfx_rtnetlink_rcv_msg+0x10/0x10
[ 41.523832] netlink_rcv_skb+0x53/0x100
[ 41.524157] netlink_unicast+0x23b/0x390
[ 41.524484] netlink_sendmsg+0x1f2/0x440
[ 41.524826] __sys_sendto+0x1d8/0x1f0
[ 41.525145] __x64_sys_sendto+0x1f/0x30
[ 41.525467] do_syscall_64+0xa5/0x1b0
[ 41.525794] entry_SYSCALL_64_after_hwframe+0x72/0x7a
[ 41.526213] RIP: 0033:0x7fbc4cfcea9a
[ 41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89
[ 41.527942] RSP: 002b:00007f
---truncated--- |
["https://git.kernel.org/stable/c/01b11a0566670612bd464a932e5ac2eae53d8652","https://git.kernel.org/stable/c/3fb02ec57ead2891a2306af8c51a306bc5945e70","https://git.kernel.org/stable/c/4b19e9507c275de0cfe61c24db69179dc52cf9fb","https://git.kernel.org/stable/c/6cdb20c342cd0193d3e956e3d83981d0f438bb83","https://git.kernel.org/stable/c/7633c4da919ad51164acbf1aa322cc1a3ead6129","https://git.kernel.org/stable/c/b4b3b69a19016d4e7fbdbd1dbcc184915eb862e1","https://git.kernel.org/stable/c/cca606e14264098cba65efa82790825dbf69e903","https://git.kernel.org/stable/c/de76ae9ea1a6cf9e77fcec4f2df2904e26c23ceb","https://git.kernel.org/stable/c/01b11a0566670612bd464a932e5ac2eae53d8652","https://git.kernel.org/stable/c/3fb02ec57ead2891a2306af8c51a306bc5945e70","https://git.kernel.org/stable/c/4b19e9507c275de0cfe61c24db69179dc52cf9fb","https://git.kernel.org/stable/c/6cdb20c342cd0193d3e956e3d83981d0f438bb83","https://git.kernel.org/stable/c/7633c4da919ad51164acbf1aa322cc1a3ead6129","https://git.kernel.org/stable/c/b4b3b69a19016d4e7fbdbd1dbcc184915eb862e1","https://git.kernel.org/stable/c/cca606e14264098cba65efa82790825dbf69e903","https://git.kernel.org/stable/c/de76ae9ea1a6cf9e77fcec4f2df2904e26c23ceb","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35984
|
Medium |
fixed |
- 4.19.313
- 5.4.275
- 5.10.216
- 5.15.158
- 6.1.90
- 6.6.30
- 6.8.9
|
In the Linux kernel, the following vulnerability has been resolved:
i2c: smbus: fix NULL function pointer dereference
Baruch reported an OOPS when using the designware controller as target
only. Target-only modes break the assumption of one transfer function
always being available. Fix this by always checking the pointer in
__i2c_transfer.
[wsa: dropped the simplification in core-smbus to avoid theoretical regressions] |
["https://git.kernel.org/stable/c/357c64ef1ef39b1e7cd91ab6bdd304d043702c83","https://git.kernel.org/stable/c/40f1d79f07b49c8a64a861706e5163f2db4bd95d","https://git.kernel.org/stable/c/4e75e222d397c6752b229ed72fc4644c8c36ecde","https://git.kernel.org/stable/c/5a09eae9a7db597fe0c1fc91636205b4a25d2620","https://git.kernel.org/stable/c/5fd72404587d7db4acb2d241fd8c387afb0a7aec","https://git.kernel.org/stable/c/91811a31b68d3765b3065f4bb6d7d6d84a7cfc9f","https://git.kernel.org/stable/c/ad3c3ac7a03be3697114f781193dd3e9d97e6e23","https://git.kernel.org/stable/c/e3425674ff68dc521c57c6eabad0cbd20a027d85","https://git.kernel.org/stable/c/357c64ef1ef39b1e7cd91ab6bdd304d043702c83","https://git.kernel.org/stable/c/40f1d79f07b49c8a64a861706e5163f2db4bd95d","https://git.kernel.org/stable/c/4e75e222d397c6752b229ed72fc4644c8c36ecde","https://git.kernel.org/stable/c/5a09eae9a7db597fe0c1fc91636205b4a25d2620","https://git.kernel.org/stable/c/5fd72404587d7db4acb2d241fd8c387afb0a7aec","https://git.kernel.org/stable/c/91811a31b68d3765b3065f4bb6d7d6d84a7cfc9f","https://git.kernel.org/stable/c/ad3c3ac7a03be3697114f781193dd3e9d97e6e23","https://git.kernel.org/stable/c/e3425674ff68dc521c57c6eabad0cbd20a027d85","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46707
|
Medium |
fixed |
- 5.10.225
- 5.15.166
- 6.1.107
- 6.6.48
- 6.10.7
|
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3
On a system with a GICv3, if a guest hasn't been configured with
GICv3 and that the host is not capable of GICv2 emulation,
a write to any of the ICC_*SGI*_EL1 registers is trapped to EL2.
We therefore try to emulate the SGI access, only to hit a NULL
pointer as no private interrupt is allocated (no GIC, remember?).
The obvious fix is to give the guest what it deserves, in the
shape of a UNDEF exception. |
["https://git.kernel.org/stable/c/15818af2f7aa55eff375333cb7689df15d3f24ef","https://git.kernel.org/stable/c/2073132f6ed3079369e857a8deb33d11bdd983bc","https://git.kernel.org/stable/c/3e6245ebe7ef341639e9a7e402b3ade8ad45a19f","https://git.kernel.org/stable/c/94d4fbad01b19ec5eab3d6b50aaec4f9db8b2d8d","https://git.kernel.org/stable/c/96b076e8ee5bc3a1126848c8add0f74bd30dc9d1","https://git.kernel.org/stable/c/9d7629bec5c3f80bd0e3bf8103c06a2f7046bd92"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49994
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
block: fix integer overflow in BLKSECDISCARD
I independently rediscovered
commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155
block: fix overflow in blk_ioctl_discard()
but for secure erase.
Same problem:
uint64_t r[2] = {512, 18446744073709551104ULL};
ioctl(fd, BLKSECDISCARD, r);
will enter near infinite loop inside blkdev_issue_secure_erase():
a.out: attempt to access beyond end of device
loop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048
bio_check_eod: 3286214 callbacks suppressed |
["https://git.kernel.org/stable/c/0842ddd83939eb4db940b9af7d39e79722bc41aa","https://git.kernel.org/stable/c/697ba0b6ec4ae04afb67d3911799b5e2043b4455","https://git.kernel.org/stable/c/6c9915fa9410cbb9bd75ee283c03120046c56d3d","https://git.kernel.org/stable/c/8476f8428e8b48fd7a0e4258fa2a96a8f4468239","https://git.kernel.org/stable/c/a99bacb35c1416355eef957560e8fcac3a665549"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50014
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix access to uninitialised lock in fc replay path
The following kernel trace can be triggered with fstest generic/629 when
executed against a filesystem with fast-commit feature enabled:
INFO: trying to register non-static key.
The code is fine but needs lockdep annotation, or maybe
you didn't initialize this object before use?
turning off the locking correctness validator.
CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x66/0x90
register_lock_class+0x759/0x7d0
__lock_acquire+0x85/0x2630
? __find_get_block+0xb4/0x380
lock_acquire+0xd1/0x2d0
? __ext4_journal_get_write_access+0xd5/0x160
_raw_spin_lock+0x33/0x40
? __ext4_journal_get_write_access+0xd5/0x160
__ext4_journal_get_write_access+0xd5/0x160
ext4_reserve_inode_write+0x61/0xb0
__ext4_mark_inode_dirty+0x79/0x270
? ext4_ext_replay_set_iblocks+0x2f8/0x450
ext4_ext_replay_set_iblocks+0x330/0x450
ext4_fc_replay+0x14c8/0x1540
? jread+0x88/0x2e0
? rcu_is_watching+0x11/0x40
do_one_pass+0x447/0xd00
jbd2_journal_recover+0x139/0x1b0
jbd2_journal_load+0x96/0x390
ext4_load_and_init_journal+0x253/0xd40
ext4_fill_super+0x2cc6/0x3180
...
In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in
function ext4_check_bdev_write_error(). Unfortunately, at this point this
spinlock has not been initialized yet. Moving it's initialization to an
earlier point in __ext4_fill_super() fixes this splat. |
["https://git.kernel.org/stable/c/13ea9547763a0488a90ff37cdf52ec85e36ea344","https://git.kernel.org/stable/c/23dfdb56581ad92a9967bcd720c8c23356af74c1","https://git.kernel.org/stable/c/6e35f560daebe40264c95e9a1ab03110d4997df6","https://git.kernel.org/stable/c/b002031d585a14eed511117dda8c6452a804d508","https://git.kernel.org/stable/c/d157fc20ca5239fd56965a5a8aa1a0e25919891a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44955
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Don't refer to dc_sink in is_dsc_need_re_compute
[Why]
When unplug one of monitors connected after mst hub, encounter null pointer dereference.
It's due to dc_sink get released immediately in early_unregister() or detect_ctx(). When
commit new state which directly referring to info stored in dc_sink will cause null pointer
dereference.
[how]
Remove redundant checking condition. Relevant condition should already be covered by checking
if dsc_aux is null or not. Also reset dsc_aux to NULL when the connector is disconnected. |
["https://git.kernel.org/stable/c/39b217193729aa45eded8de24d9245468a0c0263","https://git.kernel.org/stable/c/c7e65cab54a89f4df54110f0b44c4ade93d1a911","https://git.kernel.org/stable/c/fcf6a49d79923a234844b8efe830a61f3f0584e4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48879
|
Medium |
fixed |
- 4.19.270
- 5.4.229
- 5.10.164
- 5.15.89
- 6.1.7
|
In the Linux kernel, the following vulnerability has been resolved:
efi: fix NULL-deref in init error path
In cases where runtime services are not supported or have been disabled,
the runtime services workqueue will never have been allocated.
Do not try to destroy the workqueue unconditionally in the unlikely
event that EFI initialisation fails to avoid dereferencing a NULL
pointer. |
["https://git.kernel.org/stable/c/4ca71bc0e1995d15486cd7b60845602a28399cb5","https://git.kernel.org/stable/c/585a0b2b3ae7903c6abee3087d09c69e955a7794","https://git.kernel.org/stable/c/5fcf75a8a4c3e7ee9122d143684083c9faf20452","https://git.kernel.org/stable/c/703c13fe3c9af557d312f5895ed6a5fda2711104","https://git.kernel.org/stable/c/adc96d30f6503d30dc68670c013716f1d9fcc747","https://git.kernel.org/stable/c/e2ea55564229e4bea1474af15b111b3a3043b76f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48905
|
Medium |
fixed |
- 4.19.233
- 5.4.183
- 5.10.104
- 5.15.27
- 5.16.13
|
In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: free reset-work-item when flushing
Fix a tiny memory leak when flushing the reset work queue. |
["https://git.kernel.org/stable/c/39738a2346b270e8f72f88d8856de2c167bd2899","https://git.kernel.org/stable/c/4c26745e4576cec224092e6cc12e37829333b183","https://git.kernel.org/stable/c/58b07100c20e95c78b8cb4d6d28ca53eb9ef81f2","https://git.kernel.org/stable/c/6acbc8875282d3ca8a73fa93cd7a9b166de5019c","https://git.kernel.org/stable/c/786576c03b313a9ff6585458aa0dfd039d897f51","https://git.kernel.org/stable/c/8d0657f39f487d904fca713e0bc39c2707382553"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48908
|
Medium |
fixed |
- 4.9.305
- 4.14.270
- 4.19.233
- 5.4.183
- 5.10.104
- 5.15.27
- 5.16.13
|
In the Linux kernel, the following vulnerability has been resolved:
net: arcnet: com20020: Fix null-ptr-deref in com20020pci_probe()
During driver initialization, the pointer of card info, i.e. the
variable 'ci' is required. However, the definition of
'com20020pci_id_table' reveals that this field is empty for some
devices, which will cause null pointer dereference when initializing
these devices.
The following log reveals it:
[ 3.973806] KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
[ 3.973819] RIP: 0010:com20020pci_probe+0x18d/0x13e0 [com20020_pci]
[ 3.975181] Call Trace:
[ 3.976208] local_pci_probe+0x13f/0x210
[ 3.977248] pci_device_probe+0x34c/0x6d0
[ 3.977255] ? pci_uevent+0x470/0x470
[ 3.978265] really_probe+0x24c/0x8d0
[ 3.978273] __driver_probe_device+0x1b3/0x280
[ 3.979288] driver_probe_device+0x50/0x370
Fix this by checking whether the 'ci' is a null pointer first. |
["https://git.kernel.org/stable/c/5f394102ee27dbf051a4e283390cd8d1759dacea","https://git.kernel.org/stable/c/8e3bc7c5bbf87e86e9cd652ca2a9166942d86206","https://git.kernel.org/stable/c/b1ee6b9340a38bdb9e5c90f0eac5b22b122c3049","https://git.kernel.org/stable/c/b838add93e1dd98210482dc433768daaf752bdef","https://git.kernel.org/stable/c/bd6f1fd5d33dfe5d1b4f2502d3694a7cc13f166d","https://git.kernel.org/stable/c/ca0bdff4249a644f2ca7a49d410d95b8dacf1f72","https://git.kernel.org/stable/c/e50c589678e50f8d574612e473ca60ef45190896","https://git.kernel.org/stable/c/ea372aab54903310756217d81610901a8e66cb7d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48910
|
Medium |
fixed |
- 4.9.313
- 4.14.278
- 5.4.193
- 5.10.104
- 5.15.27
- 5.16.13
|
In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: ensure we call ipv6_mc_down() at most once
There are two reasons for addrconf_notify() to be called with NETDEV_DOWN:
either the network device is actually going down, or IPv6 was disabled
on the interface.
If either of them stays down while the other is toggled, we repeatedly
call the code for NETDEV_DOWN, including ipv6_mc_down(), while never
calling the corresponding ipv6_mc_up() in between. This will cause a
new entry in idev->mc_tomb to be allocated for each multicast group
the interface is subscribed to, which in turn leaks one struct ifmcaddr6
per nontrivial multicast group the interface is subscribed to.
The following reproducer will leak at least $n objects:
ip addr add ff2e::4242/32 dev eth0 autojoin
sysctl -w net.ipv6.conf.eth0.disable_ipv6=1
for i in $(seq 1 $n); do
ip link set up eth0; ip link set down eth0
done
Joining groups with IPV6_ADD_MEMBERSHIP (unprivileged) or setting the
sysctl net.ipv6.conf.eth0.forwarding to 1 (=> subscribing to ff02::2)
can also be used to create a nontrivial idev->mc_list, which will the
leak objects with the right up-down-sequence.
Based on both sources for NETDEV_DOWN events the interface IPv6 state
should be considered:
- not ready if the network interface is not ready OR IPv6 is disabled
for it
- ready if the network interface is ready AND IPv6 is enabled for it
The functions ipv6_mc_up() and ipv6_down() should only be run when this
state changes.
Implement this by remembering when the IPv6 state is ready, and only
run ipv6_mc_down() if it actually changed from ready to not ready.
The other direction (not ready -> ready) already works correctly, as:
- the interface notification triggered codepath for NETDEV_UP /
NETDEV_CHANGE returns early if ipv6 is disabled, and
- the disable_ipv6=0 triggered codepath skips fully initializing the
interface as long as addrconf_link_ready(dev) returns false
- calling ipv6_mc_up() repeatedly does not leak anything |
["https://git.kernel.org/stable/c/24888915364cfa410de62d8abb5df95c3b67455d","https://git.kernel.org/stable/c/72124e65a70b84e6303a5cd21b0ac1f27d7d61a4","https://git.kernel.org/stable/c/9588ac2eddc2f223ebcebf6e9f5caed84d32922b","https://git.kernel.org/stable/c/9995b408f17ff8c7f11bc725c8aa225ba3a63b1c","https://git.kernel.org/stable/c/9a8736b2da28b24f01707f592ff059b9f90a058c","https://git.kernel.org/stable/c/b11781515208dd31fbcd0b664078dce5dc44523f","https://git.kernel.org/stable/c/c71bf3229f9e9dd60ba02f5a5be02066edf57012","https://git.kernel.org/stable/c/f4c63b24dea9cc2043ff845dcca9aaf8109ea38a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48911
|
Medium |
fixed |
- 4.9.305
- 4.14.270
- 4.19.233
- 5.4.183
- 5.10.104
- 5.15.27
- 5.16.13
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_queue: fix possible use-after-free
Eric Dumazet says:
The sock_hold() side seems suspect, because there is no guarantee
that sk_refcnt is not already 0.
On failure, we cannot queue the packet and need to indicate an
error. The packet will be dropped by the caller.
v2: split skb prefetch hunk into separate change |
["https://git.kernel.org/stable/c/21b27b2baa27423286e9b8d3f0b194d587083d95","https://git.kernel.org/stable/c/34dc4a6a7f261736ef7183868a5bddad31c7f9e3","https://git.kernel.org/stable/c/43c25da41e3091b31a906651a43e80a2719aa1ff","https://git.kernel.org/stable/c/4d05239203fa38ea8a6f31e228460da4cb17a71a","https://git.kernel.org/stable/c/c3873070247d9e3c7a6b0cf9bf9b45e8018427b1","https://git.kernel.org/stable/c/dcc3cb920bf7ba66ac5e9272293a9ba5f80917ee","https://git.kernel.org/stable/c/dd648bd1b33a828f62befa696b206c688da0ec43","https://git.kernel.org/stable/c/ef97921ccdc243170fcef857ba2a17cf697aece5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52893
|
Medium |
fixed |
- 4.14.304
- 4.19.271
- 5.4.230
- 5.10.165
- 5.15.90
- 6.1.8
|
In the Linux kernel, the following vulnerability has been resolved:
gsmi: fix null-deref in gsmi_get_variable
We can get EFI variables without fetching the attribute, so we must
allow for that in gsmi.
commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore
access layer") added a new get_variable call with attr=NULL, which
triggers panic in gsmi. |
["https://git.kernel.org/stable/c/32313c11bdc8a02c577abaf865be3664ab30410a","https://git.kernel.org/stable/c/6646d769fdb0ce4318ef9afd127f8526d1ca8393","https://git.kernel.org/stable/c/a769b05eeed7accc4019a1ed9799dd72067f1ce8","https://git.kernel.org/stable/c/ae2a9dcc8caa60b1e14671294e5ec902ea5d1dfd","https://git.kernel.org/stable/c/eb0421d90f916dffe96b4c049ddf01c0c50620d2","https://git.kernel.org/stable/c/ee5763ef829bd923033510de6d1df7c73f085e4b","https://git.kernel.org/stable/c/ffef77794fb5f1245c3249b86342bad2299accb5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52901
|
Medium |
fixed |
- 4.14.304
- 4.19.271
- 5.4.230
- 5.10.165
- 5.15.90
- 6.1.8
|
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Check endpoint is valid before dereferencing it
When the host controller is not responding, all URBs queued to all
endpoints need to be killed. This can cause a kernel panic if we
dereference an invalid endpoint.
Fix this by using xhci_get_virt_ep() helper to find the endpoint and
checking if the endpoint is valid before dereferencing it.
[233311.853271] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead
[233311.853393] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000e8
[233311.853964] pc : xhci_hc_died+0x10c/0x270
[233311.853971] lr : xhci_hc_died+0x1ac/0x270
[233311.854077] Call trace:
[233311.854085] xhci_hc_died+0x10c/0x270
[233311.854093] xhci_stop_endpoint_command_watchdog+0x100/0x1a4
[233311.854105] call_timer_fn+0x50/0x2d4
[233311.854112] expire_timers+0xac/0x2e4
[233311.854118] run_timer_softirq+0x300/0xabc
[233311.854127] __do_softirq+0x148/0x528
[233311.854135] irq_exit+0x194/0x1a8
[233311.854143] __handle_domain_irq+0x164/0x1d0
[233311.854149] gic_handle_irq.22273+0x10c/0x188
[233311.854156] el1_irq+0xfc/0x1a8
[233311.854175] lpm_cpuidle_enter+0x25c/0x418 [msm_pm]
[233311.854185] cpuidle_enter_state+0x1f0/0x764
[233311.854194] do_idle+0x594/0x6ac
[233311.854201] cpu_startup_entry+0x7c/0x80
[233311.854209] secondary_start_kernel+0x170/0x198 |
["https://git.kernel.org/stable/c/08864dc14a6803f0377ca77b9740b26db30c020f","https://git.kernel.org/stable/c/2d2820d5f375563690c96e60676855205abfb7f5","https://git.kernel.org/stable/c/375be2dd61a072f7b1cac9b17eea59e07b58db3a","https://git.kernel.org/stable/c/66fc1600855c05c4ba4e997184c91cf298e0405c","https://git.kernel.org/stable/c/9891e5c73cab3fd9ed532dc50e9799e55e974766","https://git.kernel.org/stable/c/e8fb5bc76eb86437ab87002d4a36d6da02165654","https://git.kernel.org/stable/c/f39c813af0b64f44af94e435c07bfa1ddc2575f5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52907
|
Medium |
fixed |
- 4.14.303
- 4.19.270
- 5.4.229
- 5.10.164
- 5.15.89
- 6.1.7
|
In the Linux kernel, the following vulnerability has been resolved:
nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame()
Fix a use-after-free that occurs in hcd when in_urb sent from
pn533_usb_send_frame() is completed earlier than out_urb. Its callback
frees the skb data in pn533_send_async_complete() that is used as a
transfer buffer of out_urb. Wait before sending in_urb until the
callback of out_urb is called. To modify the callback of out_urb alone,
separate the complete function of out_urb and ack_urb.
Found by a modified version of syzkaller.
BUG: KASAN: use-after-free in dummy_timer
Call Trace:
memcpy (mm/kasan/shadow.c:65)
dummy_perform_transfer (drivers/usb/gadget/udc/dummy_hcd.c:1352)
transfer (drivers/usb/gadget/udc/dummy_hcd.c:1453)
dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:1972)
arch_static_branch (arch/x86/include/asm/jump_label.h:27)
static_key_false (include/linux/jump_label.h:207)
timer_expire_exit (include/trace/events/timer.h:127)
call_timer_fn (kernel/time/timer.c:1475)
expire_timers (kernel/time/timer.c:1519)
__run_timers (kernel/time/timer.c:1790)
run_timer_softirq (kernel/time/timer.c:1803) |
["https://git.kernel.org/stable/c/0ca78c99656f5c448567db1e148367aa3b01c80a","https://git.kernel.org/stable/c/321db5131c92983dac4f3338e8fbb6df214238c0","https://git.kernel.org/stable/c/35529d6b827eedb6bf7e81130e4b7e0aba9e58d2","https://git.kernel.org/stable/c/39ae73e581112cfe27ba50aecb1c891ce57cecb1","https://git.kernel.org/stable/c/8998db5021a28ad67aa8d627bdb4226e4046ccc4","https://git.kernel.org/stable/c/9424d2205fe94a095fb9365ec0c6137f0b394a2b","https://git.kernel.org/stable/c/9dab880d675b9d0dd56c6428e4e8352a3339371d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52827
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix possible out-of-bound read in ath12k_htt_pull_ppdu_stats()
len is extracted from HTT message and could be an unexpected value in
case errors happen, so add validation before using to avoid possible
out-of-bound read in the following message iteration and parsing.
The same issue also applies to ppdu_info->ppdu_stats.common.num_users,
so validate it before using too.
These are found during code review.
Compile test only. |
["https://git.kernel.org/stable/c/1bc44a505a229bb1dd4957e11aa594edeea3690e","https://git.kernel.org/stable/c/79527c21a3ce04cffc35ea54f74ee087e532be57","https://git.kernel.org/stable/c/c9e44111da221246efb2e623ae1be40a5cf6542c","https://git.kernel.org/stable/c/1bc44a505a229bb1dd4957e11aa594edeea3690e","https://git.kernel.org/stable/c/79527c21a3ce04cffc35ea54f74ee087e532be57","https://git.kernel.org/stable/c/c9e44111da221246efb2e623ae1be40a5cf6542c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50268
|
High |
fixed |
- 5.10.230
- 5.15.172
- 6.1.117
- 6.6.61
- 6.11.8
|
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd()
The "*cmd" variable can be controlled by the user via debugfs. That means
"new_cam" can be as high as 255 while the size of the uc->updated[] array
is UCSI_MAX_ALTMODES (30).
The call tree is:
ucsi_cmd() // val comes from simple_attr_write_xsigned()
-> ucsi_send_command()
-> ucsi_send_command_common()
-> ucsi_run_command() // calls ucsi->ops->sync_control()
-> ucsi_ccg_sync_control() |
["https://git.kernel.org/stable/c/3a2ba841659a0f15102585120dea75d8d5209616","https://git.kernel.org/stable/c/604314ecd682913925980dc955caea2d036eab5f","https://git.kernel.org/stable/c/69e19774f15e12dda6c6c58001d059e30895009b","https://git.kernel.org/stable/c/7dd08a0b4193087976db6b3ee7807de7e8316f96","https://git.kernel.org/stable/c/8f47984b35f3be0cfc652c2ca358d5768ea3456b","https://git.kernel.org/stable/c/d76923164705821aa1b01b8d9d1741f20c654ab4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4622
|
High |
fixed |
|
A use-after-free vulnerability in the Linux kernel's af_unix component can be exploited to achieve local privilege escalation.
The unix_stream_sendpage() function tries to add data to the last skb in the peer's recv queue without locking the queue. Thus there is a race where unix_stream_sendpage() could access an skb locklessly that is being released by garbage collection, resulting in use-after-free.
We recommend upgrading past commit 790c2f9d15b594350ae9bca7b236f2b1859de02c. |
["http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y\u0026id=790c2f9d15b594350ae9bca7b236f2b1859de02c","https://kernel.dance/790c2f9d15b594350ae9bca7b236f2b1859de02c","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.debian.org/security/2023/dsa-5492","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y\u0026id=790c2f9d15b594350ae9bca7b236f2b1859de02c","https://kernel.dance/790c2f9d15b594350ae9bca7b236f2b1859de02c","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.debian.org/security/2023/dsa-5492"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56614
|
High |
fixed |
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
xsk: fix OOB map writes when deleting elements
Jordy says:
"
In the xsk_map_delete_elem function an unsigned integer
(map->max_entries) is compared with a user-controlled signed integer
(k). Due to implicit type conversion, a large unsigned value for
map->max_entries can bypass the intended bounds check:
if (k >= map->max_entries)
return -EINVAL;
This allows k to hold a negative value (between -2147483648 and -2),
which is then used as an array index in m->xsk_map[k], which results
in an out-of-bounds access.
spin_lock_bh(&m->lock);
map_entry = &m->xsk_map[k]; // Out-of-bounds map_entry
old_xs = unrcu_pointer(xchg(map_entry, NULL)); // Oob write
if (old_xs)
xsk_map_sock_delete(old_xs, map_entry);
spin_unlock_bh(&m->lock);
The xchg operation can then be used to cause an out-of-bounds write.
Moreover, the invalid map_entry passed to xsk_map_sock_delete can lead
to further memory corruption.
"
It indeed results in following splat:
[76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108
[76612.904330] #PF: supervisor write access in kernel mode
[76612.909639] #PF: error_code(0x0002) - not-present page
[76612.914855] PGD 0 P4D 0
[76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP
[76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470
[76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019
[76612.939781] RIP: 0010:xsk_map_delete_elem+0x2d/0x60
[76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff <48> 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31
[76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246
[76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000
[76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000
[76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007
[76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8
[76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0
[76613.005303] FS: 00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000
[76613.013517] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0
[76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[76613.041086] PKRU: 55555554
[76613.043842] Call Trace:
[76613.046331] <TASK>
[76613.048468] ? __die+0x20/0x60
[76613.051581] ? page_fault_oops+0x15a/0x450
[76613.055747] ? search_extable+0x22/0x30
[76613.059649] ? search_bpf_extables+0x5f/0x80
[76613.063988] ? exc_page_fault+0xa9/0x140
[76613.067975] ? asm_exc_page_fault+0x22/0x30
[76613.072229] ? xsk_map_delete_elem+0x2d/0x60
[76613.076573] ? xsk_map_delete_elem+0x23/0x60
[76613.080914] __sys_bpf+0x19b7/0x23c0
[76613.084555] __x64_sys_bpf+0x1a/0x20
[76613.088194] do_syscall_64+0x37/0xb0
[76613.091832] entry_SYSCALL_64_after_hwframe+0x4b/0x53
[76613.096962] RIP: 0033:0x7f80b6d1e88d
[76613.100592] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48
[76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIG_RAX: 0000000000000141
[76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d
[76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003
[76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000
[76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8
[76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00
---truncated--- |
["https://git.kernel.org/stable/c/32cd3db7de97c0c7a018756ce66244342fd583f0","https://git.kernel.org/stable/c/4d03f705e9d7aabebc6bfa5810f8aab6d176cbb7","https://git.kernel.org/stable/c/d486b5741d987d3e0e6be4ac22cafdf94e6d1a47","https://git.kernel.org/stable/c/ed08c93d5a9801cc8f224a046411fd603c538d07","https://git.kernel.org/stable/c/f8abd03f83d5fe81e76eb93e2c4373eb9f75fd8a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53103
|
High |
fixed |
- 4.19.324
- 5.4.286
- 5.10.230
- 5.15.172
- 6.1.117
- 6.6.61
- 6.11.8
|
In the Linux kernel, the following vulnerability has been resolved:
hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer
When hvs is released, there is a possibility that vsk->trans may not
be initialized to NULL, which could lead to a dangling pointer.
This issue is resolved by initializing vsk->trans to NULL. |
["https://git.kernel.org/stable/c/285266ef92f7b4bf7d26e1e95e215ce6a6badb4a","https://git.kernel.org/stable/c/414476c4fb11be070c09ab8f3e75c9ee324a108a","https://git.kernel.org/stable/c/4bdc5a62c6e50600d8a1c3e18fd6dce0c27c9497","https://git.kernel.org/stable/c/4fe1d42f2acc463b733bb42e3f8e67dbc2a0eb2d","https://git.kernel.org/stable/c/7cf25987820350cb950856c71b409e5b6eed52bd","https://git.kernel.org/stable/c/8621725afb38e111969c64280b71480afde2aace","https://git.kernel.org/stable/c/98d8dde9232250a57ad5ef16479bf6a349e09b80","https://git.kernel.org/stable/c/e0fe3392371293175f25028020ded5267f4cd8e3","https://git.kernel.org/stable/c/e629295bd60abf4da1db85b82819ca6a4f6c1e79"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56608
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix out-of-bounds access in 'dcn21_link_encoder_create'
An issue was identified in the dcn21_link_encoder_create function where
an out-of-bounds access could occur when the hpd_source index was used
to reference the link_enc_hpd_regs array. This array has a fixed size
and the index was not being checked against the array's bounds before
accessing it.
This fix adds a conditional check to ensure that the hpd_source index is
within the valid range of the link_enc_hpd_regs array. If the index is
out of bounds, the function now returns NULL to prevent undefined
behavior.
References:
[ 65.920507] ------------[ cut here ]------------
[ 65.920510] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn21/dcn21_resource.c:1312:29
[ 65.920519] index 7 is out of range for type 'dcn10_link_enc_hpd_registers [5]'
[ 65.920523] CPU: 3 PID: 1178 Comm: modprobe Tainted: G OE 6.8.0-cleanershaderfeatureresetasdntipmi200nv2132 #13
[ 65.920525] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS WMJ0429N_Weekly_20_04_2 04/29/2020
[ 65.920527] Call Trace:
[ 65.920529] <TASK>
[ 65.920532] dump_stack_lvl+0x48/0x70
[ 65.920541] dump_stack+0x10/0x20
[ 65.920543] __ubsan_handle_out_of_bounds+0xa2/0xe0
[ 65.920549] dcn21_link_encoder_create+0xd9/0x140 [amdgpu]
[ 65.921009] link_create+0x6d3/0xed0 [amdgpu]
[ 65.921355] create_links+0x18a/0x4e0 [amdgpu]
[ 65.921679] dc_create+0x360/0x720 [amdgpu]
[ 65.921999] ? dmi_matches+0xa0/0x220
[ 65.922004] amdgpu_dm_init+0x2b6/0x2c90 [amdgpu]
[ 65.922342] ? console_unlock+0x77/0x120
[ 65.922348] ? dev_printk_emit+0x86/0xb0
[ 65.922354] dm_hw_init+0x15/0x40 [amdgpu]
[ 65.922686] amdgpu_device_init+0x26a8/0x33a0 [amdgpu]
[ 65.922921] amdgpu_driver_load_kms+0x1b/0xa0 [amdgpu]
[ 65.923087] amdgpu_pci_probe+0x1b7/0x630 [amdgpu]
[ 65.923087] local_pci_probe+0x4b/0xb0
[ 65.923087] pci_device_probe+0xc8/0x280
[ 65.923087] really_probe+0x187/0x300
[ 65.923087] __driver_probe_device+0x85/0x130
[ 65.923087] driver_probe_device+0x24/0x110
[ 65.923087] __driver_attach+0xac/0x1d0
[ 65.923087] ? __pfx___driver_attach+0x10/0x10
[ 65.923087] bus_for_each_dev+0x7d/0xd0
[ 65.923087] driver_attach+0x1e/0x30
[ 65.923087] bus_add_driver+0xf2/0x200
[ 65.923087] driver_register+0x64/0x130
[ 65.923087] ? __pfx_amdgpu_init+0x10/0x10 [amdgpu]
[ 65.923087] __pci_register_driver+0x61/0x70
[ 65.923087] amdgpu_init+0x7d/0xff0 [amdgpu]
[ 65.923087] do_one_initcall+0x49/0x310
[ 65.923087] ? kmalloc_trace+0x136/0x360
[ 65.923087] do_init_module+0x6a/0x270
[ 65.923087] load_module+0x1fce/0x23a0
[ 65.923087] init_module_from_file+0x9c/0xe0
[ 65.923087] ? init_module_from_file+0x9c/0xe0
[ 65.923087] idempotent_init_module+0x179/0x230
[ 65.923087] __x64_sys_finit_module+0x5d/0xa0
[ 65.923087] do_syscall_64+0x76/0x120
[ 65.923087] entry_SYSCALL_64_after_hwframe+0x6e/0x76
[ 65.923087] RIP: 0033:0x7f2d80f1e88d
[ 65.923087] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48
[ 65.923087] RSP: 002b:00007ffc7bc1aa78 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 65.923087] RAX: ffffffffffffffda RBX: 0000564c9c1db130 RCX: 00007f2d80f1e88d
[ 65.923087] RDX: 0000000000000000 RSI: 0000564c9c1e5480 RDI: 000000000000000f
[ 65.923087] RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000002
[ 65.923087] R10: 000000000000000f R11: 0000000000000246 R12: 0000564c9c1e5480
[ 65.923087] R13: 0000564c9c1db260 R14: 0000000000000000 R15: 0000564c9c1e54b0
[ 65.923087] </TASK>
[ 65.923927] ---[ end trace ]--- |
["https://git.kernel.org/stable/c/08ac5fdb9c6dc34d0ed4bc64ce3c5c3d411b3b53","https://git.kernel.org/stable/c/280f722601c8bf4d8a9c62dd727cf3a2fd0a47be","https://git.kernel.org/stable/c/5bd410c21037107b83ffbb51dd2d6460f9de9ed1","https://git.kernel.org/stable/c/63de35a8fcfca59ae8750d469a7eb220c7557baf","https://git.kernel.org/stable/c/b19ca8425a4b86e8f0d7c33c4e87ef7b0ebdaa29","https://git.kernel.org/stable/c/f01ddd589e162979421e6914b1c74018633f01e0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38552
|
High |
fixed |
- 4.19.316
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix potential index out of bounds in color transformation function
Fixes index out of bounds issue in the color transformation function.
The issue could occur when the index 'i' exceeds the number of transfer
function points (TRANSFER_FUNC_POINTS).
The fix adds a check to ensure 'i' is within bounds before accessing the
transfer function points. If 'i' is out of bounds, an error message is
logged and the function returns false to indicate an error.
Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max |
["https://git.kernel.org/stable/c/04bc4d1090c343025d69149ca669a27c5b9c34a7","https://git.kernel.org/stable/c/123edbae64f4d21984359b99c6e79fcde31c6123","https://git.kernel.org/stable/c/4e8c8b37ee84b3b19c448d2b8e4c916d2f5b9c86","https://git.kernel.org/stable/c/604c506ca43fce52bb882cff9c1fdf2ec3b4029c","https://git.kernel.org/stable/c/63ae548f1054a0b71678d0349c7dc9628ddd42ca","https://git.kernel.org/stable/c/7226ddf3311c5e5a7726ad7d4e7b079bb3cfbb29","https://git.kernel.org/stable/c/98b8a6bfd30d07a19cfacdf82b50f84bf3360869","https://git.kernel.org/stable/c/ced9c4e2289a786b8fa684d8893b7045ea53ef7e","https://git.kernel.org/stable/c/e280ab978c81443103d7c61bdd1d8d708cf6ed6d","https://git.kernel.org/stable/c/04bc4d1090c343025d69149ca669a27c5b9c34a7","https://git.kernel.org/stable/c/123edbae64f4d21984359b99c6e79fcde31c6123","https://git.kernel.org/stable/c/4e8c8b37ee84b3b19c448d2b8e4c916d2f5b9c86","https://git.kernel.org/stable/c/604c506ca43fce52bb882cff9c1fdf2ec3b4029c","https://git.kernel.org/stable/c/63ae548f1054a0b71678d0349c7dc9628ddd42ca","https://git.kernel.org/stable/c/7226ddf3311c5e5a7726ad7d4e7b079bb3cfbb29","https://git.kernel.org/stable/c/98b8a6bfd30d07a19cfacdf82b50f84bf3360869","https://git.kernel.org/stable/c/ced9c4e2289a786b8fa684d8893b7045ea53ef7e","https://git.kernel.org/stable/c/e280ab978c81443103d7c61bdd1d8d708cf6ed6d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50246
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Add rough attr alloc_size check |
["https://git.kernel.org/stable/c/2fcae4c2014a40c8ae0fc3d8cca3ba9e168308de","https://git.kernel.org/stable/c/c4a8ba334262e9a5c158d618a4820e1b9c12495c","https://git.kernel.org/stable/c/e91fbb21f248bdd8140f343dac32b77b9bc10fec","https://git.kernel.org/stable/c/effac690913af9a6c3d6cd967281a34e47ed3e4c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49931
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix array out-of-bound access in SoC stats
Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a
maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process()
function access ath12k_soc_dp_stats::hal_reo_error using the REO
destination SRNG ring ID, which is incorrect. SRNG ring ID differ from
normal ring ID, and this usage leads to out-of-bounds array access. To
fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID
directly instead of the SRNG ring ID to avoid out-of-bounds array access.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 |
["https://git.kernel.org/stable/c/a4aef827a41cdaf6201bbaf773c1eae4e20e967b","https://git.kernel.org/stable/c/ad791e3ec60cb66c1e4dc121ffbf872df312427d","https://git.kernel.org/stable/c/d0e4274d9dc9f8409d56d622cd3ecf7b6fd49e2f","https://git.kernel.org/stable/c/e106b7ad13c1d246adaa57df73edb8f8b8acb240"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46744
|
High |
fixed |
- 4.19.322
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
Squashfs: sanity check symbolic link size
Syzkiller reports a "KMSAN: uninit-value in pick_link" bug.
This is caused by an uninitialised page, which is ultimately caused
by a corrupted symbolic link size read from disk.
The reason why the corrupted symlink size causes an uninitialised
page is due to the following sequence of events:
1. squashfs_read_inode() is called to read the symbolic
link from disk. This assigns the corrupted value
3875536935 to inode->i_size.
2. Later squashfs_symlink_read_folio() is called, which assigns
this corrupted value to the length variable, which being a
signed int, overflows producing a negative number.
3. The following loop that fills in the page contents checks that
the copied bytes is less than length, which being negative means
the loop is skipped, producing an uninitialised page.
This patch adds a sanity check which checks that the symbolic
link size is not larger than expected.
--
V2: fix spelling mistake. |
["https://git.kernel.org/stable/c/087f25b2d36adae19951114ffcbb7106ed405ebb","https://git.kernel.org/stable/c/1b9451ba6f21478a75288ea3e3fca4be35e2a438","https://git.kernel.org/stable/c/5c8906de98d0d7ad42ff3edf2cb6cd7e0ea658c4","https://git.kernel.org/stable/c/810ee43d9cd245d138a2733d87a24858a23f577d","https://git.kernel.org/stable/c/c3af7e460a526007e4bed1ce3623274a1a6afe5e","https://git.kernel.org/stable/c/ef4e249971eb77ec33d74c5c3de1e2576faf6c90","https://git.kernel.org/stable/c/f82cb7f24032ed023fc67d26ea9bf322d8431a90","https://git.kernel.org/stable/c/fac5e82ab1334fc8ed6ff7183702df634bd1d93d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26592
|
High |
fixed |
- 5.15.149
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix UAF issue in ksmbd_tcp_new_connection()
The race is between the handling of a new TCP connection and
its disconnection. It leads to UAF on `struct tcp_transport` in
ksmbd_tcp_new_connection() function. |
["https://git.kernel.org/stable/c/24290ba94cd0136e417283b0dbf8fcdabcf62111","https://git.kernel.org/stable/c/380965e48e9c32ee4263c023e1d830ea7e462ed1","https://git.kernel.org/stable/c/38d20c62903d669693a1869aa68c4dd5674e2544","https://git.kernel.org/stable/c/69d54650b751532d1e1613a4fb433e591aeef126","https://git.kernel.org/stable/c/999daf367b924fdf14e9d83e034ee0f86bc17ec6","https://git.kernel.org/stable/c/24290ba94cd0136e417283b0dbf8fcdabcf62111","https://git.kernel.org/stable/c/380965e48e9c32ee4263c023e1d830ea7e462ed1","https://git.kernel.org/stable/c/38d20c62903d669693a1869aa68c4dd5674e2544","https://git.kernel.org/stable/c/69d54650b751532d1e1613a4fb433e591aeef126","https://git.kernel.org/stable/c/999daf367b924fdf14e9d83e034ee0f86bc17ec6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42284
|
High |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
tipc: Return non-zero value from tipc_udp_addr2str() on error
tipc_udp_addr2str() should return non-zero value if the UDP media
address is invalid. Otherwise, a buffer overflow access can occur in
tipc_media_addr_printf(). Fix this by returning 1 on an invalid UDP
media address. |
["https://git.kernel.org/stable/c/253405541be2f15ffebdeac2f4cf4b7e9144d12f","https://git.kernel.org/stable/c/2abe350db1aa599eeebc6892237d0bce0f1de62a","https://git.kernel.org/stable/c/5eea127675450583680c8170358bcba43227bd69","https://git.kernel.org/stable/c/728734352743a78b4c5a7285b282127696a4a813","https://git.kernel.org/stable/c/76ddf84a52f0d8ec3f5db6ccce08faf202a17d28","https://git.kernel.org/stable/c/7ec3335dd89c8d169e9650e4bac64fde71fdf15b","https://git.kernel.org/stable/c/aa38bf74899de07cf70b50cd17f8ad45fb6654c8","https://git.kernel.org/stable/c/fa96c6baef1b5385e2f0c0677b32b3839e716076"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2018-6559
|
Low |
|
N/A
|
The Linux kernel, as used in Ubuntu 18.04 LTS and Ubuntu 18.10, allows local users to obtain names of files in which they would not normally be able to access via an overlayfs mount inside of a user namespace. |
["http://www.securityfocus.com/bid/105752","https://launchpad.net/bugs/1793458","https://lists.ubuntu.com/archives/kernel-team/2018-October/096172.html","https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-6559.html","https://usn.ubuntu.com/3832-1/","https://usn.ubuntu.com/3833-1/","https://usn.ubuntu.com/3835-1/","https://usn.ubuntu.com/3836-1/","https://usn.ubuntu.com/3836-2/","http://www.securityfocus.com/bid/105752","https://launchpad.net/bugs/1793458","https://lists.ubuntu.com/archives/kernel-team/2018-October/096172.html","https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-6559.html","https://usn.ubuntu.com/3832-1/","https://usn.ubuntu.com/3833-1/","https://usn.ubuntu.com/3835-1/","https://usn.ubuntu.com/3836-1/","https://usn.ubuntu.com/3836-2/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42075
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix remap of arena.
The bpf arena logic didn't account for mremap operation. Add a refcnt for
multiple mmap events to prevent use-after-free in arena_vm_close. |
["https://git.kernel.org/stable/c/87496a1b01e8e2e399428c0db25e106f7961d01e","https://git.kernel.org/stable/c/b90d77e5fd784ada62ddd714d15ee2400c28e1cf","https://git.kernel.org/stable/c/87496a1b01e8e2e399428c0db25e106f7961d01e","https://git.kernel.org/stable/c/b90d77e5fd784ada62ddd714d15ee2400c28e1cf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42269
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: iptables: Fix potential null-ptr-deref in ip6table_nat_table_init().
ip6table_nat_table_init() accesses net->gen->ptr[ip6table_nat_net_ops.id],
but the function is exposed to user space before the entry is allocated
via register_pernet_subsys().
Let's call register_pernet_subsys() before xt_register_template(). |
["https://git.kernel.org/stable/c/419ee6274c5153b89c4393c1946faa4c3cad4f9e","https://git.kernel.org/stable/c/87dba44e9471b79b255d0736858a897332db9226","https://git.kernel.org/stable/c/91b6df6611b7edb28676c4f63f90c56c30d3e601","https://git.kernel.org/stable/c/c22921df777de5606f1047b1345b8d22ef1c0b34","https://git.kernel.org/stable/c/e85b9b6a87be4cb3710082038b677e97f2389003"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42270
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: iptables: Fix null-ptr-deref in iptable_nat_table_init().
We had a report that iptables-restore sometimes triggered null-ptr-deref
at boot time. [0]
The problem is that iptable_nat_table_init() is exposed to user space
before the kernel fully initialises netns.
In the small race window, a user could call iptable_nat_table_init()
that accesses net_generic(net, iptable_nat_net_id), which is available
only after registering iptable_nat_net_ops.
Let's call register_pernet_subsys() before xt_register_template().
[0]:
bpfilter: Loaded bpfilter_umh pid 11702
Started bpfilter
BUG: kernel NULL pointer dereference, address: 0000000000000013
PF: supervisor write access in kernel mode
PF: error_code(0x0002) - not-present page
PGD 0 P4D 0
PREEMPT SMP NOPTI
CPU: 2 PID: 11879 Comm: iptables-restor Not tainted 6.1.92-99.174.amzn2023.x86_64 #1
Hardware name: Amazon EC2 c6i.4xlarge/, BIOS 1.0 10/16/2017
RIP: 0010:iptable_nat_table_init (net/ipv4/netfilter/iptable_nat.c:87 net/ipv4/netfilter/iptable_nat.c:121) iptable_nat
Code: 10 4c 89 f6 48 89 ef e8 0b 19 bb ff 41 89 c4 85 c0 75 38 41 83 c7 01 49 83 c6 28 41 83 ff 04 75 dc 48 8b 44 24 08 48 8b 0c 24 <48> 89 08 4c 89 ef e8 a2 3b a2 cf 48 83 c4 10 44 89 e0 5b 5d 41 5c
RSP: 0018:ffffbef902843cd0 EFLAGS: 00010246
RAX: 0000000000000013 RBX: ffff9f4b052caa20 RCX: ffff9f4b20988d80
RDX: 0000000000000000 RSI: 0000000000000064 RDI: ffffffffc04201c0
RBP: ffff9f4b29394000 R08: ffff9f4b07f77258 R09: ffff9f4b07f77240
R10: 0000000000000000 R11: ffff9f4b09635388 R12: 0000000000000000
R13: ffff9f4b1a3c6c00 R14: ffff9f4b20988e20 R15: 0000000000000004
FS: 00007f6284340000(0000) GS:ffff9f51fe280000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000013 CR3: 00000001d10a6005 CR4: 00000000007706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<TASK>
? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259)
? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259)
? xt_find_table_lock (net/netfilter/x_tables.c:1259)
? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420)
? page_fault_oops (arch/x86/mm/fault.c:727)
? exc_page_fault (./arch/x86/include/asm/irqflags.h:40 ./arch/x86/include/asm/irqflags.h:75 arch/x86/mm/fault.c:1470 arch/x86/mm/fault.c:1518)
? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:570)
? iptable_nat_table_init (net/ipv4/netfilter/iptable_nat.c:87 net/ipv4/netfilter/iptable_nat.c:121) iptable_nat
xt_find_table_lock (net/netfilter/x_tables.c:1259)
xt_request_find_table_lock (net/netfilter/x_tables.c:1287)
get_info (net/ipv4/netfilter/ip_tables.c:965)
? security_capable (security/security.c:809 (discriminator 13))
? ns_capable (kernel/capability.c:376 kernel/capability.c:397)
? do_ipt_get_ctl (net/ipv4/netfilter/ip_tables.c:1656)
? bpfilter_send_req (net/bpfilter/bpfilter_kern.c:52) bpfilter
nf_getsockopt (net/netfilter/nf_sockopt.c:116)
ip_getsockopt (net/ipv4/ip_sockglue.c:1827)
__sys_getsockopt (net/socket.c:2327)
__x64_sys_getsockopt (net/socket.c:2342 net/socket.c:2339 net/socket.c:2339)
do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:81)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
RIP: 0033:0x7f62844685ee
Code: 48 8b 0d 45 28 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 37 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 09
RSP: 002b:00007ffd1f83d638 EFLAGS: 00000246 ORIG_RAX: 0000000000000037
RAX: ffffffffffffffda RBX: 00007ffd1f83d680 RCX: 00007f62844685ee
RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000004
RBP: 0000000000000004 R08: 00007ffd1f83d670 R09: 0000558798ffa2a0
R10: 00007ffd1f83d680 R11: 0000000000000246 R12: 00007ffd1f83e3b2
R13: 00007f6284
---truncated--- |
["https://git.kernel.org/stable/c/08ed888b69a22647153fe2bec55b7cd0a46102cc","https://git.kernel.org/stable/c/5830aa863981d43560748aa93589c0695191d95d","https://git.kernel.org/stable/c/70014b73d7539fcbb6b4ff5f37368d7241d8e626","https://git.kernel.org/stable/c/95590a4929027769af35b153645c0ab6fd22b29b","https://git.kernel.org/stable/c/b98ddb65fa1674b0e6b52de8af9103b63f51b643"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44966
|
Medium |
fixed |
- 5.15.165
- 6.1.106
- 6.6.47
- 6.10.6
|
In the Linux kernel, the following vulnerability has been resolved:
binfmt_flat: Fix corruption when not offsetting data start
Commit 04d82a6d0881 ("binfmt_flat: allow not offsetting data start")
introduced a RISC-V specific variant of the FLAT format which does
not allocate any space for the (obsolete) array of shared library
pointers. However, it did not disable the code which initializes the
array, resulting in the corruption of sizeof(long) bytes before the DATA
segment, generally the end of the TEXT segment.
Introduce MAX_SHARED_LIBS_UPDATE which depends on the state of
CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET to guard the initialization of
the shared library pointer region so that it will only be initialized
if space is reserved for it. |
["https://git.kernel.org/stable/c/3a684499261d0f7ed5ee72793025c88c2276809c","https://git.kernel.org/stable/c/3eb3cd5992f7a0c37edc8d05b4c38c98758d8671","https://git.kernel.org/stable/c/49df34d2b7da9e57c839555a2f7877291ce45ad1","https://git.kernel.org/stable/c/9350ba06ee61db392c486716ac68ecc20e030f7c","https://git.kernel.org/stable/c/af65d5383854cc3f172a7d0843b628758bf462c8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49567
|
Medium |
fixed |
- 4.9.325
- 4.14.290
- 4.19.254
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
mm/mempolicy: fix uninit-value in mpol_rebind_policy()
mpol_set_nodemask()(mm/mempolicy.c) does not set up nodemask when
pol->mode is MPOL_LOCAL. Check pol->mode before access
pol->w.cpuset_mems_allowed in mpol_rebind_policy()(mm/mempolicy.c).
BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:352 [inline]
BUG: KMSAN: uninit-value in mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368
mpol_rebind_policy mm/mempolicy.c:352 [inline]
mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368
cpuset_change_task_nodemask kernel/cgroup/cpuset.c:1711 [inline]
cpuset_attach+0x787/0x15e0 kernel/cgroup/cpuset.c:2278
cgroup_migrate_execute+0x1023/0x1d20 kernel/cgroup/cgroup.c:2515
cgroup_migrate kernel/cgroup/cgroup.c:2771 [inline]
cgroup_attach_task+0x540/0x8b0 kernel/cgroup/cgroup.c:2804
__cgroup1_procs_write+0x5cc/0x7a0 kernel/cgroup/cgroup-v1.c:520
cgroup1_tasks_write+0x94/0xb0 kernel/cgroup/cgroup-v1.c:539
cgroup_file_write+0x4c2/0x9e0 kernel/cgroup/cgroup.c:3852
kernfs_fop_write_iter+0x66a/0x9f0 fs/kernfs/file.c:296
call_write_iter include/linux/fs.h:2162 [inline]
new_sync_write fs/read_write.c:503 [inline]
vfs_write+0x1318/0x2030 fs/read_write.c:590
ksys_write+0x28b/0x510 fs/read_write.c:643
__do_sys_write fs/read_write.c:655 [inline]
__se_sys_write fs/read_write.c:652 [inline]
__x64_sys_write+0xdb/0x120 fs/read_write.c:652
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x44/0xae
Uninit was created at:
slab_post_alloc_hook mm/slab.h:524 [inline]
slab_alloc_node mm/slub.c:3251 [inline]
slab_alloc mm/slub.c:3259 [inline]
kmem_cache_alloc+0x902/0x11c0 mm/slub.c:3264
mpol_new mm/mempolicy.c:293 [inline]
do_set_mempolicy+0x421/0xb70 mm/mempolicy.c:853
kernel_set_mempolicy mm/mempolicy.c:1504 [inline]
__do_sys_set_mempolicy mm/mempolicy.c:1510 [inline]
__se_sys_set_mempolicy+0x44c/0xb60 mm/mempolicy.c:1507
__x64_sys_set_mempolicy+0xd8/0x110 mm/mempolicy.c:1507
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x44/0xae
KMSAN: uninit-value in mpol_rebind_task (2)
https://syzkaller.appspot.com/bug?id=d6eb90f952c2a5de9ea718a1b873c55cb13b59dc
This patch seems to fix below bug too.
KMSAN: uninit-value in mpol_rebind_mm (2)
https://syzkaller.appspot.com/bug?id=f2fecd0d7013f54ec4162f60743a2b28df40926b
The uninit-value is pol->w.cpuset_mems_allowed in mpol_rebind_policy().
When syzkaller reproducer runs to the beginning of mpol_new(),
mpol_new() mm/mempolicy.c
do_mbind() mm/mempolicy.c
kernel_mbind() mm/mempolicy.c
`mode` is 1(MPOL_PREFERRED), nodes_empty(*nodes) is `true` and `flags`
is 0. Then
mode = MPOL_LOCAL;
...
policy->mode = mode;
policy->flags = flags;
will be executed. So in mpol_set_nodemask(),
mpol_set_nodemask() mm/mempolicy.c
do_mbind()
kernel_mbind()
pol->mode is 4 (MPOL_LOCAL), that `nodemask` in `pol` is not initialized,
which will be accessed in mpol_rebind_policy(). |
["https://git.kernel.org/stable/c/018160ad314d75b1409129b2247b614a9f35894c","https://git.kernel.org/stable/c/13d51565cec1aa432a6ab363edc2bbc53c6f49cb","https://git.kernel.org/stable/c/5735845906fb1d90fe597f8b503fc0a857d475e3","https://git.kernel.org/stable/c/777e563f10e91e91130fe06bee85220d508e7b9b","https://git.kernel.org/stable/c/8c5429a04ccd8dbcc3c753dab2f4126774ec28d4","https://git.kernel.org/stable/c/a1f8765f68bc9bf5744b365bb9f5e0b6db93edfe","https://git.kernel.org/stable/c/aaa1c5d635a6fca2043513ffb5be169f9cd17d9e","https://git.kernel.org/stable/c/ddb3f0b68863bd1c5f43177eea476bce316d4993"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49657
|
Medium |
fixed |
- 4.9.323
- 4.14.288
- 4.19.252
- 5.4.205
- 5.10.130
- 5.15.54
- 5.18.11
|
In the Linux kernel, the following vulnerability has been resolved:
usbnet: fix memory leak in error case
usbnet_write_cmd_async() mixed up which buffers
need to be freed in which error case.
v2: add Fixes tag
v3: fix uninitialized buf pointer |
["https://git.kernel.org/stable/c/0085da9df3dced730027923a6b48f58e9016af91","https://git.kernel.org/stable/c/04894ab34faf40ab72a8a5ab5b404bb0606bbbff","https://git.kernel.org/stable/c/3eed421ca5c809da93456f69203d164d5220be3d","https://git.kernel.org/stable/c/5269209f54dd8dfd15f9383f3a3a1fe8370764f8","https://git.kernel.org/stable/c/b55a21b764c1e182014630fa5486d717484ac58f","https://git.kernel.org/stable/c/d5165e657987ff4ba0ace896d4376a3718a9fbc3","https://git.kernel.org/stable/c/db89582ff330556188da856e01382ccbf3a5e706","https://git.kernel.org/stable/c/e7b4f69946a38209b4a4f660bf0e4cbed94f9b4b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56599
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath10k: avoid NULL pointer error during sdio remove
When running 'rmmod ath10k', ath10k_sdio_remove() will free sdio
workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON
is set to yes, kernel panic will happen:
Call trace:
destroy_workqueue+0x1c/0x258
ath10k_sdio_remove+0x84/0x94
sdio_bus_remove+0x50/0x16c
device_release_driver_internal+0x188/0x25c
device_driver_detach+0x20/0x2c
This is because during 'rmmod ath10k', ath10k_sdio_remove() will call
ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()
will finally be called in ath10k_core_destroy(). This function will free
struct cfg80211_registered_device *rdev and all its members, including
wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio
workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.
After device release, destroy_workqueue() will use NULL pointer then the
kernel panic happen.
Call trace:
ath10k_sdio_remove
->ath10k_core_unregister
……
->ath10k_core_stop
->ath10k_hif_stop
->ath10k_sdio_irq_disable
->ath10k_hif_power_down
->del_timer_sync(&ar_sdio->sleep_timer)
->ath10k_core_destroy
->ath10k_mac_destroy
->ieee80211_free_hw
->wiphy_free
……
->wiphy_dev_release
->destroy_workqueue
Need to call destroy_workqueue() before ath10k_core_destroy(), free
the work queue buffer first and then free pointer of work queue by
ath10k_core_destroy(). This order matches the error path order in
ath10k_sdio_probe().
No work will be queued on sdio workqueue between it is destroyed and
ath10k_core_destroy() is called. Based on the call_stack above, the
reason is:
Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and
ath10k_sdio_irq_disable() will queue work on sdio workqueue.
Sleep timer will be deleted before ath10k_core_destroy() in
ath10k_hif_power_down().
ath10k_sdio_irq_disable() only be called in ath10k_hif_stop().
ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif
bus, so ath10k_sdio_hif_tx_sg() won't be called anymore.
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189 |
["https://git.kernel.org/stable/c/27d5d217ae7ffb99dd623375a17a7d3418d9c755","https://git.kernel.org/stable/c/27fda36eedad9e4ec795dc481f307901d1885112","https://git.kernel.org/stable/c/543c0924d446b21f35701ca084d7feca09511220","https://git.kernel.org/stable/c/6e5dbd1c04abf2c19b2282915e6fa48b6ccc6921","https://git.kernel.org/stable/c/95c38953cb1ecf40399a676a1f85dfe2b5780a9a","https://git.kernel.org/stable/c/b35de9e01fc79c7baac666fb2dcb4ba7698a1d97"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50146
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Don't call cleanup on profile rollback failure
When profile rollback fails in mlx5e_netdev_change_profile, the netdev
profile var is left set to NULL. Avoid a crash when unloading the driver
by not calling profile->cleanup in such a case.
This was encountered while testing, with the original trigger that
the wq rescuer thread creation got interrupted (presumably due to
Ctrl+C-ing modprobe), which gets converted to ENOMEM (-12) by
mlx5e_priv_init, the profile rollback also fails for the same reason
(signal still active) so the profile is left as NULL, leading to a crash
later in _mlx5e_remove.
[ 732.473932] mlx5_core 0000:08:00.1: E-Switch: Unload vfs: mode(OFFLOADS), nvfs(2), necvfs(0), active vports(2)
[ 734.525513] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR
[ 734.557372] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12
[ 734.559187] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: new profile init failed, -12
[ 734.560153] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR
[ 734.589378] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12
[ 734.591136] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12
[ 745.537492] BUG: kernel NULL pointer dereference, address: 0000000000000008
[ 745.538222] #PF: supervisor read access in kernel mode
<snipped>
[ 745.551290] Call Trace:
[ 745.551590] <TASK>
[ 745.551866] ? __die+0x20/0x60
[ 745.552218] ? page_fault_oops+0x150/0x400
[ 745.555307] ? exc_page_fault+0x79/0x240
[ 745.555729] ? asm_exc_page_fault+0x22/0x30
[ 745.556166] ? mlx5e_remove+0x6b/0xb0 [mlx5_core]
[ 745.556698] auxiliary_bus_remove+0x18/0x30
[ 745.557134] device_release_driver_internal+0x1df/0x240
[ 745.557654] bus_remove_device+0xd7/0x140
[ 745.558075] device_del+0x15b/0x3c0
[ 745.558456] mlx5_rescan_drivers_locked.part.0+0xb1/0x2f0 [mlx5_core]
[ 745.559112] mlx5_unregister_device+0x34/0x50 [mlx5_core]
[ 745.559686] mlx5_uninit_one+0x46/0xf0 [mlx5_core]
[ 745.560203] remove_one+0x4e/0xd0 [mlx5_core]
[ 745.560694] pci_device_remove+0x39/0xa0
[ 745.561112] device_release_driver_internal+0x1df/0x240
[ 745.561631] driver_detach+0x47/0x90
[ 745.562022] bus_remove_driver+0x84/0x100
[ 745.562444] pci_unregister_driver+0x3b/0x90
[ 745.562890] mlx5_cleanup+0xc/0x1b [mlx5_core]
[ 745.563415] __x64_sys_delete_module+0x14d/0x2f0
[ 745.563886] ? kmem_cache_free+0x1b0/0x460
[ 745.564313] ? lockdep_hardirqs_on_prepare+0xe2/0x190
[ 745.564825] do_syscall_64+0x6d/0x140
[ 745.565223] entry_SYSCALL_64_after_hwframe+0x4b/0x53
[ 745.565725] RIP: 0033:0x7f1579b1288b |
["https://git.kernel.org/stable/c/3955b77494c3c7d14873b1db67e7e00c46a714db","https://git.kernel.org/stable/c/4dbc1d1a9f39c3711ad2a40addca04d07d9ab5d0","https://git.kernel.org/stable/c/d6fe973c8873c998734a050f366b28facc03d32a","https://git.kernel.org/stable/c/db84cb4c8c565e6d4de84b23c2818b63991adfdd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38557
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Reload only IB representors upon lag disable/enable
On lag disable, the bond IB device along with all of its
representors are destroyed, and then the slaves' representors get reloaded.
In case the slave IB representor load fails, the eswitch error flow
unloads all representors, including ethernet representors, where the
netdevs get detached and removed from lag bond. Such flow is inaccurate
as the lag driver is not responsible for loading/unloading ethernet
representors. Furthermore, the flow described above begins by holding
lag lock to prevent bond changes during disable flow. However, when
reaching the ethernet representors detachment from lag, the lag lock is
required again, triggering the following deadlock:
Call trace:
__switch_to+0xf4/0x148
__schedule+0x2c8/0x7d0
schedule+0x50/0xe0
schedule_preempt_disabled+0x18/0x28
__mutex_lock.isra.13+0x2b8/0x570
__mutex_lock_slowpath+0x1c/0x28
mutex_lock+0x4c/0x68
mlx5_lag_remove_netdev+0x3c/0x1a0 [mlx5_core]
mlx5e_uplink_rep_disable+0x70/0xa0 [mlx5_core]
mlx5e_detach_netdev+0x6c/0xb0 [mlx5_core]
mlx5e_netdev_change_profile+0x44/0x138 [mlx5_core]
mlx5e_netdev_attach_nic_profile+0x28/0x38 [mlx5_core]
mlx5e_vport_rep_unload+0x184/0x1b8 [mlx5_core]
mlx5_esw_offloads_rep_load+0xd8/0xe0 [mlx5_core]
mlx5_eswitch_reload_reps+0x74/0xd0 [mlx5_core]
mlx5_disable_lag+0x130/0x138 [mlx5_core]
mlx5_lag_disable_change+0x6c/0x70 [mlx5_core] // hold ldev->lock
mlx5_devlink_eswitch_mode_set+0xc0/0x410 [mlx5_core]
devlink_nl_cmd_eswitch_set_doit+0xdc/0x180
genl_family_rcv_msg_doit.isra.17+0xe8/0x138
genl_rcv_msg+0xe4/0x220
netlink_rcv_skb+0x44/0x108
genl_rcv+0x40/0x58
netlink_unicast+0x198/0x268
netlink_sendmsg+0x1d4/0x418
sock_sendmsg+0x54/0x60
__sys_sendto+0xf4/0x120
__arm64_sys_sendto+0x30/0x40
el0_svc_common+0x8c/0x120
do_el0_svc+0x30/0xa0
el0_svc+0x20/0x30
el0_sync_handler+0x90/0xb8
el0_sync+0x160/0x180
Thus, upon lag enable/disable, load and unload only the IB representors
of the slaves preventing the deadlock mentioned above.
While at it, refactor the mlx5_esw_offloads_rep_load() function to have
a static helper method for its internal logic, in symmetry with the
representor unload design. |
["https://git.kernel.org/stable/c/0f06228d4a2dcc1fca5b3ddb0eefa09c05b102c4","https://git.kernel.org/stable/c/0f320f28f54b1b269a755be2e3fb3695e0b80b07","https://git.kernel.org/stable/c/e93fc8d959e56092e2eca1e5511c2d2f0ad6807a","https://git.kernel.org/stable/c/f03c714a0fdd1f93101a929d0e727c28a66383fc","https://git.kernel.org/stable/c/0f06228d4a2dcc1fca5b3ddb0eefa09c05b102c4","https://git.kernel.org/stable/c/0f320f28f54b1b269a755be2e3fb3695e0b80b07","https://git.kernel.org/stable/c/e93fc8d959e56092e2eca1e5511c2d2f0ad6807a","https://git.kernel.org/stable/c/f03c714a0fdd1f93101a929d0e727c28a66383fc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44939
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix null ptr deref in dtInsertEntry
[syzbot reported]
general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
RIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713
...
[Analyze]
In dtInsertEntry(), when the pointer h has the same value as p, after writing
name in UniStrncpy_to_le(), p->header.flag will be cleared. This will cause the
previously true judgment "p->header.flag & BT-LEAF" to change to no after writing
the name operation, this leads to entering an incorrect branch and accessing the
uninitialized object ih when judging this condition for the second time.
[Fix]
After got the page, check freelist first, if freelist == 0 then exit dtInsert()
and return -EINVAL. |
["https://git.kernel.org/stable/c/53023ab11836ac56fd75f7a71ec1356e50920fa9","https://git.kernel.org/stable/c/6ea10dbb1e6c58384136e9adfd75f81951e423f6","https://git.kernel.org/stable/c/9c2ac38530d1a3ee558834dfa16c85a40fd0e702","https://git.kernel.org/stable/c/ce6dede912f064a855acf6f04a04cbb2c25b8c8c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42073
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_buffers: Fix memory corruptions on Spectrum-4 systems
The following two shared buffer operations make use of the Shared Buffer
Status Register (SBSR):
# devlink sb occupancy snapshot pci/0000:01:00.0
# devlink sb occupancy clearmax pci/0000:01:00.0
The register has two masks of 256 bits to denote on which ingress /
egress ports the register should operate on. Spectrum-4 has more than
256 ports, so the register was extended by cited commit with a new
'port_page' field.
However, when filling the register's payload, the driver specifies the
ports as absolute numbers and not relative to the first port of the port
page, resulting in memory corruptions [1].
Fix by specifying the ports relative to the first port of the port page.
[1]
BUG: KASAN: slab-use-after-free in mlxsw_sp_sb_occ_snapshot+0xb6d/0xbc0
Read of size 1 at addr ffff8881068cb00f by task devlink/1566
[...]
Call Trace:
<TASK>
dump_stack_lvl+0xc6/0x120
print_report+0xce/0x670
kasan_report+0xd7/0x110
mlxsw_sp_sb_occ_snapshot+0xb6d/0xbc0
mlxsw_devlink_sb_occ_snapshot+0x75/0xb0
devlink_nl_sb_occ_snapshot_doit+0x1f9/0x2a0
genl_family_rcv_msg_doit+0x20c/0x300
genl_rcv_msg+0x567/0x800
netlink_rcv_skb+0x170/0x450
genl_rcv+0x2d/0x40
netlink_unicast+0x547/0x830
netlink_sendmsg+0x8d4/0xdb0
__sys_sendto+0x49b/0x510
__x64_sys_sendto+0xe5/0x1c0
do_syscall_64+0xc1/0x1d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
[...]
Allocated by task 1:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
__kasan_kmalloc+0x8f/0xa0
copy_verifier_state+0xbc2/0xfb0
do_check_common+0x2c51/0xc7e0
bpf_check+0x5107/0x9960
bpf_prog_load+0xf0e/0x2690
__sys_bpf+0x1a61/0x49d0
__x64_sys_bpf+0x7d/0xc0
do_syscall_64+0xc1/0x1d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 1:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x60
poison_slab_object+0x109/0x170
__kasan_slab_free+0x14/0x30
kfree+0xca/0x2b0
free_verifier_state+0xce/0x270
do_check_common+0x4828/0xc7e0
bpf_check+0x5107/0x9960
bpf_prog_load+0xf0e/0x2690
__sys_bpf+0x1a61/0x49d0
__x64_sys_bpf+0x7d/0xc0
do_syscall_64+0xc1/0x1d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f |
["https://git.kernel.org/stable/c/942901e0fc74ad4b7992ef7ca9336e68d5fd6d36","https://git.kernel.org/stable/c/bf8781ede7bd9a37c0fcabca78976e61300b5a1a","https://git.kernel.org/stable/c/bfa86a96912faa0b6142a918db88cc0c738a769e","https://git.kernel.org/stable/c/c28947de2bed40217cf256c5d0d16880054fcf13","https://git.kernel.org/stable/c/942901e0fc74ad4b7992ef7ca9336e68d5fd6d36","https://git.kernel.org/stable/c/bf8781ede7bd9a37c0fcabca78976e61300b5a1a","https://git.kernel.org/stable/c/bfa86a96912faa0b6142a918db88cc0c738a769e","https://git.kernel.org/stable/c/c28947de2bed40217cf256c5d0d16880054fcf13"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50229
|
Medium |
fixed |
- 4.19.323
- 5.4.285
- 5.10.229
- 5.15.171
- 6.1.116
- 6.6.60
- 6.11.7
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential deadlock with newly created symlinks
Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers
memory reclamation involving the filesystem layer, which can result in
circular lock dependencies among the reader/writer semaphore
nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the
fs_reclaim pseudo lock.
This is because after commit 21fc61c73c39 ("don't put symlink bodies in
pagecache into highmem"), the gfp flags of the page cache for symbolic
links are overwritten to GFP_KERNEL via inode_nohighmem().
This is not a problem for symlinks read from the backing device, because
the __GFP_FS flag is dropped after inode_nohighmem() is called. However,
when a new symlink is created with nilfs_symlink(), the gfp flags remain
overwritten to GFP_KERNEL. Then, memory allocation called from
page_symlink() etc. triggers memory reclamation including the FS layer,
which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can
cause a deadlock if they are called while nilfs->ns_segctor_sem is held:
Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags
of newly created symlinks in the same way that nilfs_new_inode() and
__nilfs_read_inode() do, as a workaround until we adopt nofs allocation
scope consistently or improve the locking constraints. |
["https://git.kernel.org/stable/c/1246d86e7bbde265761932c6e2dce28c69cdcb91","https://git.kernel.org/stable/c/58c7f44c7b9e5ac7e3b1e5da2572ed7767a12f38","https://git.kernel.org/stable/c/69548bb663fcb63f9ee0301be808a36b9d78dac3","https://git.kernel.org/stable/c/9aa5d43ac4cace8fb9bd964ff6c23f599dc3cd24","https://git.kernel.org/stable/c/a1686db1e59f8fc016c4c9361e2119dd206f479a","https://git.kernel.org/stable/c/b3a033e3ecd3471248d474ef263aadc0059e516a","https://git.kernel.org/stable/c/c72e0df0b56c1166736dc8eb62070ebb12591447","https://git.kernel.org/stable/c/cc38c596e648575ce58bfc31623a6506eda4b94a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49878
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
resource: fix region_intersects() vs add_memory_driver_managed()
On a system with CXL memory, the resource tree (/proc/iomem) related to
CXL memory may look like something as follows.
490000000-50fffffff : CXL Window 0
490000000-50fffffff : region0
490000000-50fffffff : dax0.0
490000000-50fffffff : System RAM (kmem)
Because drivers/dax/kmem.c calls add_memory_driver_managed() during
onlining CXL memory, which makes "System RAM (kmem)" a descendant of "CXL
Window X". This confuses region_intersects(), which expects all "System
RAM" resources to be at the top level of iomem_resource. This can lead to
bugs.
For example, when the following command line is executed to write some
memory in CXL memory range via /dev/mem,
$ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1
dd: error writing '/dev/mem': Bad address
1+0 records in
0+0 records out
0 bytes copied, 0.0283507 s, 0.0 kB/s
the command fails as expected. However, the error code is wrong. It
should be "Operation not permitted" instead of "Bad address". More
seriously, the /dev/mem permission checking in devmem_is_allowed() passes
incorrectly. Although the accessing is prevented later because ioremap()
isn't allowed to map system RAM, it is a potential security issue. During
command executing, the following warning is reported in the kernel log for
calling ioremap() on system RAM.
ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff
WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d
Call Trace:
memremap+0xcb/0x184
xlate_dev_mem_ptr+0x25/0x2f
write_mem+0x94/0xfb
vfs_write+0x128/0x26d
ksys_write+0xac/0xfe
do_syscall_64+0x9a/0xfd
entry_SYSCALL_64_after_hwframe+0x4b/0x53
The details of command execution process are as follows. In the above
resource tree, "System RAM" is a descendant of "CXL Window 0" instead of a
top level resource. So, region_intersects() will report no System RAM
resources in the CXL memory region incorrectly, because it only checks the
top level resources. Consequently, devmem_is_allowed() will return 1
(allow access via /dev/mem) for CXL memory region incorrectly.
Fortunately, ioremap() doesn't allow to map System RAM and reject the
access.
So, region_intersects() needs to be fixed to work correctly with the
resource tree with "System RAM" not at top level as above. To fix it, if
we found a unmatched resource in the top level, we will continue to search
matched resources in its descendant resources. So, we will not miss any
matched resources in resource tree anymore.
In the new implementation, an example resource tree
|------------- "CXL Window 0" ------------|
|-- "System RAM" --|
will behave similar as the following fake resource tree for
region_intersects(, IORESOURCE_SYSTEM_RAM, ),
|-- "System RAM" --||-- "CXL Window 0a" --|
Where "CXL Window 0a" is part of the original "CXL Window 0" that
isn't covered by "System RAM". |
["https://git.kernel.org/stable/c/06ff97a20b8c9e9d256b0d2c3e87f78f8ccea3de","https://git.kernel.org/stable/c/1d5f85f1b7db79c75c9e07d6571ce2a7bdf725c4","https://git.kernel.org/stable/c/333fbaf6864a4ca031367eb947961a1f3484d337","https://git.kernel.org/stable/c/393331e16ce205e036e58b3d8ca4ee2e635f21d9","https://git.kernel.org/stable/c/4b90d2eb451b357681063ba4552b10b39d7ad885","https://git.kernel.org/stable/c/8a6fef7d22a1d952aed68584d3fcc0d018d2bdc3","https://git.kernel.org/stable/c/927abc5b7d6d2c2e936bec5a2f71d9512c5e72f7","https://git.kernel.org/stable/c/b4afe4183ec77f230851ea139d91e5cf2644c68b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35976
|
Medium |
fixed |
- 4.19.317
- 5.4.278
- 5.10.216
- 5.15.156
- 6.1.87
- 6.6.28
- 6.8.7
|
In the Linux kernel, the following vulnerability has been resolved:
xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING
syzbot reported an illegal copy in xsk_setsockopt() [1]
Make sure to validate setsockopt() @optlen parameter.
[1]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]
BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420
Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549
CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x169/0x550 mm/kasan/report.c:488
kasan_report+0x143/0x180 mm/kasan/report.c:601
copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
copy_from_sockptr include/linux/sockptr.h:55 [inline]
xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420
do_sock_setsockopt+0x3af/0x720 net/socket.c:2311
__sys_setsockopt+0x1ae/0x250 net/socket.c:2334
__do_sys_setsockopt net/socket.c:2343 [inline]
__se_sys_setsockopt net/socket.c:2340 [inline]
__x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
do_syscall_64+0xfb/0x240
entry_SYSCALL_64_after_hwframe+0x6d/0x75
RIP: 0033:0x7fb40587de69
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69
RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006
RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000
R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08
</TASK>
Allocated by task 7549:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
poison_kmalloc_redzone mm/kasan/common.c:370 [inline]
__kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387
kasan_kmalloc include/linux/kasan.h:211 [inline]
__do_kmalloc_node mm/slub.c:3966 [inline]
__kmalloc+0x233/0x4a0 mm/slub.c:3979
kmalloc include/linux/slab.h:632 [inline]
__cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869
do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293
__sys_setsockopt+0x1ae/0x250 net/socket.c:2334
__do_sys_setsockopt net/socket.c:2343 [inline]
__se_sys_setsockopt net/socket.c:2340 [inline]
__x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
do_syscall_64+0xfb/0x240
entry_SYSCALL_64_after_hwframe+0x6d/0x75
The buggy address belongs to the object at ffff888028c6cde0
which belongs to the cache kmalloc-8 of size 8
The buggy address is located 1 bytes to the right of
allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)
The buggy address belongs to the physical page:
page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c
anon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)
page_type: 0xffffffff()
raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001
raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223
set_page_owner include/linux/page_owner.h:31 [inline]
post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533
prep_new_page mm/page_alloc.c:
---truncated--- |
["https://git.kernel.org/stable/c/0b45c25d60e38f5c2cb6823f886773a34323306d","https://git.kernel.org/stable/c/237f3cf13b20db183d3706d997eedc3c49eacd44","https://git.kernel.org/stable/c/2a523f14a3f53b46ff0e1fafd215b0bc5f6783aa","https://git.kernel.org/stable/c/2eb979fbb2479bcd7e049f2f9978b6590dd8a0e6","https://git.kernel.org/stable/c/a82984b3c6a7e8c7937dba6e857ddf829d149417","https://git.kernel.org/stable/c/b143e19dc28c3211f050f7848d87d9b0a170e10c","https://git.kernel.org/stable/c/beb99266830520e15fbc6ca8cc5a5240d76851fd","https://git.kernel.org/stable/c/f0a068de65d5b7358e9aff792716afa9333f3922","https://git.kernel.org/stable/c/0b45c25d60e38f5c2cb6823f886773a34323306d","https://git.kernel.org/stable/c/237f3cf13b20db183d3706d997eedc3c49eacd44","https://git.kernel.org/stable/c/2a523f14a3f53b46ff0e1fafd215b0bc5f6783aa","https://git.kernel.org/stable/c/2eb979fbb2479bcd7e049f2f9978b6590dd8a0e6","https://git.kernel.org/stable/c/a82984b3c6a7e8c7937dba6e857ddf829d149417","https://git.kernel.org/stable/c/b143e19dc28c3211f050f7848d87d9b0a170e10c","https://git.kernel.org/stable/c/beb99266830520e15fbc6ca8cc5a5240d76851fd","https://git.kernel.org/stable/c/f0a068de65d5b7358e9aff792716afa9333f3922"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52817
|
Medium |
fixed |
- 4.19.300
- 5.4.262
- 5.10.202
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL
In certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log:
1. Navigate to the directory: /sys/kernel/debug/dri/0
2. Execute command: cat amdgpu_regs_smc
3. Exception Log::
[4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000
[4005007.702562] #PF: supervisor instruction fetch in kernel mode
[4005007.702567] #PF: error_code(0x0010) - not-present page
[4005007.702570] PGD 0 P4D 0
[4005007.702576] Oops: 0010 [#1] SMP NOPTI
[4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G OE 5.15.0-43-generic #46-Ubunt u
[4005007.702590] RIP: 0010:0x0
[4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
[4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206
[4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68
[4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000
[4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980
[4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000
[4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000
[4005007.702622] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000
[4005007.702626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0
[4005007.702633] Call Trace:
[4005007.702636] <TASK>
[4005007.702640] amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu]
[4005007.703002] full_proxy_read+0x5c/0x80
[4005007.703011] vfs_read+0x9f/0x1a0
[4005007.703019] ksys_read+0x67/0xe0
[4005007.703023] __x64_sys_read+0x19/0x20
[4005007.703028] do_syscall_64+0x5c/0xc0
[4005007.703034] ? do_user_addr_fault+0x1e3/0x670
[4005007.703040] ? exit_to_user_mode_prepare+0x37/0xb0
[4005007.703047] ? irqentry_exit_to_user_mode+0x9/0x20
[4005007.703052] ? irqentry_exit+0x19/0x30
[4005007.703057] ? exc_page_fault+0x89/0x160
[4005007.703062] ? asm_exc_page_fault+0x8/0x30
[4005007.703068] entry_SYSCALL_64_after_hwframe+0x44/0xae
[4005007.703075] RIP: 0033:0x7f5e07672992
[4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e c 28 48 89 54 24
[4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992
[4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003
[4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010
[4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000
[4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000
[4005007.703105] </TASK>
[4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_ iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) iommu_v 2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca
[4005007.703184] CR2: 0000000000000000
[4005007.703188] ---[ en
---truncated--- |
["https://git.kernel.org/stable/c/174f62a0aa15c211e60208b41ee9e7cdfb73d455","https://git.kernel.org/stable/c/437e0fa907ba39b4d7eda863c03ea9cf48bd93a9","https://git.kernel.org/stable/c/5104fdf50d326db2c1a994f8b35dcd46e63ae4ad","https://git.kernel.org/stable/c/6c1b3d89a2dda79881726bb6e37af19c0936d736","https://git.kernel.org/stable/c/820daf9ffe2b0afb804567b10983fb38bc5ae288","https://git.kernel.org/stable/c/ba3c0796d292de84f2932cc5bbb0f771fc720996","https://git.kernel.org/stable/c/bf2d51eedf03bd61e3556e35d74d49e2e6112398","https://git.kernel.org/stable/c/f475d5502f33a6c5b149b0afe96316ad1962a64a","https://git.kernel.org/stable/c/174f62a0aa15c211e60208b41ee9e7cdfb73d455","https://git.kernel.org/stable/c/437e0fa907ba39b4d7eda863c03ea9cf48bd93a9","https://git.kernel.org/stable/c/5104fdf50d326db2c1a994f8b35dcd46e63ae4ad","https://git.kernel.org/stable/c/6c1b3d89a2dda79881726bb6e37af19c0936d736","https://git.kernel.org/stable/c/820daf9ffe2b0afb804567b10983fb38bc5ae288","https://git.kernel.org/stable/c/ba3c0796d292de84f2932cc5bbb0f771fc720996","https://git.kernel.org/stable/c/bf2d51eedf03bd61e3556e35d74d49e2e6112398","https://git.kernel.org/stable/c/f475d5502f33a6c5b149b0afe96316ad1962a64a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50275
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
arm64/sve: Discard stale CPU state when handling SVE traps
The logic for handling SVE traps manipulates saved FPSIMD/SVE state
incorrectly, and a race with preemption can result in a task having
TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state
is stale (e.g. with SVE traps enabled). This has been observed to result
in warnings from do_sve_acc() where SVE traps are not expected while
TIF_SVE is set:
| if (test_and_set_thread_flag(TIF_SVE))
| WARN_ON(1); /* SVE access shouldn't have trapped */
Warnings of this form have been reported intermittently, e.g.
https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/
https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/
The race can occur when the SVE trap handler is preempted before and
after manipulating the saved FPSIMD/SVE state, starting and ending on
the same CPU, e.g.
| void do_sve_acc(unsigned long esr, struct pt_regs *regs)
| {
| // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled
| // task->fpsimd_cpu is 0.
| // per_cpu_ptr(&fpsimd_last_state, 0) is task.
|
| ...
|
| // Preempted; migrated from CPU 0 to CPU 1.
| // TIF_FOREIGN_FPSTATE is set.
|
| get_cpu_fpsimd_context();
|
| if (test_and_set_thread_flag(TIF_SVE))
| WARN_ON(1); /* SVE access shouldn't have trapped */
|
| sve_init_regs() {
| if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {
| ...
| } else {
| fpsimd_to_sve(current);
| current->thread.fp_type = FP_STATE_SVE;
| }
| }
|
| put_cpu_fpsimd_context();
|
| // Preempted; migrated from CPU 1 to CPU 0.
| // task->fpsimd_cpu is still 0
| // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then:
| // - Stale HW state is reused (with SVE traps enabled)
| // - TIF_FOREIGN_FPSTATE is cleared
| // - A return to userspace skips HW state restore
| }
Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set
by calling fpsimd_flush_task_state() to detach from the saved CPU
state. This ensures that a subsequent context switch will not reuse the
stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the
new state to be reloaded from memory prior to a return to userspace. |
["https://git.kernel.org/stable/c/51d11ea0250d6ee461987403bbfd4b2abb5613a7","https://git.kernel.org/stable/c/51d3d80a6dc314982a9a0aeb0961085922a1aa15","https://git.kernel.org/stable/c/751ecf6afd6568adc98f2a6052315552c0483d18","https://git.kernel.org/stable/c/de529504b3274d57caf8f66800b714b0d3ee235a","https://git.kernel.org/stable/c/fa9ce027b3ce37a2bb173bf2553b5caa438fd8c9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26882
|
High |
fixed |
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv()
Apply the same fix than ones found in :
8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")
1ca1ba465e55 ("geneve: make sure to pull inner header in geneve_rx()")
We have to save skb->network_header in a temporary variable
in order to be able to recompute the network_header pointer
after a pskb_inet_may_pull() call.
pskb_inet_may_pull() makes sure the needed headers are in skb->head.
syzbot reported:
BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
BUG: KMSAN: uninit-value in ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409
__INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409
__ipgre_rcv+0x9bc/0xbc0 net/ipv4/ip_gre.c:389
ipgre_rcv net/ipv4/ip_gre.c:411 [inline]
gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447
gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163
ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205
ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233
NF_HOOK include/linux/netfilter.h:314 [inline]
ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254
dst_input include/net/dst.h:461 [inline]
ip_rcv_finish net/ipv4/ip_input.c:449 [inline]
NF_HOOK include/linux/netfilter.h:314 [inline]
ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569
__netif_receive_skb_one_core net/core/dev.c:5534 [inline]
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648
netif_receive_skb_internal net/core/dev.c:5734 [inline]
netif_receive_skb+0x58/0x660 net/core/dev.c:5793
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1556
tun_get_user+0x53b9/0x66e0 drivers/net/tun.c:2009
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055
call_write_iter include/linux/fs.h:2087 [inline]
new_sync_write fs/read_write.c:497 [inline]
vfs_write+0xb6b/0x1520 fs/read_write.c:590
ksys_write+0x20f/0x4c0 fs/read_write.c:643
__do_sys_write fs/read_write.c:655 [inline]
__se_sys_write fs/read_write.c:652 [inline]
__x64_sys_write+0x93/0xd0 fs/read_write.c:652
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at:
__alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590
alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133
alloc_pages+0x1be/0x1e0 mm/mempolicy.c:2204
skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909
tun_build_skb drivers/net/tun.c:1686 [inline]
tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055
call_write_iter include/linux/fs.h:2087 [inline]
new_sync_write fs/read_write.c:497 [inline]
vfs_write+0xb6b/0x1520 fs/read_write.c:590
ksys_write+0x20f/0x4c0 fs/read_write.c:643
__do_sys_write fs/read_write.c:655 [inline]
__se_sys_write fs/read_write.c:652 [inline]
__x64_sys_write+0x93/0xd0 fs/read_write.c:652
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b |
["https://git.kernel.org/stable/c/5c03387021cfa3336b97e0dcba38029917a8af2a","https://git.kernel.org/stable/c/60044ab84836359534bd7153b92e9c1584140e4a","https://git.kernel.org/stable/c/77fd5294ea09b21f6772ac954a121b87323cec80","https://git.kernel.org/stable/c/b0ec2abf98267f14d032102551581c833b0659d3","https://git.kernel.org/stable/c/c4c857723b37c20651300b3de4ff25059848b4b0","https://git.kernel.org/stable/c/ca914f1cdee8a85799942c9b0ce5015bbd6844e1","https://git.kernel.org/stable/c/ec6bb01e02cbd47781dd90775b631a1dc4bd9d2b","https://git.kernel.org/stable/c/f6723d8dbfdc10c784a56748f86a9a3cd410dbd5","https://git.kernel.org/stable/c/5c03387021cfa3336b97e0dcba38029917a8af2a","https://git.kernel.org/stable/c/60044ab84836359534bd7153b92e9c1584140e4a","https://git.kernel.org/stable/c/77fd5294ea09b21f6772ac954a121b87323cec80","https://git.kernel.org/stable/c/b0ec2abf98267f14d032102551581c833b0659d3","https://git.kernel.org/stable/c/c4c857723b37c20651300b3de4ff25059848b4b0","https://git.kernel.org/stable/c/ca914f1cdee8a85799942c9b0ce5015bbd6844e1","https://git.kernel.org/stable/c/ec6bb01e02cbd47781dd90775b631a1dc4bd9d2b","https://git.kernel.org/stable/c/f6723d8dbfdc10c784a56748f86a9a3cd410dbd5","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://security.netapp.com/advisory/ntap-20241220-0002/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52905
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: Fix resource leakage in VF driver unbind
resources allocated like mcam entries to support the Ntuple feature
and hash tables for the tc feature are not getting freed in driver
unbind. This patch fixes the issue. |
["https://git.kernel.org/stable/c/53da7aec32982f5ee775b69dce06d63992ce4af3","https://git.kernel.org/stable/c/c8ca0ad10df08ea36bcac1288062d567d22604c9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48904
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Fix I/O page table memory leak
The current logic updates the I/O page table mode for the domain
before calling the logic to free memory used for the page table.
This results in IOMMU page table memory leak, and can be observed
when launching VM w/ pass-through devices.
Fix by freeing the memory used for page table before updating the mode. |
["https://git.kernel.org/stable/c/378e2fe1eb58d5c2ed55c8fe5e11f9db5033cdd6","https://git.kernel.org/stable/c/6b0b2d9a6a308bcd9300c2d83000a82812c56cea","https://git.kernel.org/stable/c/c78627f757e37c2cf386b59c700c4e1574988597"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52910
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
iommu/iova: Fix alloc iova overflows issue
In __alloc_and_insert_iova_range, there is an issue that retry_pfn
overflows. The value of iovad->anchor.pfn_hi is ~0UL, then when
iovad->cached_node is iovad->anchor, curr_iova->pfn_hi + 1 will
overflow. As a result, if the retry logic is executed, low_pfn is
updated to 0, and then new_pfn < low_pfn returns false to make the
allocation successful.
This issue occurs in the following two situations:
1. The first iova size exceeds the domain size. When initializing
iova domain, iovad->cached_node is assigned as iovad->anchor. For
example, the iova domain size is 10M, start_pfn is 0x1_F000_0000,
and the iova size allocated for the first time is 11M. The
following is the log information, new->pfn_lo is smaller than
iovad->cached_node.
Example log as follows:
[ 223.798112][T1705487] sh: [name:iova&]__alloc_and_insert_iova_range
start_pfn:0x1f0000,retry_pfn:0x0,size:0xb00,limit_pfn:0x1f0a00
[ 223.799590][T1705487] sh: [name:iova&]__alloc_and_insert_iova_range
success start_pfn:0x1f0000,new->pfn_lo:0x1efe00,new->pfn_hi:0x1f08ff
2. The node with the largest iova->pfn_lo value in the iova domain
is deleted, iovad->cached_node will be updated to iovad->anchor,
and then the alloc iova size exceeds the maximum iova size that can
be allocated in the domain.
After judging that retry_pfn is less than limit_pfn, call retry_pfn+1
to fix the overflow issue. |
["https://git.kernel.org/stable/c/61cbf790e7329ed78877560be7136f0b911bba7f","https://git.kernel.org/stable/c/c929a230c84441e400c32e7b7b4ab763711fb63e","https://git.kernel.org/stable/c/dcdb3ba7e2a8caae7bfefd603bc22fd0ce9a389c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46780
|
Medium |
fixed |
- 4.19.322
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: protect references to superblock parameters exposed in sysfs
The superblock buffers of nilfs2 can not only be overwritten at runtime
for modifications/repairs, but they are also regularly swapped, replaced
during resizing, and even abandoned when degrading to one side due to
backing device issues. So, accessing them requires mutual exclusion using
the reader/writer semaphore "nilfs->ns_sem".
Some sysfs attribute show methods read this superblock buffer without the
necessary mutual exclusion, which can cause problems with pointer
dereferencing and memory access, so fix it. |
["https://git.kernel.org/stable/c/157c0d94b4c40887329418c70ef4edd1a8d6b4ed","https://git.kernel.org/stable/c/19cfeba0e4b8eda51484fcf8cf7d150418e1d880","https://git.kernel.org/stable/c/683408258917541bdb294cd717c210a04381931e","https://git.kernel.org/stable/c/8c6e43b3d5f109cf9c61bc188fcc8175404e924f","https://git.kernel.org/stable/c/962562d4c70c5cdeb4e955d63ff2017c4eca1aad","https://git.kernel.org/stable/c/b14e7260bb691d7f563f61da07d61e3c8b59a614","https://git.kernel.org/stable/c/b90beafac05931cbfcb6b1bd4f67c1923f47040e","https://git.kernel.org/stable/c/ba97ba173f9625d5f34a986088979eae8b80d38e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-23454
|
Medium |
|
N/A
|
cbq_classify in net/sched/sch_cbq.c in the Linux kernel through 6.1.4 allows attackers to cause a denial of service (slab-out-of-bounds read) because of type confusion (non-negative numbers can sometimes indicate a TC_ACT_SHOT condition rather than valid classification results). |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=caa4b35b4317d5147b3ab0fbdc9c075c7d2e9c12","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://www.debian.org/security/2023/dsa-5324","https://www.openwall.com/lists/oss-security/2023/01/10/1","https://www.openwall.com/lists/oss-security/2023/01/10/4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=caa4b35b4317d5147b3ab0fbdc9c075c7d2e9c12","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://www.debian.org/security/2023/dsa-5324","https://www.openwall.com/lists/oss-security/2023/01/10/1","https://www.openwall.com/lists/oss-security/2023/01/10/4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48835
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Page fault in reply q processing
A page fault was encountered in mpt3sas on a LUN reset error path:
[ 145.763216] mpt3sas_cm1: Task abort tm failed: handle(0x0002),timeout(30) tr_method(0x0) smid(3) msix_index(0)
[ 145.778932] scsi 1:0:0:0: task abort: FAILED scmd(0x0000000024ba29a2)
[ 145.817307] scsi 1:0:0:0: attempting device reset! scmd(0x0000000024ba29a2)
[ 145.827253] scsi 1:0:0:0: [sg1] tag#2 CDB: Receive Diagnostic 1c 01 01 ff fc 00
[ 145.837617] scsi target1:0:0: handle(0x0002), sas_address(0x500605b0000272b9), phy(0)
[ 145.848598] scsi target1:0:0: enclosure logical id(0x500605b0000272b8), slot(0)
[ 149.858378] mpt3sas_cm1: Poll ReplyDescriptor queues for completion of smid(0), task_type(0x05), handle(0x0002)
[ 149.875202] BUG: unable to handle page fault for address: 00000007fffc445d
[ 149.885617] #PF: supervisor read access in kernel mode
[ 149.894346] #PF: error_code(0x0000) - not-present page
[ 149.903123] PGD 0 P4D 0
[ 149.909387] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 149.917417] CPU: 24 PID: 3512 Comm: scsi_eh_1 Kdump: loaded Tainted: G S O 5.10.89-altav-1 #1
[ 149.934327] Hardware name: DDN 200NVX2 /200NVX2-MB , BIOS ATHG2.2.02.01 09/10/2021
[ 149.951871] RIP: 0010:_base_process_reply_queue+0x4b/0x900 [mpt3sas]
[ 149.961889] Code: 0f 84 22 02 00 00 8d 48 01 49 89 fd 48 8d 57 38 f0 0f b1 4f 38 0f 85 d8 01 00 00 49 8b 45 10 45 31 e4 41 8b 55 0c 48 8d 1c d0 <0f> b6 03 83 e0 0f 3c 0f 0f 85 a2 00 00 00 e9 e6 01 00 00 0f b7 ee
[ 149.991952] RSP: 0018:ffffc9000f1ebcb8 EFLAGS: 00010246
[ 150.000937] RAX: 0000000000000055 RBX: 00000007fffc445d RCX: 000000002548f071
[ 150.011841] RDX: 00000000ffff8881 RSI: 0000000000000001 RDI: ffff888125ed50d8
[ 150.022670] RBP: 0000000000000000 R08: 0000000000000000 R09: c0000000ffff7fff
[ 150.033445] R10: ffffc9000f1ebb68 R11: ffffc9000f1ebb60 R12: 0000000000000000
[ 150.044204] R13: ffff888125ed50d8 R14: 0000000000000080 R15: 34cdc00034cdea80
[ 150.054963] FS: 0000000000000000(0000) GS:ffff88dfaf200000(0000) knlGS:0000000000000000
[ 150.066715] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 150.076078] CR2: 00000007fffc445d CR3: 000000012448a006 CR4: 0000000000770ee0
[ 150.086887] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 150.097670] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 150.108323] PKRU: 55555554
[ 150.114690] Call Trace:
[ 150.120497] ? printk+0x48/0x4a
[ 150.127049] mpt3sas_scsih_issue_tm.cold.114+0x2e/0x2b3 [mpt3sas]
[ 150.136453] mpt3sas_scsih_issue_locked_tm+0x86/0xb0 [mpt3sas]
[ 150.145759] scsih_dev_reset+0xea/0x300 [mpt3sas]
[ 150.153891] scsi_eh_ready_devs+0x541/0x9e0 [scsi_mod]
[ 150.162206] ? __scsi_host_match+0x20/0x20 [scsi_mod]
[ 150.170406] ? scsi_try_target_reset+0x90/0x90 [scsi_mod]
[ 150.178925] ? blk_mq_tagset_busy_iter+0x45/0x60
[ 150.186638] ? scsi_try_target_reset+0x90/0x90 [scsi_mod]
[ 150.195087] scsi_error_handler+0x3a5/0x4a0 [scsi_mod]
[ 150.203206] ? __schedule+0x1e9/0x610
[ 150.209783] ? scsi_eh_get_sense+0x210/0x210 [scsi_mod]
[ 150.217924] kthread+0x12e/0x150
[ 150.224041] ? kthread_worker_fn+0x130/0x130
[ 150.231206] ret_from_fork+0x1f/0x30
This is caused by mpt3sas_base_sync_reply_irqs() using an invalid reply_q
pointer outside of the list_for_each_entry() loop. At the end of the full
list traversal the pointer is invalid.
Move the _base_process_reply_queue() call inside of the loop. |
["https://git.kernel.org/stable/c/0cd2dd4bcf4abc812148c4943f966a3c8dccb00f","https://git.kernel.org/stable/c/3916e33b917581e2b2086e856c291cb86ea98a05","https://git.kernel.org/stable/c/69ad4ef868c1fc7609daa235dfa46d28ba7a3ba3","https://git.kernel.org/stable/c/98e7a654a5bebaf1a28e987af5e44c002544a413","https://git.kernel.org/stable/c/0cd2dd4bcf4abc812148c4943f966a3c8dccb00f","https://git.kernel.org/stable/c/3916e33b917581e2b2086e856c291cb86ea98a05","https://git.kernel.org/stable/c/69ad4ef868c1fc7609daa235dfa46d28ba7a3ba3","https://git.kernel.org/stable/c/98e7a654a5bebaf1a28e987af5e44c002544a413"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52650
|
Medium |
fixed |
- 4.19.311
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
drm/tegra: dsi: Add missing check for of_find_device_by_node
Add check for the return value of of_find_device_by_node() and return
the error if it fails in order to avoid NULL pointer dereference. |
["https://git.kernel.org/stable/c/3169eaf1365541fd8e521091010c44fbe14691fc","https://git.kernel.org/stable/c/47a13d0b9d8527518639ab5c39667f69d6203e80","https://git.kernel.org/stable/c/50c0ad785a780c72a2fdaba10b38c645ffb4eae6","https://git.kernel.org/stable/c/52aa507148c4aad41436e2005d742ffcafad9976","https://git.kernel.org/stable/c/92003981a6df5dc84af8a5904f8ee112fa324129","https://git.kernel.org/stable/c/93128052bf832359531c3c0a9e3567b2b8682a2d","https://git.kernel.org/stable/c/afe6fcb9775882230cd29b529203eabd5d2a638d","https://git.kernel.org/stable/c/c5d2342d24ef6e08fc90a529fe3dc59de421a2b9","https://git.kernel.org/stable/c/f05631a8525c3b5e5994ecb1304d2d878956c0f5","https://git.kernel.org/stable/c/3169eaf1365541fd8e521091010c44fbe14691fc","https://git.kernel.org/stable/c/47a13d0b9d8527518639ab5c39667f69d6203e80","https://git.kernel.org/stable/c/50c0ad785a780c72a2fdaba10b38c645ffb4eae6","https://git.kernel.org/stable/c/52aa507148c4aad41436e2005d742ffcafad9976","https://git.kernel.org/stable/c/92003981a6df5dc84af8a5904f8ee112fa324129","https://git.kernel.org/stable/c/93128052bf832359531c3c0a9e3567b2b8682a2d","https://git.kernel.org/stable/c/afe6fcb9775882230cd29b529203eabd5d2a638d","https://git.kernel.org/stable/c/c5d2342d24ef6e08fc90a529fe3dc59de421a2b9","https://git.kernel.org/stable/c/f05631a8525c3b5e5994ecb1304d2d878956c0f5","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26966
|
Medium |
fixed |
- 4.19.312
- 5.4.274
- 5.10.215
- 5.15.154
- 6.1.84
- 6.6.24
- 6.7.12
- 6.8.3
|
In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: mmcc-apq8084: fix terminating of frequency table arrays
The frequency table arrays are supposed to be terminated with an
empty element. Add such entry to the end of the arrays where it
is missing in order to avoid possible out-of-bound access when
the table is traversed by functions like qcom_find_freq() or
qcom_find_freq_floor().
Only compile tested. |
["https://git.kernel.org/stable/c/185de0b7cdeaad8b89ebd4c8a258ff2f21adba99","https://git.kernel.org/stable/c/3aedcf3755c74dafc187eb76acb04e3e6348b1a9","https://git.kernel.org/stable/c/5533686e99b04994d7c4877dc0e4282adc9444a2","https://git.kernel.org/stable/c/5638330150db2cc30b53eed04e481062faa3ece8","https://git.kernel.org/stable/c/7e5432401536117c316d7f3b21d46b64c1514f38","https://git.kernel.org/stable/c/9b4c4546dd61950e80ffdca1bf6925f42b665b03","https://git.kernel.org/stable/c/a09aecb6cb482de88301c43bf00a6c8726c4d34f","https://git.kernel.org/stable/c/a903cfd38d8dee7e754fb89fd1bebed99e28003d","https://git.kernel.org/stable/c/b2dfb216f32627c2f6a8041f2d9d56d102ab87c0","https://git.kernel.org/stable/c/185de0b7cdeaad8b89ebd4c8a258ff2f21adba99","https://git.kernel.org/stable/c/3aedcf3755c74dafc187eb76acb04e3e6348b1a9","https://git.kernel.org/stable/c/5533686e99b04994d7c4877dc0e4282adc9444a2","https://git.kernel.org/stable/c/5638330150db2cc30b53eed04e481062faa3ece8","https://git.kernel.org/stable/c/7e5432401536117c316d7f3b21d46b64c1514f38","https://git.kernel.org/stable/c/9b4c4546dd61950e80ffdca1bf6925f42b665b03","https://git.kernel.org/stable/c/a09aecb6cb482de88301c43bf00a6c8726c4d34f","https://git.kernel.org/stable/c/a903cfd38d8dee7e754fb89fd1bebed99e28003d","https://git.kernel.org/stable/c/b2dfb216f32627c2f6a8041f2d9d56d102ab87c0","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26969
|
Medium |
fixed |
- 4.19.312
- 5.4.274
- 5.10.215
- 5.15.154
- 6.1.84
- 6.6.24
- 6.7.12
- 6.8.3
|
In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: gcc-ipq8074: fix terminating of frequency table arrays
The frequency table arrays are supposed to be terminated with an
empty element. Add such entry to the end of the arrays where it
is missing in order to avoid possible out-of-bound access when
the table is traversed by functions like qcom_find_freq() or
qcom_find_freq_floor().
Only compile tested. |
["https://git.kernel.org/stable/c/1040ef5ed95d6fd2628bad387d78a61633e09429","https://git.kernel.org/stable/c/83fe1bbd9e259ad109827ccfbfc2488e0dea8e94","https://git.kernel.org/stable/c/851cc19bdb02556fb13629b3e4fef6f2bdb038fe","https://git.kernel.org/stable/c/9de184d4e557d550fb0b7b833b676bda4f269e4f","https://git.kernel.org/stable/c/b6b31b4c67ea6bd9222e5b73b330554c57f2f90d","https://git.kernel.org/stable/c/be9e2752d823eca1d5af67014a1844a9176ff566","https://git.kernel.org/stable/c/dd92b159c506804ac57adf3742d9728298bb1255","https://git.kernel.org/stable/c/e117c6e2d1617520f5f7d7f6f6b395f01d8b5a27","https://git.kernel.org/stable/c/fc3ac2fcd0a7fad63eba1b359490a4b81720d0f9","https://git.kernel.org/stable/c/1040ef5ed95d6fd2628bad387d78a61633e09429","https://git.kernel.org/stable/c/83fe1bbd9e259ad109827ccfbfc2488e0dea8e94","https://git.kernel.org/stable/c/851cc19bdb02556fb13629b3e4fef6f2bdb038fe","https://git.kernel.org/stable/c/9de184d4e557d550fb0b7b833b676bda4f269e4f","https://git.kernel.org/stable/c/b6b31b4c67ea6bd9222e5b73b330554c57f2f90d","https://git.kernel.org/stable/c/be9e2752d823eca1d5af67014a1844a9176ff566","https://git.kernel.org/stable/c/dd92b159c506804ac57adf3742d9728298bb1255","https://git.kernel.org/stable/c/e117c6e2d1617520f5f7d7f6f6b395f01d8b5a27","https://git.kernel.org/stable/c/fc3ac2fcd0a7fad63eba1b359490a4b81720d0f9","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27046
|
Medium |
fixed |
- 4.19.311
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
nfp: flower: handle acti_netdevs allocation failure
The kmalloc_array() in nfp_fl_lag_do_work() will return null, if
the physical memory has run out. As a result, if we dereference
the acti_netdevs, the null pointer dereference bugs will happen.
This patch adds a check to judge whether allocation failure occurs.
If it happens, the delayed work will be rescheduled and try again. |
["https://git.kernel.org/stable/c/0d387dc503f9a53e6d1f6e9dd0292d38f083eba5","https://git.kernel.org/stable/c/3b1e8a617eb0f4cdc19def530047a95b5abde07d","https://git.kernel.org/stable/c/408ba7fd04f959c61b50db79c983484312fea642","https://git.kernel.org/stable/c/84e95149bd341705f0eca6a7fcb955c548805002","https://git.kernel.org/stable/c/928705e341010dd910fdece61ccb974f494a758f","https://git.kernel.org/stable/c/9d8eb1238377cd994829f9162ae396a84ae037b2","https://git.kernel.org/stable/c/c8df9203bf22c66fa26e8d8c7f8ce181cf88099d","https://git.kernel.org/stable/c/c9b4e220dd18f79507803f38a55d53b483f6c9c3","https://git.kernel.org/stable/c/d746889db75a76aeee95fb705b8e1ac28c684a2e","https://git.kernel.org/stable/c/0d387dc503f9a53e6d1f6e9dd0292d38f083eba5","https://git.kernel.org/stable/c/3b1e8a617eb0f4cdc19def530047a95b5abde07d","https://git.kernel.org/stable/c/408ba7fd04f959c61b50db79c983484312fea642","https://git.kernel.org/stable/c/84e95149bd341705f0eca6a7fcb955c548805002","https://git.kernel.org/stable/c/928705e341010dd910fdece61ccb974f494a758f","https://git.kernel.org/stable/c/9d8eb1238377cd994829f9162ae396a84ae037b2","https://git.kernel.org/stable/c/c8df9203bf22c66fa26e8d8c7f8ce181cf88099d","https://git.kernel.org/stable/c/c9b4e220dd18f79507803f38a55d53b483f6c9c3","https://git.kernel.org/stable/c/d746889db75a76aeee95fb705b8e1ac28c684a2e","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27074
|
Medium |
fixed |
- 4.19.311
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
media: go7007: fix a memleak in go7007_load_encoder
In go7007_load_encoder, bounce(i.e. go->boot_fw), is allocated without
a deallocation thereafter. After the following call chain:
saa7134_go7007_init
|-> go7007_boot_encoder
|-> go7007_load_encoder
|-> kfree(go)
go is freed and thus bounce is leaked. |
["https://git.kernel.org/stable/c/291cda0b805fc0d6e90d201710311630c8667159","https://git.kernel.org/stable/c/7405a0d4442792988e9ae834e7d84f9d163731a4","https://git.kernel.org/stable/c/790fa2c04dfb9f095ec372bf17909424d6e864b3","https://git.kernel.org/stable/c/7f11dd3d165b178e738fe73dfeea513e383bedb5","https://git.kernel.org/stable/c/b49fe84c6cefcc1c2336d793b53442e716c95073","https://git.kernel.org/stable/c/b9b683844b01d171a72b9c0419a2d760d946ee12","https://git.kernel.org/stable/c/d43988a23c32588ccd0c74219637afb96cd78661","https://git.kernel.org/stable/c/e04d15c8bb3e111dd69f98894acd92d63e87aac3","https://git.kernel.org/stable/c/f31c1cc37411f5f7bcb266133f9a7e1b4bdf2975","https://git.kernel.org/stable/c/291cda0b805fc0d6e90d201710311630c8667159","https://git.kernel.org/stable/c/7405a0d4442792988e9ae834e7d84f9d163731a4","https://git.kernel.org/stable/c/790fa2c04dfb9f095ec372bf17909424d6e864b3","https://git.kernel.org/stable/c/7f11dd3d165b178e738fe73dfeea513e383bedb5","https://git.kernel.org/stable/c/b49fe84c6cefcc1c2336d793b53442e716c95073","https://git.kernel.org/stable/c/b9b683844b01d171a72b9c0419a2d760d946ee12","https://git.kernel.org/stable/c/d43988a23c32588ccd0c74219637afb96cd78661","https://git.kernel.org/stable/c/e04d15c8bb3e111dd69f98894acd92d63e87aac3","https://git.kernel.org/stable/c/f31c1cc37411f5f7bcb266133f9a7e1b4bdf2975","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27077
|
Medium |
fixed |
- 4.19.311
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
media: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity
The entity->name (i.e. name) is allocated in v4l2_m2m_register_entity
but isn't freed in its following error-handling paths. This patch
adds such deallocation to prevent memleak of entity->name. |
["https://git.kernel.org/stable/c/0175f2d34c85744f9ad6554f696cf0afb5bd04e4","https://git.kernel.org/stable/c/0c9550b032de48d6a7fa6a4ddc09699d64d9300d","https://git.kernel.org/stable/c/3dd8abb0ed0e0a7c66d6d677c86ccb188cc39333","https://git.kernel.org/stable/c/5dc319cc3c4f7b74f7dfba349aa26f87efb52458","https://git.kernel.org/stable/c/8f94b49a5b5d386c038e355bef6347298aabd211","https://git.kernel.org/stable/c/90029b9c979b60de5cb2b70ade4bbf61d561bc5d","https://git.kernel.org/stable/c/9c23ef30e840fedc66948299509f6c2777c9cf4f","https://git.kernel.org/stable/c/afd2a82fe300032f63f8be5d6cd6981e75f8bbf2","https://git.kernel.org/stable/c/dc866b69cc51af9b8509b4731b8ce2a4950cd0ef","https://git.kernel.org/stable/c/0175f2d34c85744f9ad6554f696cf0afb5bd04e4","https://git.kernel.org/stable/c/0c9550b032de48d6a7fa6a4ddc09699d64d9300d","https://git.kernel.org/stable/c/3dd8abb0ed0e0a7c66d6d677c86ccb188cc39333","https://git.kernel.org/stable/c/5dc319cc3c4f7b74f7dfba349aa26f87efb52458","https://git.kernel.org/stable/c/8f94b49a5b5d386c038e355bef6347298aabd211","https://git.kernel.org/stable/c/90029b9c979b60de5cb2b70ade4bbf61d561bc5d","https://git.kernel.org/stable/c/9c23ef30e840fedc66948299509f6c2777c9cf4f","https://git.kernel.org/stable/c/afd2a82fe300032f63f8be5d6cd6981e75f8bbf2","https://git.kernel.org/stable/c/dc866b69cc51af9b8509b4731b8ce2a4950cd0ef","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27078
|
Medium |
fixed |
- 4.19.311
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
media: v4l2-tpg: fix some memleaks in tpg_alloc
In tpg_alloc, resources should be deallocated in each and every
error-handling paths, since they are allocated in for statements.
Otherwise there would be memleaks because tpg_free is called only when
tpg_alloc return 0. |
["https://git.kernel.org/stable/c/0de691ff547d86dd54c24b40a81f9c925df8dd77","https://git.kernel.org/stable/c/31096da07933598da8522c54bd007376fb152a09","https://git.kernel.org/stable/c/4c86c772fef06f5d7a66151bac42366825db0941","https://git.kernel.org/stable/c/622b1cf38521569869c8f7b9fbe9e4f1a289add7","https://git.kernel.org/stable/c/6bf5c2fade8ed53b2d26fa9875e5b04f36c7145d","https://git.kernel.org/stable/c/770a57922ce36a8476c43f7400b6501c554ea511","https://git.kernel.org/stable/c/8269ab16415f2065cd792c49b0475543936cbd79","https://git.kernel.org/stable/c/8cf9c5051076e0eb958f4361d50d8b0c3ee6691c","https://git.kernel.org/stable/c/94303a06e1852a366e9671fff46d19459f88cb28","https://git.kernel.org/stable/c/0de691ff547d86dd54c24b40a81f9c925df8dd77","https://git.kernel.org/stable/c/31096da07933598da8522c54bd007376fb152a09","https://git.kernel.org/stable/c/4c86c772fef06f5d7a66151bac42366825db0941","https://git.kernel.org/stable/c/622b1cf38521569869c8f7b9fbe9e4f1a289add7","https://git.kernel.org/stable/c/6bf5c2fade8ed53b2d26fa9875e5b04f36c7145d","https://git.kernel.org/stable/c/770a57922ce36a8476c43f7400b6501c554ea511","https://git.kernel.org/stable/c/8269ab16415f2065cd792c49b0475543936cbd79","https://git.kernel.org/stable/c/8cf9c5051076e0eb958f4361d50d8b0c3ee6691c","https://git.kernel.org/stable/c/94303a06e1852a366e9671fff46d19459f88cb28","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35811
|
Medium |
fixed |
- 4.19.312
- 5.4.274
- 5.10.215
- 5.15.154
- 6.1.84
- 6.6.24
- 6.7.12
- 6.8.3
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach
This is the candidate patch of CVE-2023-47233 :
https://nvd.nist.gov/vuln/detail/CVE-2023-47233
In brcm80211 driver,it starts with the following invoking chain
to start init a timeout worker:
->brcmf_usb_probe
->brcmf_usb_probe_cb
->brcmf_attach
->brcmf_bus_started
->brcmf_cfg80211_attach
->wl_init_priv
->brcmf_init_escan
->INIT_WORK(&cfg->escan_timeout_work,
brcmf_cfg80211_escan_timeout_worker);
If we disconnect the USB by hotplug, it will call
brcmf_usb_disconnect to make cleanup. The invoking chain is :
brcmf_usb_disconnect
->brcmf_usb_disconnect_cb
->brcmf_detach
->brcmf_cfg80211_detach
->kfree(cfg);
While the timeout woker may still be running. This will cause
a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker.
Fix it by deleting the timer and canceling the worker in
brcmf_cfg80211_detach.
[arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free] |
["https://git.kernel.org/stable/c/0a7591e14a8da794d0b93b5d1c6254ccb23adacb","https://git.kernel.org/stable/c/0b812f706fd7090be74812101114a0e165b36744","https://git.kernel.org/stable/c/0f7352557a35ab7888bc7831411ec8a3cbe20d78","https://git.kernel.org/stable/c/190794848e2b9d15de92d502b6ac652806904f5a","https://git.kernel.org/stable/c/202c503935042272e2f9e1bb549d5f69a8681169","https://git.kernel.org/stable/c/6678a1e7d896c00030b31491690e8ddc9a90767a","https://git.kernel.org/stable/c/8c36205123dc57349b59b4f1a2301eb278cbc731","https://git.kernel.org/stable/c/8e3f03f4ef7c36091f46e7349096efb5a2cdb3a1","https://git.kernel.org/stable/c/bacb8c3ab86dcd760c15903fcee58169bc3026aa","https://git.kernel.org/stable/c/0a7591e14a8da794d0b93b5d1c6254ccb23adacb","https://git.kernel.org/stable/c/0b812f706fd7090be74812101114a0e165b36744","https://git.kernel.org/stable/c/0f7352557a35ab7888bc7831411ec8a3cbe20d78","https://git.kernel.org/stable/c/190794848e2b9d15de92d502b6ac652806904f5a","https://git.kernel.org/stable/c/202c503935042272e2f9e1bb549d5f69a8681169","https://git.kernel.org/stable/c/6678a1e7d896c00030b31491690e8ddc9a90767a","https://git.kernel.org/stable/c/8c36205123dc57349b59b4f1a2301eb278cbc731","https://git.kernel.org/stable/c/8e3f03f4ef7c36091f46e7349096efb5a2cdb3a1","https://git.kernel.org/stable/c/bacb8c3ab86dcd760c15903fcee58169bc3026aa","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35828
|
Medium |
fixed |
- 4.19.311
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()
In the for statement of lbs_allocate_cmd_buffer(), if the allocation of
cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to
be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer(). |
["https://git.kernel.org/stable/c/4d99d267da3415db2124029cb5a6d2d955ca43f9","https://git.kernel.org/stable/c/5f0e4aede01cb01fa633171f0533affd25328c3a","https://git.kernel.org/stable/c/8e243ac649c10922a6b4855170eaefe4c5b3faab","https://git.kernel.org/stable/c/96481624fb5a6319079fb5059e46dbce43a90186","https://git.kernel.org/stable/c/bea9573c795acec5614d4ac2dcc7b3b684cea5bf","https://git.kernel.org/stable/c/d219724d4b0ddb8ec7dfeaed5989f23edabaf591","https://git.kernel.org/stable/c/da10f6b7918abd5b4bc5c9cb66f0fc6763ac48f3","https://git.kernel.org/stable/c/e888c4461e109f7b93c3522afcbbaa5a8fdf29d2","https://git.kernel.org/stable/c/f0dd27314c7afe34794c2aa19dd6f2d30eb23bc7","https://git.kernel.org/stable/c/4d99d267da3415db2124029cb5a6d2d955ca43f9","https://git.kernel.org/stable/c/5f0e4aede01cb01fa633171f0533affd25328c3a","https://git.kernel.org/stable/c/8e243ac649c10922a6b4855170eaefe4c5b3faab","https://git.kernel.org/stable/c/96481624fb5a6319079fb5059e46dbce43a90186","https://git.kernel.org/stable/c/bea9573c795acec5614d4ac2dcc7b3b684cea5bf","https://git.kernel.org/stable/c/d219724d4b0ddb8ec7dfeaed5989f23edabaf591","https://git.kernel.org/stable/c/da10f6b7918abd5b4bc5c9cb66f0fc6763ac48f3","https://git.kernel.org/stable/c/e888c4461e109f7b93c3522afcbbaa5a8fdf29d2","https://git.kernel.org/stable/c/f0dd27314c7afe34794c2aa19dd6f2d30eb23bc7","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43828
|
Medium |
fixed |
- 5.10.224
- 5.15.165
- 6.1.103
- 6.6.44
- 6.10.3
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix infinite loop when replaying fast_commit
When doing fast_commit replay an infinite loop may occur due to an
uninitialized extent_status struct. ext4_ext_determine_insert_hole() does
not detect the replay and calls ext4_es_find_extent_range(), which will
return immediately without initializing the 'es' variable.
Because 'es' contains garbage, an integer overflow may happen causing an
infinite loop in this function, easily reproducible using fstest generic/039.
This commit fixes this issue by unconditionally initializing the structure
in function ext4_es_find_extent_range().
Thanks to Zhang Yi, for figuring out the real problem! |
["https://git.kernel.org/stable/c/0619f7750f2b178a1309808832ab20d85e0ad121","https://git.kernel.org/stable/c/181e63cd595c688194e07332f9944b3a63193de2","https://git.kernel.org/stable/c/5ed0496e383cb6de120e56991385dce70bbb87c1","https://git.kernel.org/stable/c/81f819c537d29932e4b9267f02411cbc8b355178","https://git.kernel.org/stable/c/907c3fe532253a6ef4eb9c4d67efb71fab58c706","https://git.kernel.org/stable/c/c6e67df64783e99a657ef2b8c834ba2bf54c539c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52814
|
Medium |
fixed |
- 5.10.202
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix potential null pointer derefernce
The amdgpu_ras_get_context may return NULL if device
not support ras feature, so add check before using. |
["https://git.kernel.org/stable/c/80285ae1ec8717b597b20de38866c29d84d321a1","https://git.kernel.org/stable/c/9b70fc7d70e8ef7c4a65034c9487f58609e708a1","https://git.kernel.org/stable/c/b0702ee4d811708251cdf54d4a1d3e888d365111","https://git.kernel.org/stable/c/b93a25de28af153312f0fc979b0663fc4bd3442b","https://git.kernel.org/stable/c/c11cf5e117f50f5a767054600885acd981449afe","https://git.kernel.org/stable/c/da46e63482fdc5e35c008865c22ac64027f6f0c2","https://git.kernel.org/stable/c/80285ae1ec8717b597b20de38866c29d84d321a1","https://git.kernel.org/stable/c/9b70fc7d70e8ef7c4a65034c9487f58609e708a1","https://git.kernel.org/stable/c/b0702ee4d811708251cdf54d4a1d3e888d365111","https://git.kernel.org/stable/c/b93a25de28af153312f0fc979b0663fc4bd3442b","https://git.kernel.org/stable/c/c11cf5e117f50f5a767054600885acd981449afe","https://git.kernel.org/stable/c/da46e63482fdc5e35c008865c22ac64027f6f0c2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35852
|
Medium |
fixed |
- 5.4.275
- 5.10.216
- 5.15.158
- 6.1.90
- 6.6.30
- 6.8.9
|
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix memory leak when canceling rehash work
The rehash delayed work is rescheduled with a delay if the number of
credits at end of the work is not negative as supposedly it means that
the migration ended. Otherwise, it is rescheduled immediately.
After "mlxsw: spectrum_acl_tcam: Fix possible use-after-free during
rehash" the above is no longer accurate as a non-negative number of
credits is no longer indicative of the migration being done. It can also
happen if the work encountered an error in which case the migration will
resume the next time the work is scheduled.
The significance of the above is that it is possible for the work to be
pending and associated with hints that were allocated when the migration
started. This leads to the hints being leaked [1] when the work is
canceled while pending as part of ACL region dismantle.
Fix by freeing the hints if hints are associated with a work that was
canceled while pending.
Blame the original commit since the reliance on not having a pending
work associated with hints is fragile.
[1]
unreferenced object 0xffff88810e7c3000 (size 256):
comm "kworker/0:16", pid 176, jiffies 4295460353
hex dump (first 32 bytes):
00 30 95 11 81 88 ff ff 61 00 00 00 00 00 00 80 .0......a.......
00 00 61 00 40 00 00 00 00 00 00 00 04 00 00 00 ..a.@...........
backtrace (crc 2544ddb9):
[<00000000cf8cfab3>] kmalloc_trace+0x23f/0x2a0
[<000000004d9a1ad9>] objagg_hints_get+0x42/0x390
[<000000000b143cf3>] mlxsw_sp_acl_erp_rehash_hints_get+0xca/0x400
[<0000000059bdb60a>] mlxsw_sp_acl_tcam_vregion_rehash_work+0x868/0x1160
[<00000000e81fd734>] process_one_work+0x59c/0xf20
[<00000000ceee9e81>] worker_thread+0x799/0x12c0
[<00000000bda6fe39>] kthread+0x246/0x300
[<0000000070056d23>] ret_from_fork+0x34/0x70
[<00000000dea2b93e>] ret_from_fork_asm+0x1a/0x30 |
["https://git.kernel.org/stable/c/51cefc9da400b953fee749c9e5d26cd4a2b5d758","https://git.kernel.org/stable/c/5bfe7bf9656ed2633718388f12b7c38b86414a04","https://git.kernel.org/stable/c/63d814d93c5cce4c18284adc810028f28dca493f","https://git.kernel.org/stable/c/857ed800133ffcfcee28582090b63b0cbb8ba59d","https://git.kernel.org/stable/c/d72dd6fcd7886d0523afbab8b4a4b22d17addd7d","https://git.kernel.org/stable/c/de1aaefa75be9d0ec19c9a3e0e2f9696de20c6ab","https://git.kernel.org/stable/c/fb4e2b70a7194b209fc7320bbf33b375f7114bd5","https://git.kernel.org/stable/c/51cefc9da400b953fee749c9e5d26cd4a2b5d758","https://git.kernel.org/stable/c/5bfe7bf9656ed2633718388f12b7c38b86414a04","https://git.kernel.org/stable/c/63d814d93c5cce4c18284adc810028f28dca493f","https://git.kernel.org/stable/c/857ed800133ffcfcee28582090b63b0cbb8ba59d","https://git.kernel.org/stable/c/d72dd6fcd7886d0523afbab8b4a4b22d17addd7d","https://git.kernel.org/stable/c/de1aaefa75be9d0ec19c9a3e0e2f9696de20c6ab","https://git.kernel.org/stable/c/fb4e2b70a7194b209fc7320bbf33b375f7114bd5","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21735
|
High |
fixed |
- 6.1.129
- 6.6.78
- 6.12.14
- 6.13.3
|
In the Linux kernel, the following vulnerability has been resolved:
NFC: nci: Add bounds checking in nci_hci_create_pipe()
The "pipe" variable is a u8 which comes from the network. If it's more
than 127, then it results in memory corruption in the caller,
nci_hci_connect_gate(). |
["https://git.kernel.org/stable/c/10b3f947b609713e04022101f492d288a014ddfa","https://git.kernel.org/stable/c/110b43ef05342d5a11284cc8b21582b698b4ef1c","https://git.kernel.org/stable/c/172cdfc3a5ea20289c58fb73dadc6fd4a8784a4e","https://git.kernel.org/stable/c/2ae4bade5a64d126bd18eb66bd419005c5550218","https://git.kernel.org/stable/c/59c7ed20217c0939862fbf8145bc49d5b3a13f4f","https://git.kernel.org/stable/c/674e17c5933779a8bf5c15d596fdfcb5ccdebbc2","https://git.kernel.org/stable/c/bd249109d266f1d52548c46634a15b71656e0d44","https://git.kernel.org/stable/c/d5a461c315e5ff92657f84d8ba50caa5abf5c22a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46804
|
High |
fixed |
- 5.10.226
- 5.15.167
- 6.1.109
- 6.6.50
- 6.10.9
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add array index check for hdcp ddc access
[Why]
Coverity reports OVERRUN warning. Do not check if array
index valid.
[How]
Check msg_id valid and valid array index. |
["https://git.kernel.org/stable/c/0ee4387c5a4b57ec733c3fb4365188d5979cd9c7","https://git.kernel.org/stable/c/2a63c90c7a90ab2bd23deebc2814fc5b52abf6d2","https://git.kernel.org/stable/c/4e70c0f5251c25885c31ee84a31f99a01f7cf50e","https://git.kernel.org/stable/c/8b5ccf3d011969417be653b5a145c72dbd30472c","https://git.kernel.org/stable/c/a3b5ee22a9d3a30045191da5678ca8451ebaea30","https://git.kernel.org/stable/c/f338f99f6a04d03c802087d82a83561cbd5bdc99"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46844
|
High |
fixed |
- 4.19.322
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
um: line: always fill *error_out in setup_one_line()
The pointer isn't initialized by callers, but I have
encountered cases where it's still printed; initialize
it in all possible cases in setup_one_line(). |
["https://git.kernel.org/stable/c/289979d64573f43df1d0e6bc6435de63a0d69cdf","https://git.kernel.org/stable/c/3bedb7ce080690d0d6172db790790c1219bcbdd5","https://git.kernel.org/stable/c/43f782c27907f306c664b6614fd6f264ac32cce6","https://git.kernel.org/stable/c/824ac4a5edd3f7494ab1996826c4f47f8ef0f63d","https://git.kernel.org/stable/c/96301fdc2d533a196197c055af875fe33d47ef84","https://git.kernel.org/stable/c/c8944d449fda9f58c03bd99649b2df09948fc874","https://git.kernel.org/stable/c/ec5b47a370177d79ae7773858042c107e21f8ecc","https://git.kernel.org/stable/c/fc843d3837ebcb1c16d3768ef3eb55e25d5331f2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50143
|
High |
fixed |
- 4.19.323
- 5.4.285
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
udf: fix uninit-value use in udf_get_fileshortad
Check for overflow when computing alen in udf_current_aext to mitigate
later uninit-value use in udf_get_fileshortad KMSAN bug[1].
After applying the patch reproducer did not trigger any issue[2].
[1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df
[2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000 |
["https://git.kernel.org/stable/c/1ac49babc952f48d82676979b20885e480e69be8","https://git.kernel.org/stable/c/264db9d666ad9a35075cc9ed9ec09d021580fbb1","https://git.kernel.org/stable/c/417bd613bdbe791549f7687bb1b9b8012ff111c2","https://git.kernel.org/stable/c/4fc0d8660e391dcd8dde23c44d702be1f6846c61","https://git.kernel.org/stable/c/5eb76fb98b3335aa5cca6a7db2e659561c79c32b","https://git.kernel.org/stable/c/72e445df65a0aa9066c6fe2b8736ba2fcca6dac7","https://git.kernel.org/stable/c/e52e0b92ed31dc62afbda15c243dcee0bb5bb58d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50180
|
High |
fixed |
- 4.19.323
- 5.4.285
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
fbdev: sisfb: Fix strbuf array overflow
The values of the variables xres and yres are placed in strbuf.
These variables are obtained from strbuf1.
The strbuf1 array contains digit characters
and a space if the array contains non-digit characters.
Then, when executing sprintf(strbuf, "%ux%ux8", xres, yres);
more than 16 bytes will be written to strbuf.
It is suggested to increase the size of the strbuf array to 24.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/11c0d49093b82f6c547fd419c41a982d26bdf5ef","https://git.kernel.org/stable/c/252f147b1826cbb30ae0304cf86b66d3bb12b743","https://git.kernel.org/stable/c/41cf6f26abe4f491b694c54bd1aa2530369b7510","https://git.kernel.org/stable/c/433c84c8495008922534c5cafdae6ff970fb3241","https://git.kernel.org/stable/c/57c4f4db0a194416da237fd09dad9527e00cb587","https://git.kernel.org/stable/c/688872c4ea4a528cd6a057d545c83506b533ee1f","https://git.kernel.org/stable/c/889304120ecb2ca30674d89cd4ef15990b6a571c","https://git.kernel.org/stable/c/9cf14f5a2746c19455ce9cb44341b5527b5e19c3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46725
|
High |
fixed |
- 5.10.226
- 5.15.167
- 6.1.109
- 6.6.50
- 6.10.9
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix out-of-bounds write warning
Check the ring type value to fix the out-of-bounds
write warning |
["https://git.kernel.org/stable/c/130bee397b9cd52006145c87a456fd8719390cb5","https://git.kernel.org/stable/c/919f9bf9997b8dcdc132485ea96121e7d15555f9","https://git.kernel.org/stable/c/a60d1f7ff62e453dde2d3b4907e178954d199844","https://git.kernel.org/stable/c/be1684930f5262a622d40ce7a6f1423530d87f89","https://git.kernel.org/stable/c/c253b87c7c37ec40a2e0c84e4a6b636ba5cd66b2","https://git.kernel.org/stable/c/cf2db220b38301b6486a0f11da24a0f317de558c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49022
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac8021: fix possible oob access in ieee80211_get_rate_duration
Fix possible out-of-bound access in ieee80211_get_rate_duration routine
as reported by the following UBSAN report:
UBSAN: array-index-out-of-bounds in net/mac80211/airtime.c:455:47
index 15 is out of range for type 'u16 [12]'
CPU: 2 PID: 217 Comm: kworker/u32:10 Not tainted 6.1.0-060100rc3-generic
Hardware name: Acer Aspire TC-281/Aspire TC-281, BIOS R01-A2 07/18/2017
Workqueue: mt76 mt76u_tx_status_data [mt76_usb]
Call Trace:
<TASK>
show_stack+0x4e/0x61
dump_stack_lvl+0x4a/0x6f
dump_stack+0x10/0x18
ubsan_epilogue+0x9/0x43
__ubsan_handle_out_of_bounds.cold+0x42/0x47
ieee80211_get_rate_duration.constprop.0+0x22f/0x2a0 [mac80211]
? ieee80211_tx_status_ext+0x32e/0x640 [mac80211]
ieee80211_calc_rx_airtime+0xda/0x120 [mac80211]
ieee80211_calc_tx_airtime+0xb4/0x100 [mac80211]
mt76x02_send_tx_status+0x266/0x480 [mt76x02_lib]
mt76x02_tx_status_data+0x52/0x80 [mt76x02_lib]
mt76u_tx_status_data+0x67/0xd0 [mt76_usb]
process_one_work+0x225/0x400
worker_thread+0x50/0x3e0
? process_one_work+0x400/0x400
kthread+0xe9/0x110
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x22/0x30 |
["https://git.kernel.org/stable/c/0184ede0ec61b9cd075babfaa45081b1bf322234","https://git.kernel.org/stable/c/3e8f7abcc3473bc9603323803aeaed4ffcc3a2ab","https://git.kernel.org/stable/c/59b54f0563b6546c94bdb6823d3b382c75407019","https://git.kernel.org/stable/c/f0fcad4c7201ecfaa17357f4ce0c50b4708df22d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47670
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: add bounds checking to ocfs2_xattr_find_entry()
Add a paranoia check to make sure it doesn't stray beyond valid memory
region containing ocfs2 xattr entries when scanning for a match. It will
prevent out-of-bound access in case of crafted images. |
["https://git.kernel.org/stable/c/1f6e167d6753fe3ea493cdc7f7de8d03147a4d39","https://git.kernel.org/stable/c/34759b7e4493d7337cbc414c132cef378c492a2c","https://git.kernel.org/stable/c/5bbe51eaf01a5dd6fb3f0dea81791e5dbc6dc6dd","https://git.kernel.org/stable/c/60c0d36189bad58b1a8e69af8781d90009559ea1","https://git.kernel.org/stable/c/8e7bef408261746c160853fc27df3139659f5f77","https://git.kernel.org/stable/c/9b32539590a8e6400ac2f6e7cf9cbb8e08711a2f","https://git.kernel.org/stable/c/9e3041fecdc8f78a5900c3aa51d3d756e73264d6","https://git.kernel.org/stable/c/b49a786beb11ff740cb9e0c20b999c2a0e1729c2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49889
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid use-after-free in ext4_ext_show_leaf()
In ext4_find_extent(), path may be freed by error or be reallocated, so
using a previously saved *ppath may have been freed and thus may trigger
use-after-free, as follows:
ext4_split_extent
path = *ppath;
ext4_split_extent_at(ppath)
path = ext4_find_extent(ppath)
ext4_split_extent_at(ppath)
// ext4_find_extent fails to free path
// but zeroout succeeds
ext4_ext_show_leaf(inode, path)
eh = path[depth].p_hdr
// path use-after-free !!!
Similar to ext4_split_extent_at(), we use *ppath directly as an input to
ext4_ext_show_leaf(). Fix a spelling error by the way.
Same problem in ext4_ext_handle_unwritten_extents(). Since 'path' is only
used in ext4_ext_show_leaf(), remove 'path' and use *ppath directly.
This issue is triggered only when EXT_DEBUG is defined and therefore does
not affect functionality. |
["https://git.kernel.org/stable/c/2eba3b0cc5b8de624918d21f32b5b8db59a90b39","https://git.kernel.org/stable/c/34b2096380ba475771971a778a478661a791aa15","https://git.kernel.org/stable/c/4999fed877bb64e3e7f9ab9996de2ca983c41928","https://git.kernel.org/stable/c/4e2524ba2ca5f54bdbb9e5153bea00421ef653f5","https://git.kernel.org/stable/c/8b114f2cc7dd5d36729d040b68432fbd0f0a8868","https://git.kernel.org/stable/c/b0cb4561fc4284d04e69c8a66c8504928ab2484e","https://git.kernel.org/stable/c/d483c7cc1796bd6a80e7b3a8fd494996260f6b67"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49930
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix array out-of-bound access in SoC stats
Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a
maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx()
function access ath11k_soc_dp_stats::hal_reo_error using the REO
destination SRNG ring ID, which is incorrect. SRNG ring ID differ from
normal ring ID, and this usage leads to out-of-bounds array access. To fix
this issue, modify ath11k_dp_process_rx() to use the normal ring ID
directly instead of the SRNG ring ID to avoid out-of-bounds array access.
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 |
["https://git.kernel.org/stable/c/01b77f5ee11c89754fb836af8f76799d3b72ae2f","https://git.kernel.org/stable/c/0f26f26944035ec67546a944f182cbad6577a9c0","https://git.kernel.org/stable/c/4dd732893bd38cec51f887244314e2b47f0d658f","https://git.kernel.org/stable/c/6045ef5b4b00fee3629689f791992900a1c94009","https://git.kernel.org/stable/c/69f253e46af98af17e3efa3e5dfa72fcb7d1983d","https://git.kernel.org/stable/c/73e235728e515faccc104b0153b47d0f263b3344","https://git.kernel.org/stable/c/7a552bc2f3efe2aaf77a85cb34cdf4a63d81a1a7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49936
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
net/xen-netback: prevent UAF in xenvif_flush_hash()
During the list_for_each_entry_rcu iteration call of xenvif_flush_hash,
kfree_rcu does not exist inside the rcu read critical section, so if
kfree_rcu is called when the rcu grace period ends during the iteration,
UAF occurs when accessing head->next after the entry becomes free.
Therefore, to solve this, you need to change it to list_for_each_entry_safe. |
["https://git.kernel.org/stable/c/0fa5e94a1811d68fbffa0725efe6d4ca62c03d12","https://git.kernel.org/stable/c/143edf098b80669d05245b2f2367dd156a83a2c5","https://git.kernel.org/stable/c/3c4423b0c4b98213b3438e15061e1d08220e6982","https://git.kernel.org/stable/c/54d8639af5568fc41c0e274fc3ec9cf86c59fcbb","https://git.kernel.org/stable/c/a0465723b8581cad27164c9073fd780904cd22d4","https://git.kernel.org/stable/c/a7f0073fcd12ed7de185ef2c0af9d0fa1ddef22c","https://git.kernel.org/stable/c/d408889d4b54f5501e4becc4dbbb9065143fbf4e","https://git.kernel.org/stable/c/efcff6ce7467f01f0753609f420333f3f2ceceda"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50055
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
driver core: bus: Fix double free in driver API bus_register()
For bus_register(), any error which happens after kset_register() will
cause that @priv are freed twice, fixed by setting @priv with NULL after
the first free. |
["https://git.kernel.org/stable/c/4797953712214ea57a437443bb0ad6d1e0646d70","https://git.kernel.org/stable/c/5be4bc1c73ca389a96d418a52054d897c6fe6d21","https://git.kernel.org/stable/c/87bc3cb23c56de2c5e14a58d87cf953e7a2508f8","https://git.kernel.org/stable/c/9ce15f68abedfae7ae0a35e95895aeddfd0f0c6a","https://git.kernel.org/stable/c/bfa54a793ba77ef696755b66f3ac4ed00c7d1248","https://git.kernel.org/stable/c/d885c464c25018b81a6b58f5d548fc2e3ef87dd1","https://git.kernel.org/stable/c/fc1f391a71a3ee88291e205cffd673fe24d99266"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50242
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Additional check in ntfs_file_release |
["https://git.kernel.org/stable/c/031d6f608290c847ba6378322d0986d08d1a645a","https://git.kernel.org/stable/c/542532afe249588ae88d8409d4bf861c315f8862","https://git.kernel.org/stable/c/550ef40fa6366d5d11b122e5f36b1f9aa20c087e","https://git.kernel.org/stable/c/82685eb6ca1db2bd11190451085bcb86ed03aa24","https://git.kernel.org/stable/c/d1ac7e2620302e3e49573df39bd4e868e8b4962a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50283
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp
ksmbd_user_session_put should be called under smb3_preauth_hash_rsp().
It will avoid freeing session before calling smb3_preauth_hash_rsp(). |
["https://git.kernel.org/stable/c/1b6ad475d4ed577d34e0157eb507be00c588bf5c","https://git.kernel.org/stable/c/b8fc56fbca7482c1e5c0e3351c6ae78982e25ada","https://git.kernel.org/stable/c/c6cdc08c25a868a08068dfc319fa9fce982b8e7f","https://git.kernel.org/stable/c/cb645064e0811053c94e86677f2e58ed29359d62","https://git.kernel.org/stable/c/f7557bbca40d4ca8bb1c6c940ac6c95078bd0827"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44940
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
fou: remove warn in gue_gro_receive on unsupported protocol
Drop the WARN_ON_ONCE inn gue_gro_receive if the encapsulated type is
not known or does not have a GRO handler.
Such a packet is easily constructed. Syzbot generates them and sets
off this warning.
Remove the warning as it is expected and not actionable.
The warning was previously reduced from WARN_ON to WARN_ON_ONCE in
commit 270136613bf7 ("fou: Do WARN_ON_ONCE in gue_gro_receive for bad
proto callbacks"). |
["https://git.kernel.org/stable/c/3db4395332e7050ef9ddeb3052e6b5019f2a2a59","https://git.kernel.org/stable/c/440ab7f97261bc28501636a13998e1b1946d2e79","https://git.kernel.org/stable/c/5a2e37bc648a2503bf6d687aed27b9f4455d82eb","https://git.kernel.org/stable/c/a925a200299a6dfc7c172f54da6f374edc930053","https://git.kernel.org/stable/c/b1453a5616c7bd8acd90633ceba4e59105ba3b51","https://git.kernel.org/stable/c/dd89a81d850fa9a65f67b4527c0e420d15bf836c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57798
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/dp_mst: Ensure mst_primary pointer is valid in drm_dp_mst_handle_up_req()
While receiving an MST up request message from one thread in
drm_dp_mst_handle_up_req(), the MST topology could be removed from
another thread via drm_dp_mst_topology_mgr_set_mst(false), freeing
mst_primary and setting drm_dp_mst_topology_mgr::mst_primary to NULL.
This could lead to a NULL deref/use-after-free of mst_primary in
drm_dp_mst_handle_up_req().
Avoid the above by holding a reference for mst_primary in
drm_dp_mst_handle_up_req() while it's used.
v2: Fix kfreeing the request if getting an mst_primary reference fails. |
["https://git.kernel.org/stable/c/9735d40f5fde9970aa46e828ecc85c32571d58a2","https://git.kernel.org/stable/c/ce55818b2d3a999f886af91679589e4644ff1dc8","https://git.kernel.org/stable/c/e54b00086f7473dbda1a7d6fc47720ced157c6a8","https://git.kernel.org/stable/c/f61b2e5e7821f868d6afc22382a66a30ee780ba0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46871
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Correct the defined value for AMDGPU_DMUB_NOTIFICATION_MAX
[Why & How]
It actually exposes '6' types in enum dmub_notification_type. Not 5. Using smaller
number to create array dmub_callback & dmub_thread_offload has potential to access
item out of array bound. Fix it. |
["https://git.kernel.org/stable/c/800a5ab673c4a61ca220cce177386723d91bdb37","https://git.kernel.org/stable/c/9f404b0bc2df3880758fb3c3bc7496f596f347d7","https://git.kernel.org/stable/c/ad28d7c3d989fc5689581664653879d664da76f0","https://git.kernel.org/stable/c/c592b6355b9b57b8e59fc5978ce1e14f64488a98","https://git.kernel.org/stable/c/e1896f381d27466c26cb44b4450eae05cd59dfd0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48998
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
powerpc/bpf/32: Fix Oops on tail call tests
test_bpf tail call tests end up as:
test_bpf: #0 Tail call leaf jited:1 85 PASS
test_bpf: #1 Tail call 2 jited:1 111 PASS
test_bpf: #2 Tail call 3 jited:1 145 PASS
test_bpf: #3 Tail call 4 jited:1 170 PASS
test_bpf: #4 Tail call load/store leaf jited:1 190 PASS
test_bpf: #5 Tail call load/store jited:1
BUG: Unable to handle kernel data access on write at 0xf1b4e000
Faulting instruction address: 0xbe86b710
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K MMU=Hash PowerMac
Modules linked in: test_bpf(+)
CPU: 0 PID: 97 Comm: insmod Not tainted 6.1.0-rc4+ #195
Hardware name: PowerMac3,1 750CL 0x87210 PowerMac
NIP: be86b710 LR: be857e88 CTR: be86b704
REGS: f1b4df20 TRAP: 0300 Not tainted (6.1.0-rc4+)
MSR: 00009032 <EE,ME,IR,DR,RI> CR: 28008242 XER: 00000000
DAR: f1b4e000 DSISR: 42000000
GPR00: 00000001 f1b4dfe0 c11d2280 00000000 00000000 00000000 00000002 00000000
GPR08: f1b4e000 be86b704 f1b4e000 00000000 00000000 100d816a f2440000 fe73baa8
GPR16: f2458000 00000000 c1941ae4 f1fe2248 00000045 c0de0000 f2458030 00000000
GPR24: 000003e8 0000000f f2458000 f1b4dc90 3e584b46 00000000 f24466a0 c1941a00
NIP [be86b710] 0xbe86b710
LR [be857e88] __run_one+0xec/0x264 [test_bpf]
Call Trace:
[f1b4dfe0] [00000002] 0x2 (unreliable)
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
---[ end trace 0000000000000000 ]---
This is a tentative to write above the stack. The problem is encoutered
with tests added by commit 38608ee7b690 ("bpf, tests: Add load store
test case for tail call")
This happens because tail call is done to a BPF prog with a different
stack_depth. At the time being, the stack is kept as is when the caller
tail calls its callee. But at exit, the callee restores the stack based
on its own properties. Therefore here, at each run, r1 is erroneously
increased by 32 - 16 = 16 bytes.
This was done that way in order to pass the tail call count from caller
to callee through the stack. As powerpc32 doesn't have a red zone in
the stack, it was necessary the maintain the stack as is for the tail
call. But it was not anticipated that the BPF frame size could be
different.
Let's take a new approach. Use register r4 to carry the tail call count
during the tail call, and save it into the stack at function entry if
required. This means the input parameter must be in r3, which is more
correct as it is a 32 bits parameter, then tail call better match with
normal BPF function entry, the down side being that we move that input
parameter back and forth between r3 and r4. That can be optimised later.
Doing that also has the advantage of maximising the common parts between
tail calls and a normal function exit.
With the fix, tail call tests are now successfull:
test_bpf: #0 Tail call leaf jited:1 53 PASS
test_bpf: #1 Tail call 2 jited:1 115 PASS
test_bpf: #2 Tail call 3 jited:1 154 PASS
test_bpf: #3 Tail call 4 jited:1 165 PASS
test_bpf: #4 Tail call load/store leaf jited:1 101 PASS
test_bpf: #5 Tail call load/store jited:1 141 PASS
test_bpf: #6 Tail call error path, max count reached jited:1 994 PASS
test_bpf: #7 Tail call count preserved across function calls jited:1 140975 PASS
test_bpf: #8 Tail call error path, NULL target jited:1 110 PASS
test_bpf: #9 Tail call error path, index out of range jited:1 69 PASS
test_bpf: test_tail_calls: Summary: 10 PASSED, 0 FAILED, [10/10 JIT'ed] |
["https://git.kernel.org/stable/c/747a6e547240baaaf41874d27333b87b87cfd24c","https://git.kernel.org/stable/c/89d21e259a94f7d5582ec675aa445f5a79f347e4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52501
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Do not attempt to read past "commit"
When iterating over the ring buffer while the ring buffer is active, the
writer can corrupt the reader. There's barriers to help detect this and
handle it, but that code missed the case where the last event was at the
very end of the page and has only 4 bytes left.
The checks to detect the corruption by the writer to reads needs to see the
length of the event. If the length in the first 4 bytes is zero then the
length is stored in the second 4 bytes. But if the writer is in the process
of updating that code, there's a small window where the length in the first
4 bytes could be zero even though the length is only 4 bytes. That will
cause rb_event_length() to read the next 4 bytes which could happen to be off the
allocated page.
To protect against this, fail immediately if the next event pointer is
less than 8 bytes from the end of the commit (last byte of data), as all
events must be a minimum of 8 bytes anyway. |
["https://git.kernel.org/stable/c/344f2f3e61a90f0150c754796ec9a17fcaeec03d","https://git.kernel.org/stable/c/75fc9e99b3a71006720ad1e029db11a4b5c32d4a","https://git.kernel.org/stable/c/95a404bd60af6c4d9d8db01ad14fe8957ece31ca","https://git.kernel.org/stable/c/b08a4938229dbb530a35c41b83002a1457c6ff49","https://git.kernel.org/stable/c/cee5151c5410e868826b8afecfb356f3799ebea3","https://git.kernel.org/stable/c/344f2f3e61a90f0150c754796ec9a17fcaeec03d","https://git.kernel.org/stable/c/75fc9e99b3a71006720ad1e029db11a4b5c32d4a","https://git.kernel.org/stable/c/95a404bd60af6c4d9d8db01ad14fe8957ece31ca","https://git.kernel.org/stable/c/b08a4938229dbb530a35c41b83002a1457c6ff49","https://git.kernel.org/stable/c/cee5151c5410e868826b8afecfb356f3799ebea3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52877
|
Medium |
fixed |
- 5.15.138
- 6.1.62
- 6.5.11
- 6.6.1
|
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: tcpm: Fix NULL pointer dereference in tcpm_pd_svdm()
It is possible that typec_register_partner() returns ERR_PTR on failure.
When port->partner is an error, a NULL pointer dereference may occur as
shown below.
[91222.095236][ T319] typec port0: failed to register partner (-17)
...
[91225.061491][ T319] Unable to handle kernel NULL pointer dereference
at virtual address 000000000000039f
[91225.274642][ T319] pc : tcpm_pd_data_request+0x310/0x13fc
[91225.274646][ T319] lr : tcpm_pd_data_request+0x298/0x13fc
[91225.308067][ T319] Call trace:
[91225.308070][ T319] tcpm_pd_data_request+0x310/0x13fc
[91225.308073][ T319] tcpm_pd_rx_handler+0x100/0x9e8
[91225.355900][ T319] kthread_worker_fn+0x178/0x58c
[91225.355902][ T319] kthread+0x150/0x200
[91225.355905][ T319] ret_from_fork+0x10/0x30
Add a check for port->partner to avoid dereferencing a NULL pointer. |
["https://git.kernel.org/stable/c/4987daf86c152ff882d51572d154ad12e4ff3a4b","https://git.kernel.org/stable/c/9ee038590d808a95d16adf92818dcd4752273c08","https://git.kernel.org/stable/c/b37a168c0137156042a0ca9626651b5a789e822b","https://git.kernel.org/stable/c/e5f53a68a596e04df3fde3099273435a30b6fdac","https://git.kernel.org/stable/c/e7a802447c491903aa7cb45967aa2a934a4e63fc","https://git.kernel.org/stable/c/4987daf86c152ff882d51572d154ad12e4ff3a4b","https://git.kernel.org/stable/c/9ee038590d808a95d16adf92818dcd4752273c08","https://git.kernel.org/stable/c/b37a168c0137156042a0ca9626651b5a789e822b","https://git.kernel.org/stable/c/e5f53a68a596e04df3fde3099273435a30b6fdac","https://git.kernel.org/stable/c/e7a802447c491903aa7cb45967aa2a934a4e63fc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35989
|
Medium |
fixed |
- 5.15.158
- 6.1.90
- 6.6.30
- 6.8.9
|
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix oops during rmmod on single-CPU platforms
During the removal of the idxd driver, registered offline callback is
invoked as part of the clean up process. However, on systems with only
one CPU online, no valid target is available to migrate the
perf context, resulting in a kernel oops:
BUG: unable to handle page fault for address: 000000000002a2b8
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 1470e1067 P4D 0
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57
Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023
RIP: 0010:mutex_lock+0x2e/0x50
...
Call Trace:
<TASK>
__die+0x24/0x70
page_fault_oops+0x82/0x160
do_user_addr_fault+0x65/0x6b0
__pfx___rdmsr_safe_on_cpu+0x10/0x10
exc_page_fault+0x7d/0x170
asm_exc_page_fault+0x26/0x30
mutex_lock+0x2e/0x50
mutex_lock+0x1e/0x50
perf_pmu_migrate_context+0x87/0x1f0
perf_event_cpu_offline+0x76/0x90 [idxd]
cpuhp_invoke_callback+0xa2/0x4f0
__pfx_perf_event_cpu_offline+0x10/0x10 [idxd]
cpuhp_thread_fun+0x98/0x150
smpboot_thread_fn+0x27/0x260
smpboot_thread_fn+0x1af/0x260
__pfx_smpboot_thread_fn+0x10/0x10
kthread+0x103/0x140
__pfx_kthread+0x10/0x10
ret_from_fork+0x31/0x50
__pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1b/0x30
<TASK>
Fix the issue by preventing the migration of the perf context to an
invalid target. |
["https://git.kernel.org/stable/c/023b6390a15a98f9c3aa5e7da78d485d5384a08e","https://git.kernel.org/stable/c/47533176fdcef17b114a6f688bc872901c1ec6bb","https://git.kernel.org/stable/c/9edd3aa34d50f27b97be30b2ba4a6af0945ff56b","https://git.kernel.org/stable/c/f221033f5c24659dc6ad7e5cf18fb1b075f4a8be","https://git.kernel.org/stable/c/f976eca36cdf94e32fa4f865db0e7c427c9aa33c","https://git.kernel.org/stable/c/023b6390a15a98f9c3aa5e7da78d485d5384a08e","https://git.kernel.org/stable/c/47533176fdcef17b114a6f688bc872901c1ec6bb","https://git.kernel.org/stable/c/9edd3aa34d50f27b97be30b2ba4a6af0945ff56b","https://git.kernel.org/stable/c/f221033f5c24659dc6ad7e5cf18fb1b075f4a8be","https://git.kernel.org/stable/c/f976eca36cdf94e32fa4f865db0e7c427c9aa33c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27025
|
Medium |
fixed |
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
nbd: null check for nla_nest_start
nla_nest_start() may fail and return NULL. Insert a check and set errno
based on other call sites within the same source code. |
["https://git.kernel.org/stable/c/31edf4bbe0ba27fd03ac7d87eb2ee3d2a231af6d","https://git.kernel.org/stable/c/44214d744be32a4769faebba764510888f1eb19e","https://git.kernel.org/stable/c/4af837db0fd3679fabc7b7758397090b0c06dced","https://git.kernel.org/stable/c/96436365e5d80d0106ea785a4f80a58e7c9edff8","https://git.kernel.org/stable/c/98e60b538e66c90b9a856828c71d4e975ebfa797","https://git.kernel.org/stable/c/b7f5aed55829f376e4f7e5ea5b80ccdcb023e983","https://git.kernel.org/stable/c/ba6a9970ce9e284cbc04099361c58731e308596a","https://git.kernel.org/stable/c/e803040b368d046434fbc8a91945c690332c4fcf","https://git.kernel.org/stable/c/31edf4bbe0ba27fd03ac7d87eb2ee3d2a231af6d","https://git.kernel.org/stable/c/44214d744be32a4769faebba764510888f1eb19e","https://git.kernel.org/stable/c/4af837db0fd3679fabc7b7758397090b0c06dced","https://git.kernel.org/stable/c/96436365e5d80d0106ea785a4f80a58e7c9edff8","https://git.kernel.org/stable/c/98e60b538e66c90b9a856828c71d4e975ebfa797","https://git.kernel.org/stable/c/b7f5aed55829f376e4f7e5ea5b80ccdcb023e983","https://git.kernel.org/stable/c/ba6a9970ce9e284cbc04099361c58731e308596a","https://git.kernel.org/stable/c/e803040b368d046434fbc8a91945c690332c4fcf","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27038
|
Medium |
fixed |
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
clk: Fix clk_core_get NULL dereference
It is possible for clk_core_get to dereference a NULL in the following
sequence:
clk_core_get()
of_clk_get_hw_from_clkspec()
__of_clk_get_hw_from_provider()
__clk_get_hw()
__clk_get_hw() can return NULL which is dereferenced by clk_core_get() at
hw->core.
Prior to commit dde4eff47c82 ("clk: Look for parents with clkdev based
clk_lookups") the check IS_ERR_OR_NULL() was performed which would have
caught the NULL.
Reading the description of this function it talks about returning NULL but
that cannot be so at the moment.
Update the function to check for hw before dereferencing it and return NULL
if hw is NULL. |
["https://git.kernel.org/stable/c/0efb9ef6fb95384ba631d6819e66f10392aabfa2","https://git.kernel.org/stable/c/239174535dba11f7b83de0eaaa27909024f8c185","https://git.kernel.org/stable/c/6f073b24a9e2becd25ac4505a9780a87e621bb51","https://git.kernel.org/stable/c/a5d9b1aa61b401867b9066d54086b3e4ee91f8ed","https://git.kernel.org/stable/c/a8b2b26fdd011ebe36d68a9a321ca45801685959","https://git.kernel.org/stable/c/c554badcae9c45b737a22d23454170c6020b90e6","https://git.kernel.org/stable/c/d7ae7d1265686b55832a445b1db8cdd69738ac07","https://git.kernel.org/stable/c/e97fe4901e0f59a0bfd524578fe3768f8ca42428","https://git.kernel.org/stable/c/0efb9ef6fb95384ba631d6819e66f10392aabfa2","https://git.kernel.org/stable/c/239174535dba11f7b83de0eaaa27909024f8c185","https://git.kernel.org/stable/c/6f073b24a9e2becd25ac4505a9780a87e621bb51","https://git.kernel.org/stable/c/a5d9b1aa61b401867b9066d54086b3e4ee91f8ed","https://git.kernel.org/stable/c/a8b2b26fdd011ebe36d68a9a321ca45801685959","https://git.kernel.org/stable/c/c554badcae9c45b737a22d23454170c6020b90e6","https://git.kernel.org/stable/c/d7ae7d1265686b55832a445b1db8cdd69738ac07","https://git.kernel.org/stable/c/e97fe4901e0f59a0bfd524578fe3768f8ca42428","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27388
|
Medium |
fixed |
- 4.19.311
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: fix some memleaks in gssx_dec_option_array
The creds and oa->data need to be freed in the error-handling paths after
their allocation. So this patch add these deallocations in the
corresponding paths. |
["https://git.kernel.org/stable/c/3cfcfc102a5e57b021b786a755a38935e357797d","https://git.kernel.org/stable/c/5e6013ae2c8d420faea553d363935f65badd32c3","https://git.kernel.org/stable/c/934212a623cbab851848b6de377eb476718c3e4c","https://git.kernel.org/stable/c/9806c2393cd2ab0a8e7bb9ffae02ce20e3112ec4","https://git.kernel.org/stable/c/996997d1fb2126feda550d6adcedcbd94911fc69","https://git.kernel.org/stable/c/b97c37978ca825557d331c9012e0c1ddc0e42364","https://git.kernel.org/stable/c/bb336cd8d5ecb69c430ebe3e7bcff68471d93fa8","https://git.kernel.org/stable/c/bfa9d86d39a0fe4685f90c3529aa9bd62a9d97a8","https://git.kernel.org/stable/c/dd292e884c649f9b1c18af0ec75ca90b390cd044","https://git.kernel.org/stable/c/3cfcfc102a5e57b021b786a755a38935e357797d","https://git.kernel.org/stable/c/5e6013ae2c8d420faea553d363935f65badd32c3","https://git.kernel.org/stable/c/934212a623cbab851848b6de377eb476718c3e4c","https://git.kernel.org/stable/c/9806c2393cd2ab0a8e7bb9ffae02ce20e3112ec4","https://git.kernel.org/stable/c/996997d1fb2126feda550d6adcedcbd94911fc69","https://git.kernel.org/stable/c/b97c37978ca825557d331c9012e0c1ddc0e42364","https://git.kernel.org/stable/c/bb336cd8d5ecb69c430ebe3e7bcff68471d93fa8","https://git.kernel.org/stable/c/bfa9d86d39a0fe4685f90c3529aa9bd62a9d97a8","https://git.kernel.org/stable/c/dd292e884c649f9b1c18af0ec75ca90b390cd044","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46714
|
Medium |
fixed |
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.109
- 6.6.50
- 6.10.9
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Skip wbscl_set_scaler_filter if filter is null
Callers can pass null in filter (i.e. from returned from the function
wbscl_get_filter_coeffs_16p) and a null check is added to ensure that is
not the case.
This fixes 4 NULL_RETURNS issues reported by Coverity. |
["https://git.kernel.org/stable/c/0364f1f17a86d89dc39040beea4f099e60189f1b","https://git.kernel.org/stable/c/1726914cb17cedab233820d26b86764dc08857b4","https://git.kernel.org/stable/c/54834585e91cab13e9f82d3a811deb212a4df786","https://git.kernel.org/stable/c/6d94c05a13fadd80c3e732f14c83b2632ebfaa50","https://git.kernel.org/stable/c/c083c8be6bdd046049884bec076660d4ec9a19ca","https://git.kernel.org/stable/c/c4d31653c03b90e51515b1380115d1aedad925dd","https://git.kernel.org/stable/c/e3a95f29647ae45d1ec9541cd7df64f40bf2120a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46719
|
Medium |
fixed |
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.109
- 6.6.50
- 6.10.9
|
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: Fix null pointer dereference in trace
ucsi_register_altmode checks IS_ERR for the alt pointer and treats
NULL as valid. When CONFIG_TYPEC_DP_ALTMODE is not enabled,
ucsi_register_displayport returns NULL which causes a NULL pointer
dereference in trace. Rather than return NULL, call
typec_port_register_altmode to register DisplayPort alternate mode
as a non-controllable mode when CONFIG_TYPEC_DP_ALTMODE is not enabled. |
["https://git.kernel.org/stable/c/3aa56313b0de06ce1911950b2cc0c269614a87a9","https://git.kernel.org/stable/c/3b9f2d9301ae67070fe77a0c06758722fd7172b7","https://git.kernel.org/stable/c/7e64cabe81c303bdf6fd26b6a09a3289b33bc870","https://git.kernel.org/stable/c/8095bf0579ed4906a33f7bec675bfb29b6b16a3b","https://git.kernel.org/stable/c/99331fe68a8eaa4097143a33fb0c12d5e5e8e830","https://git.kernel.org/stable/c/99516f76db48e1a9d54cdfed63c1babcee4e71a5","https://git.kernel.org/stable/c/b4243c05d7e3db0bdbf9124e6fa59b4ca7c807ae"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48853
|
Medium |
fixed |
- 4.9.320
- 4.14.281
- 4.19.245
- 5.4.189
- 5.10.110
- 5.15.29
- 5.16.15
|
In the Linux kernel, the following vulnerability has been resolved:
swiotlb: fix info leak with DMA_FROM_DEVICE
The problem I'm addressing was discovered by the LTP test covering
cve-2018-1000204.
A short description of what happens follows:
1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO
interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV
and a corresponding dxferp. The peculiar thing about this is that TUR
is not reading from the device.
2) In sg_start_req() the invocation of blk_rq_map_user() effectively
bounces the user-space buffer. As if the device was to transfer into
it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in
sg_build_indirect()") we make sure this first bounce buffer is
allocated with GFP_ZERO.
3) For the rest of the story we keep ignoring that we have a TUR, so the
device won't touch the buffer we prepare as if the we had a
DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device
and the buffer allocated by SG is mapped by the function
virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here
scatter-gather and not scsi generics). This mapping involves bouncing
via the swiotlb (we need swiotlb to do virtio in protected guest like
s390 Secure Execution, or AMD SEV).
4) When the SCSI TUR is done, we first copy back the content of the second
(that is swiotlb) bounce buffer (which most likely contains some
previous IO data), to the first bounce buffer, which contains all
zeros. Then we copy back the content of the first bounce buffer to
the user-space buffer.
5) The test case detects that the buffer, which it zero-initialized,
ain't all zeros and fails.
One can argue that this is an swiotlb problem, because without swiotlb
we leak all zeros, and the swiotlb should be transparent in a sense that
it does not affect the outcome (if all other participants are well
behaved).
Copying the content of the original buffer into the swiotlb buffer is
the only way I can think of to make swiotlb transparent in such
scenarios. So let's do just that if in doubt, but allow the driver
to tell us that the whole mapped buffer is going to be overwritten,
in which case we can preserve the old behavior and avoid the performance
impact of the extra bounce. |
["https://git.kernel.org/stable/c/270475d6d2410ec66e971bf181afe1958dad565e","https://git.kernel.org/stable/c/6bfc5377a210dbda2a237f16d94d1bd4f1335026","https://git.kernel.org/stable/c/7403f4118ab94be837ab9d770507537a8057bc63","https://git.kernel.org/stable/c/8d9ac1b6665c73f23e963775f85d99679fd8e192","https://git.kernel.org/stable/c/971e5dadffd02beba1063e7dd9c3a82de17cf534","https://git.kernel.org/stable/c/c132f2ba716b5ee6b35f82226a6e5417d013d753","https://git.kernel.org/stable/c/ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e","https://git.kernel.org/stable/c/270475d6d2410ec66e971bf181afe1958dad565e","https://git.kernel.org/stable/c/6bfc5377a210dbda2a237f16d94d1bd4f1335026","https://git.kernel.org/stable/c/7403f4118ab94be837ab9d770507537a8057bc63","https://git.kernel.org/stable/c/8d9ac1b6665c73f23e963775f85d99679fd8e192","https://git.kernel.org/stable/c/971e5dadffd02beba1063e7dd9c3a82de17cf534","https://git.kernel.org/stable/c/c132f2ba716b5ee6b35f82226a6e5417d013d753","https://git.kernel.org/stable/c/d4d975e7921079f877f828099bb8260af335508f","https://git.kernel.org/stable/c/ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26826
|
Medium |
fixed |
- 5.15.149
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix data re-injection from stale subflow
When the MPTCP PM detects that a subflow is stale, all the packet
scheduler must re-inject all the mptcp-level unacked data. To avoid
acquiring unneeded locks, it first try to check if any unacked data
is present at all in the RTX queue, but such check is currently
broken, as it uses TCP-specific helper on an MPTCP socket.
Funnily enough fuzzers and static checkers are happy, as the accessed
memory still belongs to the mptcp_sock struct, and even from a
functional perspective the recovery completed successfully, as
the short-cut test always failed.
A recent unrelated TCP change - commit d5fed5addb2b ("tcp: reorganize
tcp_sock fast path variables") - exposed the issue, as the tcp field
reorganization makes the mptcp code always skip the re-inection.
Fix the issue dropping the bogus call: we are on a slow path, the early
optimization proved once again to be evil. |
["https://git.kernel.org/stable/c/624902eab7abcb8731b333ec73f206d38d839cd8","https://git.kernel.org/stable/c/6673d9f1c2cd984390550dbdf7d5ae07b20abbf8","https://git.kernel.org/stable/c/6f95120f898b40d13fd441225ef511307853c9c2","https://git.kernel.org/stable/c/b609c783c535493aa3fca22c7e40a120370b1ca5","https://git.kernel.org/stable/c/b6c620dc43ccb4e802894e54b651cf81495e9598","https://git.kernel.org/stable/c/624902eab7abcb8731b333ec73f206d38d839cd8","https://git.kernel.org/stable/c/6673d9f1c2cd984390550dbdf7d5ae07b20abbf8","https://git.kernel.org/stable/c/6f95120f898b40d13fd441225ef511307853c9c2","https://git.kernel.org/stable/c/b609c783c535493aa3fca22c7e40a120370b1ca5","https://git.kernel.org/stable/c/b6c620dc43ccb4e802894e54b651cf81495e9598"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38780
|
Medium |
fixed |
- 4.14
- 4.19.316
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.93
- 6.6.33
- 6.9.4
|
In the Linux kernel, the following vulnerability has been resolved:
dma-buf/sw-sync: don't enable IRQ from sync_print_obj()
Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from
known context") by error replaced spin_unlock_irqrestore() with
spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite
sync_print_obj() is called from sync_debugfs_show(), lockdep complains
inconsistent lock state warning.
Use plain spin_{lock,unlock}() for sync_print_obj(), for
sync_debugfs_show() is already using spin_{lock,unlock}_irq(). |
["https://git.kernel.org/stable/c/165b25e3ee9333f7b04f8db43895beacb51582ed","https://git.kernel.org/stable/c/1ff116f68560a25656933d5a18e7619cb6773d8a","https://git.kernel.org/stable/c/242b30466879e6defa521573c27e12018276c33a","https://git.kernel.org/stable/c/8a283cdfc8beeb14024387a925247b563d614e1e","https://git.kernel.org/stable/c/9d75fab2c14a25553a1664586ed122c316bd1878","https://git.kernel.org/stable/c/a4ee78244445ab73af22bfc5a5fc543963b25aef","https://git.kernel.org/stable/c/ae6fc4e6a3322f6d1c8ff59150d8469487a73dd8","https://git.kernel.org/stable/c/b794918961516f667b0c745aebdfebbb8a98df39","https://git.kernel.org/stable/c/165b25e3ee9333f7b04f8db43895beacb51582ed","https://git.kernel.org/stable/c/1ff116f68560a25656933d5a18e7619cb6773d8a","https://git.kernel.org/stable/c/242b30466879e6defa521573c27e12018276c33a","https://git.kernel.org/stable/c/8a283cdfc8beeb14024387a925247b563d614e1e","https://git.kernel.org/stable/c/9d75fab2c14a25553a1664586ed122c316bd1878","https://git.kernel.org/stable/c/a4ee78244445ab73af22bfc5a5fc543963b25aef","https://git.kernel.org/stable/c/ae6fc4e6a3322f6d1c8ff59150d8469487a73dd8","https://git.kernel.org/stable/c/b794918961516f667b0c745aebdfebbb8a98df39"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40980
|
Medium |
fixed |
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.96
- 6.6.36
- 6.9.7
|
In the Linux kernel, the following vulnerability has been resolved:
drop_monitor: replace spin_lock by raw_spin_lock
trace_drop_common() is called with preemption disabled, and it acquires
a spin_lock. This is problematic for RT kernels because spin_locks are
sleeping locks in this configuration, which causes the following splat:
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47
preempt_count: 1, expected: 0
RCU nest depth: 2, expected: 2
5 locks held by rcuc/47/449:
#0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210
#1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130
#2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210
#3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70
#4: ff1100086ee07520 (&data->lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290
irq event stamp: 139909
hardirqs last enabled at (139908): [<ffffffffb1df2b33>] _raw_spin_unlock_irqrestore+0x63/0x80
hardirqs last disabled at (139909): [<ffffffffb19bd03d>] trace_drop_common.constprop.0+0x26d/0x290
softirqs last enabled at (139892): [<ffffffffb07a1083>] __local_bh_enable_ip+0x103/0x170
softirqs last disabled at (139898): [<ffffffffb0909b33>] rcu_cpu_kthread+0x93/0x1f0
Preemption disabled at:
[<ffffffffb1de786b>] rt_mutex_slowunlock+0xab/0x2e0
CPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7
Hardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022
Call Trace:
<TASK>
dump_stack_lvl+0x8c/0xd0
dump_stack+0x14/0x20
__might_resched+0x21e/0x2f0
rt_spin_lock+0x5e/0x130
? trace_drop_common.constprop.0+0xb5/0x290
? skb_queue_purge_reason.part.0+0x1bf/0x230
trace_drop_common.constprop.0+0xb5/0x290
? preempt_count_sub+0x1c/0xd0
? _raw_spin_unlock_irqrestore+0x4a/0x80
? __pfx_trace_drop_common.constprop.0+0x10/0x10
? rt_mutex_slowunlock+0x26a/0x2e0
? skb_queue_purge_reason.part.0+0x1bf/0x230
? __pfx_rt_mutex_slowunlock+0x10/0x10
? skb_queue_purge_reason.part.0+0x1bf/0x230
trace_kfree_skb_hit+0x15/0x20
trace_kfree_skb+0xe9/0x150
kfree_skb_reason+0x7b/0x110
skb_queue_purge_reason.part.0+0x1bf/0x230
? __pfx_skb_queue_purge_reason.part.0+0x10/0x10
? mark_lock.part.0+0x8a/0x520
...
trace_drop_common() also disables interrupts, but this is a minor issue
because we could easily replace it with a local_lock.
Replace the spin_lock with raw_spin_lock to avoid sleeping in atomic
context. |
["https://git.kernel.org/stable/c/07ea878684dfb78a9d4f564c39d07e855a9e242e","https://git.kernel.org/stable/c/594e47957f3fe034645e6885393ce96c12286334","https://git.kernel.org/stable/c/76ce2f9125244e1708d29c1d3f9d1d50b347bda0","https://git.kernel.org/stable/c/96941f29ebcc1e9cbf570dc903f30374909562f5","https://git.kernel.org/stable/c/b3722fb69468693555f531cddda5c30444726dac","https://git.kernel.org/stable/c/f1e197a665c2148ebc25fe09c53689e60afea195","https://git.kernel.org/stable/c/f251ccef1d864790e5253386e95544420b7cd8f3","https://git.kernel.org/stable/c/07ea878684dfb78a9d4f564c39d07e855a9e242e","https://git.kernel.org/stable/c/594e47957f3fe034645e6885393ce96c12286334","https://git.kernel.org/stable/c/76ce2f9125244e1708d29c1d3f9d1d50b347bda0","https://git.kernel.org/stable/c/96941f29ebcc1e9cbf570dc903f30374909562f5","https://git.kernel.org/stable/c/b3722fb69468693555f531cddda5c30444726dac","https://git.kernel.org/stable/c/f1e197a665c2148ebc25fe09c53689e60afea195","https://git.kernel.org/stable/c/f251ccef1d864790e5253386e95544420b7cd8f3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40981
|
Medium |
fixed |
- 4.19.317
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.96
- 6.6.36
- 6.9.7
|
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: bypass empty buckets in batadv_purge_orig_ref()
Many syzbot reports are pointing to soft lockups in
batadv_purge_orig_ref() [1]
Root cause is unknown, but we can avoid spending too much
time there and perhaps get more interesting reports.
[1]
watchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621]
Modules linked in:
irq event stamp: 6182794
hardirqs last enabled at (6182793): [<ffff8000801dae10>] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386
hardirqs last disabled at (6182794): [<ffff80008ad66a78>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
hardirqs last disabled at (6182794): [<ffff80008ad66a78>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
softirqs last enabled at (6182792): [<ffff80008aab71c4>] spin_unlock_bh include/linux/spinlock.h:396 [inline]
softirqs last enabled at (6182792): [<ffff80008aab71c4>] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287
softirqs last disabled at (6182790): [<ffff80008aab61dc>] spin_lock_bh include/linux/spinlock.h:356 [inline]
softirqs last disabled at (6182790): [<ffff80008aab61dc>] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271
CPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
Workqueue: bat_events batadv_purge_orig
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline]
pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388
lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386
sp : ffff800099007970
x29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000
x26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001
x23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4
x20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0
x17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001
x14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003
x11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000
x8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000
x2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000
Call trace:
__daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline]
arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline]
__local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386
__raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]
_raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210
spin_unlock_bh include/linux/spinlock.h:396 [inline]
batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287
batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300
process_one_work+0x694/0x1204 kernel/workqueue.c:2633
process_scheduled_works kernel/workqueue.c:2706 [inline]
worker_thread+0x938/0xef4 kernel/workqueue.c:2787
kthread+0x288/0x310 kernel/kthread.c:388
ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
Sending NMI from CPU 0 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51
lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103
sp : ffff800093a17d30
x29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4
x26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002
x23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000
x20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396
x17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001
---truncated--- |
["https://git.kernel.org/stable/c/154e3f862ba33675cf3f4abf0a0a309a89df87d2","https://git.kernel.org/stable/c/2685008a5f9a636434a8508419cee8158a2f52c8","https://git.kernel.org/stable/c/40dc8ab605894acae1473e434944924a22cfaaa0","https://git.kernel.org/stable/c/79636f636126775436a11ee9cf00a9253a33ac11","https://git.kernel.org/stable/c/82cdea8f3af1e36543c937df963d108c60bea030","https://git.kernel.org/stable/c/92176caf9896572f00e741a93cecc0ef1172da07","https://git.kernel.org/stable/c/ae7f3cffe86aea3da0e8e079525a1ae619b8862a","https://git.kernel.org/stable/c/fed7914858a1f1f3e6350bb0f620d6ef15107d16","https://git.kernel.org/stable/c/154e3f862ba33675cf3f4abf0a0a309a89df87d2","https://git.kernel.org/stable/c/2685008a5f9a636434a8508419cee8158a2f52c8","https://git.kernel.org/stable/c/40dc8ab605894acae1473e434944924a22cfaaa0","https://git.kernel.org/stable/c/79636f636126775436a11ee9cf00a9253a33ac11","https://git.kernel.org/stable/c/82cdea8f3af1e36543c937df963d108c60bea030","https://git.kernel.org/stable/c/92176caf9896572f00e741a93cecc0ef1172da07","https://git.kernel.org/stable/c/ae7f3cffe86aea3da0e8e079525a1ae619b8862a","https://git.kernel.org/stable/c/fed7914858a1f1f3e6350bb0f620d6ef15107d16"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41063
|
Medium |
fixed |
- 4.19.319
- 5.4.281
- 5.10.223
- 5.15.164
- 6.1.101
- 6.6.42
- 6.9.11
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_core: cancel all works upon hci_unregister_dev()
syzbot is reporting that calling hci_release_dev() from hci_error_reset()
due to hci_dev_put() from hci_error_reset() can cause deadlock at
destroy_workqueue(), for hci_error_reset() is called from
hdev->req_workqueue which destroy_workqueue() needs to flush.
We need to make sure that hdev->{rx_work,cmd_work,tx_work} which are
queued into hdev->workqueue and hdev->{power_on,error_reset} which are
queued into hdev->req_workqueue are no longer running by the moment
destroy_workqueue(hdev->workqueue);
destroy_workqueue(hdev->req_workqueue);
are called from hci_release_dev().
Call cancel_work_sync() on these work items from hci_unregister_dev()
as soon as hdev->list is removed from hci_dev_list. |
["https://git.kernel.org/stable/c/0d151a103775dd9645c78c97f77d6e2a5298d913","https://git.kernel.org/stable/c/3f939bd73fed12dddc2a32a76116c19ca47c7678","https://git.kernel.org/stable/c/48542881997e17b49dc16b93fe910e0cfcf7a9f9","https://git.kernel.org/stable/c/96600c2e5ee8213dbab5df1617293d8e847bb4fa","https://git.kernel.org/stable/c/9cfc84b1d464cc024286f42a090718f9067b80ed","https://git.kernel.org/stable/c/d2ce562a5aff1dcd0c50d9808ea825ef90da909f","https://git.kernel.org/stable/c/d6cbce18370641a21dd889e8613d8153df15eb39","https://git.kernel.org/stable/c/ddeda6ca5f218b668b560d90fc31ae469adbfd92","https://git.kernel.org/stable/c/0d151a103775dd9645c78c97f77d6e2a5298d913","https://git.kernel.org/stable/c/3f939bd73fed12dddc2a32a76116c19ca47c7678","https://git.kernel.org/stable/c/48542881997e17b49dc16b93fe910e0cfcf7a9f9","https://git.kernel.org/stable/c/96600c2e5ee8213dbab5df1617293d8e847bb4fa","https://git.kernel.org/stable/c/9cfc84b1d464cc024286f42a090718f9067b80ed","https://git.kernel.org/stable/c/d2ce562a5aff1dcd0c50d9808ea825ef90da909f","https://git.kernel.org/stable/c/d6cbce18370641a21dd889e8613d8153df15eb39","https://git.kernel.org/stable/c/ddeda6ca5f218b668b560d90fc31ae469adbfd92"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42153
|
Medium |
fixed |
- 4.19.318
- 5.4.280
- 5.10.222
- 5.15.163
- 6.1.98
- 6.6.39
- 6.9.9
|
In the Linux kernel, the following vulnerability has been resolved:
i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr
When del_timer_sync() is called in an interrupt context it throws a warning
because of potential deadlock. The timer is used only to exit from
wait_for_completion() after a timeout so replacing the call with
wait_for_completion_timeout() allows to remove the problematic timer and
its related functions altogether. |
["https://git.kernel.org/stable/c/27cd3873fa76ebeb9f948baae40cb9a6d8692289","https://git.kernel.org/stable/c/2849a1b747cf37aa5b684527104d3a53f1e296d2","https://git.kernel.org/stable/c/3503372d0bf7b324ec0bd6b90606703991426176","https://git.kernel.org/stable/c/3d32327f5cfc087ee3922a3bcdcc29880dcdb50f","https://git.kernel.org/stable/c/92e494a7568b60ae80d57fc0deafcaf3a4029ab3","https://git.kernel.org/stable/c/a349e5ab4dc9954746e836cd10b407ce48f9b2f6","https://git.kernel.org/stable/c/effe0500afda017a86c94482b1e36bc37586c9af","https://git.kernel.org/stable/c/f63b94be6942ba82c55343e196bd09b53227618e","https://git.kernel.org/stable/c/27cd3873fa76ebeb9f948baae40cb9a6d8692289","https://git.kernel.org/stable/c/2849a1b747cf37aa5b684527104d3a53f1e296d2","https://git.kernel.org/stable/c/3503372d0bf7b324ec0bd6b90606703991426176","https://git.kernel.org/stable/c/3d32327f5cfc087ee3922a3bcdcc29880dcdb50f","https://git.kernel.org/stable/c/92e494a7568b60ae80d57fc0deafcaf3a4029ab3","https://git.kernel.org/stable/c/a349e5ab4dc9954746e836cd10b407ce48f9b2f6","https://git.kernel.org/stable/c/effe0500afda017a86c94482b1e36bc37586c9af","https://git.kernel.org/stable/c/f63b94be6942ba82c55343e196bd09b53227618e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48972
|
Medium |
fixed |
- 4.9.336
- 4.14.302
- 4.19.269
- 5.4.227
- 5.10.159
- 5.15.83
- 6.0.13
|
In the Linux kernel, the following vulnerability has been resolved:
mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add()
Kernel fault injection test reports null-ptr-deref as follows:
BUG: kernel NULL pointer dereference, address: 0000000000000008
RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114
Call Trace:
<TASK>
raw_notifier_call_chain+0x6d/0xa0 kernel/notifier.c:87
call_netdevice_notifiers_info+0x6e/0xc0 net/core/dev.c:1944
unregister_netdevice_many_notify+0x60d/0xcb0 net/core/dev.c:1982
unregister_netdevice_queue+0x154/0x1a0 net/core/dev.c:10879
register_netdevice+0x9a8/0xb90 net/core/dev.c:10083
ieee802154_if_add+0x6ed/0x7e0 net/mac802154/iface.c:659
ieee802154_register_hw+0x29c/0x330 net/mac802154/main.c:229
mcr20a_probe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316
ieee802154_if_add() allocates wpan_dev as netdev's private data, but not
init the list in struct wpan_dev. cfg802154_netdev_notifier_call() manage
the list when device register/unregister, and may lead to null-ptr-deref.
Use INIT_LIST_HEAD() on it to initialize it correctly. |
["https://git.kernel.org/stable/c/1831d4540406708e48239cf38fd9c3b7ea98e08f","https://git.kernel.org/stable/c/42c319635c0cf7eb36eccac6cda76532f47b61a3","https://git.kernel.org/stable/c/623918f40fa68e3bb21312a3fafb90f491bf5358","https://git.kernel.org/stable/c/7410f4d1221bb182510b7778ab6eefa8b9b7102d","https://git.kernel.org/stable/c/9980a3ea20de40c83817877106c909cb032692d2","https://git.kernel.org/stable/c/a110287ef4a423980309490df632e1c1e73b3dc9","https://git.kernel.org/stable/c/b3d72d3135d2ef68296c1ee174436efd65386f04","https://git.kernel.org/stable/c/f00c84fb1635c27ba24ec5df65d5bd7d7dc00008"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49002
|
Medium |
fixed |
- 4.9.335
- 4.14.301
- 4.19.268
- 5.4.226
- 5.10.158
- 5.15.82
- 6.0.12
|
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init()
for_each_pci_dev() is implemented by pci_get_device(). The comment of
pci_get_device() says that it will increase the reference count for the
returned pci_dev and also decrease the reference count for the input
pci_dev @from if it is not NULL.
If we break for_each_pci_dev() loop with pdev not NULL, we need to call
pci_dev_put() to decrease the reference count. Add the missing
pci_dev_put() for the error path to avoid reference count leak. |
["https://git.kernel.org/stable/c/2a8f7b90681472948de172dbbf5a54cd342870aa","https://git.kernel.org/stable/c/4bedbbd782ebbe7287231fea862c158d4f08a9e3","https://git.kernel.org/stable/c/71c4a621985fc051ab86d3a86c749069a993fcb2","https://git.kernel.org/stable/c/876d7bfb89273997056220029ff12b1c2cc4691d","https://git.kernel.org/stable/c/a5c65cd56aed027f8a97fda8b691caaeb66d115e","https://git.kernel.org/stable/c/bdb613ef179ad4bb9d56a2533e9b30e434f1dfb7","https://git.kernel.org/stable/c/cbdd83bd2fd67142b03ce9dbdd1eab322ff7321f","https://git.kernel.org/stable/c/d47bc9d7bcdbb9adc9703513d964b514fee5b0bf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50061
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition
In the cdns_i3c_master_probe function, &master->hj_work is bound with
cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call
cnds_i3c_master_demux_ibis function to start the work.
If we remove the module which will call cdns_i3c_master_remove to
make cleanup, it will free master->base through i3c_master_unregister
while the work mentioned above will be used. The sequence of operations
that may lead to a UAF bug is as follows:
CPU0 CPU1
| cdns_i3c_master_hj
cdns_i3c_master_remove |
i3c_master_unregister(&master->base) |
device_unregister(&master->dev) |
device_release |
//free master->base |
| i3c_master_do_daa(&master->base)
| //use master->base
Fix it by ensuring that the work is canceled before proceeding with
the cleanup in cdns_i3c_master_remove. |
["https://git.kernel.org/stable/c/2a21bad9964c91b34d65ba269914233720c0b1ce","https://git.kernel.org/stable/c/609366e7a06d035990df78f1562291c3bf0d4a12","https://git.kernel.org/stable/c/687016d6a1efbfacdd2af913e2108de6b75a28d5","https://git.kernel.org/stable/c/ea0256e393e0072e8c80fd941547807f0c28108b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50086
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix user-after-free from session log off
There is racy issue between smb2 session log off and smb2 session setup.
It will cause user-after-free from session log off.
This add session_lock when setting SMB2_SESSION_EXPIRED and referece
count to session struct not to free session while it is being used. |
["https://git.kernel.org/stable/c/0f62358ce85b2d4c949ef1b648be01b29cec667a","https://git.kernel.org/stable/c/5511999e9615e4318e9142d23b29bd1597befc08","https://git.kernel.org/stable/c/7aa8804c0b67b3cb263a472d17f2cb50d7f1a930","https://git.kernel.org/stable/c/a9839c37fd813b432988f58a9d9dd59253d3eb2c","https://git.kernel.org/stable/c/ee371898b53a9b9b51c02d22a8c31bfb86d45f0d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48899
|
Medium |
fixed |
- 4.19.270
- 5.4.229
- 5.10.164
- 5.15.89
- 6.1.7
|
In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: Fix GEM handle creation UAF
Userspace can guess the handle value and try to race GEM object creation
with handle close, resulting in a use-after-free if we dereference the
object after dropping the handle's reference. For that reason, dropping
the handle's reference must be done *after* we are done dereferencing
the object. |
["https://git.kernel.org/stable/c/011ecdbcd520c90c344b872ca6b4821f7783b2f8","https://git.kernel.org/stable/c/19ec87d06acfab2313ee82b2a689bf0c154e57ea","https://git.kernel.org/stable/c/52531258318ed59a2dc5a43df2eaf0eb1d65438e","https://git.kernel.org/stable/c/68bcd063857075d2f9edfed6024387ac377923e2","https://git.kernel.org/stable/c/adc48e5e408afbb01d261bd303fd9fbbbaa3e317","https://git.kernel.org/stable/c/d01d6d2b06c0d8390adf8f3ba08aa60b5642ef73"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3239
|
High |
fixed |
- 4.14.295
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
A flaw use after free in the Linux kernel video4linux driver was found in the way user triggers em28xx_usb_probe() for the Empia 28xx based TV cards. A local user could use this flaw to crash the system or potentially escalate their privileges on the system. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c08eadca1bdfa099e20a32f8fa4b52b2f672236d","https://security.netapp.com/advisory/ntap-20230214-0006/","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c08eadca1bdfa099e20a32f8fa4b52b2f672236d","https://security.netapp.com/advisory/ntap-20230214-0006/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49960
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix timer use-after-free on failed mount
Syzbot has found an ODEBUG bug in ext4_fill_super
The del_timer_sync function cancels the s_err_report timer,
which reminds about filesystem errors daily. We should
guarantee the timer is no longer active before kfree(sbi).
When filesystem mounting fails, the flow goes to failed_mount3,
where an error occurs when ext4_stop_mmpd is called, causing
a read I/O failure. This triggers the ext4_handle_error function
that ultimately re-arms the timer,
leaving the s_err_report timer active before kfree(sbi) is called.
Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd. |
["https://git.kernel.org/stable/c/0ce160c5bdb67081a62293028dc85758a8efb22a","https://git.kernel.org/stable/c/22e9b83f0f33bc5a7a3181769d1dccbf021f5b04","https://git.kernel.org/stable/c/7aac0c17a8cdf4a3236991c1e60435c6a984076c","https://git.kernel.org/stable/c/9203817ba46ebba7c865c8de2aba399537b6e891","https://git.kernel.org/stable/c/b85569585d0154d4db1e4f9e3e6a4731d407feb0","https://git.kernel.org/stable/c/cf3196e5e2f36cd80dab91ffae402e13935724bc","https://git.kernel.org/stable/c/fa78fb51d396f4f2f80f8e96a3b1516f394258be"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49989
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: fix double free issue during amdgpu module unload
Flexible endpoints use DIGs from available inflexible endpoints,
so only the encoders of inflexible links need to be freed.
Otherwise, a double free issue may occur when unloading the
amdgpu module.
[ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0
[ 279.190577] Call Trace:
[ 279.190580] <TASK>
[ 279.190582] ? show_regs+0x69/0x80
[ 279.190590] ? die+0x3b/0x90
[ 279.190595] ? do_trap+0xc8/0xe0
[ 279.190601] ? do_error_trap+0x73/0xa0
[ 279.190605] ? __slab_free+0x152/0x2f0
[ 279.190609] ? exc_invalid_op+0x56/0x70
[ 279.190616] ? __slab_free+0x152/0x2f0
[ 279.190642] ? asm_exc_invalid_op+0x1f/0x30
[ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu]
[ 279.191096] ? __slab_free+0x152/0x2f0
[ 279.191102] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu]
[ 279.191469] kfree+0x260/0x2b0
[ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu]
[ 279.191821] link_destroy+0xd7/0x130 [amdgpu]
[ 279.192248] dc_destruct+0x90/0x270 [amdgpu]
[ 279.192666] dc_destroy+0x19/0x40 [amdgpu]
[ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu]
[ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu]
[ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu]
[ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu]
[ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu]
[ 279.194632] pci_device_remove+0x3a/0xa0
[ 279.194638] device_remove+0x40/0x70
[ 279.194642] device_release_driver_internal+0x1ad/0x210
[ 279.194647] driver_detach+0x4e/0xa0
[ 279.194650] bus_remove_driver+0x6f/0xf0
[ 279.194653] driver_unregister+0x33/0x60
[ 279.194657] pci_unregister_driver+0x44/0x90
[ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu]
[ 279.194939] __do_sys_delete_module.isra.0+0x198/0x2f0
[ 279.194946] __x64_sys_delete_module+0x16/0x20
[ 279.194950] do_syscall_64+0x58/0x120
[ 279.194954] entry_SYSCALL_64_after_hwframe+0x6e/0x76
[ 279.194980] </TASK> |
["https://git.kernel.org/stable/c/20b5a8f9f4670a8503aa9fa95ca632e77c6bf55d","https://git.kernel.org/stable/c/3c0ff4de45ce2c5f7997a1ffa6eefee4b79e6b58","https://git.kernel.org/stable/c/43c296870740a3a264cdca9f18db12e12e9cfbdb","https://git.kernel.org/stable/c/7af9e6fa63dbd43a61d4ecc8f59426596a75e507","https://git.kernel.org/stable/c/cf6f3ebd6312d465fee096d1f58089b177c7c67f","https://git.kernel.org/stable/c/df948b5ba6858d5da34f622d408e5517057cec07"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50047
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix UAF in async decryption
Doing an async decryption (large read) crashes with a
slab-use-after-free way down in the crypto API.
Reproducer:
# mount.cifs -o ...,seal,esize=1 //srv/share /mnt
# dd if=/mnt/largefile of=/dev/null
...
[ 194.196391] ==================================================================
[ 194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110
[ 194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899
[ 194.197707]
[ 194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43
[ 194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014
[ 194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs]
[ 194.200032] Call Trace:
[ 194.200191] <TASK>
[ 194.200327] dump_stack_lvl+0x4e/0x70
[ 194.200558] ? gf128mul_4k_lle+0xc1/0x110
[ 194.200809] print_report+0x174/0x505
[ 194.201040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 194.201352] ? srso_return_thunk+0x5/0x5f
[ 194.201604] ? __virt_addr_valid+0xdf/0x1c0
[ 194.201868] ? gf128mul_4k_lle+0xc1/0x110
[ 194.202128] kasan_report+0xc8/0x150
[ 194.202361] ? gf128mul_4k_lle+0xc1/0x110
[ 194.202616] gf128mul_4k_lle+0xc1/0x110
[ 194.202863] ghash_update+0x184/0x210
[ 194.203103] shash_ahash_update+0x184/0x2a0
[ 194.203377] ? __pfx_shash_ahash_update+0x10/0x10
[ 194.203651] ? srso_return_thunk+0x5/0x5f
[ 194.203877] ? crypto_gcm_init_common+0x1ba/0x340
[ 194.204142] gcm_hash_assoc_remain_continue+0x10a/0x140
[ 194.204434] crypt_message+0xec1/0x10a0 [cifs]
[ 194.206489] ? __pfx_crypt_message+0x10/0x10 [cifs]
[ 194.208507] ? srso_return_thunk+0x5/0x5f
[ 194.209205] ? srso_return_thunk+0x5/0x5f
[ 194.209925] ? srso_return_thunk+0x5/0x5f
[ 194.210443] ? srso_return_thunk+0x5/0x5f
[ 194.211037] decrypt_raw_data+0x15f/0x250 [cifs]
[ 194.212906] ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]
[ 194.214670] ? srso_return_thunk+0x5/0x5f
[ 194.215193] smb2_decrypt_offload+0x12a/0x6c0 [cifs]
This is because TFM is being used in parallel.
Fix this by allocating a new AEAD TFM for async decryption, but keep
the existing one for synchronous READ cases (similar to what is done
in smb3_calc_signature()).
Also remove the calls to aead_request_set_callback() and
crypto_wait_req() since it's always going to be a synchronous operation. |
["https://git.kernel.org/stable/c/0809fb86ad13b29e1d6d491364fc7ea4fb545995","https://git.kernel.org/stable/c/538c26d9bf70c90edc460d18c81008a4e555925a","https://git.kernel.org/stable/c/8f14a476abba13144df5434871a7225fd29af633","https://git.kernel.org/stable/c/b0abcd65ec545701b8793e12bc27dc98042b151a","https://git.kernel.org/stable/c/bce966530fd5542bbb422cb45ecb775f7a1a6bc3","https://git.kernel.org/stable/c/ef51c0d544b1518b35364480317ab6d3468f205d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21680
|
High |
fixed |
- 5.15.177
- 6.1.127
- 6.6.74
- 6.12.11
|
In the Linux kernel, the following vulnerability has been resolved:
pktgen: Avoid out-of-bounds access in get_imix_entries
Passing a sufficient amount of imix entries leads to invalid access to the
pkt_dev->imix_entries array because of the incorrect boundary check.
UBSAN: array-index-out-of-bounds in net/core/pktgen.c:874:24
index 20 is out of range for type 'imix_pkt [20]'
CPU: 2 PID: 1210 Comm: bash Not tainted 6.10.0-rc1 #121
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Call Trace:
<TASK>
dump_stack_lvl lib/dump_stack.c:117
__ubsan_handle_out_of_bounds lib/ubsan.c:429
get_imix_entries net/core/pktgen.c:874
pktgen_if_write net/core/pktgen.c:1063
pde_write fs/proc/inode.c:334
proc_reg_write fs/proc/inode.c:346
vfs_write fs/read_write.c:593
ksys_write fs/read_write.c:644
do_syscall_64 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:130
Found by Linux Verification Center (linuxtesting.org) with SVACE.
[ fp: allow to fill the array completely; minor changelog cleanup ] |
["https://git.kernel.org/stable/c/1a9b65c672ca9dc4ba52ca2fd54329db9580ce29","https://git.kernel.org/stable/c/3450092cc2d1c311c5ea92a2486daa2a33520ea5","https://git.kernel.org/stable/c/76201b5979768500bca362871db66d77cb4c225e","https://git.kernel.org/stable/c/7cde21f52042aa2e29a654458166b873d2ae66b3","https://git.kernel.org/stable/c/e5d24a7074dcd0c7e76b7e7e4efbbe7418d62486"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49991
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer
Pass pointer reference to amdgpu_bo_unref to clear the correct pointer,
otherwise amdgpu_bo_unref clear the local variable, the original pointer
not set to NULL, this could cause use-after-free bug. |
["https://git.kernel.org/stable/c/30ceb873cc2e97348d9da2265b2d1ddf07f682e1","https://git.kernel.org/stable/c/6c9289806591807e4e3be9a23df8ee2069180055","https://git.kernel.org/stable/c/71f3240f82987f0f070ea5bed559033de7d4c0e1","https://git.kernel.org/stable/c/c86ad39140bbcb9dc75a10046c2221f657e8083b","https://git.kernel.org/stable/c/e7831613cbbcd9058d3658fbcdc5d5884ceb2e0c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53061
|
High |
fixed |
- 4.19.324
- 5.4.286
- 5.10.230
- 5.15.172
- 6.1.117
- 6.6.61
- 6.11.8
|
In the Linux kernel, the following vulnerability has been resolved:
media: s5p-jpeg: prevent buffer overflows
The current logic allows word to be less than 2. If this happens,
there will be buffer overflows, as reported by smatch. Add extra
checks to prevent it.
While here, remove an unused word = 0 assignment. |
["https://git.kernel.org/stable/c/14a22762c3daeac59a5a534e124acbb4d7a79b3a","https://git.kernel.org/stable/c/784bc785a453eb2f8433dd62075befdfa1b2d6fd","https://git.kernel.org/stable/c/a930cddfd153b5d4401df0c01effa14c831ff21e","https://git.kernel.org/stable/c/c5f6fefcda8fac8f082b6c5bf416567f4e100c51","https://git.kernel.org/stable/c/c85db2d4432de4ff9d97006691ce2dcb5bda660e","https://git.kernel.org/stable/c/c951a0859fdacf49a2298b5551a7e52b95ff6f51","https://git.kernel.org/stable/c/e5117f6e7adcf9fd7546cdd0edc9abe4474bc98b","https://git.kernel.org/stable/c/f54e8e1e39dacccebcfb9a9a36f0552a0a97e2ef"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48954
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
s390/qeth: fix use-after-free in hsci
KASAN found that addr was dereferenced after br2dev_event_work was freed.
==================================================================
BUG: KASAN: use-after-free in qeth_l2_br2dev_worker+0x5ba/0x6b0
Read of size 1 at addr 00000000fdcea440 by task kworker/u760:4/540
CPU: 17 PID: 540 Comm: kworker/u760:4 Tainted: G E 6.1.0-20221128.rc7.git1.5aa3bed4ce83.300.fc36.s390x+kasan #1
Hardware name: IBM 8561 T01 703 (LPAR)
Workqueue: 0.0.8000_event qeth_l2_br2dev_worker
Call Trace:
[<000000016944d4ce>] dump_stack_lvl+0xc6/0xf8
[<000000016942cd9c>] print_address_description.constprop.0+0x34/0x2a0
[<000000016942d118>] print_report+0x110/0x1f8
[<0000000167a7bd04>] kasan_report+0xfc/0x128
[<000000016938d79a>] qeth_l2_br2dev_worker+0x5ba/0x6b0
[<00000001673edd1e>] process_one_work+0x76e/0x1128
[<00000001673ee85c>] worker_thread+0x184/0x1098
[<000000016740718a>] kthread+0x26a/0x310
[<00000001672c606a>] __ret_from_fork+0x8a/0xe8
[<00000001694711da>] ret_from_fork+0xa/0x40
Allocated by task 108338:
kasan_save_stack+0x40/0x68
kasan_set_track+0x36/0x48
__kasan_kmalloc+0xa0/0xc0
qeth_l2_switchdev_event+0x25a/0x738
atomic_notifier_call_chain+0x9c/0xf8
br_switchdev_fdb_notify+0xf4/0x110
fdb_notify+0x122/0x180
fdb_add_entry.constprop.0.isra.0+0x312/0x558
br_fdb_add+0x59e/0x858
rtnl_fdb_add+0x58a/0x928
rtnetlink_rcv_msg+0x5f8/0x8d8
netlink_rcv_skb+0x1f2/0x408
netlink_unicast+0x570/0x790
netlink_sendmsg+0x752/0xbe0
sock_sendmsg+0xca/0x110
____sys_sendmsg+0x510/0x6a8
___sys_sendmsg+0x12a/0x180
__sys_sendmsg+0xe6/0x168
__do_sys_socketcall+0x3c8/0x468
do_syscall+0x22c/0x328
__do_syscall+0x94/0xf0
system_call+0x82/0xb0
Freed by task 540:
kasan_save_stack+0x40/0x68
kasan_set_track+0x36/0x48
kasan_save_free_info+0x4c/0x68
____kasan_slab_free+0x14e/0x1a8
__kasan_slab_free+0x24/0x30
__kmem_cache_free+0x168/0x338
qeth_l2_br2dev_worker+0x154/0x6b0
process_one_work+0x76e/0x1128
worker_thread+0x184/0x1098
kthread+0x26a/0x310
__ret_from_fork+0x8a/0xe8
ret_from_fork+0xa/0x40
Last potentially related work creation:
kasan_save_stack+0x40/0x68
__kasan_record_aux_stack+0xbe/0xd0
insert_work+0x56/0x2e8
__queue_work+0x4ce/0xd10
queue_work_on+0xf4/0x100
qeth_l2_switchdev_event+0x520/0x738
atomic_notifier_call_chain+0x9c/0xf8
br_switchdev_fdb_notify+0xf4/0x110
fdb_notify+0x122/0x180
fdb_add_entry.constprop.0.isra.0+0x312/0x558
br_fdb_add+0x59e/0x858
rtnl_fdb_add+0x58a/0x928
rtnetlink_rcv_msg+0x5f8/0x8d8
netlink_rcv_skb+0x1f2/0x408
netlink_unicast+0x570/0x790
netlink_sendmsg+0x752/0xbe0
sock_sendmsg+0xca/0x110
____sys_sendmsg+0x510/0x6a8
___sys_sendmsg+0x12a/0x180
__sys_sendmsg+0xe6/0x168
__do_sys_socketcall+0x3c8/0x468
do_syscall+0x22c/0x328
__do_syscall+0x94/0xf0
system_call+0x82/0xb0
Second to last potentially related work creation:
kasan_save_stack+0x40/0x68
__kasan_record_aux_stack+0xbe/0xd0
kvfree_call_rcu+0xb2/0x760
kernfs_unlink_open_file+0x348/0x430
kernfs_fop_release+0xc2/0x320
__fput+0x1ae/0x768
task_work_run+0x1bc/0x298
exit_to_user_mode_prepare+0x1a0/0x1a8
__do_syscall+0x94/0xf0
system_call+0x82/0xb0
The buggy address belongs to the object at 00000000fdcea400
which belongs to the cache kmalloc-96 of size 96
The buggy address is located 64 bytes inside of
96-byte region [00000000fdcea400, 00000000fdcea460)
The buggy address belongs to the physical page:
page:000000005a9c26e8 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xfdcea
flags: 0x3ffff00000000200(slab|node=0|zone=1|lastcpupid=0x1ffff)
raw: 3ffff00000000200 0000000000000000 0000000100000122 000000008008cc00
raw: 0000000000000000 0020004100000000 ffffffff00000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
00000000fdcea300: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
00000000fdcea380: fb fb fb fb fb fb f
---truncated--- |
["https://git.kernel.org/stable/c/bde0dfc7c4569406a6ddeec363d04a1df7b3073f","https://git.kernel.org/stable/c/db6343a5b0d9661f2dd76f653c6d274d38234d2b","https://git.kernel.org/stable/c/ebaaadc332cd21e9df4dcf9ce12552d9354bbbe4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46828
|
High |
fixed |
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
sched: sch_cake: fix bulk flow accounting logic for host fairness
In sch_cake, we keep track of the count of active bulk flows per host,
when running in dst/src host fairness mode, which is used as the
round-robin weight when iterating through flows. The count of active
bulk flows is updated whenever a flow changes state.
This has a peculiar interaction with the hash collision handling: when a
hash collision occurs (after the set-associative hashing), the state of
the hash bucket is simply updated to match the new packet that collided,
and if host fairness is enabled, that also means assigning new per-host
state to the flow. For this reason, the bulk flow counters of the
host(s) assigned to the flow are decremented, before new state is
assigned (and the counters, which may not belong to the same host
anymore, are incremented again).
Back when this code was introduced, the host fairness mode was always
enabled, so the decrement was unconditional. When the configuration
flags were introduced the *increment* was made conditional, but
the *decrement* was not. Which of course can lead to a spurious
decrement (and associated wrap-around to U16_MAX).
AFAICT, when host fairness is disabled, the decrement and wrap-around
happens as soon as a hash collision occurs (which is not that common in
itself, due to the set-associative hashing). However, in most cases this
is harmless, as the value is only used when host fairness mode is
enabled. So in order to trigger an array overflow, sch_cake has to first
be configured with host fairness disabled, and while running in this
mode, a hash collision has to occur to cause the overflow. Then, the
qdisc has to be reconfigured to enable host fairness, which leads to the
array out-of-bounds because the wrapped-around value is retained and
used as an array index. It seems that syzbot managed to trigger this,
which is quite impressive in its own right.
This patch fixes the issue by introducing the same conditional check on
decrement as is used on increment.
The original bug predates the upstreaming of cake, but the commit listed
in the Fixes tag touched that code, meaning that this patch won't apply
before that. |
["https://git.kernel.org/stable/c/4a4eeefa514db570be025ab46d779af180e2c9bb","https://git.kernel.org/stable/c/546ea84d07e3e324644025e2aae2d12ea4c5896e","https://git.kernel.org/stable/c/549e407569e08459d16122341d332cb508024094","https://git.kernel.org/stable/c/7725152b54d295b7da5e34c2f419539b30d017bd","https://git.kernel.org/stable/c/cde71a5677971f4f1b69b25e854891dbe78066a4","https://git.kernel.org/stable/c/d4a9039a7b3d8005b90c7b1a55a306444f0e5447","https://git.kernel.org/stable/c/d7c01c0714c04431b5e18cf17a9ea68a553d1c3c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49287
|
High |
fixed |
- 4.14.276
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.1
|
In the Linux kernel, the following vulnerability has been resolved:
tpm: fix reference counting for struct tpm_chip
The following sequence of operations results in a refcount warning:
1. Open device /dev/tpmrm.
2. Remove module tpm_tis_spi.
3. Write a TPM command to the file descriptor opened at step 1.
------------[ cut here ]------------
WARNING: CPU: 3 PID: 1161 at lib/refcount.c:25 kobject_get+0xa0/0xa4
refcount_t: addition on 0; use-after-free.
Modules linked in: tpm_tis_spi tpm_tis_core tpm mdio_bcm_unimac brcmfmac
sha256_generic libsha256 sha256_arm hci_uart btbcm bluetooth cfg80211 vc4
brcmutil ecdh_generic ecc snd_soc_core crc32_arm_ce libaes
raspberrypi_hwmon ac97_bus snd_pcm_dmaengine bcm2711_thermal snd_pcm
snd_timer genet snd phy_generic soundcore [last unloaded: spi_bcm2835]
CPU: 3 PID: 1161 Comm: hold_open Not tainted 5.10.0ls-main-dirty #2
Hardware name: BCM2711
[<c0410c3c>] (unwind_backtrace) from [<c040b580>] (show_stack+0x10/0x14)
[<c040b580>] (show_stack) from [<c1092174>] (dump_stack+0xc4/0xd8)
[<c1092174>] (dump_stack) from [<c0445a30>] (__warn+0x104/0x108)
[<c0445a30>] (__warn) from [<c0445aa8>] (warn_slowpath_fmt+0x74/0xb8)
[<c0445aa8>] (warn_slowpath_fmt) from [<c08435d0>] (kobject_get+0xa0/0xa4)
[<c08435d0>] (kobject_get) from [<bf0a715c>] (tpm_try_get_ops+0x14/0x54 [tpm])
[<bf0a715c>] (tpm_try_get_ops [tpm]) from [<bf0a7d6c>] (tpm_common_write+0x38/0x60 [tpm])
[<bf0a7d6c>] (tpm_common_write [tpm]) from [<c05a7ac0>] (vfs_write+0xc4/0x3c0)
[<c05a7ac0>] (vfs_write) from [<c05a7ee4>] (ksys_write+0x58/0xcc)
[<c05a7ee4>] (ksys_write) from [<c04001a0>] (ret_fast_syscall+0x0/0x4c)
Exception stack(0xc226bfa8 to 0xc226bff0)
bfa0: 00000000 000105b4 00000003 beafe664 00000014 00000000
bfc0: 00000000 000105b4 000103f8 00000004 00000000 00000000 b6f9c000 beafe684
bfe0: 0000006c beafe648 0001056c b6eb6944
---[ end trace d4b8409def9b8b1f ]---
The reason for this warning is the attempt to get the chip->dev reference
in tpm_common_write() although the reference counter is already zero.
Since commit 8979b02aaf1d ("tpm: Fix reference count to main device") the
extra reference used to prevent a premature zero counter is never taken,
because the required TPM_CHIP_FLAG_TPM2 flag is never set.
Fix this by moving the TPM 2 character device handling from
tpm_chip_alloc() to tpm_add_char_device() which is called at a later point
in time when the flag has been set in case of TPM2.
Commit fdc915f7f719 ("tpm: expose spaces via a device link /dev/tpmrm<n>")
already introduced function tpm_devs_release() to release the extra
reference but did not implement the required put on chip->devs that results
in the call of this function.
Fix this by putting chip->devs in tpm_chip_unregister().
Finally move the new implementation for the TPM 2 handling into a new
function to avoid multiple checks for the TPM_CHIP_FLAG_TPM2 flag in the
good case and error cases. |
["https://git.kernel.org/stable/c/290e05f346d1829e849662c97e42d5ad984f5258","https://git.kernel.org/stable/c/2f928c0d5c02dbab49e8c19d98725c822f6fc409","https://git.kernel.org/stable/c/473a66f99cb8173c14138c5a5c69bfad04e8f9ac","https://git.kernel.org/stable/c/662893b4f6bd466ff9e1cd454c44c26d32d554fe","https://git.kernel.org/stable/c/6e7baf84149fb43950631415de231b3a41915aa3","https://git.kernel.org/stable/c/7e0438f83dc769465ee663bb5dcf8cc154940712","https://git.kernel.org/stable/c/a27ed2f3695baf15f9b34d2d7a1f9fc105539a81","https://git.kernel.org/stable/c/cb64bd038beacb4331fe464a36c8b5481e8f51e2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56786
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: put bpf_link's program when link is safe to be deallocated
In general, BPF link's underlying BPF program should be considered to be
reachable through attach hook -> link -> prog chain, and, pessimistically,
we have to assume that as long as link's memory is not safe to free,
attach hook's code might hold a pointer to BPF program and use it.
As such, it's not (generally) correct to put link's program early before
waiting for RCU GPs to go through. More eager bpf_prog_put() that we
currently do is mostly correct due to BPF program's release code doing
similar RCU GP waiting, but as will be shown in the following patches,
BPF program can be non-sleepable (and, thus, reliant on only "classic"
RCU GP), while BPF link's attach hook can have sleepable semantics and
needs to be protected by RCU Tasks Trace, and for such cases BPF link
has to go through RCU Tasks Trace + "classic" RCU GPs before being
deallocated. And so, if we put BPF program early, we might free BPF
program before we free BPF link, leading to use-after-free situation.
So, this patch defers bpf_prog_put() until we are ready to perform
bpf_link's deallocation. At worst, this delays BPF program freeing by
one extra RCU GP, but that seems completely acceptable. Alternatively,
we'd need more elaborate ways to determine BPF hook, BPF link, and BPF
program lifetimes, and how they relate to each other, which seems like
an unnecessary complication.
Note, for most BPF links we still will perform eager bpf_prog_put() and
link dealloc, so for those BPF links there are no observable changes
whatsoever. Only BPF links that use deferred dealloc might notice
slightly delayed freeing of BPF programs.
Also, to reduce code and logic duplication, extract program put + link
dealloc logic into bpf_link_dealloc() helper. |
["https://git.kernel.org/stable/c/2fcb921c2799c49ac5e365cf4110f94a64ae4885","https://git.kernel.org/stable/c/5fe23c57abadfd46a7a66e81f3536e4757252a0b","https://git.kernel.org/stable/c/f44ec8733a8469143fde1984b5e6931b2e2f6f3f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42230
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Fix scv instruction crash with kexec
kexec on pseries disables AIL (reloc_on_exc), required for scv
instruction support, before other CPUs have been shut down. This means
they can execute scv instructions after AIL is disabled, which causes an
interrupt at an unexpected entry location that crashes the kernel.
Change the kexec sequence to disable AIL after other CPUs have been
brought down.
As a refresher, the real-mode scv interrupt vector is 0x17000, and the
fixed-location head code probably couldn't easily deal with implementing
such high addresses so it was just decided not to support that interrupt
at all. |
["https://git.kernel.org/stable/c/21a741eb75f80397e5f7d3739e24d7d75e619011","https://git.kernel.org/stable/c/8c6506616386ce37e59b2745fc481c6713fae4f3","https://git.kernel.org/stable/c/c550679d604798d9fed8a5b2bb5693448a25407c","https://git.kernel.org/stable/c/d10e3c39001e9194b9a1bfd6979bd3fa19dccdc5","https://git.kernel.org/stable/c/21a741eb75f80397e5f7d3739e24d7d75e619011","https://git.kernel.org/stable/c/8c6506616386ce37e59b2745fc481c6713fae4f3","https://git.kernel.org/stable/c/c550679d604798d9fed8a5b2bb5693448a25407c","https://git.kernel.org/stable/c/d10e3c39001e9194b9a1bfd6979bd3fa19dccdc5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52800
|
Medium |
fixed |
- 5.10.202
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix htt pktlog locking
The ath11k active pdevs are protected by RCU but the htt pktlog handling
code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a
read-side critical section.
Mark the code in question as an RCU read-side critical section to avoid
any potential use-after-free issues.
Compile tested only. |
["https://git.kernel.org/stable/c/03ed26935bebf6b6fd8a656490bf3dcc71b72679","https://git.kernel.org/stable/c/3a51e6b4da71fdfa43ec006d6abc020f3e22d14e","https://git.kernel.org/stable/c/3f77c7d605b29df277d77e9ee75d96e7ad145d2d","https://git.kernel.org/stable/c/423762f021825b5e57c3d6f01ff96a9ff19cdcd8","https://git.kernel.org/stable/c/69cede2a5a5f60e3f5602b901b52cb64edd2ea6c","https://git.kernel.org/stable/c/e3199b3fac65c9f103055390b6fd07c5cffa5961","https://git.kernel.org/stable/c/03ed26935bebf6b6fd8a656490bf3dcc71b72679","https://git.kernel.org/stable/c/3a51e6b4da71fdfa43ec006d6abc020f3e22d14e","https://git.kernel.org/stable/c/3f77c7d605b29df277d77e9ee75d96e7ad145d2d","https://git.kernel.org/stable/c/423762f021825b5e57c3d6f01ff96a9ff19cdcd8","https://git.kernel.org/stable/c/69cede2a5a5f60e3f5602b901b52cb64edd2ea6c","https://git.kernel.org/stable/c/e3199b3fac65c9f103055390b6fd07c5cffa5961"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38550
|
Medium |
fixed |
- 5.15.161
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: kirkwood: Fix potential NULL dereference
In kirkwood_dma_hw_params() mv_mbus_dram_info() returns NULL if
CONFIG_PLAT_ORION macro is not defined.
Fix this bug by adding NULL check.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/1a7254525ca7a6f3e37d7882d7f7ad97f6235f7c","https://git.kernel.org/stable/c/5bf5154739cd676b6d0958079070557c8d96afb6","https://git.kernel.org/stable/c/802b49e39da669b54bd9b77dc3c649999a446bf6","https://git.kernel.org/stable/c/d48d0c5fd733bd6d8d3ddb2ed553777ab4724169","https://git.kernel.org/stable/c/de9987cec6fde1dd41dfcb971433e05945852489","https://git.kernel.org/stable/c/ea60ab95723f5738e7737b56dda95e6feefa5b50","https://git.kernel.org/stable/c/1a7254525ca7a6f3e37d7882d7f7ad97f6235f7c","https://git.kernel.org/stable/c/5bf5154739cd676b6d0958079070557c8d96afb6","https://git.kernel.org/stable/c/802b49e39da669b54bd9b77dc3c649999a446bf6","https://git.kernel.org/stable/c/d48d0c5fd733bd6d8d3ddb2ed553777ab4724169","https://git.kernel.org/stable/c/de9987cec6fde1dd41dfcb971433e05945852489","https://git.kernel.org/stable/c/ea60ab95723f5738e7737b56dda95e6feefa5b50"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-40476
|
Medium |
fixed |
|
A null pointer dereference issue was discovered in fs/io_uring.c in the Linux kernel before 5.15.62. A local user could use this flaw to crash the system or potentially cause a denial of service. |
["https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/io_uring.c?h=v5.15.61\u0026id=3746d62ecf1c872a520c4866118edccb121c44fd","https://lore.kernel.org/lkml/CAO4S-mdVW5GkODk0+vbQexNAAJZopwzFJ9ACvRCJ989fQ4A6Ow%40mail.gmail.com/","https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.62","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/io_uring.c?h=v5.15.61\u0026id=3746d62ecf1c872a520c4866118edccb121c44fd","https://lore.kernel.org/lkml/CAO4S-mdVW5GkODk0+vbQexNAAJZopwzFJ9ACvRCJ989fQ4A6Ow%40mail.gmail.com/","https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.62"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38608
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix netif state handling
mlx5e_suspend cleans resources only if netif_device_present() returns
true. However, mlx5e_resume changes the state of netif, via
mlx5e_nic_enable, only if reg_state == NETREG_REGISTERED.
In the below case, the above leads to NULL-ptr Oops[1] and memory
leaks:
mlx5e_probe
_mlx5e_resume
mlx5e_attach_netdev
mlx5e_nic_enable <-- netdev not reg, not calling netif_device_attach()
register_netdev <-- failed for some reason.
ERROR_FLOW:
_mlx5e_suspend <-- netif_device_present return false, resources aren't freed :(
Hence, clean resources in this case as well.
[1]
BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 0 P4D 0
Oops: 0010 [#1] SMP
CPU: 2 PID: 9345 Comm: test-ovs-ct-gen Not tainted 6.5.0_for_upstream_min_debug_2023_09_05_16_01 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:0x0
Code: Unable to access opcode bytes at0xffffffffffffffd6.
RSP: 0018:ffff888178aaf758 EFLAGS: 00010246
Call Trace:
<TASK>
? __die+0x20/0x60
? page_fault_oops+0x14c/0x3c0
? exc_page_fault+0x75/0x140
? asm_exc_page_fault+0x22/0x30
notifier_call_chain+0x35/0xb0
blocking_notifier_call_chain+0x3d/0x60
mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core]
mlx5_core_uplink_netdev_event_replay+0x3e/0x60 [mlx5_core]
mlx5_mdev_netdev_track+0x53/0x60 [mlx5_ib]
mlx5_ib_roce_init+0xc3/0x340 [mlx5_ib]
__mlx5_ib_add+0x34/0xd0 [mlx5_ib]
mlx5r_probe+0xe1/0x210 [mlx5_ib]
? auxiliary_match_id+0x6a/0x90
auxiliary_bus_probe+0x38/0x80
? driver_sysfs_add+0x51/0x80
really_probe+0xc9/0x3e0
? driver_probe_device+0x90/0x90
__driver_probe_device+0x80/0x160
driver_probe_device+0x1e/0x90
__device_attach_driver+0x7d/0x100
bus_for_each_drv+0x80/0xd0
__device_attach+0xbc/0x1f0
bus_probe_device+0x86/0xa0
device_add+0x637/0x840
__auxiliary_device_add+0x3b/0xa0
add_adev+0xc9/0x140 [mlx5_core]
mlx5_rescan_drivers_locked+0x22a/0x310 [mlx5_core]
mlx5_register_device+0x53/0xa0 [mlx5_core]
mlx5_init_one_devl_locked+0x5c4/0x9c0 [mlx5_core]
mlx5_init_one+0x3b/0x60 [mlx5_core]
probe_one+0x44c/0x730 [mlx5_core]
local_pci_probe+0x3e/0x90
pci_device_probe+0xbf/0x210
? kernfs_create_link+0x5d/0xa0
? sysfs_do_create_link_sd+0x60/0xc0
really_probe+0xc9/0x3e0
? driver_probe_device+0x90/0x90
__driver_probe_device+0x80/0x160
driver_probe_device+0x1e/0x90
__device_attach_driver+0x7d/0x100
bus_for_each_drv+0x80/0xd0
__device_attach+0xbc/0x1f0
pci_bus_add_device+0x54/0x80
pci_iov_add_virtfn+0x2e6/0x320
sriov_enable+0x208/0x420
mlx5_core_sriov_configure+0x9e/0x200 [mlx5_core]
sriov_numvfs_store+0xae/0x1a0
kernfs_fop_write_iter+0x10c/0x1a0
vfs_write+0x291/0x3c0
ksys_write+0x5f/0xe0
do_syscall_64+0x3d/0x90
entry_SYSCALL_64_after_hwframe+0x46/0xb0
CR2: 0000000000000000
---[ end trace 0000000000000000 ]--- |
["https://git.kernel.org/stable/c/3d5918477f94e4c2f064567875c475468e264644","https://git.kernel.org/stable/c/f7e6cfb864a53af71c5cc904f1cc22215d68f5c6","https://git.kernel.org/stable/c/3d5918477f94e4c2f064567875c475468e264644","https://git.kernel.org/stable/c/f7e6cfb864a53af71c5cc904f1cc22215d68f5c6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48661
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
gpio: mockup: Fix potential resource leakage when register a chip
If creation of software node fails, the locally allocated string
array is left unfreed. Free it on error path. |
["https://git.kernel.org/stable/c/02743c4091ccfb246f5cdbbe3f44b152d5d12933","https://git.kernel.org/stable/c/41f857033c44442a27f591fda8d986e7c9e42872","https://git.kernel.org/stable/c/9b26723e058faaf11b532fb4aa16d6849d581790","https://git.kernel.org/stable/c/02743c4091ccfb246f5cdbbe3f44b152d5d12933","https://git.kernel.org/stable/c/41f857033c44442a27f591fda8d986e7c9e42872","https://git.kernel.org/stable/c/9b26723e058faaf11b532fb4aa16d6849d581790"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48859
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: marvell: prestera: Add missing of_node_put() in prestera_switch_set_base_mac_addr
This node pointer is returned by of_find_compatible_node() with
refcount incremented. Calling of_node_put() to aovid the refcount leak. |
["https://git.kernel.org/stable/c/4cc66bf17220ff9631f9fa99b02a872e0ad5a08b","https://git.kernel.org/stable/c/b7c2fd1d126329340639adfb8dd2938fe4b65df7","https://git.kernel.org/stable/c/c9ffa3e2bc451816ce0295e40063514fabf2bd36","https://git.kernel.org/stable/c/4cc66bf17220ff9631f9fa99b02a872e0ad5a08b","https://git.kernel.org/stable/c/b7c2fd1d126329340639adfb8dd2938fe4b65df7","https://git.kernel.org/stable/c/c9ffa3e2bc451816ce0295e40063514fabf2bd36"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57940
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
exfat: fix the infinite loop in exfat_readdir()
If the file system is corrupted so that a cluster is linked to
itself in the cluster chain, and there is an unused directory
entry in the cluster, 'dentry' will not be incremented, causing
condition 'dentry < max_dentries' unable to prevent an infinite
loop.
This infinite loop causes s_lock not to be released, and other
tasks will hang, such as exfat_sync_fs().
This commit stops traversing the cluster chain when there is unused
directory entry in the cluster to avoid this infinite loop. |
["https://git.kernel.org/stable/c/28c21f0ac5293a4bf19b3e0e32005d6dd31a6c17","https://git.kernel.org/stable/c/31beabd0f47f8c3ed9965ba861c9e5b252d4920a","https://git.kernel.org/stable/c/d8cfbb8723bd3d3222f360227a1cc15227189ca6","https://git.kernel.org/stable/c/d9ea94f5cd117d56e573696d0045ab3044185a15","https://git.kernel.org/stable/c/dc1d7afceb982e8f666e70a582e6b5aa806de063","https://git.kernel.org/stable/c/fee873761bd978d077d8c55334b4966ac4cb7b59"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21638
|
Medium |
fixed |
- 3.11
- 3.13
- 5.4.290
- 5.10.234
- 5.15.177
- 6.1.125
- 6.6.72
- 6.12.10
|
In the Linux kernel, the following vulnerability has been resolved:
sctp: sysctl: auth_enable: avoid using current->nsproxy
As mentioned in a previous commit of this series, using the 'net'
structure via 'current' is not recommended for different reasons:
- Inconsistency: getting info from the reader's/writer's netns vs only
from the opener's netns.
- current->nsproxy can be NULL in some cases, resulting in an 'Oops'
(null-ptr-deref), e.g. when the current task is exiting, as spotted by
syzbot [1] using acct(2).
The 'net' structure can be obtained from the table->data using
container_of().
Note that table->data could also be used directly, but that would
increase the size of this fix, while 'sctp.ctl_sock' still needs to be
retrieved from 'net' structure. |
["https://git.kernel.org/stable/c/15649fd5415eda664ef35780c2013adeb5d9c695","https://git.kernel.org/stable/c/1b67030d39f2b00f94ac1f0af11ba6657589e4d3","https://git.kernel.org/stable/c/7ec30c54f339c640aa7e49d7e9f7bbed6bd42bf6","https://git.kernel.org/stable/c/bd2a2939423566c654545fa3e96a656662a0af9e","https://git.kernel.org/stable/c/c184bc621e3cef03ac9ba81a50dda2dae6a21d36","https://git.kernel.org/stable/c/cf387cdebfaebae228dfba162f94c567a67610c3","https://git.kernel.org/stable/c/dc583e7e5f8515ca489c0df28e4362a70eade382"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21639
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
sctp: sysctl: rto_min/max: avoid using current->nsproxy
As mentioned in a previous commit of this series, using the 'net'
structure via 'current' is not recommended for different reasons:
- Inconsistency: getting info from the reader's/writer's netns vs only
from the opener's netns.
- current->nsproxy can be NULL in some cases, resulting in an 'Oops'
(null-ptr-deref), e.g. when the current task is exiting, as spotted by
syzbot [1] using acct(2).
The 'net' structure can be obtained from the table->data using
container_of().
Note that table->data could also be used directly, as this is the only
member needed from the 'net' structure, but that would increase the size
of this fix, to use '*data' everywhere 'net->sctp.rto_min/max' is used. |
["https://git.kernel.org/stable/c/0f78f09466744589e420935e646ae78212a38290","https://git.kernel.org/stable/c/246428bfb9e7db15c5cd08e1d0eca41b65af2b06","https://git.kernel.org/stable/c/4059507e34aa5fe0fa9fd5b2b5f0c8b26ab2d482","https://git.kernel.org/stable/c/9fc17b76fc70763780aa78b38fcf4742384044a5","https://git.kernel.org/stable/c/c87f1f6ade56c711f8736901e330685b453e420e","https://git.kernel.org/stable/c/c8d179f3b1c1d60bf4484f50aa67b4c70f91bff9","https://git.kernel.org/stable/c/dc9d0e3cfd16f66fbf0862857c6b391c8613ca9f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21640
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
sctp: sysctl: cookie_hmac_alg: avoid using current->nsproxy
As mentioned in a previous commit of this series, using the 'net'
structure via 'current' is not recommended for different reasons:
- Inconsistency: getting info from the reader's/writer's netns vs only
from the opener's netns.
- current->nsproxy can be NULL in some cases, resulting in an 'Oops'
(null-ptr-deref), e.g. when the current task is exiting, as spotted by
syzbot [1] using acct(2).
The 'net' structure can be obtained from the table->data using
container_of().
Note that table->data could also be used directly, as this is the only
member needed from the 'net' structure, but that would increase the size
of this fix, to use '*data' everywhere 'net->sctp.sctp_hmac_alg' is
used. |
["https://git.kernel.org/stable/c/03ca51faba2b017bf6c90e139434c4117d0afcdc","https://git.kernel.org/stable/c/3cd0659deb9c03535fd61839e91d4d4d3e51ac71","https://git.kernel.org/stable/c/5599b212d2f4466e1832a94e9932684aaa364587","https://git.kernel.org/stable/c/86ddf8118123cb58a0fb8724cad6979c4069065b","https://git.kernel.org/stable/c/ad673e514b2793b8d5902f6ba6ab7e890dea23d5","https://git.kernel.org/stable/c/ea62dd1383913b5999f3d16ae99d411f41b528d4","https://git.kernel.org/stable/c/f0bb3935470684306e4e04793a20ac4c4b08de0b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21666
|
Medium |
fixed |
- 5.15.177
- 6.1.127
- 6.6.74
- 6.12.11
|
In the Linux kernel, the following vulnerability has been resolved:
vsock: prevent null-ptr-deref in vsock_*[has_data|has_space]
Recent reports have shown how we sometimes call vsock_*_has_data()
when a vsock socket has been de-assigned from a transport (see attached
links), but we shouldn't.
Previous commits should have solved the real problems, but we may have
more in the future, so to avoid null-ptr-deref, we can return 0
(no space, no data available) but with a warning.
This way the code should continue to run in a nearly consistent state
and have a warning that allows us to debug future problems. |
["https://git.kernel.org/stable/c/91751e248256efc111e52e15115840c35d85abaf","https://git.kernel.org/stable/c/9e5fed46ccd2c34c5fa5a9c8825ce4823fdc853e","https://git.kernel.org/stable/c/b52e50dd4fabd12944172bd486a4f4853b7f74dd","https://git.kernel.org/stable/c/bc9c49341f9728c31fe248c5fbba32d2e81a092b","https://git.kernel.org/stable/c/c23d1d4f8efefb72258e9cedce29de10d057f8ca","https://git.kernel.org/stable/c/daeac89cdb03d30028186f5ff7dc26ec8fa843e7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21669
|
Medium |
fixed |
- 5.15.177
- 6.1.127
- 6.6.74
- 6.12.11
|
In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: discard packets if the transport changes
If the socket has been de-assigned or assigned to another transport,
we must discard any packets received because they are not expected
and would cause issues when we access vsk->transport.
A possible scenario is described by Hyunwoo Kim in the attached link,
where after a first connect() interrupted by a signal, and a second
connect() failed, we can find `vsk->transport` at NULL, leading to a
NULL pointer dereference. |
["https://git.kernel.org/stable/c/18a7fc371d1dbf8deff16c2dd9292bcc73f43040","https://git.kernel.org/stable/c/2cb7c756f605ec02ffe562fb26828e4bcc5fdfc1","https://git.kernel.org/stable/c/6486915fa661584d70e8e7e4068c6c075c67dd6d","https://git.kernel.org/stable/c/677579b641af109613564460a4e3bdcb16850b61","https://git.kernel.org/stable/c/88244163bc7e7b0ce9dd7bf4c8a563b41525c3ee","https://git.kernel.org/stable/c/d88b249e14bd0ee1e46bbe4f456e22e01b8c68de"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21683
|
Medium |
fixed |
- 5.15.177
- 6.1.127
- 6.6.74
- 6.12.11
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix bpf_sk_select_reuseport() memory leak
As pointed out in the original comment, lookup in sockmap can return a TCP
ESTABLISHED socket. Such TCP socket may have had SO_ATTACH_REUSEPORT_EBPF
set before it was ESTABLISHED. In other words, a non-NULL sk_reuseport_cb
does not imply a non-refcounted socket.
Drop sk's reference in both error paths.
unreferenced object 0xffff888101911800 (size 2048):
comm "test_progs", pid 44109, jiffies 4297131437
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
80 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 9336483b):
__kmalloc_noprof+0x3bf/0x560
__reuseport_alloc+0x1d/0x40
reuseport_alloc+0xca/0x150
reuseport_attach_prog+0x87/0x140
sk_reuseport_attach_bpf+0xc8/0x100
sk_setsockopt+0x1181/0x1990
do_sock_setsockopt+0x12b/0x160
__sys_setsockopt+0x7b/0xc0
__x64_sys_setsockopt+0x1b/0x30
do_syscall_64+0x93/0x180
entry_SYSCALL_64_after_hwframe+0x76/0x7e |
["https://git.kernel.org/stable/c/0ab52a8ca6e156a64c51b5e7456cac9a0ebfd9bf","https://git.kernel.org/stable/c/b02e70be498b138e9c21701c2f33f4018ca7cd5e","https://git.kernel.org/stable/c/b3af60928ab9129befa65e6df0310d27300942bf","https://git.kernel.org/stable/c/bb36838dac7bb334a3f3d7eb29875593ec9473fc","https://git.kernel.org/stable/c/cccd51dd22574216e64e5d205489e634f86999f3","https://git.kernel.org/stable/c/d0a3b3d1176d39218b8edb2a2d03164942ab9ccd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49974
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Limit the number of concurrent async COPY operations
Nothing appears to limit the number of concurrent async COPY
operations that clients can start. In addition, AFAICT each async
COPY can copy an unlimited number of 4MB chunks, so can run for a
long time. Thus IMO async COPY can become a DoS vector.
Add a restriction mechanism that bounds the number of concurrent
background COPY operations. Start simple and try to be fair -- this
patch implements a per-namespace limit.
An async COPY request that occurs while this limit is exceeded gets
NFS4ERR_DELAY. The requesting client can choose to send the request
again after a delay or fall back to a traditional read/write style
copy.
If there is need to make the mechanism more sophisticated, we can
visit that in future patches. |
["https://git.kernel.org/stable/c/43e46ee5efc03990b223f7aa8b77aa9c3d3acfdf","https://git.kernel.org/stable/c/6a488ad7745b8f64625c6d3a24ce7e448e83f11b","https://git.kernel.org/stable/c/7ea9260874b779637aff6d24c344b8ef4ac862a0","https://git.kernel.org/stable/c/9e52ff544e0bfa09ee339fd7b0937ee3c080c24e","https://git.kernel.org/stable/c/aadc3bbea163b6caaaebfdd2b6c4667fbc726752","https://git.kernel.org/stable/c/ae267989b7b7933dfedcd26468d0a88fc3a9da9e","https://git.kernel.org/stable/c/b4e21431a0db4854b5023cd5af001be557e6c3db"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40972
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: do not create EA inode under buffer lock
ext4_xattr_set_entry() creates new EA inodes while holding buffer lock
on the external xattr block. This is problematic as it nests all the
allocation locking (which acquires locks on other buffers) under the
buffer lock. This can even deadlock when the filesystem is corrupted and
e.g. quota file is setup to contain xattr block as data block. Move the
allocation of EA inode out of ext4_xattr_set_entry() into the callers. |
["https://git.kernel.org/stable/c/0752e7fb549d90c33b4d4186f11cfd25a556d1dd","https://git.kernel.org/stable/c/0a46ef234756dca04623b7591e8ebb3440622f0b","https://git.kernel.org/stable/c/111103907234bffd0a34fba070ad9367de058752","https://git.kernel.org/stable/c/737fb7853acd5bc8984f6f42e4bfba3334be8ae1","https://git.kernel.org/stable/c/0a46ef234756dca04623b7591e8ebb3440622f0b","https://git.kernel.org/stable/c/111103907234bffd0a34fba070ad9367de058752"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46802
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: added NULL check at start of dc_validate_stream
[Why]
prevent invalid memory access
[How]
check if dc and stream are NULL |
["https://git.kernel.org/stable/c/154a50bf4221a6a6ccf88d565b8184da7c40a2dd","https://git.kernel.org/stable/c/26c56049cc4f1705b498df013949427692a4b0d5","https://git.kernel.org/stable/c/356fcce9cdbfe338a275e9e1836adfdd7f5c52a9","https://git.kernel.org/stable/c/6bf920193ba1853bad780bba565a789246d9003c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21636
|
Medium |
fixed |
- 5.15.177
- 6.1.125
- 6.6.72
- 6.12.10
|
In the Linux kernel, the following vulnerability has been resolved:
sctp: sysctl: plpmtud_probe_interval: avoid using current->nsproxy
As mentioned in a previous commit of this series, using the 'net'
structure via 'current' is not recommended for different reasons:
- Inconsistency: getting info from the reader's/writer's netns vs only
from the opener's netns.
- current->nsproxy can be NULL in some cases, resulting in an 'Oops'
(null-ptr-deref), e.g. when the current task is exiting, as spotted by
syzbot [1] using acct(2).
The 'net' structure can be obtained from the table->data using
container_of().
Note that table->data could also be used directly, as this is the only
member needed from the 'net' structure, but that would increase the size
of this fix, to use '*data' everywhere 'net->sctp.probe_interval' is
used. |
["https://git.kernel.org/stable/c/1dc5da6c4178f3e4b95c631418f72de9f86c0449","https://git.kernel.org/stable/c/284a221f8fa503628432c7bb5108277c688c6ffa","https://git.kernel.org/stable/c/44ee8635922b6eb940faddb961a8347c6857d722","https://git.kernel.org/stable/c/6259d2484d0ceff42245d1f09cc8cb6ee72d847a","https://git.kernel.org/stable/c/bcf8c60074e81ed2ac2d35130917175a3949c917"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21637
|
Medium |
fixed |
- 5.15.177
- 6.1.125
- 6.6.72
- 6.12.10
|
In the Linux kernel, the following vulnerability has been resolved:
sctp: sysctl: udp_port: avoid using current->nsproxy
As mentioned in a previous commit of this series, using the 'net'
structure via 'current' is not recommended for different reasons:
- Inconsistency: getting info from the reader's/writer's netns vs only
from the opener's netns.
- current->nsproxy can be NULL in some cases, resulting in an 'Oops'
(null-ptr-deref), e.g. when the current task is exiting, as spotted by
syzbot [1] using acct(2).
The 'net' structure can be obtained from the table->data using
container_of().
Note that table->data could also be used directly, but that would
increase the size of this fix, while 'sctp.ctl_sock' still needs to be
retrieved from 'net' structure. |
["https://git.kernel.org/stable/c/0a0966312ac3eedd7f5f2a766ed4702df39a9a65","https://git.kernel.org/stable/c/55627918febdf9d71107a1e68d1528dc591c9a15","https://git.kernel.org/stable/c/5b77d73f3be5102720fb685b9e6900e3500e1096","https://git.kernel.org/stable/c/c10377bbc1972d858eaf0ab366a311b39f8ef1b6","https://git.kernel.org/stable/c/e919197fb8616331f5dc81e4c3cc3d12769cb725"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21665
|
Medium |
fixed |
- 5.15.177
- 6.1.127
- 6.6.74
- 6.12.11
|
In the Linux kernel, the following vulnerability has been resolved:
filemap: avoid truncating 64-bit offset to 32 bits
On 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a
64-bit value to 32 bits, leading to a possible infinite loop when writing
to an xfs filesystem. |
["https://git.kernel.org/stable/c/09528bb1a4123e2a234eac2bc45a0e51e78dab43","https://git.kernel.org/stable/c/280f1fb89afc01e7376f59ae611d54ca69e9f967","https://git.kernel.org/stable/c/64e5fd96330df2ad278d1c4edcca581f26e5f76e","https://git.kernel.org/stable/c/80fc836f3ebe2f2d2d2c80c698b7667974285a04","https://git.kernel.org/stable/c/f505e6c91e7a22d10316665a86d79f84d9f0ba76"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50012
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: Avoid a bad reference count on CPU node
In the parse_perf_domain function, if the call to
of_parse_phandle_with_args returns an error, then the reference to the
CPU device node that was acquired at the start of the function would not
be properly decremented.
Address this by declaring the variable with the __free(device_node)
cleanup attribute. |
["https://git.kernel.org/stable/c/0f41f383b5a61a2bf6429a449ebba7fb08179d81","https://git.kernel.org/stable/c/47cb1d9278f179df8250304ec41009e3e836a926","https://git.kernel.org/stable/c/6c3d8387839252f1a0fc6367f314446e4a2ebd0b","https://git.kernel.org/stable/c/77f88b17387a017416babf1e6488fa17682287e2","https://git.kernel.org/stable/c/c0f02536fffbbec71aced36d52a765f8c4493dc2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46857
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix bridge mode operations when there are no VFs
Currently, trying to set the bridge mode attribute when numvfs=0 leads to a
crash:
bridge link set dev eth2 hwmode vepa
[ 168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030
[...]
[ 168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core]
[...]
[ 168.976037] Call Trace:
[ 168.976188] <TASK>
[ 168.978620] _mlx5_eswitch_set_vepa_locked+0x113/0x230 [mlx5_core]
[ 168.979074] mlx5_eswitch_set_vepa+0x7f/0xa0 [mlx5_core]
[ 168.979471] rtnl_bridge_setlink+0xe9/0x1f0
[ 168.979714] rtnetlink_rcv_msg+0x159/0x400
[ 168.980451] netlink_rcv_skb+0x54/0x100
[ 168.980675] netlink_unicast+0x241/0x360
[ 168.980918] netlink_sendmsg+0x1f6/0x430
[ 168.981162] ____sys_sendmsg+0x3bb/0x3f0
[ 168.982155] ___sys_sendmsg+0x88/0xd0
[ 168.985036] __sys_sendmsg+0x59/0xa0
[ 168.985477] do_syscall_64+0x79/0x150
[ 168.987273] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 168.987773] RIP: 0033:0x7f8f7950f917
(esw->fdb_table.legacy.vepa_fdb is null)
The bridge mode is only relevant when there are multiple functions per
port. Therefore, prevent setting and getting this setting when there are no
VFs.
Note that after this change, there are no settings to change on the PF
interface using `bridge link` when there are no VFs, so the interface no
longer appears in the `bridge link` output. |
["https://git.kernel.org/stable/c/505ae01f75f839b54329164bbfecf24cc1361b31","https://git.kernel.org/stable/c/52c4beb79e095e0631b5cac46ed48a2aefe51985","https://git.kernel.org/stable/c/65feee671e37f3b6eda0b6af28f204b5bcf7fa50","https://git.kernel.org/stable/c/b1d305abef4640af1b4f1b4774d513cd81b10cfc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43913
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
nvme: apple: fix device reference counting
Drivers must call nvme_uninit_ctrl after a successful nvme_init_ctrl.
Split the allocation side out to make the error handling boundary easier
to navigate. The apple driver had been doing this wrong, leaking the
controller device memory on a tagset failure. |
["https://git.kernel.org/stable/c/b9ecbfa45516182cd062fecd286db7907ba84210","https://git.kernel.org/stable/c/d59c4d0eb6adc24c2201f153ccb7fd0a335b0d3d","https://git.kernel.org/stable/c/f7d9a18572fcd7130459b7691bd19ee2a2e951ad"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44963
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not BUG_ON() when freeing tree block after error
When freeing a tree block, at btrfs_free_tree_block(), if we fail to
create a delayed reference we don't deal with the error and just do a
BUG_ON(). The error most likely to happen is -ENOMEM, and we have a
comment mentioning that only -ENOMEM can happen, but that is not true,
because in case qgroups are enabled any error returned from
btrfs_qgroup_trace_extent_post() (can be -EUCLEAN or anything returned
from btrfs_search_slot() for example) can be propagated back to
btrfs_free_tree_block().
So stop doing a BUG_ON() and return the error to the callers and make
them abort the transaction to prevent leaking space. Syzbot was
triggering this, likely due to memory allocation failure injection. |
["https://git.kernel.org/stable/c/22d907bcd283d69d5e60497fc0d51969545c583b","https://git.kernel.org/stable/c/98251cd60b4d702a8a81de442ab621e83a3fb24f","https://git.kernel.org/stable/c/bb3868033a4cccff7be57e9145f2117cbdc91c11"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26584
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: tls: handle backlogging of crypto requests
Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our
requests to the crypto API, crypto_aead_{encrypt,decrypt} can return
-EBUSY instead of -EINPROGRESS in valid situations. For example, when
the cryptd queue for AESNI is full (easy to trigger with an
artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued
to the backlog but still processed. In that case, the async callback
will also be called twice: first with err == -EINPROGRESS, which it
seems we can just ignore, then with err == 0.
Compared to Sabrina's original patch this version uses the new
tls_*crypt_async_wait() helpers and converts the EBUSY to
EINPROGRESS to avoid having to modify all the error handling
paths. The handling is identical. |
["https://git.kernel.org/stable/c/13eca403876bbea3716e82cdfe6f1e6febb38754","https://git.kernel.org/stable/c/3ade391adc584f17b5570fd205de3ad029090368","https://git.kernel.org/stable/c/8590541473188741055d27b955db0777569438e3","https://git.kernel.org/stable/c/ab6397f072e5097f267abf5cb08a8004e6b17694","https://git.kernel.org/stable/c/cd1bbca03f3c1d845ce274c0d0a66de8e5929f72","https://git.kernel.org/stable/c/13eca403876bbea3716e82cdfe6f1e6febb38754","https://git.kernel.org/stable/c/3ade391adc584f17b5570fd205de3ad029090368","https://git.kernel.org/stable/c/8590541473188741055d27b955db0777569438e3","https://git.kernel.org/stable/c/ab6397f072e5097f267abf5cb08a8004e6b17694","https://git.kernel.org/stable/c/cd1bbca03f3c1d845ce274c0d0a66de8e5929f72"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48946
|
Medium |
fixed |
- 4.9.337
- 4.14.303
- 4.19.270
- 5.4.229
- 5.10.161
- 5.15.85
- 6.0.15
|
In the Linux kernel, the following vulnerability has been resolved:
udf: Fix preallocation discarding at indirect extent boundary
When preallocation extent is the first one in the extent block, the
code would corrupt extent tree header instead. Fix the problem and use
udf_delete_aext() for deleting extent to avoid some code duplication. |
["https://git.kernel.org/stable/c/12a88f572d6d94b5c0b72e2d1782cc2e96ac06cf","https://git.kernel.org/stable/c/1a075f4a549481ce6e8518d8379f193ccec6b746","https://git.kernel.org/stable/c/4d835efd561dfb9bf5409f11f4ecd428d5d29226","https://git.kernel.org/stable/c/63dbbd8f1499b0a161e701a04aa50148d60bd1f7","https://git.kernel.org/stable/c/72f651c96c8aadf087fd782d551bf7db648a8c2e","https://git.kernel.org/stable/c/7665857f88557c372da35534165721156756f77f","https://git.kernel.org/stable/c/ae56d9a017724f130cf1a263dd82a78d2a6e3852","https://git.kernel.org/stable/c/c8b6fa4511a7900db9fb0353b630d4d2ed1ba99c","https://git.kernel.org/stable/c/cfe4c1b25dd6d2f056afc00b7c98bcb3dd0b1fc3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41088
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
can: mcp251xfd: fix infinite loop when xmit fails
When the mcp251xfd_start_xmit() function fails, the driver stops
processing messages, and the interrupt routine does not return,
running indefinitely even after killing the running application.
Error messages:
[ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16
[ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3).
... and repeat forever.
The issue can be triggered when multiple devices share the same SPI
interface. And there is concurrent access to the bus.
The problem occurs because tx_ring->head increments even if
mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX
package while still expecting a response in
mcp251xfd_handle_tefif_one().
Resolve the issue by starting a workqueue to write the tx obj
synchronously if err = -EBUSY. In case of another error, decrement
tx_ring->head, remove skb from the echo stack, and drop the message.
[mkl: use more imperative wording in patch description] |
["https://git.kernel.org/stable/c/3e72558c1711d524e3150103739ddd06650e291b","https://git.kernel.org/stable/c/6c6b4afa59c2fb4d1759235f866d8caed2aa4729","https://git.kernel.org/stable/c/d8fb63e46c884c898a38f061c2330f7729e75510","https://git.kernel.org/stable/c/f926c022ebaabf7963bebf89a97201d66978a025","https://git.kernel.org/stable/c/3e72558c1711d524e3150103739ddd06650e291b","https://git.kernel.org/stable/c/6c6b4afa59c2fb4d1759235f866d8caed2aa4729","https://git.kernel.org/stable/c/d8fb63e46c884c898a38f061c2330f7729e75510","https://git.kernel.org/stable/c/f926c022ebaabf7963bebf89a97201d66978a025"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41007
|
Low |
fixed |
- 5.4.280
- 5.10.222
- 5.15.163
- 6.1.100
- 6.6.41
- 6.9.10
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: avoid too many retransmit packets
If a TCP socket is using TCP_USER_TIMEOUT, and the other peer
retracted its window to zero, tcp_retransmit_timer() can
retransmit a packet every two jiffies (2 ms for HZ=1000),
for about 4 minutes after TCP_USER_TIMEOUT has 'expired'.
The fix is to make sure tcp_rtx_probe0_timed_out() takes
icsk->icsk_user_timeout into account.
Before blamed commit, the socket would not timeout after
icsk->icsk_user_timeout, but would use standard exponential
backoff for the retransmits.
Also worth noting that before commit e89688e3e978 ("net: tcp:
fix unexcepted socket die when snd_wnd is 0"), the issue
would last 2 minutes instead of 4. |
["https://git.kernel.org/stable/c/04317a2471c2f637b4c49cbd0e9c0d04a519f570","https://git.kernel.org/stable/c/5d7e64d70a11d988553a08239c810a658e841982","https://git.kernel.org/stable/c/66cb64a1d2239cd0309f9b5038b05462570a5be1","https://git.kernel.org/stable/c/7bb7670f92bfbd05fc41a8f9a8f358b7ffed65f4","https://git.kernel.org/stable/c/97a9063518f198ec0adb2ecb89789de342bb8283","https://git.kernel.org/stable/c/d2346fca5bed130dc712f276ac63450201d52969","https://git.kernel.org/stable/c/dfcdd7f89e401d2c6616be90c76c2fac3fa98fde","https://git.kernel.org/stable/c/e113cddefa27bbf5a79f72387b8fbd432a61a466","https://git.kernel.org/stable/c/04317a2471c2f637b4c49cbd0e9c0d04a519f570","https://git.kernel.org/stable/c/5d7e64d70a11d988553a08239c810a658e841982","https://git.kernel.org/stable/c/66cb64a1d2239cd0309f9b5038b05462570a5be1","https://git.kernel.org/stable/c/7bb7670f92bfbd05fc41a8f9a8f358b7ffed65f4","https://git.kernel.org/stable/c/97a9063518f198ec0adb2ecb89789de342bb8283","https://git.kernel.org/stable/c/d2346fca5bed130dc712f276ac63450201d52969","https://git.kernel.org/stable/c/dfcdd7f89e401d2c6616be90c76c2fac3fa98fde","https://git.kernel.org/stable/c/e113cddefa27bbf5a79f72387b8fbd432a61a466"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-40791
|
Medium |
fixed |
|
extract_user_to_sg in lib/scatterlist.c in the Linux kernel before 6.4.12 fails to unpin pages in a certain situation, as demonstrated by a WARNING for try_grab_page. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.12","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f443fd5af5dbd531f880d3645d5dd36976cf087f","https://lkml.org/lkml/2023/8/3/323","https://lore.kernel.org/linux-crypto/20571.1690369076%40warthog.procyon.org.uk/","https://security.netapp.com/advisory/ntap-20231110-0009/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.12","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f443fd5af5dbd531f880d3645d5dd36976cf087f","https://lkml.org/lkml/2023/8/3/323","https://lore.kernel.org/linux-crypto/20571.1690369076%40warthog.procyon.org.uk/","https://security.netapp.com/advisory/ntap-20231110-0009/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50193
|
High |
fixed |
- 5.10.228
- 5.15.169
- 6.1.114
- 6.6.58
- 6.11.5
|
In the Linux kernel, the following vulnerability has been resolved:
x86/entry_32: Clear CPU buffers after register restore in NMI return
CPU buffers are currently cleared after call to exc_nmi, but before
register state is restored. This may be okay for MDS mitigation but not for
RDFS. Because RDFS mitigation requires CPU buffers to be cleared when
registers don't have any sensitive data.
Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI. |
["https://git.kernel.org/stable/c/227358e89703c344008119be7e8ffa3fdb5b92de","https://git.kernel.org/stable/c/43778de19d2ef129636815274644b9c16e78c66b","https://git.kernel.org/stable/c/48a2440d0f20c826b884e04377ccc1e4696c84e9","https://git.kernel.org/stable/c/64adf22c4bc73ede920baca5defefb70f190cdbc","https://git.kernel.org/stable/c/6f44a5fc15b5cece0785bc07453db77d99b0a6de","https://git.kernel.org/stable/c/b6400eb0b347821efc57760221f8fb6d63b9548a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53099
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Check validity of link->type in bpf_link_show_fdinfo()
If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessing
bpf_link_type_strs[link->type] may result in an out-of-bounds access.
To spot such missed invocations early in the future, checking the
validity of link->type in bpf_link_show_fdinfo() and emitting a warning
when such invocations are missed. |
["https://git.kernel.org/stable/c/24fec234d2ba9ca3c14e545ebe3fd6dcb47f074d","https://git.kernel.org/stable/c/4e8074bb33d18f56af30a0252cb3606d27eb1c13","https://git.kernel.org/stable/c/79f87a6ec39fb5968049a6775a528bf58b25c20a","https://git.kernel.org/stable/c/8421d4c8762bd022cb491f2f0f7019ef51b4f0a7","https://git.kernel.org/stable/c/b3eb1b6a9f745d6941b345f0fae014dc8bb06d36","https://git.kernel.org/stable/c/d5092b0a1aaf35d77ebd8d33384d7930bec5cb5d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46724
|
High |
fixed |
- 5.10.226
- 5.15.167
- 6.1.109
- 6.6.50
- 6.10.9
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number
Check the fb_channel_number range to avoid the array out-of-bounds
read error |
["https://git.kernel.org/stable/c/32915dc909ff502823babfe07d5416c5b6e8a8b1","https://git.kernel.org/stable/c/45f7b02afc464c208e8f56bcbc672ef5c364c815","https://git.kernel.org/stable/c/725b728cc0c8c5fafdfb51cb0937870d33a40fa4","https://git.kernel.org/stable/c/d768394fa99467bcf2703bde74ddc96eeb0b71fa","https://git.kernel.org/stable/c/db7a86676fd624768a5d907faf34ad7bb4ff25f4","https://git.kernel.org/stable/c/f9267972490f9fcffe146e79828e97acc0da588c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46731
|
High |
fixed |
- 5.10.226
- 5.15.167
- 6.1.109
- 6.6.50
- 6.10.9
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: fix the Out-of-bounds read warning
using index i - 1U may beyond element index
for mc_data[] when i = 0. |
["https://git.kernel.org/stable/c/12c6967428a099bbba9dfd247bb4322a984fcc0b","https://git.kernel.org/stable/c/20c6373a6be93039f9d66029bb1e21038a060be1","https://git.kernel.org/stable/c/3317966efcdc5101e93db21514b68917e7eb34ea","https://git.kernel.org/stable/c/38e32a0d837443c91c4b615a067b976cfb925376","https://git.kernel.org/stable/c/d83fb9f9f63e9a120bf405b078f829f0b2e58934","https://git.kernel.org/stable/c/f1e261ced9bcad772a45a2fcdf413c3490e87299"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50035
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
ppp: fix ppp_async_encode() illegal access
syzbot reported an issue in ppp_async_encode() [1]
In this case, pppoe_sendmsg() is called with a zero size.
Then ppp_async_encode() is called with an empty skb.
BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]
BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675
ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]
ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675
ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634
ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline]
ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304
pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379
sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113
__release_sock+0x1da/0x330 net/core/sock.c:3072
release_sock+0x6b/0x250 net/core/sock.c:3626
pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903
sock_sendmsg_nosec net/socket.c:729 [inline]
__sock_sendmsg+0x30f/0x380 net/socket.c:744
____sys_sendmsg+0x903/0xb60 net/socket.c:2602
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
__sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
__do_sys_sendmmsg net/socket.c:2771 [inline]
__se_sys_sendmmsg net/socket.c:2768 [inline]
__x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at:
slab_post_alloc_hook mm/slub.c:4092 [inline]
slab_alloc_node mm/slub.c:4135 [inline]
kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587
__alloc_skb+0x363/0x7b0 net/core/skbuff.c:678
alloc_skb include/linux/skbuff.h:1322 [inline]
sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732
pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867
sock_sendmsg_nosec net/socket.c:729 [inline]
__sock_sendmsg+0x30f/0x380 net/socket.c:744
____sys_sendmsg+0x903/0xb60 net/socket.c:2602
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
__sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
__do_sys_sendmmsg net/socket.c:2771 [inline]
__se_sys_sendmmsg net/socket.c:2768 [inline]
__x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 |
["https://git.kernel.org/stable/c/30d91a478d58cbae3dbaa8224d17d0d839f0d71b","https://git.kernel.org/stable/c/40dddd4b8bd08a69471efd96107a4e1c73fabefc","https://git.kernel.org/stable/c/4151ec65abd755133ebec687218fadd2d2631167","https://git.kernel.org/stable/c/8dfe93901b410ae41264087427f3b9f389388f83","https://git.kernel.org/stable/c/8fe992ff3df493d1949922ca234419f3ede08dff","https://git.kernel.org/stable/c/c007a14797240607038bd3464501109f408940e2","https://git.kernel.org/stable/c/ce249a4c68d0ce27a8c5d853338d502e2711a314","https://git.kernel.org/stable/c/fadf8fdb3110d3138e05c3765f645535434f8d76"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-26365
|
High |
fixed |
- 4.9.322
- 4.14.287
- 4.19.251
- 5.4.204
- 5.10.129
- 5.15.53
- 5.18.10
|
Linux disk/nic frontends data leaks T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742). |
["http://www.openwall.com/lists/oss-security/2022/07/05/6","http://xenbits.xen.org/xsa/advisory-403.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-403.txt","http://www.openwall.com/lists/oss-security/2022/07/05/6","http://xenbits.xen.org/xsa/advisory-403.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-403.txt"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-33741
|
High |
fixed |
- 4.9.322
- 4.14.287
- 4.19.251
- 5.4.204
- 5.10.129
- 5.15.53
- 5.18.10
|
Linux disk/nic frontends data leaks T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742). |
["http://www.openwall.com/lists/oss-security/2022/07/05/6","http://xenbits.xen.org/xsa/advisory-403.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-403.txt","http://www.openwall.com/lists/oss-security/2022/07/05/6","http://xenbits.xen.org/xsa/advisory-403.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-403.txt"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50059
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition
In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev
function, then &sndev->check_link_status_work is bound with
check_link_status_work. switchtec_ntb_link_notification may be called
to start the work.
If we remove the module which will call switchtec_ntb_remove to make
cleanup, it will free sndev through kfree(sndev), while the work
mentioned above will be used. The sequence of operations that may lead
to a UAF bug is as follows:
CPU0 CPU1
| check_link_status_work
switchtec_ntb_remove |
kfree(sndev); |
| if (sndev->link_force_down)
| // use sndev
Fix it by ensuring that the work is canceled before proceeding with
the cleanup in switchtec_ntb_remove. |
["https://git.kernel.org/stable/c/177925d9c8715a897bb79eca62628862213ba956","https://git.kernel.org/stable/c/3ae45be8492460a35b5aebf6acac1f1d32708946","https://git.kernel.org/stable/c/5126d8f5567f49b52e21fca320eaa97977055099","https://git.kernel.org/stable/c/92728fceefdaa2a0a3aae675f86193b006eeaa43","https://git.kernel.org/stable/c/b650189687822b705711f0567a65a164a314d8df","https://git.kernel.org/stable/c/e51aded92d42784313ba16c12f4f88cc4f973bbb","https://git.kernel.org/stable/c/fa840ba4bd9f3bad7f104e5b32028ee73af8b3dd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1998
|
Medium |
fixed |
|
The Linux kernel allows userspace processes to enable mitigations by calling prctl with PR_SET_SPECULATION_CTRL which disables the speculation feature as well as by using seccomp. We had noticed that on VMs of at least one major cloud provider, the kernel still left the victim process exposed to attacks in some cases even after enabling the spectre-BTI mitigation with prctl. The same behavior can be observed on a bare-metal machine when forcing the mitigation to IBRS on boot command line.
This happened because when plain IBRS was enabled (not enhanced IBRS), the kernel had some logic that determined that STIBP was not needed. The IBRS bit implicitly protects against cross-thread branch target injection. However, with legacy IBRS, the IBRS bit was cleared on returning to userspace, due to performance reasons, which disabled the implicit STIBP and left userspace threads vulnerable to cross-thread branch target injection against which STIBP protects. |
["https://github.com/google/security-research/security/advisories/GHSA-mj4w-6495-6crx","https://github.com/torvalds/linux/commit/6921ed9049bc7457f66c1596c5b78aec0dae4a9d","https://kernel.dance/#6921ed9049bc7457f66c1596c5b78aec0dae4a9d","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://github.com/google/security-research/security/advisories/GHSA-mj4w-6495-6crx","https://github.com/torvalds/linux/commit/6921ed9049bc7457f66c1596c5b78aec0dae4a9d","https://kernel.dance/#6921ed9049bc7457f66c1596c5b78aec0dae4a9d","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57874
|
Medium |
fixed |
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
arm64: ptrace: fix partial SETREGSET for NT_ARM_TAGGED_ADDR_CTRL
Currently tagged_addr_ctrl_set() doesn't initialize the temporary 'ctrl'
variable, and a SETREGSET call with a length of zero will leave this
uninitialized. Consequently tagged_addr_ctrl_set() will consume an
arbitrary value, potentially leaking up to 64 bits of memory from the
kernel stack. The read is limited to a specific slot on the stack, and
the issue does not provide a write mechanism.
As set_tagged_addr_ctrl() only accepts values where bits [63:4] zero and
rejects other values, a partial SETREGSET attempt will randomly succeed
or fail depending on the value of the uninitialized value, and the
exposure is significantly limited.
Fix this by initializing the temporary value before copying the regset
from userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG,
NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing
value of the tagged address ctrl will be retained.
The NT_ARM_TAGGED_ADDR_CTRL regset is only visible in the
user_aarch64_view used by a native AArch64 task to manipulate another
native AArch64 task. As get_tagged_addr_ctrl() only returns an error
value when called for a compat task, tagged_addr_ctrl_get() and
tagged_addr_ctrl_set() should never observe an error value from
get_tagged_addr_ctrl(). Add a WARN_ON_ONCE() to both to indicate that
such an error would be unexpected, and error handlnig is not missing in
either case. |
["https://git.kernel.org/stable/c/1152dd13845efde5554f80c7e1233bae1d26bd3e","https://git.kernel.org/stable/c/1370cf3eb5495d70e00547598583a4cd45b40b99","https://git.kernel.org/stable/c/1c176f5155ee6161fee6f416b64aa50394d3f220","https://git.kernel.org/stable/c/96035c0093db258975b8887676afe59a64c34a72","https://git.kernel.org/stable/c/abd614bbfcee73247495bd9472da8f85ac83546e","https://git.kernel.org/stable/c/ca62d90085f4af36de745883faab9f8a7cbb45d3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48698
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: fix memory leak when using debugfs_lookup()
When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. Fix this up by properly
calling dput(). |
["https://git.kernel.org/stable/c/3a6279d243cb035eaaff1450980b40cf19748f05","https://git.kernel.org/stable/c/58acd2ebae034db3bacf38708f508fbd12ae2e54","https://git.kernel.org/stable/c/cbfac7fa491651c57926c99edeb7495c6c1aeac2","https://git.kernel.org/stable/c/3a6279d243cb035eaaff1450980b40cf19748f05","https://git.kernel.org/stable/c/58acd2ebae034db3bacf38708f508fbd12ae2e54","https://git.kernel.org/stable/c/cbfac7fa491651c57926c99edeb7495c6c1aeac2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56672
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
blk-cgroup: Fix UAF in blkcg_unpin_online()
blkcg_unpin_online() walks up the blkcg hierarchy putting the online pin. To
walk up, it uses blkcg_parent(blkcg) but it was calling that after
blkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the
following UAF:
==================================================================
BUG: KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270
Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117
CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty #48
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022
Workqueue: cgwb_release cgwb_release_workfn
Call Trace:
<TASK>
dump_stack_lvl+0x27/0x80
print_report+0x151/0x710
kasan_report+0xc0/0x100
blkcg_unpin_online+0x15a/0x270
cgwb_release_workfn+0x194/0x480
process_scheduled_works+0x71b/0xe20
worker_thread+0x82a/0xbd0
kthread+0x242/0x2c0
ret_from_fork+0x33/0x70
ret_from_fork_asm+0x1a/0x30
</TASK>
...
Freed by task 1944:
kasan_save_track+0x2b/0x70
kasan_save_free_info+0x3c/0x50
__kasan_slab_free+0x33/0x50
kfree+0x10c/0x330
css_free_rwork_fn+0xe6/0xb30
process_scheduled_works+0x71b/0xe20
worker_thread+0x82a/0xbd0
kthread+0x242/0x2c0
ret_from_fork+0x33/0x70
ret_from_fork_asm+0x1a/0x30
Note that the UAF is not easy to trigger as the free path is indirected
behind a couple RCU grace periods and a work item execution. I could only
trigger it with artifical msleep() injected in blkcg_unpin_online().
Fix it by reading the parent pointer before destroying the blkcg's blkg's. |
["https://git.kernel.org/stable/c/29d1e06560f0f6179062ac638b4064deb637d1ad","https://git.kernel.org/stable/c/5baa28569c924d9a90d036c2aaab79f791fedaf8","https://git.kernel.org/stable/c/64afc6fe24c9896c0153e5a199bcea241ecb0d5c","https://git.kernel.org/stable/c/83f5a87ee8caa76a917f59912a74d6811f773c67","https://git.kernel.org/stable/c/86e6ca55b83c575ab0f2e105cf08f98e58d3d7af","https://git.kernel.org/stable/c/8a07350fe070017a887433f4d6909433955be5f1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35888
|
Medium |
fixed |
- 4.19.312
- 5.4.274
- 5.10.215
- 5.15.154
- 6.1.85
- 6.6.26
- 6.8.5
|
In the Linux kernel, the following vulnerability has been resolved:
erspan: make sure erspan_base_hdr is present in skb->head
syzbot reported a problem in ip6erspan_rcv() [1]
Issue is that ip6erspan_rcv() (and erspan_rcv()) no longer make
sure erspan_base_hdr is present in skb linear part (skb->head)
before getting @ver field from it.
Add the missing pskb_may_pull() calls.
v2: Reload iph pointer in erspan_rcv() after pskb_may_pull()
because skb->head might have changed.
[1]
BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]
BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline]
BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]
BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610
pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]
pskb_may_pull include/linux/skbuff.h:2756 [inline]
ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]
gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610
ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438
ip6_input_finish net/ipv6/ip6_input.c:483 [inline]
NF_HOOK include/linux/netfilter.h:314 [inline]
ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492
ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586
dst_input include/net/dst.h:460 [inline]
ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79
NF_HOOK include/linux/netfilter.h:314 [inline]
ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310
__netif_receive_skb_one_core net/core/dev.c:5538 [inline]
__netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652
netif_receive_skb_internal net/core/dev.c:5738 [inline]
netif_receive_skb+0x58/0x660 net/core/dev.c:5798
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549
tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
call_write_iter include/linux/fs.h:2108 [inline]
new_sync_write fs/read_write.c:497 [inline]
vfs_write+0xb63/0x1520 fs/read_write.c:590
ksys_write+0x20f/0x4c0 fs/read_write.c:643
__do_sys_write fs/read_write.c:655 [inline]
__se_sys_write fs/read_write.c:652 [inline]
__x64_sys_write+0x93/0xe0 fs/read_write.c:652
do_syscall_64+0xd5/0x1f0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
Uninit was created at:
slab_post_alloc_hook mm/slub.c:3804 [inline]
slab_alloc_node mm/slub.c:3845 [inline]
kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577
__alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668
alloc_skb include/linux/skbuff.h:1318 [inline]
alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504
sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795
tun_alloc_skb drivers/net/tun.c:1525 [inline]
tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
call_write_iter include/linux/fs.h:2108 [inline]
new_sync_write fs/read_write.c:497 [inline]
vfs_write+0xb63/0x1520 fs/read_write.c:590
ksys_write+0x20f/0x4c0 fs/read_write.c:643
__do_sys_write fs/read_write.c:655 [inline]
__se_sys_write fs/read_write.c:652 [inline]
__x64_sys_write+0x93/0xe0 fs/read_write.c:652
do_syscall_64+0xd5/0x1f0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0 |
["https://git.kernel.org/stable/c/06a939f72a24a7d8251f84cf4c042df86c6666ac","https://git.kernel.org/stable/c/0ac328a5a4138a6c03dfc3f46017bd5c19167446","https://git.kernel.org/stable/c/17af420545a750f763025149fa7b833a4fc8b8f0","https://git.kernel.org/stable/c/1db7fcb2b290c47c202b79528824f119fa28937d","https://git.kernel.org/stable/c/4e3fdeecec5707678b0d1f18c259dadb97262e9d","https://git.kernel.org/stable/c/b14b9f9503ec823ca75be766dcaeff4f0bfeca85","https://git.kernel.org/stable/c/e54a0c79cdc2548729dd7e2e468b08c5af4d0df5","https://git.kernel.org/stable/c/ee0088101beee10fa809716d6245d915b09c37c7","https://git.kernel.org/stable/c/06a939f72a24a7d8251f84cf4c042df86c6666ac","https://git.kernel.org/stable/c/0ac328a5a4138a6c03dfc3f46017bd5c19167446","https://git.kernel.org/stable/c/17af420545a750f763025149fa7b833a4fc8b8f0","https://git.kernel.org/stable/c/1db7fcb2b290c47c202b79528824f119fa28937d","https://git.kernel.org/stable/c/4e3fdeecec5707678b0d1f18c259dadb97262e9d","https://git.kernel.org/stable/c/b14b9f9503ec823ca75be766dcaeff4f0bfeca85","https://git.kernel.org/stable/c/e54a0c79cdc2548729dd7e2e468b08c5af4d0df5","https://git.kernel.org/stable/c/ee0088101beee10fa809716d6245d915b09c37c7","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26756
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
md: Don't register sync_thread for reshape directly
Currently, if reshape is interrupted, then reassemble the array will
register sync_thread directly from pers->run(), in this case
'MD_RECOVERY_RUNNING' is set directly, however, there is no guarantee
that md_do_sync() will be executed, hence stop_sync_thread() will hang
because 'MD_RECOVERY_RUNNING' can't be cleared.
Last patch make sure that md_do_sync() will set MD_RECOVERY_DONE,
however, following hang can still be triggered by dm-raid test
shell/lvconvert-raid-reshape.sh occasionally:
[root@fedora ~]# cat /proc/1982/stack
[<0>] stop_sync_thread+0x1ab/0x270 [md_mod]
[<0>] md_frozen_sync_thread+0x5c/0xa0 [md_mod]
[<0>] raid_presuspend+0x1e/0x70 [dm_raid]
[<0>] dm_table_presuspend_targets+0x40/0xb0 [dm_mod]
[<0>] __dm_destroy+0x2a5/0x310 [dm_mod]
[<0>] dm_destroy+0x16/0x30 [dm_mod]
[<0>] dev_remove+0x165/0x290 [dm_mod]
[<0>] ctl_ioctl+0x4bb/0x7b0 [dm_mod]
[<0>] dm_ctl_ioctl+0x11/0x20 [dm_mod]
[<0>] vfs_ioctl+0x21/0x60
[<0>] __x64_sys_ioctl+0xb9/0xe0
[<0>] do_syscall_64+0xc6/0x230
[<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74
Meanwhile mddev->recovery is:
MD_RECOVERY_RUNNING |
MD_RECOVERY_INTR |
MD_RECOVERY_RESHAPE |
MD_RECOVERY_FROZEN
Fix this problem by remove the code to register sync_thread directly
from raid10 and raid5. And let md_check_recovery() to register
sync_thread. |
["https://git.kernel.org/stable/c/13b520fb62b772e408f9b79c5fe18ad414e90417","https://git.kernel.org/stable/c/ad39c08186f8a0f221337985036ba86731d6aafe","https://git.kernel.org/stable/c/13b520fb62b772e408f9b79c5fe18ad414e90417","https://git.kernel.org/stable/c/ad39c08186f8a0f221337985036ba86731d6aafe"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46750
|
Medium |
fixed |
- 4.19.322
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
PCI: Add missing bridge lock to pci_bus_lock()
One of the true positives that the cfg_access_lock lockdep effort
identified is this sequence:
WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70
RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70
Call Trace:
<TASK>
? __warn+0x8c/0x190
? pci_bridge_secondary_bus_reset+0x5d/0x70
? report_bug+0x1f8/0x200
? handle_bug+0x3c/0x70
? exc_invalid_op+0x18/0x70
? asm_exc_invalid_op+0x1a/0x20
? pci_bridge_secondary_bus_reset+0x5d/0x70
pci_reset_bus+0x1d8/0x270
vmd_probe+0x778/0xa10
pci_device_probe+0x95/0x120
Where pci_reset_bus() users are triggering unlocked secondary bus resets.
Ironically pci_bus_reset(), several calls down from pci_reset_bus(), uses
pci_bus_lock() before issuing the reset which locks everything *but* the
bridge itself.
For the same motivation as adding:
bridge = pci_upstream_bridge(dev);
if (bridge)
pci_dev_lock(bridge);
to pci_reset_function() for the "bus" and "cxl_bus" reset cases, add
pci_dev_lock() for @bus->self to pci_bus_lock().
[bhelgaas: squash in recursive locking deadlock fix from Keith Busch:
https://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com] |
["https://git.kernel.org/stable/c/04e85a3285b0e5c5af6fd2c0fd6e95ffecc01945","https://git.kernel.org/stable/c/0790b89c7e911003b8c50ae50e3ac7645de1fae9","https://git.kernel.org/stable/c/7253b4fed46471cc247c6cacefac890a8472c083","https://git.kernel.org/stable/c/78c6e39fef5c428960aff742149bba302dd46f5a","https://git.kernel.org/stable/c/81c68e218ab883dfa368460a59b674084c0240da","https://git.kernel.org/stable/c/a4e772898f8bf2e7e1cf661a12c60a5612c4afab","https://git.kernel.org/stable/c/df77a678c33871a6e4ac5b54a71662f1d702335b","https://git.kernel.org/stable/c/e2355d513b89a2cb511b4ded0deb426cdb01acd0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53093
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
nvme-multipath: defer partition scanning
We need to suppress the partition scan from occuring within the
controller's scan_work context. If a path error occurs here, the IO will
wait until a path becomes available or all paths are torn down, but that
action also occurs within scan_work, so it would deadlock. Defer the
partion scan to a different context that does not block scan_work. |
["https://git.kernel.org/stable/c/1f021341eef41e77a633186e9be5223de2ce5d48","https://git.kernel.org/stable/c/4a57f42e5ed42cb8f1beb262c4f6d3e698939e4e","https://git.kernel.org/stable/c/60de2e03f984cfbcdc12fa552f95087c35a05a98","https://git.kernel.org/stable/c/a91b7eddf45afeeb9c5ece11dddff5de0921b00f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48850
|
Medium |
fixed |
- 4.9.307
- 4.14.272
- 4.19.235
- 5.4.185
- 5.10.106
- 5.15.29
- 5.16.15
|
In the Linux kernel, the following vulnerability has been resolved:
net-sysfs: add check for netdevice being present to speed_show
When bringing down the netdevice or system shutdown, a panic can be
triggered while accessing the sysfs path because the device is already
removed.
[ 755.549084] mlx5_core 0000:12:00.1: Shutdown was called
[ 756.404455] mlx5_core 0000:12:00.0: Shutdown was called
...
[ 757.937260] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 758.031397] IP: [<ffffffff8ee11acb>] dma_pool_alloc+0x1ab/0x280
crash> bt
...
PID: 12649 TASK: ffff8924108f2100 CPU: 1 COMMAND: "amsd"
...
#9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778
[exception RIP: dma_pool_alloc+0x1ab]
RIP: ffffffff8ee11acb RSP: ffff89240e1a3968 RFLAGS: 00010046
RAX: 0000000000000246 RBX: ffff89243d874100 RCX: 0000000000001000
RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff89243d874090
RBP: ffff89240e1a39c0 R8: 000000000001f080 R9: ffff8905ffc03c00
R10: ffffffffc04680d4 R11: ffffffff8edde9fd R12: 00000000000080d0
R13: ffff89243d874090 R14: ffff89243d874080 R15: 0000000000000000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core]
#11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core]
#12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core]
#13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core]
#14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core]
#15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core]
#16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core]
#17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46
#18 [ffff89240e1a3d48] speed_show at ffffffff8f277208
#19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3
#20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf
#21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596
#22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10
#23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5
#24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff
#25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f
#26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92
crash> net_device.state ffff89443b0c0000
state = 0x5 (__LINK_STATE_START| __LINK_STATE_NOCARRIER)
To prevent this scenario, we also make sure that the netdevice is present. |
["https://git.kernel.org/stable/c/081369ad088a76429984483b8a5f7e967a125aad","https://git.kernel.org/stable/c/3a79f380b3e10edf6caa9aac90163a5d7a282204","https://git.kernel.org/stable/c/4224cfd7fb6523f7a9d1c8bb91bb5df1e38eb624","https://git.kernel.org/stable/c/75fc8363227a999e8f3d17e2eb28dce5600dcd3f","https://git.kernel.org/stable/c/8879b5313e9fa5e0c6d6812a0d25d83aed0110e2","https://git.kernel.org/stable/c/8d5e69d8fbf3a35ab4fbe56b8f092802b43f3ef6","https://git.kernel.org/stable/c/a7b9ab04c5932dee7ec95e0abc58b0df350c0dd2","https://git.kernel.org/stable/c/d15c9f6e3335002fea1c33bc8f71a705fa96976c","https://git.kernel.org/stable/c/081369ad088a76429984483b8a5f7e967a125aad","https://git.kernel.org/stable/c/3a79f380b3e10edf6caa9aac90163a5d7a282204","https://git.kernel.org/stable/c/4224cfd7fb6523f7a9d1c8bb91bb5df1e38eb624","https://git.kernel.org/stable/c/75fc8363227a999e8f3d17e2eb28dce5600dcd3f","https://git.kernel.org/stable/c/8879b5313e9fa5e0c6d6812a0d25d83aed0110e2","https://git.kernel.org/stable/c/8d5e69d8fbf3a35ab4fbe56b8f092802b43f3ef6","https://git.kernel.org/stable/c/a7b9ab04c5932dee7ec95e0abc58b0df350c0dd2","https://git.kernel.org/stable/c/d15c9f6e3335002fea1c33bc8f71a705fa96976c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36969
|
Medium |
fixed |
- 5.15.160
- 6.1.92
- 6.6.32
- 6.8.11
- 6.9.2
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix division by zero in setup_dsc_config
When slice_height is 0, the division by slice_height in the calculation
of the number of slices will cause a division by zero driver crash. This
leaves the kernel in a state that requires a reboot. This patch adds a
check to avoid the division by zero.
The stack trace below is for the 6.8.4 Kernel. I reproduced the issue on
a Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitor
connected via Thunderbolt. The amdgpu driver crashed with this exception
when I rebooted the system with the monitor connected.
kernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447)
kernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154)
kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
kernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175)
kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
kernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2))
kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
kernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548)
kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
kernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpu
After applying this patch, the driver no longer crashes when the monitor
is connected and the system is rebooted. I believe this is the same
issue reported for 3113. |
["https://git.kernel.org/stable/c/130afc8a886183a94cf6eab7d24f300014ff87ba","https://git.kernel.org/stable/c/308de6be0c9c7ba36915c0d398e771725c0ea911","https://git.kernel.org/stable/c/7e4f50dfc98c49b3dc6875a35c3112522fb25639","https://git.kernel.org/stable/c/91402e0e5de9124a3108db7a14163fcf9a6d322f","https://git.kernel.org/stable/c/a32c8f951c8a456c1c251e1dcdf21787f8066445","https://git.kernel.org/stable/c/f187fcbbb8f8bf10c6687f0beae22509369f7563","https://git.kernel.org/stable/c/130afc8a886183a94cf6eab7d24f300014ff87ba","https://git.kernel.org/stable/c/308de6be0c9c7ba36915c0d398e771725c0ea911","https://git.kernel.org/stable/c/7e4f50dfc98c49b3dc6875a35c3112522fb25639","https://git.kernel.org/stable/c/91402e0e5de9124a3108db7a14163fcf9a6d322f","https://git.kernel.org/stable/c/a32c8f951c8a456c1c251e1dcdf21787f8066445","https://git.kernel.org/stable/c/f187fcbbb8f8bf10c6687f0beae22509369f7563"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42069
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: mana: Fix possible double free in error handling path
When auxiliary_device_add() returns error and then calls
auxiliary_device_uninit(), callback function adev_release
calls kfree(madev). We shouldn't call kfree(madev) again
in the error handling path. Set 'madev' to NULL. |
["https://git.kernel.org/stable/c/1864b8224195d0e43ddb92a8151f54f6562090cc","https://git.kernel.org/stable/c/3243e64eb4d897c3eeb48b2a7221ab5a95e1282a","https://git.kernel.org/stable/c/ed45c0a0b662079d4c0e518014cc148c753979b4","https://git.kernel.org/stable/c/1864b8224195d0e43ddb92a8151f54f6562090cc","https://git.kernel.org/stable/c/3243e64eb4d897c3eeb48b2a7221ab5a95e1282a","https://git.kernel.org/stable/c/ed45c0a0b662079d4c0e518014cc148c753979b4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49899
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Initialize denominators' default to 1
[WHAT & HOW]
Variables used as denominators and maybe not assigned to other values,
should not be 0. Change their default to 1 so they are never 0.
This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity. |
["https://git.kernel.org/stable/c/7f8e93b862aba08d540f1e9e03e0ceb4d0cfd5fb","https://git.kernel.org/stable/c/9be768f08b16f020da376538b08463ac3a2ce8cd","https://git.kernel.org/stable/c/9f35cec5e4b9759b38c663d18eae4eaf30f36527","https://git.kernel.org/stable/c/b995c0a6de6c74656a0c39cd57a0626351b13e3c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-39190
|
Medium |
fixed |
|
An issue was discovered in net/netfilter/nf_tables_api.c in the Linux kernel before 5.19.6. A denial of service can occur upon binding to an already bound chain. |
["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.6","https://github.com/torvalds/linux/commit/e02f0d3970404bfea385b6edb86f2d936db0ea2b","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/all/20220824220330.64283-12-pablo%40netfilter.org/","https://twitter.com/pr0Ln","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.6","https://github.com/torvalds/linux/commit/e02f0d3970404bfea385b6edb86f2d936db0ea2b","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/all/20220824220330.64283-12-pablo%40netfilter.org/","https://twitter.com/pr0Ln"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49937
|
Medium |
fixed |
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: Set correct chandef when starting CAC
When starting CAC in a mode other than AP mode, it return a
"WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]"
caused by the chandef.chan being null at the end of CAC.
Solution: Ensure the channel definition is set for the different modes
when starting CAC to avoid getting a NULL 'chan' at the end of CAC.
Call Trace:
? show_regs.part.0+0x14/0x16
? __warn+0x67/0xc0
? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]
? report_bug+0xa7/0x130
? exc_overflow+0x30/0x30
? handle_bug+0x27/0x50
? exc_invalid_op+0x18/0x60
? handle_exception+0xf6/0xf6
? exc_overflow+0x30/0x30
? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]
? exc_overflow+0x30/0x30
? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]
? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211]
? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211]
? process_one_work+0x165/0x280
? worker_thread+0x120/0x3f0
? kthread+0xc2/0xf0
? process_one_work+0x280/0x280
? kthread_complete_and_exit+0x20/0x20
? ret_from_fork+0x19/0x24
[shorten subject, remove OCB, reorder cases to match previous list] |
["https://git.kernel.org/stable/c/04053e55dd50741cf6c59b9bbaa4238218c05c70","https://git.kernel.org/stable/c/20361712880396e44ce80aaeec2d93d182035651","https://git.kernel.org/stable/c/95f32191e50b75e0f75fae1bb925cdf51d8df0a3","https://git.kernel.org/stable/c/c628026563f4ea9e0413dd4b69429e4a1db240b1","https://git.kernel.org/stable/c/f4dbfda159e43d49b43003cc3c2914751939035f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41012
|
Medium |
fixed |
- 4.19.319
- 5.4.281
- 5.10.223
- 5.15.164
- 6.1.101
- 6.6.42
- 6.9.9
|
In the Linux kernel, the following vulnerability has been resolved:
filelock: Remove locks reliably when fcntl/close race is detected
When fcntl_setlk() races with close(), it removes the created lock with
do_lock_file_wait().
However, LSMs can allow the first do_lock_file_wait() that created the lock
while denying the second do_lock_file_wait() that tries to remove the lock.
Separately, posix_lock_file() could also fail to
remove a lock due to GFP_KERNEL allocation failure (when splitting a range
in the middle).
After the bug has been triggered, use-after-free reads will occur in
lock_get_status() when userspace reads /proc/locks. This can likely be used
to read arbitrary kernel memory, but can't corrupt kernel memory.
Fix it by calling locks_remove_posix() instead, which is designed to
reliably get rid of POSIX locks associated with the given file and
files_struct and is also used by filp_flush(). |
["https://git.kernel.org/stable/c/3cad1bc010416c6dd780643476bc59ed742436b9","https://git.kernel.org/stable/c/52c87ab18c76c14d7209646ccb3283b3f5d87b22","https://git.kernel.org/stable/c/5661b9c7ec189406c2dde00837aaa4672efb6240","https://git.kernel.org/stable/c/5f5d0799eb0a01d550c21b7894e26b2d9db55763","https://git.kernel.org/stable/c/b6d223942c34057fdfd8f149e763fa823731b224","https://git.kernel.org/stable/c/d30ff33040834c3b9eee29740acd92f9c7ba2250","https://git.kernel.org/stable/c/dc2ce1dfceaa0767211a9d963ddb029ab21c4235","https://git.kernel.org/stable/c/ef8fc41cd6f95f9a4a3470f085aecf350569a0b3","https://git.kernel.org/stable/c/3cad1bc010416c6dd780643476bc59ed742436b9","https://git.kernel.org/stable/c/52c87ab18c76c14d7209646ccb3283b3f5d87b22","https://git.kernel.org/stable/c/5661b9c7ec189406c2dde00837aaa4672efb6240","https://git.kernel.org/stable/c/5f5d0799eb0a01d550c21b7894e26b2d9db55763","https://git.kernel.org/stable/c/b6d223942c34057fdfd8f149e763fa823731b224","https://git.kernel.org/stable/c/d30ff33040834c3b9eee29740acd92f9c7ba2250","https://git.kernel.org/stable/c/dc2ce1dfceaa0767211a9d963ddb029ab21c4235","https://git.kernel.org/stable/c/ef8fc41cd6f95f9a4a3470f085aecf350569a0b3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49924
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
fbdev: pxafb: Fix possible use after free in pxafb_task()
In the pxafb_probe function, it calls the pxafb_init_fbinfo function,
after which &fbi->task is associated with pxafb_task. Moreover,
within this pxafb_init_fbinfo function, the pxafb_blank function
within the &pxafb_ops struct is capable of scheduling work.
If we remove the module which will call pxafb_remove to make cleanup,
it will call unregister_framebuffer function which can call
do_unregister_framebuffer to free fbi->fb through
put_fb_info(fb_info), while the work mentioned above will be used.
The sequence of operations that may lead to a UAF bug is as follows:
CPU0 CPU1
| pxafb_task
pxafb_remove |
unregister_framebuffer(info) |
do_unregister_framebuffer(fb_info) |
put_fb_info(fb_info) |
// free fbi->fb | set_ctrlr_state(fbi, state)
| __pxafb_lcd_power(fbi, 0)
| fbi->lcd_power(on, &fbi->fb.var)
| //use fbi->fb
Fix it by ensuring that the work is canceled before proceeding
with the cleanup in pxafb_remove.
Note that only root user can remove the driver at runtime. |
["https://git.kernel.org/stable/c/3c0d416eb4bef705f699213cee94bf54b6acdacd","https://git.kernel.org/stable/c/4a6921095eb04a900e0000da83d9475eb958e61e","https://git.kernel.org/stable/c/4cda484e584be34d55ee17436ebf7ad11922b97a","https://git.kernel.org/stable/c/6d0a07f68b66269e167def6c0b90a219cd3e7473","https://git.kernel.org/stable/c/a3a855764dbacbdb1cc51e15dc588f2d21c93e0e","https://git.kernel.org/stable/c/aaadc0cb05c999ccd8898a03298b7e5c31509b08","https://git.kernel.org/stable/c/e657fa2df4429f3805a9b3e47fb1a4a1b02a72bd","https://git.kernel.org/stable/c/e6897e299f57b103e999e62010b88e363b3eebae","https://git.kernel.org/stable/c/fdda354f60a576d52dcf90351254714681df4370"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50007
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: asihpi: Fix potential OOB array access
ASIHPI driver stores some values in the static array upon a response
from the driver, and its index depends on the firmware. We shouldn't
trust it blindly.
This patch adds a sanity check of the array index to fit in the array
size. |
["https://git.kernel.org/stable/c/219587bca2678e31700ef09ecec178ba1f735674","https://git.kernel.org/stable/c/36ee4021bcc37b834996e79740d095d6f8dd948f","https://git.kernel.org/stable/c/7a55740996701f7b2bc46dc988b60ef2e416a747","https://git.kernel.org/stable/c/7b986c7430a6bb68d523dac7bfc74cbd5b44ef96","https://git.kernel.org/stable/c/876d04bf5a8ac1d6af5afd258cd37ab83ab2cf3d","https://git.kernel.org/stable/c/a6bdb691cf7b66dcd929de1a253c5c42edd2e522","https://git.kernel.org/stable/c/ad7248a5e92587b9266c62db8bcc4e58de53e372","https://git.kernel.org/stable/c/ce2953e44829ec54bcbb57e9d890fc8af0900c80","https://git.kernel.org/stable/c/e658227d9d4f4e122d81690fdbc0d438b10288f5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53142
|
High |
fixed |
- 4.19.325
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
initramfs: avoid filename buffer overrun
The initramfs filename field is defined in
Documentation/driver-api/early-userspace/buffer-format.rst as:
37 cpio_file := ALGN(4) + cpio_header + filename + "\0" + ALGN(4) + data
...
55 ============= ================== =========================
56 Field name Field size Meaning
57 ============= ================== =========================
...
70 c_namesize 8 bytes Length of filename, including final \0
When extracting an initramfs cpio archive, the kernel's do_name() path
handler assumes a zero-terminated path at @collected, passing it
directly to filp_open() / init_mkdir() / init_mknod().
If a specially crafted cpio entry carries a non-zero-terminated filename
and is followed by uninitialized memory, then a file may be created with
trailing characters that represent the uninitialized memory. The ability
to create an initramfs entry would imply already having full control of
the system, so the buffer overrun shouldn't be considered a security
vulnerability.
Append the output of the following bash script to an existing initramfs
and observe any created /initramfs_test_fname_overrunAA* path. E.g.
./reproducer.sh | gzip >> /myinitramfs
It's easiest to observe non-zero uninitialized memory when the output is
gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(),
rather than the initrd_start+initrd_size block.
---- reproducer.sh ----
nilchar="A" # change to "\0" to properly zero terminate / pad
magic="070701"
ino=1
mode=$(( 0100777 ))
uid=0
gid=0
nlink=1
mtime=1
filesize=0
devmajor=0
devminor=1
rdevmajor=0
rdevminor=0
csum=0
fname="initramfs_test_fname_overrun"
namelen=$(( ${#fname} + 1 )) # plus one to account for terminator
printf "%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s" \
$magic $ino $mode $uid $gid $nlink $mtime $filesize \
$devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname
termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) ))
printf "%.s${nilchar}" $(seq 1 $termpadlen)
---- reproducer.sh ----
Symlink filename fields handled in do_symlink() won't overrun past the
data segment, due to the explicit zero-termination of the symlink
target.
Fix filename buffer overrun by aborting the initramfs FSM if any cpio
entry doesn't carry a zero-terminator at the expected (name_len - 1)
offset. |
["https://git.kernel.org/stable/c/1a423bbbeaf9e3e20c4686501efd9b661fe834db","https://git.kernel.org/stable/c/49d01e736c3045319e030d1e75fb983011abaca7","https://git.kernel.org/stable/c/6983b8ac787b3add5571cda563574932a59a99bb","https://git.kernel.org/stable/c/bb7ac96670ab1d8d681015f9d66e45dad579af4d","https://git.kernel.org/stable/c/c509b1acbd867d9e09580fe059a924cb5825afb1","https://git.kernel.org/stable/c/d3df9f26cff97beaa5643e551031795d5d5cddbe","https://git.kernel.org/stable/c/e017671f534dd3f568db9e47b0583e853d2da9b5","https://git.kernel.org/stable/c/f892ddcf9f645380c358e73653cb0900f6bc9eb8","https://git.kernel.org/stable/c/fb83b093f75806333b6f4ae29b158d2e0e3ec971"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40902
|
High |
fixed |
- 4.19.317
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.95
- 6.6.35
- 6.9.6
|
In the Linux kernel, the following vulnerability has been resolved:
jfs: xattr: fix buffer overflow for invalid xattr
When an xattr size is not what is expected, it is printed out to the
kernel log in hex format as a form of debugging. But when that xattr
size is bigger than the expected size, printing it out can cause an
access off the end of the buffer.
Fix this all up by properly restricting the size of the debug hex dump
in the kernel log. |
["https://git.kernel.org/stable/c/1e84c9b1838152a87cf453270a5fa75c5037e83a","https://git.kernel.org/stable/c/33aecc5799c93d3ee02f853cb94e201f9731f123","https://git.kernel.org/stable/c/4598233d9748fe4db4e13b9f473588aa25e87d69","https://git.kernel.org/stable/c/480e5bc21f2c42d90c2c16045d64d824dcdd5ec7","https://git.kernel.org/stable/c/7c55b78818cfb732680c4a72ab270cc2d2ee3d0f","https://git.kernel.org/stable/c/b537cb2f4c4a1357479716a9c339c0bda03d873f","https://git.kernel.org/stable/c/f0dedb5c511ed82cbaff4997a8decf2351ba549f","https://git.kernel.org/stable/c/fc745f6e83cb650f9a5f2c864158e3a5ea76dad0","https://git.kernel.org/stable/c/1e84c9b1838152a87cf453270a5fa75c5037e83a","https://git.kernel.org/stable/c/33aecc5799c93d3ee02f853cb94e201f9731f123","https://git.kernel.org/stable/c/4598233d9748fe4db4e13b9f473588aa25e87d69","https://git.kernel.org/stable/c/480e5bc21f2c42d90c2c16045d64d824dcdd5ec7","https://git.kernel.org/stable/c/7c55b78818cfb732680c4a72ab270cc2d2ee3d0f","https://git.kernel.org/stable/c/b537cb2f4c4a1357479716a9c339c0bda03d873f","https://git.kernel.org/stable/c/f0dedb5c511ed82cbaff4997a8decf2351ba549f","https://git.kernel.org/stable/c/fc745f6e83cb650f9a5f2c864158e3a5ea76dad0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50112
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
x86/lam: Disable ADDRESS_MASKING in most cases
Linear Address Masking (LAM) has a weakness related to transient
execution as described in the SLAM paper[1]. Unless Linear Address
Space Separation (LASS) is enabled this weakness may be exploitable.
Until kernel adds support for LASS[2], only allow LAM for COMPILE_TEST,
or when speculation mitigations have been disabled at compile time,
otherwise keep LAM disabled.
There are no processors in market that support LAM yet, so currently
nobody is affected by this issue.
[1] SLAM: https://download.vusec.net/papers/slam_sp24.pdf
[2] LASS: https://lore.kernel.org/lkml/20230609183632.48706-1-alexander.shishkin@linux.intel.com/
[ dhansen: update SPECULATION_MITIGATIONS -> CPU_MITIGATIONS ] |
["https://git.kernel.org/stable/c/3267cb6d3a174ff83d6287dcd5b0047bbd912452","https://git.kernel.org/stable/c/60a5ba560f296ad8da153f6ad3f70030bfa3958f","https://git.kernel.org/stable/c/690599066488d16db96ac0d6340f9372fc56f337"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21687
|
High |
fixed |
- 5.4.290
- 5.10.234
- 5.15.178
- 6.1.128
- 6.6.75
- 6.12.12
|
In the Linux kernel, the following vulnerability has been resolved:
vfio/platform: check the bounds of read/write syscalls
count and offset are passed from user space and not checked, only
offset is capped to 40 bits, which can be used to read/write out of
bounds of the device. |
["https://git.kernel.org/stable/c/1485932496a1b025235af8aa1e21988d6b7ccd54","https://git.kernel.org/stable/c/665cfd1083866f87301bbd232cb8ba48dcf4acce","https://git.kernel.org/stable/c/6bcb8a5b70b80143db9bf12dfa7d53636f824d53","https://git.kernel.org/stable/c/92340e6c5122d823ad064984ef7513eba9204048","https://git.kernel.org/stable/c/9377cdc118cf327248f1a9dde7b87de067681dc9","https://git.kernel.org/stable/c/a20fcaa230f7472456d12cf761ed13938e320ac3","https://git.kernel.org/stable/c/c981c32c38af80737a2fedc16e270546d139ccdd","https://git.kernel.org/stable/c/ce9ff21ea89d191e477a02ad7eabf4f996b80a69","https://git.kernel.org/stable/c/d19a8650fd3d7aed8d1af1d9a77f979a8430eba1","https://git.kernel.org/stable/c/ed81d82bb6e9df3a137f2c343ed689e6c68268ef","https://git.kernel.org/stable/c/f21636f24b6786c8b13f1af4319fa75ffcf17f38","https://git.kernel.org/stable/c/f65ce06387f8c1fb54bd59e18a8428248ec68eaf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49023
|
High |
fixed |
- 5.4.226
- 5.10.158
- 5.15.82
- 6.0.12
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: fix buffer overflow in elem comparison
For vendor elements, the code here assumes that 5 octets
are present without checking. Since the element itself is
already checked to fit, we only need to check the length. |
["https://git.kernel.org/stable/c/391cb872553627bdcf236c03ee7d5adb275e37e1","https://git.kernel.org/stable/c/88a6fe3707888bd1893e9741157a7035c4159ab6","https://git.kernel.org/stable/c/9e6b79a3cd17620d467311b30d56f2648f6880aa","https://git.kernel.org/stable/c/9f16b5c82a025cd4c864737409234ddc44fb166a","https://git.kernel.org/stable/c/f5c2ec288a865dbe3706b09bed12302e9f6d696b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-58002
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
media: uvcvideo: Remove dangling pointers
When an async control is written, we copy a pointer to the file handle
that started the operation. That pointer will be used when the device is
done. Which could be anytime in the future.
If the user closes that file descriptor, its structure will be freed,
and there will be one dangling pointer per pending async control, that
the driver will try to use.
Clean all the dangling pointers during release().
To avoid adding a performance penalty in the most common case (no async
operation), a counter has been introduced with some logic to make sure
that it is properly handled. |
["https://git.kernel.org/stable/c/117f7a2975baa4b7d702d3f4830d5a4ebd0c6d50","https://git.kernel.org/stable/c/221cd51efe4565501a3dbf04cc011b537dcce7fb","https://git.kernel.org/stable/c/2a29413ace64627e178fd422dd8a5d95219a2c0b","https://git.kernel.org/stable/c/438bda062b2c40ddd7df23b932e29ffe0a448cac","https://git.kernel.org/stable/c/4dbaa738c583a0e947803c69e8996e88cf98d971","https://git.kernel.org/stable/c/653993f46861f2971e95e9a0e36a34b49dec542c","https://git.kernel.org/stable/c/9edc7d25f7e49c33a1ce7a5ffadea2222065516c","https://git.kernel.org/stable/c/ac18d781466252cd35a3e311e0a4b264260fd927"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21785
|
High |
fixed |
- 6.1.129
- 6.6.79
- 6.12.16
- 6.13.4
|
In the Linux kernel, the following vulnerability has been resolved:
arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array
The loop that detects/populates cache information already has a bounds
check on the array size but does not account for cache levels with
separate data/instructions cache. Fix this by incrementing the index
for any populated leaf (instead of any populated level). |
["https://git.kernel.org/stable/c/4371ac7b494e933fffee2bd6265d18d73c4f05aa","https://git.kernel.org/stable/c/4ff25f0b18d1d0174c105e4620428bcdc1213860","https://git.kernel.org/stable/c/67b99a2b5811df4294c2ad50f9bff3b6a08bd618","https://git.kernel.org/stable/c/715eb1af64779e1b1aa0a7b2ffb81414d9f708e5","https://git.kernel.org/stable/c/875d742cf5327c93cba1f11e12b08d3cce7a88d2","https://git.kernel.org/stable/c/88a3e6afaf002250220793df99404977d343db14","https://git.kernel.org/stable/c/ab90894f33c15b14c1cee6959ab6c8dcb09127f8","https://git.kernel.org/stable/c/e4fde33107351ec33f1a64188612fbc6ca659284"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21858
|
High |
fixed |
- 6.1.130
- 6.6.80
- 6.12.17
- 6.13.5
|
In the Linux kernel, the following vulnerability has been resolved:
geneve: Fix use-after-free in geneve_find_dev().
syzkaller reported a use-after-free in geneve_find_dev() [0]
without repro.
geneve_configure() links struct geneve_dev.next to
net_generic(net, geneve_net_id)->geneve_list.
The net here could differ from dev_net(dev) if IFLA_NET_NS_PID,
IFLA_NET_NS_FD, or IFLA_TARGET_NETNSID is set.
When dev_net(dev) is dismantled, geneve_exit_batch_rtnl() finally
calls unregister_netdevice_queue() for each dev in the netns,
and later the dev is freed.
However, its geneve_dev.next is still linked to the backend UDP
socket netns.
Then, use-after-free will occur when another geneve dev is created
in the netns.
Let's call geneve_dellink() instead in geneve_destroy_tunnels().
[0]:
BUG: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline]
BUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343
Read of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441
CPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3d
Hardware name: linux,dummy-virt (DT)
Call trace:
show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C)
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0x16c/0x6f0 mm/kasan/report.c:489
kasan_report+0xc0/0x120 mm/kasan/report.c:602
__asan_report_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379
geneve_find_dev drivers/net/geneve.c:1295 [inline]
geneve_configure+0x234/0x858 drivers/net/geneve.c:1343
geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634
rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795
__rtnl_newlink net/core/rtnetlink.c:3906 [inline]
rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021
rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911
netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543
rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938
netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline]
netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348
netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892
sock_sendmsg_nosec net/socket.c:713 [inline]
__sock_sendmsg net/socket.c:728 [inline]
____sys_sendmsg+0x410/0x6f8 net/socket.c:2568
___sys_sendmsg+0x178/0x1d8 net/socket.c:2622
__sys_sendmsg net/socket.c:2654 [inline]
__do_sys_sendmsg net/socket.c:2659 [inline]
__se_sys_sendmsg net/socket.c:2657 [inline]
__arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657
__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49
el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132
do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151
el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744
el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762
el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600
Allocated by task 13247:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x30/0x68 mm/kasan/common.c:68
kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568
poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
__kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394
kasan_kmalloc include/linux/kasan.h:260 [inline]
__do_kmalloc_node mm/slub.c:4298 [inline]
__kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304
__kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645
alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470
rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604
rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780
__rtnl_newlink net/core/rtnetlink.c:3906 [inline]
rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021
rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911
netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543
rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938
netlink_unicast_kernel net/netlink/af_n
---truncated--- |
["https://git.kernel.org/stable/c/3ce92ca990cfac88a87c61df3cc0b5880e688ecf","https://git.kernel.org/stable/c/5a0538ac6826807d6919f6aecbb8996c2865af2c","https://git.kernel.org/stable/c/788dbca056a8783ec063da3c9d49a3a71c76c283","https://git.kernel.org/stable/c/904e746b2e7fa952ab8801b303ce826a63153d78","https://git.kernel.org/stable/c/9593172d93b9f91c362baec4643003dc29802929","https://git.kernel.org/stable/c/d5e86e27de0936f3cb0a299ce519d993e9cf3886","https://git.kernel.org/stable/c/da9b0ae47f084014b1e4b3f31f70a0defd047ff3","https://git.kernel.org/stable/c/f74f6560146714241c6e167b03165ee77a86e316"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48990
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix use-after-free during gpu recovery
[Why]
[ 754.862560] refcount_t: underflow; use-after-free.
[ 754.862898] Call Trace:
[ 754.862903] <TASK>
[ 754.862913] amdgpu_job_free_cb+0xc2/0xe1 [amdgpu]
[ 754.863543] drm_sched_main.cold+0x34/0x39 [amd_sched]
[How]
The fw_fence may be not init, check whether dma_fence_init
is performed before job free |
["https://git.kernel.org/stable/c/3cb93f390453cde4d6afda1587aaa00e75e09617","https://git.kernel.org/stable/c/d2a89cd942edd50c1e652004fd64019be78b0a96"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-2007
|
High |
fixed |
|
The specific flaw exists within the DPT I2O Controller driver. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this in conjunction with other vulnerabilities to escalate privileges and execute arbitrary code in the context of the kernel. |
["https://github.com/torvalds/linux/commit/b04e75a4a8a81887386a0d2dbf605a48e779d2a0","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20240119-0011/","https://www.debian.org/security/2023/dsa-5480","https://github.com/torvalds/linux/commit/b04e75a4a8a81887386a0d2dbf605a48e779d2a0","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20240119-0011/","https://www.debian.org/security/2023/dsa-5480"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-47521
|
High |
fixed |
|
An issue was discovered in the Linux kernel before 6.0.11. Missing validation of IEEE80211_P2P_ATTR_CHANNEL_LIST in drivers/net/wireless/microchip/wilc1000/cfg80211.c in the WILC1000 wireless driver can trigger a heap-based buffer overflow when parsing the operating channel attribute from Wi-Fi management frames. |
["https://github.com/torvalds/linux/commit/f9b62f9843c7b0afdaecabbcebf1dbba18599408","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lore.kernel.org/r/20221123153543.8568-4-philipturnbull%40github.com","https://security.netapp.com/advisory/ntap-20230113-0007/","https://github.com/torvalds/linux/commit/f9b62f9843c7b0afdaecabbcebf1dbba18599408","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lore.kernel.org/r/20221123153543.8568-4-philipturnbull%40github.com","https://security.netapp.com/advisory/ntap-20230113-0007/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26608
|
High |
fixed |
- 5.15.149
- 6.1.76
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix global oob in ksmbd_nl_policy
Similar to a reported issue (check the commit b33fb5b801c6 ("net:
qualcomm: rmnet: fix global oob in rmnet_policy"), my local fuzzer finds
another global out-of-bounds read for policy ksmbd_nl_policy. See bug
trace below:
==================================================================
BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]
BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
Read of size 1 at addr ffffffff8f24b100 by task syz-executor.1/62810
CPU: 0 PID: 62810 Comm: syz-executor.1 Tainted: G N 6.1.0 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:284 [inline]
print_report+0x172/0x475 mm/kasan/report.c:395
kasan_report+0xbb/0x1c0 mm/kasan/report.c:495
validate_nla lib/nlattr.c:386 [inline]
__nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
__nla_parse+0x3e/0x50 lib/nlattr.c:697
__nlmsg_parse include/net/netlink.h:748 [inline]
genl_family_rcv_msg_attrs_parse.constprop.0+0x1b0/0x290 net/netlink/genetlink.c:565
genl_family_rcv_msg_doit+0xda/0x330 net/netlink/genetlink.c:734
genl_family_rcv_msg net/netlink/genetlink.c:833 [inline]
genl_rcv_msg+0x441/0x780 net/netlink/genetlink.c:850
netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540
genl_rcv+0x24/0x40 net/netlink/genetlink.c:861
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg+0x154/0x190 net/socket.c:734
____sys_sendmsg+0x6df/0x840 net/socket.c:2482
___sys_sendmsg+0x110/0x1b0 net/socket.c:2536
__sys_sendmsg+0xf3/0x1c0 net/socket.c:2565
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fdd66a8f359
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fdd65e00168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007fdd66bbcf80 RCX: 00007fdd66a8f359
RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000003
RBP: 00007fdd66ada493 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffc84b81aff R14: 00007fdd65e00300 R15: 0000000000022000
</TASK>
The buggy address belongs to the variable:
ksmbd_nl_policy+0x100/0xa80
The buggy address belongs to the physical page:
page:0000000034f47940 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1ccc4b
flags: 0x200000000001000(reserved|node=0|zone=2)
raw: 0200000000001000 ffffea00073312c8 ffffea00073312c8 0000000000000000
raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffffffff8f24b000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffffffff8f24b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffffff8f24b100: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 00 00 07 f9
^
ffffffff8f24b180: f9 f9 f9 f9 00 05 f9 f9 f9 f9 f9 f9 00 00 00 05
ffffffff8f24b200: f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 00 00 04 f9
==================================================================
To fix it, add a placeholder named __KSMBD_EVENT_MAX and let
KSMBD_EVENT_MAX to be its original value - 1 according to what other
netlink families do. Also change two sites that refer the
KSMBD_EVENT_MAX to correct value. |
["https://git.kernel.org/stable/c/2c939c74ef0b74e99b92e32edc2a59f9b9ca3d5a","https://git.kernel.org/stable/c/6993328a4cd62a24df254b587c0796a4a1eecc95","https://git.kernel.org/stable/c/9863a53100f47652755545c2bd43e14a1855104d","https://git.kernel.org/stable/c/aaa1f1a2ee80888c12ae2783f3a0be10e14067c5","https://git.kernel.org/stable/c/ebeae8adf89d9a82359f6659b1663d09beec2faa","https://git.kernel.org/stable/c/2c939c74ef0b74e99b92e32edc2a59f9b9ca3d5a","https://git.kernel.org/stable/c/6993328a4cd62a24df254b587c0796a4a1eecc95","https://git.kernel.org/stable/c/9863a53100f47652755545c2bd43e14a1855104d","https://git.kernel.org/stable/c/aaa1f1a2ee80888c12ae2783f3a0be10e14067c5","https://git.kernel.org/stable/c/ebeae8adf89d9a82359f6659b1663d09beec2faa"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52870
|
Medium |
fixed |
- 5.10.201
- 5.15.139
- 6.1.63
- 6.5.12
- 6.6.2
|
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt6765: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to
avoid NULL pointer dereference. |
["https://git.kernel.org/stable/c/10cc81124407d862f0f747db4baa9c006510b480","https://git.kernel.org/stable/c/2617aa8ceaf30e41d3eb7f5fef3445542bef193a","https://git.kernel.org/stable/c/533ca5153ad6c7b7d47ae0114b14d0333964b946","https://git.kernel.org/stable/c/b5ff3e89b4e7f46ad2aa0de7e08d18e6f87d71bc","https://git.kernel.org/stable/c/b82681042724924ae3ba0f2f2eeec217fa31e830","https://git.kernel.org/stable/c/dd1f30d68fa98eb672c0a259297b761656a9025f","https://git.kernel.org/stable/c/10cc81124407d862f0f747db4baa9c006510b480","https://git.kernel.org/stable/c/2617aa8ceaf30e41d3eb7f5fef3445542bef193a","https://git.kernel.org/stable/c/533ca5153ad6c7b7d47ae0114b14d0333964b946","https://git.kernel.org/stable/c/b5ff3e89b4e7f46ad2aa0de7e08d18e6f87d71bc","https://git.kernel.org/stable/c/b82681042724924ae3ba0f2f2eeec217fa31e830","https://git.kernel.org/stable/c/dd1f30d68fa98eb672c0a259297b761656a9025f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3565
|
High |
fixed |
- 4.9.331
- 4.14.296
- 4.19.262
- 5.4.220
- 5.10.150
- 5.15.75
- 5.19.17
- 6.0.3
|
A vulnerability, which was classified as critical, has been found in Linux Kernel. Affected by this issue is the function del_timer of the file drivers/isdn/mISDN/l1oip_core.c of the component Bluetooth. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211088. |
["https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=2568a7e0832ee30b0a351016d03062ab4e0e0a3f","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://vuldb.com/?id.211088","https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=2568a7e0832ee30b0a351016d03062ab4e0e0a3f","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://vuldb.com/?id.211088"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1671
|
High |
fixed |
|
A NULL pointer dereference flaw was found in rxrpc_preparse_s in net/rxrpc/server_key.c in the Linux kernel. This flaw allows a local attacker to crash the system or leak internal kernel information. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff8376ade4f668130385839cef586a0990f8ef87","https://security.netapp.com/advisory/ntap-20220901-0004/","https://security.netapp.com/advisory/ntap-20220901-0008/","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff8376ade4f668130385839cef586a0990f8ef87","https://security.netapp.com/advisory/ntap-20220901-0004/","https://security.netapp.com/advisory/ntap-20220901-0008/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48966
|
High |
fixed |
- 4.9.336
- 4.14.302
- 4.19.269
- 5.4.227
- 5.10.159
- 5.15.83
- 6.0.13
|
In the Linux kernel, the following vulnerability has been resolved:
net: mvneta: Prevent out of bounds read in mvneta_config_rss()
The pp->indir[0] value comes from the user. It is passed to:
if (cpu_online(pp->rxq_def))
inside the mvneta_percpu_elect() function. It needs bounds checkeding
to ensure that it is not beyond the end of the cpu bitmap. |
["https://git.kernel.org/stable/c/146ebee8fcdb349d7ec0e49915e6cdafb92544ae","https://git.kernel.org/stable/c/3ceffb8f410b93553fb16fe7e84aa0d35b3ba79b","https://git.kernel.org/stable/c/47a1a2f6cd5ec3a4f8a2d9bfa1e0605347cdb92c","https://git.kernel.org/stable/c/5a142486a0db6b0b85031f22d69acd0cdcf8f72b","https://git.kernel.org/stable/c/6ca0a506dddc3e1d636935eef339576b263bf3d8","https://git.kernel.org/stable/c/a6b30598fec84f8809f5417cde73071ca43e8471","https://git.kernel.org/stable/c/e8b4fc13900b8e8be48debffd0dfd391772501f7","https://git.kernel.org/stable/c/eec1fc21edc2bb99c9e66cf66f0b5d4d643fbb50"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49031
|
High |
fixed |
- 4.9.335
- 4.14.301
- 4.19.268
- 5.4.226
- 5.10.158
- 5.15.82
- 6.0.12
|
In the Linux kernel, the following vulnerability has been resolved:
iio: health: afe4403: Fix oob read in afe4403_read_raw
KASAN report out-of-bounds read as follows:
BUG: KASAN: global-out-of-bounds in afe4403_read_raw+0x42e/0x4c0
Read of size 4 at addr ffffffffc02ac638 by task cat/279
Call Trace:
afe4403_read_raw
iio_read_channel_info
dev_attr_show
The buggy address belongs to the variable:
afe4403_channel_leds+0x18/0xffffffffffffe9e0
This issue can be reproduced by singe command:
$ cat /sys/bus/spi/devices/spi0.0/iio\:device0/in_intensity6_raw
The array size of afe4403_channel_leds is less than channels, so access
with chan->address cause OOB read in afe4403_read_raw. Fix it by moving
access before use it. |
["https://git.kernel.org/stable/c/06c6ce21cec77dfa860d57e7a006000a57812efb","https://git.kernel.org/stable/c/2d6a437064ffbe685c67ddb16dfc0946074c6c3f","https://git.kernel.org/stable/c/58143c1ed5882c138a3cd2251a336fc8755f23d9","https://git.kernel.org/stable/c/726fa3e4ab97dcff1c745bdc4fb137366cb8d3df","https://git.kernel.org/stable/c/98afcb5f3be645d330c74c5194ba0d80e26f95e0","https://git.kernel.org/stable/c/b1756af172fb80a3edc143772d49e166ec691b6c","https://git.kernel.org/stable/c/c9268df36818ee4eaaaeadc80009b442a5ca69c9","https://git.kernel.org/stable/c/e7e76a77aabef8989cbc0a8417af1aa040620867"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49032
|
High |
fixed |
- 4.9.335
- 4.14.301
- 4.19.268
- 5.4.226
- 5.10.158
- 5.15.82
- 6.0.12
|
In the Linux kernel, the following vulnerability has been resolved:
iio: health: afe4404: Fix oob read in afe4404_[read|write]_raw
KASAN report out-of-bounds read as follows:
BUG: KASAN: global-out-of-bounds in afe4404_read_raw+0x2ce/0x380
Read of size 4 at addr ffffffffc00e4658 by task cat/278
Call Trace:
afe4404_read_raw
iio_read_channel_info
dev_attr_show
The buggy address belongs to the variable:
afe4404_channel_leds+0x18/0xffffffffffffe9c0
This issue can be reproduce by singe command:
$ cat /sys/bus/i2c/devices/0-0058/iio\:device0/in_intensity6_raw
The array size of afe4404_channel_leds and afe4404_channel_offdacs
are less than channels, so access with chan->address cause OOB read
in afe4404_[read|write]_raw. Fix it by moving access before use them. |
["https://git.kernel.org/stable/c/113c08030a89aaf406f8a1d4549d758a67c2afba","https://git.kernel.org/stable/c/3f566b626029ca8598d48e5074e56bb37399ca1b","https://git.kernel.org/stable/c/5eb114f55b37dbc0487aa9c1913b81bb7837f1c4","https://git.kernel.org/stable/c/68de7da092f38395dde523f2e5db26eba6c23e28","https://git.kernel.org/stable/c/d45d9f45e7b1365fd0d9bf14680d6d5082a590d1","https://git.kernel.org/stable/c/f5575041ec15310bdc50c42b8b22118cc900226e","https://git.kernel.org/stable/c/f7419fc42afc035f6b29ce713e17dcd2000c833f","https://git.kernel.org/stable/c/fc92d9e3de0b2d30a3ccc08048a5fad533e4672b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52640
|
High |
fixed |
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix oob in ntfs_listxattr
The length of name cannot exceed the space occupied by ea. |
["https://git.kernel.org/stable/c/0830c5cf19bdec50d0ede4755ddc463663deb21c","https://git.kernel.org/stable/c/52fff5799e3d1b5803ecd2f5f19c13c65f4f7b23","https://git.kernel.org/stable/c/6ed6cdbe88334ca3430c5aee7754dc4597498dfb","https://git.kernel.org/stable/c/731ab1f9828800df871c5a7ab9ffe965317d3f15","https://git.kernel.org/stable/c/a585faf0591548fe0920641950ebfa8a6eefe1cd","https://git.kernel.org/stable/c/0830c5cf19bdec50d0ede4755ddc463663deb21c","https://git.kernel.org/stable/c/52fff5799e3d1b5803ecd2f5f19c13c65f4f7b23","https://git.kernel.org/stable/c/6ed6cdbe88334ca3430c5aee7754dc4597498dfb","https://git.kernel.org/stable/c/731ab1f9828800df871c5a7ab9ffe965317d3f15","https://git.kernel.org/stable/c/a585faf0591548fe0920641950ebfa8a6eefe1cd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52503
|
High |
fixed |
- 5.10.199
- 5.15.136
- 6.1.59
- 6.5.8
|
In the Linux kernel, the following vulnerability has been resolved:
tee: amdtee: fix use-after-free vulnerability in amdtee_close_session
There is a potential race condition in amdtee_close_session that may
cause use-after-free in amdtee_open_session. For instance, if a session
has refcount == 1, and one thread tries to free this session via:
kref_put(&sess->refcount, destroy_session);
the reference count will get decremented, and the next step would be to
call destroy_session(). However, if in another thread,
amdtee_open_session() is called before destroy_session() has completed
execution, alloc_session() may return 'sess' that will be freed up
later in destroy_session() leading to use-after-free in
amdtee_open_session.
To fix this issue, treat decrement of sess->refcount and removal of
'sess' from session list in destroy_session() as a critical section, so
that it is executed atomically. |
["https://git.kernel.org/stable/c/1680c82929bc14d706065f123dab77f2f1293116","https://git.kernel.org/stable/c/1c95574350cd63bc3c5c2fa06658010768f2a0ce","https://git.kernel.org/stable/c/60c3e7a00db954947c265b55099c21b216f2a05c","https://git.kernel.org/stable/c/da7ce52a2f6c468946195b116615297d3d113a27","https://git.kernel.org/stable/c/f4384b3e54ea813868bb81a861bf5b2406e15d8f","https://git.kernel.org/stable/c/1680c82929bc14d706065f123dab77f2f1293116","https://git.kernel.org/stable/c/1c95574350cd63bc3c5c2fa06658010768f2a0ce","https://git.kernel.org/stable/c/60c3e7a00db954947c265b55099c21b216f2a05c","https://git.kernel.org/stable/c/da7ce52a2f6c468946195b116615297d3d113a27","https://git.kernel.org/stable/c/f4384b3e54ea813868bb81a861bf5b2406e15d8f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48687
|
Medium |
fixed |
- 4.14.298
- 4.19.258
- 5.4.213
- 5.10.143
- 5.15.68
- 5.19.9
|
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: fix out-of-bounds read when setting HMAC data.
The SRv6 layer allows defining HMAC data that can later be used to sign IPv6
Segment Routing Headers. This configuration is realised via netlink through
four attributes: SEG6_ATTR_HMACKEYID, SEG6_ATTR_SECRET, SEG6_ATTR_SECRETLEN and
SEG6_ATTR_ALGID. Because the SECRETLEN attribute is decoupled from the actual
length of the SECRET attribute, it is possible to provide invalid combinations
(e.g., secret = "", secretlen = 64). This case is not checked in the code and
with an appropriately crafted netlink message, an out-of-bounds read of up
to 64 bytes (max secret length) can occur past the skb end pointer and into
skb_shared_info:
Breakpoint 1, seg6_genl_sethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208
208 memcpy(hinfo->secret, secret, slen);
(gdb) bt
#0 seg6_genl_sethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208
#1 0xffffffff81e012e9 in genl_family_rcv_msg_doit (skb=skb@entry=0xffff88800b1f9f00, nlh=nlh@entry=0xffff88800b1b7600,
extack=extack@entry=0xffffc90000ba7af0, ops=ops@entry=0xffffc90000ba7a80, hdrlen=4, net=0xffffffff84237580 <init_net>, family=<optimized out>,
family=<optimized out>) at net/netlink/genetlink.c:731
#2 0xffffffff81e01435 in genl_family_rcv_msg (extack=0xffffc90000ba7af0, nlh=0xffff88800b1b7600, skb=0xffff88800b1f9f00,
family=0xffffffff82fef6c0 <seg6_genl_family>) at net/netlink/genetlink.c:775
#3 genl_rcv_msg (skb=0xffff88800b1f9f00, nlh=0xffff88800b1b7600, extack=0xffffc90000ba7af0) at net/netlink/genetlink.c:792
#4 0xffffffff81dfffc3 in netlink_rcv_skb (skb=skb@entry=0xffff88800b1f9f00, cb=cb@entry=0xffffffff81e01350 <genl_rcv_msg>)
at net/netlink/af_netlink.c:2501
#5 0xffffffff81e00919 in genl_rcv (skb=0xffff88800b1f9f00) at net/netlink/genetlink.c:803
#6 0xffffffff81dff6ae in netlink_unicast_kernel (ssk=0xffff888010eec800, skb=0xffff88800b1f9f00, sk=0xffff888004aed000)
at net/netlink/af_netlink.c:1319
#7 netlink_unicast (ssk=ssk@entry=0xffff888010eec800, skb=skb@entry=0xffff88800b1f9f00, portid=portid@entry=0, nonblock=<optimized out>)
at net/netlink/af_netlink.c:1345
#8 0xffffffff81dff9a4 in netlink_sendmsg (sock=<optimized out>, msg=0xffffc90000ba7e48, len=<optimized out>) at net/netlink/af_netlink.c:1921
...
(gdb) p/x ((struct sk_buff *)0xffff88800b1f9f00)->head + ((struct sk_buff *)0xffff88800b1f9f00)->end
$1 = 0xffff88800b1b76c0
(gdb) p/x secret
$2 = 0xffff88800b1b76c0
(gdb) p slen
$3 = 64 '@'
The OOB data can then be read back from userspace by dumping HMAC state. This
commit fixes this by ensuring SECRETLEN cannot exceed the actual length of
SECRET. |
["https://git.kernel.org/stable/c/076f2479fc5a15c4a970ca3b5e57d42ba09a31fa","https://git.kernel.org/stable/c/3df71e11a4773d775c3633c44319f7acdb89011c","https://git.kernel.org/stable/c/55195563ec29f80f984237b743de0e2b6ba4d093","https://git.kernel.org/stable/c/56ad3f475482bca55b0ae544031333018eb145b3","https://git.kernel.org/stable/c/84a53580c5d2138c7361c7c3eea5b31827e63b35","https://git.kernel.org/stable/c/dc9dbd65c803af1607484fed5da50d41dc8dd864","https://git.kernel.org/stable/c/f684c16971ed5e77dfa25a9ad25b5297e1f58eab","https://git.kernel.org/stable/c/076f2479fc5a15c4a970ca3b5e57d42ba09a31fa","https://git.kernel.org/stable/c/3df71e11a4773d775c3633c44319f7acdb89011c","https://git.kernel.org/stable/c/55195563ec29f80f984237b743de0e2b6ba4d093","https://git.kernel.org/stable/c/56ad3f475482bca55b0ae544031333018eb145b3","https://git.kernel.org/stable/c/84a53580c5d2138c7361c7c3eea5b31827e63b35","https://git.kernel.org/stable/c/dc9dbd65c803af1607484fed5da50d41dc8dd864","https://git.kernel.org/stable/c/f684c16971ed5e77dfa25a9ad25b5297e1f58eab"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46841
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()
We handle errors here properly, ENOMEM isn't fatal, return the error. |
["https://git.kernel.org/stable/c/135b4819f6fba87fd5a2693023133e78ac73f1d3","https://git.kernel.org/stable/c/44a2c518ab221c0cadcb8c45ca86f83a52dd4da6","https://git.kernel.org/stable/c/6a0648f96c3ca647c71c6c1ddbc7c353bab79f64","https://git.kernel.org/stable/c/704c359b4093a2af650a20eaa030c435d7c30f91","https://git.kernel.org/stable/c/a580fb2c3479d993556e1c31b237c9e5be4944a3","https://git.kernel.org/stable/c/c1406d8329f500e4594cd9730cd313aebc3a4333"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50272
|
Medium |
fixed |
- 3.17
- 4.8
- 4.9
- 6.1.117
- 6.6.61
- 6.11.8
|
In the Linux kernel, the following vulnerability has been resolved:
filemap: Fix bounds checking in filemap_read()
If the caller supplies an iocb->ki_pos value that is close to the
filesystem upper limit, and an iterator with a count that causes us to
overflow that limit, then filemap_read() enters an infinite loop.
This behaviour was discovered when testing xfstests generic/525 with the
"localio" optimisation for loopback NFS mounts. |
["https://git.kernel.org/stable/c/26530b757c81f1389fb33ae0357500150933161b","https://git.kernel.org/stable/c/6450e73f4c86d481ac2e22e1bc848d346e140826","https://git.kernel.org/stable/c/6cc52df69e8464811f9f6fc12f7aaa78451eb0b8","https://git.kernel.org/stable/c/a2746ab3bbc9c6408da5cd072653ec8c24749235","https://git.kernel.org/stable/c/ace149e0830c380ddfce7e466fe860ca502fe4ee"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43849
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: pdr: protect locator_addr with the main mutex
If the service locator server is restarted fast enough, the PDR can
rewrite locator_addr fields concurrently. Protect them by placing
modification of those fields under the main pdr->lock. |
["https://git.kernel.org/stable/c/107924c14e3ddd85119ca43c26a4ee1056fa9b84","https://git.kernel.org/stable/c/3e815626d73e05152a8142f6e44aecc4133e6e08","https://git.kernel.org/stable/c/475a77fb3f0e1d527f56c60b79f5879661df5b80","https://git.kernel.org/stable/c/8543269567e2fb3d976a8255c5e348aed14f98bc","https://git.kernel.org/stable/c/d0870c4847e77a49c2f91bb2a8e0fa3c1f8dea5c","https://git.kernel.org/stable/c/eab05737ee22216250fe20d27f5a596da5ea6eb7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-58010
|
Medium |
fixed |
- 6.1.129
- 6.6.78
- 6.12.14
- 6.13.3
|
In the Linux kernel, the following vulnerability has been resolved:
binfmt_flat: Fix integer overflow bug on 32 bit systems
Most of these sizes and counts are capped at 256MB so the math doesn't
result in an integer overflow. The "relocs" count needs to be checked
as well. Otherwise on 32bit systems the calculation of "full_data"
could be wrong.
full_data = data_len + relocs * sizeof(unsigned long); |
["https://git.kernel.org/stable/c/0b6be54d7386b7addbf9e5947366f94aad046938","https://git.kernel.org/stable/c/55cf2f4b945f6a6416cc2524ba740b83cc9af25a","https://git.kernel.org/stable/c/6fb98e0576ea155267e206286413dcb3a3d55c12","https://git.kernel.org/stable/c/8e8cd712bb06a507b26efd2a56155076aa454345","https://git.kernel.org/stable/c/95506c7f33452450346fbe2975c1359100f854ca","https://git.kernel.org/stable/c/a009378af674b808efcca1e2e67916e79ce866b3","https://git.kernel.org/stable/c/bc8ca18b8ef4648532c001bd6c8151143b569275","https://git.kernel.org/stable/c/d17ca8f2dfcf423c439859995910a20e38b86f00"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-58017
|
Medium |
fixed |
- 6.1.129
- 6.6.78
- 6.12.14
- 6.13.3
|
In the Linux kernel, the following vulnerability has been resolved:
printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAX
Shifting 1 << 31 on a 32-bit int causes signed integer overflow, which
leads to undefined behavior. To prevent this, cast 1 to u32 before
performing the shift, ensuring well-defined behavior.
This change explicitly avoids any potential overflow by ensuring that
the shift occurs on an unsigned 32-bit integer. |
["https://git.kernel.org/stable/c/3d6f83df8ff2d5de84b50377e4f0d45e25311c7a","https://git.kernel.org/stable/c/404e5fd918a0b14abec06c7eca128f04c9b98e41","https://git.kernel.org/stable/c/4a2c4e7265b8eed83c25d86d702cea06493cab18","https://git.kernel.org/stable/c/4acf6bab775dbd22a9a799030a808a7305e01d63","https://git.kernel.org/stable/c/54c14022fa2ba427dc543455c2cf9225903a7174","https://git.kernel.org/stable/c/9a6d43844de2479a3ff8d674c3e2a16172e01598","https://git.kernel.org/stable/c/bb8ff054e19fe27f4e5eaac1b05e462894cfe9b1","https://git.kernel.org/stable/c/dfb7b179741ee09506dc7719d92f9e1cea01f10e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21848
|
Medium |
fixed |
- 6.1.130
- 6.6.80
- 6.12.17
- 6.13.5
|
In the Linux kernel, the following vulnerability has been resolved:
nfp: bpf: Add check for nfp_app_ctrl_msg_alloc()
Add check for the return value of nfp_app_ctrl_msg_alloc() in
nfp_bpf_cmsg_alloc() to prevent null pointer dereference. |
["https://git.kernel.org/stable/c/1358d8e07afdf21d49ca6f00c56048442977e00a","https://git.kernel.org/stable/c/29ccb1e4040da6ff02b7e64efaa2f8e6bf06020d","https://git.kernel.org/stable/c/878e7b11736e062514e58f3b445ff343e6705537","https://git.kernel.org/stable/c/897c32cd763fd11d0b6ed024c52f44d2475bb820","https://git.kernel.org/stable/c/924b239f9704566e0d86abd894d2d64bd73c11eb","https://git.kernel.org/stable/c/bd97f60750bb581f07051f98e31dfda59d3a783b","https://git.kernel.org/stable/c/d64c6ca420019712e194fe095b55f87363e22a9a","https://git.kernel.org/stable/c/e976ea6c5e1b005c64467cbf94a8577aae9c7d81"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21862
|
Medium |
fixed |
- 6.1.130
- 6.6.80
- 6.12.17
- 6.13.5
|
In the Linux kernel, the following vulnerability has been resolved:
drop_monitor: fix incorrect initialization order
Syzkaller reports the following bug:
BUG: spinlock bad magic on CPU#1, syz-executor.0/7995
lock: 0xffff88805303f3e0, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
CPU: 1 PID: 7995 Comm: syz-executor.0 Tainted: G E 5.10.209+ #1
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x119/0x179 lib/dump_stack.c:118
debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
do_raw_spin_lock+0x1f6/0x270 kernel/locking/spinlock_debug.c:112
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline]
_raw_spin_lock_irqsave+0x50/0x70 kernel/locking/spinlock.c:159
reset_per_cpu_data+0xe6/0x240 [drop_monitor]
net_dm_cmd_trace+0x43d/0x17a0 [drop_monitor]
genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739
genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]
genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800
netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2497
genl_rcv+0x29/0x40 net/netlink/genetlink.c:811
netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline]
netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1348
netlink_sendmsg+0x914/0xe00 net/netlink/af_netlink.c:1916
sock_sendmsg_nosec net/socket.c:651 [inline]
__sock_sendmsg+0x157/0x190 net/socket.c:663
____sys_sendmsg+0x712/0x870 net/socket.c:2378
___sys_sendmsg+0xf8/0x170 net/socket.c:2432
__sys_sendmsg+0xea/0x1b0 net/socket.c:2461
do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x62/0xc7
RIP: 0033:0x7f3f9815aee9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f3f972bf0c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f3f9826d050 RCX: 00007f3f9815aee9
RDX: 0000000020000000 RSI: 0000000020001300 RDI: 0000000000000007
RBP: 00007f3f981b63bd R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000006e R14: 00007f3f9826d050 R15: 00007ffe01ee6768
If drop_monitor is built as a kernel module, syzkaller may have time
to send a netlink NET_DM_CMD_START message during the module loading.
This will call the net_dm_monitor_start() function that uses
a spinlock that has not yet been initialized.
To fix this, let's place resource initialization above the registration
of a generic netlink family.
Found by InfoTeCS on behalf of Linux Verification Center
(linuxtesting.org) with Syzkaller. |
["https://git.kernel.org/stable/c/07b598c0e6f06a0f254c88dafb4ad50f8a8c6eea","https://git.kernel.org/stable/c/0efa6c42f81c60d8f72ba7f5ed8d4fec8c526282","https://git.kernel.org/stable/c/219a47d0e6195bd202f22855e35f25bd15bc4d58","https://git.kernel.org/stable/c/29f9cdcab3d96d5207a5c92b52c40ad75e5915d8","https://git.kernel.org/stable/c/6e9e0f224ffd8b819da3ea247dda404795fdd182","https://git.kernel.org/stable/c/872c7c7e57a746046796ddfead529c9d37b9f6b4","https://git.kernel.org/stable/c/b7859e8643e75619b2705b4fcac93ffd94d72b4a","https://git.kernel.org/stable/c/fcfc00bfec7bb6661074cb21356d05a4c9470a3c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46742
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
smb/server: fix potential null-ptr-deref of lease_ctx_info in smb2_open()
null-ptr-deref will occur when (req_op_level == SMB2_OPLOCK_LEVEL_LEASE)
and parse_lease_state() return NULL.
Fix this by check if 'lease_ctx_info' is NULL.
Additionally, remove the redundant parentheses in
parse_durable_handle_context(). |
["https://git.kernel.org/stable/c/07f384c5be1f8633b13f0a22616e227570450bc6","https://git.kernel.org/stable/c/3b692794b81f2ecad69a4adbba687f3836824ada","https://git.kernel.org/stable/c/4e8771a3666c8f216eefd6bd2fd50121c6c437db","https://git.kernel.org/stable/c/878f32878351104448b86ef5b85d1f8ed6f599fb","https://git.kernel.org/stable/c/ec28c35029b7930f31117f9284874b63bea4f31b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57913
|
Medium |
fixed |
- 5.4.290
- 5.10.234
- 5.15.177
- 6.1.125
- 6.6.72
- 6.12.10
|
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_fs: Remove WARN_ON in functionfs_bind
This commit addresses an issue related to below kernel panic where
panic_on_warn is enabled. It is caused by the unnecessary use of WARN_ON
in functionsfs_bind, which easily leads to the following scenarios.
1.adb_write in adbd 2. UDC write via configfs
================= =====================
->usb_ffs_open_thread() ->UDC write
->open_functionfs() ->configfs_write_iter()
->adb_open() ->gadget_dev_desc_UDC_store()
->adb_write() ->usb_gadget_register_driver_owner
->driver_register()
->StartMonitor() ->bus_add_driver()
->adb_read() ->gadget_bind_driver()
<times-out without BIND event> ->configfs_composite_bind()
->usb_add_function()
->open_functionfs() ->ffs_func_bind()
->adb_open() ->functionfs_bind()
<ffs->state !=FFS_ACTIVE>
The adb_open, adb_read, and adb_write operations are invoked from the
daemon, but trying to bind the function is a process that is invoked by
UDC write through configfs, which opens up the possibility of a race
condition between the two paths. In this race scenario, the kernel panic
occurs due to the WARN_ON from functionfs_bind when panic_on_warn is
enabled. This commit fixes the kernel panic by removing the unnecessary
WARN_ON.
Kernel panic - not syncing: kernel: panic_on_warn set ...
[ 14.542395] Call trace:
[ 14.542464] ffs_func_bind+0x1c8/0x14a8
[ 14.542468] usb_add_function+0xcc/0x1f0
[ 14.542473] configfs_composite_bind+0x468/0x588
[ 14.542478] gadget_bind_driver+0x108/0x27c
[ 14.542483] really_probe+0x190/0x374
[ 14.542488] __driver_probe_device+0xa0/0x12c
[ 14.542492] driver_probe_device+0x3c/0x220
[ 14.542498] __driver_attach+0x11c/0x1fc
[ 14.542502] bus_for_each_dev+0x104/0x160
[ 14.542506] driver_attach+0x24/0x34
[ 14.542510] bus_add_driver+0x154/0x270
[ 14.542514] driver_register+0x68/0x104
[ 14.542518] usb_gadget_register_driver_owner+0x48/0xf4
[ 14.542523] gadget_dev_desc_UDC_store+0xf8/0x144
[ 14.542526] configfs_write_iter+0xf0/0x138 |
["https://git.kernel.org/stable/c/19fc1c83454ca9d5699e39633ec79ce26355251c","https://git.kernel.org/stable/c/3e4d32cc145955d5c56c5498a3ff057e4aafa9d1","https://git.kernel.org/stable/c/82f60f3600aecd9ffcd0fbc4e193694511c85b47","https://git.kernel.org/stable/c/a8b6a18b9b66cc4c016d63132b59ce5383f7cdd2","https://git.kernel.org/stable/c/bfe60030fcd976e3546e1f73d6d0eb3fea26442e","https://git.kernel.org/stable/c/dfc51e48bca475bbee984e90f33fdc537ce09699","https://git.kernel.org/stable/c/ea6a1498742430eb2effce0d1439ff29ef37dd7d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-2196
|
High |
fixed |
- 5.4.233
- 5.7
- 5.10.170
- 5.15.96
- 6.1.14
|
A regression exists in the Linux Kernel within KVM: nVMX that allowed for speculative execution attacks. L2 can carry out Spectre v2 attacks on L1 due to L1 thinking it doesn't need retpolines or IBPB after running L2 due to KVM (L0) advertising eIBRS support to L1. An attacker at L2 with code execution can execute code on an indirect branch on the host machine. We recommend upgrading to Kernel 6.2 or past commit 2e7eab81425a |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2e7eab81425ad6c875f2ed47c0ce01e78afc38a5","https://kernel.dance/#2e7eab81425a","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2e7eab81425ad6c875f2ed47c0ce01e78afc38a5","https://kernel.dance/#2e7eab81425a","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://security.netapp.com/advisory/ntap-20230223-0002/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48948
|
High |
fixed |
- 4.9.337
- 4.14.303
- 4.19.270
- 5.4.229
- 5.10.161
- 5.15.85
- 6.0.15
|
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: uvc: Prevent buffer overflow in setup handler
Setup function uvc_function_setup permits control transfer
requests with up to 64 bytes of payload (UVC_MAX_REQUEST_SIZE),
data stage handler for OUT transfer uses memcpy to copy req->actual
bytes to uvc_event->data.data array of size 60. This may result
in an overflow of 4 bytes. |
["https://git.kernel.org/stable/c/06fd17ee92c8f1704c7e54ec0fd50ae0542a49a5","https://git.kernel.org/stable/c/4972e3528b968665b596b5434764ff8fd9446d35","https://git.kernel.org/stable/c/4c92670b16727365699fe4b19ed32013bab2c107","https://git.kernel.org/stable/c/6b41a35b41f77821db24f2d8f66794b390a585c5","https://git.kernel.org/stable/c/7b1f773277a72f9756d47a41b94e43506cce1954","https://git.kernel.org/stable/c/b8fb1cba934ea122b50f13a4f9d6fc4fdc43d2be","https://git.kernel.org/stable/c/bc8380fe5768c564f921f7b4eaba932e330b9e4b","https://git.kernel.org/stable/c/c79538f32df12887f110dcd6b9c825b482905f24","https://git.kernel.org/stable/c/d1a92bb8d697f170d93fe922da763d7d156b8841"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56615
|
High |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: fix OOB devmap writes when deleting elements
Jordy reported issue against XSKMAP which also applies to DEVMAP - the
index used for accessing map entry, due to being a signed integer,
causes the OOB writes. Fix is simple as changing the type from int to
u32, however, when compared to XSKMAP case, one more thing needs to be
addressed.
When map is released from system via dev_map_free(), we iterate through
all of the entries and an iterator variable is also an int, which
implies OOB accesses. Again, change it to be u32.
Example splat below:
[ 160.724676] BUG: unable to handle page fault for address: ffffc8fc2c001000
[ 160.731662] #PF: supervisor read access in kernel mode
[ 160.736876] #PF: error_code(0x0000) - not-present page
[ 160.742095] PGD 0 P4D 0
[ 160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP
[ 160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 Not tainted 6.12.0-rc1+ #487
[ 160.757050] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019
[ 160.767642] Workqueue: events_unbound bpf_map_free_deferred
[ 160.773308] RIP: 0010:dev_map_free+0x77/0x170
[ 160.777735] Code: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 <48> 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff
[ 160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202
[ 160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 0000000000000024
[ 160.809331] RDX: 0000000000000000 RSI: 0000000000000024 RDI: ffffc9002c001000
[ 160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001
[ 160.823823] R10: 0000000000000001 R11: 00000000000ee6b2 R12: dead000000000122
[ 160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000
[ 160.838310] FS: 0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000
[ 160.846528] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0
[ 160.859604] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 160.874092] PKRU: 55555554
[ 160.876847] Call Trace:
[ 160.879338] <TASK>
[ 160.881477] ? __die+0x20/0x60
[ 160.884586] ? page_fault_oops+0x15a/0x450
[ 160.888746] ? search_extable+0x22/0x30
[ 160.892647] ? search_bpf_extables+0x5f/0x80
[ 160.896988] ? exc_page_fault+0xa9/0x140
[ 160.900973] ? asm_exc_page_fault+0x22/0x30
[ 160.905232] ? dev_map_free+0x77/0x170
[ 160.909043] ? dev_map_free+0x58/0x170
[ 160.912857] bpf_map_free_deferred+0x51/0x90
[ 160.917196] process_one_work+0x142/0x370
[ 160.921272] worker_thread+0x29e/0x3b0
[ 160.925082] ? rescuer_thread+0x4b0/0x4b0
[ 160.929157] kthread+0xd4/0x110
[ 160.932355] ? kthread_park+0x80/0x80
[ 160.936079] ret_from_fork+0x2d/0x50
[ 160.943396] ? kthread_park+0x80/0x80
[ 160.950803] ret_from_fork_asm+0x11/0x20
[ 160.958482] </TASK> |
["https://git.kernel.org/stable/c/0f170e91d3063ca60baec4bd9f544faf3bfe29eb","https://git.kernel.org/stable/c/178e31df1fb3d9e0890eb471da16709cbc82edee","https://git.kernel.org/stable/c/70f3de869865f9c3da0508a5ea29f6f4c1889057","https://git.kernel.org/stable/c/8e858930695d3ebec423e85384c95427258c294f","https://git.kernel.org/stable/c/98c03d05936d846073df8f550e9e8bf0dde1d77f","https://git.kernel.org/stable/c/ab244dd7cf4c291f82faacdc50b45cc0f55b674d","https://git.kernel.org/stable/c/ad34306ac6836e5dd096b7d0ad4aa20cb7c8d9e5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56693
|
High |
fixed |
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
brd: defer automatic disk creation until module initialization succeeds
My colleague Wupeng found the following problems during fault injection:
BUG: unable to handle page fault for address: fffffbfff809d073
PGD 6e648067 P4D 123ec8067 PUD 123ec4067 PMD 100e38067 PTE 0
Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 5 UID: 0 PID: 755 Comm: modprobe Not tainted 6.12.0-rc3+ #17
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.1-2.fc37 04/01/2014
RIP: 0010:__asan_load8+0x4c/0xa0
...
Call Trace:
<TASK>
blkdev_put_whole+0x41/0x70
bdev_release+0x1a3/0x250
blkdev_release+0x11/0x20
__fput+0x1d7/0x4a0
task_work_run+0xfc/0x180
syscall_exit_to_user_mode+0x1de/0x1f0
do_syscall_64+0x6b/0x170
entry_SYSCALL_64_after_hwframe+0x76/0x7e
loop_init() is calling loop_add() after __register_blkdev() succeeds and
is ignoring disk_add() failure from loop_add(), for loop_add() failure
is not fatal and successfully created disks are already visible to
bdev_open().
brd_init() is currently calling brd_alloc() before __register_blkdev()
succeeds and is releasing successfully created disks when brd_init()
returns an error. This can cause UAF for the latter two case:
case 1:
T1:
modprobe brd
brd_init
brd_alloc(0) // success
add_disk
disk_scan_partitions
bdev_file_open_by_dev // alloc file
fput // won't free until back to userspace
brd_alloc(1) // failed since mem alloc error inject
// error path for modprobe will release code segment
// back to userspace
__fput
blkdev_release
bdev_release
blkdev_put_whole
bdev->bd_disk->fops->release // fops is freed now, UAF!
case 2:
T1: T2:
modprobe brd
brd_init
brd_alloc(0) // success
open(/dev/ram0)
brd_alloc(1) // fail
// error path for modprobe
close(/dev/ram0)
...
/* UAF! */
bdev->bd_disk->fops->release
Fix this problem by following what loop_init() does. Besides,
reintroduce brd_devices_mutex to help serialize modifications to
brd_list. |
["https://git.kernel.org/stable/c/259bf925583ec9e3781df778cadf00594095090d","https://git.kernel.org/stable/c/410896624db639500f24f46478b4bfa05c76bf56","https://git.kernel.org/stable/c/41219c147df8bbd6591f59af5d695fb6c9a1cbff","https://git.kernel.org/stable/c/63dfd728b30f79495dacc886127695a379805152","https://git.kernel.org/stable/c/826cc42adf44930a633d11a5993676d85ddb0842","https://git.kernel.org/stable/c/c0c2744cd2939ec5999c51dbaf2af16886548b7b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52494
|
High |
fixed |
- 5.15.149
- 6.1.76
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
bus: mhi: host: Add alignment check for event ring read pointer
Though we do check the event ring read pointer by "is_valid_ring_ptr"
to make sure it is in the buffer range, but there is another risk the
pointer may be not aligned. Since we are expecting event ring elements
are 128 bits(struct mhi_ring_element) aligned, an unaligned read pointer
could lead to multiple issues like DoS or ring buffer memory corruption.
So add a alignment check for event ring read pointer. |
["https://git.kernel.org/stable/c/2df39ac8f813860f79782807c3f7acff40b3c551","https://git.kernel.org/stable/c/94991728c84f8df54fd9eec9b85855ef9057ea08","https://git.kernel.org/stable/c/a9ebfc405fe1be145f414eafadcbf09506082010","https://git.kernel.org/stable/c/ecf8320111822a1ae5d5fc512953eab46d543d0b","https://git.kernel.org/stable/c/eff9704f5332a13b08fbdbe0f84059c9e7051d5f","https://git.kernel.org/stable/c/2df39ac8f813860f79782807c3f7acff40b3c551","https://git.kernel.org/stable/c/94991728c84f8df54fd9eec9b85855ef9057ea08","https://git.kernel.org/stable/c/a9ebfc405fe1be145f414eafadcbf09506082010","https://git.kernel.org/stable/c/ecf8320111822a1ae5d5fc512953eab46d543d0b","https://git.kernel.org/stable/c/eff9704f5332a13b08fbdbe0f84059c9e7051d5f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4207
|
High |
fixed |
- 4.14.326
- 4.19.295
- 5.4.253
- 5.10.190
- 5.15.126
- 6.1.45
- 6.4.10
|
A use-after-free vulnerability in the Linux kernel's net/sched: cls_fw component can be exploited to achieve local privilege escalation.
When fw_change() is called on an existing filter, the whole tcf_result struct is always copied into the new instance of the filter. This causes a problem when updating a filter bound to a class, as tcf_unbind_filter() is always called on the old instance in the success path, decreasing filter_cnt of the still referenced class and allowing it to be deleted, leading to a use-after-free.
We recommend upgrading past commit 76e42ae831991c828cffa8c37736ebfb831ad5ec. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76e42ae831991c828cffa8c37736ebfb831ad5ec","https://kernel.dance/76e42ae831991c828cffa8c37736ebfb831ad5ec","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.debian.org/security/2023/dsa-5492","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76e42ae831991c828cffa8c37736ebfb831ad5ec","https://kernel.dance/76e42ae831991c828cffa8c37736ebfb831ad5ec","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.debian.org/security/2023/dsa-5492"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52737
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: lock the inode in shared mode before starting fiemap
Currently fiemap does not take the inode's lock (VFS lock), it only locks
a file range in the inode's io tree. This however can lead to a deadlock
if we have a concurrent fsync on the file and fiemap code triggers a fault
when accessing the user space buffer with fiemap_fill_next_extent(). The
deadlock happens on the inode's i_mmap_lock semaphore, which is taken both
by fsync and btrfs_page_mkwrite(). This deadlock was recently reported by
syzbot and triggers a trace like the following:
task:syz-executor361 state:D stack:20264 pid:5668 ppid:5119 flags:0x00004004
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5293 [inline]
__schedule+0x995/0xe20 kernel/sched/core.c:6606
schedule+0xcb/0x190 kernel/sched/core.c:6682
wait_on_state fs/btrfs/extent-io-tree.c:707 [inline]
wait_extent_bit+0x577/0x6f0 fs/btrfs/extent-io-tree.c:751
lock_extent+0x1c2/0x280 fs/btrfs/extent-io-tree.c:1742
find_lock_delalloc_range+0x4e6/0x9c0 fs/btrfs/extent_io.c:488
writepage_delalloc+0x1ef/0x540 fs/btrfs/extent_io.c:1863
__extent_writepage+0x736/0x14e0 fs/btrfs/extent_io.c:2174
extent_write_cache_pages+0x983/0x1220 fs/btrfs/extent_io.c:3091
extent_writepages+0x219/0x540 fs/btrfs/extent_io.c:3211
do_writepages+0x3c3/0x680 mm/page-writeback.c:2581
filemap_fdatawrite_wbc+0x11e/0x170 mm/filemap.c:388
__filemap_fdatawrite_range mm/filemap.c:421 [inline]
filemap_fdatawrite_range+0x175/0x200 mm/filemap.c:439
btrfs_fdatawrite_range fs/btrfs/file.c:3850 [inline]
start_ordered_ops fs/btrfs/file.c:1737 [inline]
btrfs_sync_file+0x4ff/0x1190 fs/btrfs/file.c:1839
generic_write_sync include/linux/fs.h:2885 [inline]
btrfs_do_write_iter+0xcd3/0x1280 fs/btrfs/file.c:1684
call_write_iter include/linux/fs.h:2189 [inline]
new_sync_write fs/read_write.c:491 [inline]
vfs_write+0x7dc/0xc50 fs/read_write.c:584
ksys_write+0x177/0x2a0 fs/read_write.c:637
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f7d4054e9b9
RSP: 002b:00007f7d404fa2f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f7d405d87a0 RCX: 00007f7d4054e9b9
RDX: 0000000000000090 RSI: 0000000020000000 RDI: 0000000000000006
RBP: 00007f7d405a51d0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 61635f65646f6e69
R13: 65646f7475616f6e R14: 7261637369646f6e R15: 00007f7d405d87a8
</TASK>
INFO: task syz-executor361:5697 blocked for more than 145 seconds.
Not tainted 6.2.0-rc3-syzkaller-00376-g7c6984405241 #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor361 state:D stack:21216 pid:5697 ppid:5119 flags:0x00004004
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5293 [inline]
__schedule+0x995/0xe20 kernel/sched/core.c:6606
schedule+0xcb/0x190 kernel/sched/core.c:6682
rwsem_down_read_slowpath+0x5f9/0x930 kernel/locking/rwsem.c:1095
__down_read_common+0x54/0x2a0 kernel/locking/rwsem.c:1260
btrfs_page_mkwrite+0x417/0xc80 fs/btrfs/inode.c:8526
do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947
wp_page_shared+0x15e/0x380 mm/memory.c:3295
handle_pte_fault mm/memory.c:4949 [inline]
__handle_mm_fault mm/memory.c:5073 [inline]
handle_mm_fault+0x1b79/0x26b0 mm/memory.c:5219
do_user_addr_fault+0x69b/0xcb0 arch/x86/mm/fault.c:1428
handle_page_fault arch/x86/mm/fault.c:1519 [inline]
exc_page_fault+0x7a/0x110 arch/x86/mm/fault.c:1575
asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:570
RIP: 0010:copy_user_short_string+0xd/0x40 arch/x86/lib/copy_user_64.S:233
Code: 74 0a 89 (...)
RSP: 0018:ffffc9000570f330 EFLAGS: 000502
---truncated--- |
["https://git.kernel.org/stable/c/519b7e13b5ae8dd38da1e52275705343be6bb508","https://git.kernel.org/stable/c/d8c594da79bc0244e610a70594e824a401802be1","https://git.kernel.org/stable/c/519b7e13b5ae8dd38da1e52275705343be6bb508","https://git.kernel.org/stable/c/d8c594da79bc0244e610a70594e824a401802be1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56770
|
Medium |
fixed |
- 5.4.288
- 5.10.232
- 5.15.175
- 6.1.121
- 6.6.67
- 6.12.6
|
In the Linux kernel, the following vulnerability has been resolved:
net/sched: netem: account for backlog updates from child qdisc
In general, 'qlen' of any classful qdisc should keep track of the
number of packets that the qdisc itself and all of its children holds.
In case of netem, 'qlen' only accounts for the packets in its internal
tfifo. When netem is used with a child qdisc, the child qdisc can use
'qdisc_tree_reduce_backlog' to inform its parent, netem, about created
or dropped SKBs. This function updates 'qlen' and the backlog statistics
of netem, but netem does not account for changes made by a child qdisc.
'qlen' then indicates the wrong number of packets in the tfifo.
If a child qdisc creates new SKBs during enqueue and informs its parent
about this, netem's 'qlen' value is increased. When netem dequeues the
newly created SKBs from the child, the 'qlen' in netem is not updated.
If 'qlen' reaches the configured sch->limit, the enqueue function stops
working, even though the tfifo is not full.
Reproduce the bug:
Ensure that the sender machine has GSO enabled. Configure netem as root
qdisc and tbf as its child on the outgoing interface of the machine
as follows:
$ tc qdisc add dev <oif> root handle 1: netem delay 100ms limit 100
$ tc qdisc add dev <oif> parent 1:0 tbf rate 50Mbit burst 1542 latency 50ms
Send bulk TCP traffic out via this interface, e.g., by running an iPerf3
client on the machine. Check the qdisc statistics:
$ tc -s qdisc show dev <oif>
Statistics after 10s of iPerf3 TCP test before the fix (note that
netem's backlog > limit, netem stopped accepting packets):
qdisc netem 1: root refcnt 2 limit 1000 delay 100ms
Sent 2767766 bytes 1848 pkt (dropped 652, overlimits 0 requeues 0)
backlog 4294528236b 1155p requeues 0
qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms
Sent 2767766 bytes 1848 pkt (dropped 327, overlimits 7601 requeues 0)
backlog 0b 0p requeues 0
Statistics after the fix:
qdisc netem 1: root refcnt 2 limit 1000 delay 100ms
Sent 37766372 bytes 24974 pkt (dropped 9, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms
Sent 37766372 bytes 24974 pkt (dropped 327, overlimits 96017 requeues 0)
backlog 0b 0p requeues 0
tbf segments the GSO SKBs (tbf_segment) and updates the netem's 'qlen'.
The interface fully stops transferring packets and "locks". In this case,
the child qdisc and tfifo are empty, but 'qlen' indicates the tfifo is at
its limit and no more packets are accepted.
This patch adds a counter for the entries in the tfifo. Netem's 'qlen' is
only decreased when a packet is returned by its dequeue function, and not
during enqueuing into the child qdisc. External updates to 'qlen' are thus
accounted for and only the behavior of the backlog statistics changes. As
in other qdiscs, 'qlen' then keeps track of how many packets are held in
netem and all of its children. As before, sch->limit remains as the
maximum number of packets in the tfifo. The same applies to netem's
backlog statistics. |
["https://git.kernel.org/stable/c/10df49cfca73dfbbdb6c4150d859f7e8926ae427","https://git.kernel.org/stable/c/216509dda290f6db92c816dd54b83c1df9da9e76","https://git.kernel.org/stable/c/356078a5c55ec8d2061fcc009fb8599f5b0527f9","https://git.kernel.org/stable/c/3824c5fad18eeb7abe0c4fc966f29959552dca3e","https://git.kernel.org/stable/c/83c6ab12f08dcc09d4c5ac86fdb89736b28f1d31","https://git.kernel.org/stable/c/c2047b0e216c8edce227d7c42f99ac2877dad0e4","https://git.kernel.org/stable/c/f8d4bc455047cf3903cd6f85f49978987dbb3027"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42064
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Skip pipe if the pipe idx not set properly
[why]
Driver crashes when pipe idx not set properly
[how]
Add code to skip the pipe that idx not set properly |
["https://git.kernel.org/stable/c/27df59c6071470efce7182ee92fbb16afba551e0","https://git.kernel.org/stable/c/af114efe8d24b5711cfbedf7180f2ac1a296c24b","https://git.kernel.org/stable/c/27df59c6071470efce7182ee92fbb16afba551e0","https://git.kernel.org/stable/c/af114efe8d24b5711cfbedf7180f2ac1a296c24b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42065
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Add a NULL check in xe_ttm_stolen_mgr_init
Add an explicit check to ensure that the mgr is not NULL. |
["https://git.kernel.org/stable/c/a6eff8f9c7e844cb24ccb188ca24abcd59734e74","https://git.kernel.org/stable/c/cc796a77985d6af75c9362cb2e73dce4ae3f97cd","https://git.kernel.org/stable/c/a6eff8f9c7e844cb24ccb188ca24abcd59734e74","https://git.kernel.org/stable/c/cc796a77985d6af75c9362cb2e73dce4ae3f97cd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42066
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Fix potential integer overflow in page size calculation
Explicitly cast tbo->page_alignment to u64 before bit-shifting to
prevent overflow when assigning to min_page_size. |
["https://git.kernel.org/stable/c/4f4fcafde343a54465f85a2909fc684918507a4b","https://git.kernel.org/stable/c/79d54ddf0e292b810887994bb04709c5ac0e1531","https://git.kernel.org/stable/c/4f4fcafde343a54465f85a2909fc684918507a4b","https://git.kernel.org/stable/c/79d54ddf0e292b810887994bb04709c5ac0e1531"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42078
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
nfsd: initialise nfsd_info.mutex early.
nfsd_info.mutex can be dereferenced by svc_pool_stats_start()
immediately after the new netns is created. Currently this can
trigger an oops.
Move the initialisation earlier before it can possibly be dereferenced. |
["https://git.kernel.org/stable/c/7e8b94045bc77ce4f085ddfb9eb04e5760e66169","https://git.kernel.org/stable/c/e0011bca603c101f2a3c007bdb77f7006fa78fb1","https://git.kernel.org/stable/c/7e8b94045bc77ce4f085ddfb9eb04e5760e66169","https://git.kernel.org/stable/c/e0011bca603c101f2a3c007bdb77f7006fa78fb1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42081
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/xe_devcoredump: Check NULL before assignments
Assign 'xe_devcoredump_snapshot *' and 'xe_device *' only if
'coredump' is not NULL.
v2
- Fix commit messages.
v3
- Define variables before code.(Ashutosh/Jose)
v4
- Drop return check for coredump_to_xe. (Jose/Rodrigo)
v5
- Modify misleading commit message. (Matt) |
["https://git.kernel.org/stable/c/76ec0e33707282d5321555698d902f4e067aff37","https://git.kernel.org/stable/c/b15e65349553b1689d15fbdebea874ca5ae2274a","https://git.kernel.org/stable/c/76ec0e33707282d5321555698d902f4e067aff37","https://git.kernel.org/stable/c/b15e65349553b1689d15fbdebea874ca5ae2274a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42083
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ionic: fix kernel panic due to multi-buffer handling
Currently, the ionic_run_xdp() doesn't handle multi-buffer packets
properly for XDP_TX and XDP_REDIRECT.
When a jumbo frame is received, the ionic_run_xdp() first makes xdp
frame with all necessary pages in the rx descriptor.
And if the action is either XDP_TX or XDP_REDIRECT, it should unmap
dma-mapping and reset page pointer to NULL for all pages, not only the
first page.
But it doesn't for SG pages. So, SG pages unexpectedly will be reused.
It eventually causes kernel panic.
Oops: general protection fault, probably for non-canonical address 0x504f4e4dbebc64ff: 0000 [#1] PREEMPT SMP NOPTI
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.10.0-rc3+ #25
RIP: 0010:xdp_return_frame+0x42/0x90
Code: 01 75 12 5b 4c 89 e6 5d 31 c9 41 5c 31 d2 41 5d e9 73 fd ff ff 44 8b 6b 20 0f b7 43 0a 49 81 ed 68 01 00 00 49 29 c5 49 01 fd <41> 80 7d0
RSP: 0018:ffff99d00122ce08 EFLAGS: 00010202
RAX: 0000000000005453 RBX: ffff8d325f904000 RCX: 0000000000000001
RDX: 00000000670e1000 RSI: 000000011f90d000 RDI: 504f4e4d4c4b4a49
RBP: ffff99d003907740 R08: 0000000000000000 R09: 0000000000000000
R10: 000000011f90d000 R11: 0000000000000000 R12: ffff8d325f904010
R13: 504f4e4dbebc64fd R14: ffff8d3242b070c8 R15: ffff99d0039077c0
FS: 0000000000000000(0000) GS:ffff8d399f780000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f41f6c85e38 CR3: 000000037ac30000 CR4: 00000000007506f0
PKRU: 55555554
Call Trace:
<IRQ>
? die_addr+0x33/0x90
? exc_general_protection+0x251/0x2f0
? asm_exc_general_protection+0x22/0x30
? xdp_return_frame+0x42/0x90
ionic_tx_clean+0x211/0x280 [ionic 15881354510e6a9c655c59c54812b319ed2cd015]
ionic_tx_cq_service+0xd3/0x210 [ionic 15881354510e6a9c655c59c54812b319ed2cd015]
ionic_txrx_napi+0x41/0x1b0 [ionic 15881354510e6a9c655c59c54812b319ed2cd015]
__napi_poll.constprop.0+0x29/0x1b0
net_rx_action+0x2c4/0x350
handle_softirqs+0xf4/0x320
irq_exit_rcu+0x78/0xa0
common_interrupt+0x77/0x90 |
["https://git.kernel.org/stable/c/8ae401525ae84228a8986bb369224a6224e4d22f","https://git.kernel.org/stable/c/e3f02f32a05009a688a87f5799e049ed6b55bab5","https://git.kernel.org/stable/c/8ae401525ae84228a8986bb369224a6224e4d22f","https://git.kernel.org/stable/c/e3f02f32a05009a688a87f5799e049ed6b55bab5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42134
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
virtio-pci: Check if is_avq is NULL
[bug]
In the virtio_pci_common.c function vp_del_vqs, vp_dev->is_avq is involved
to determine whether it is admin virtqueue, but this function vp_dev->is_avq
may be empty. For installations, virtio_pci_legacy does not assign a value
to vp_dev->is_avq.
[fix]
Check whether it is vp_dev->is_avq before use.
[test]
Test with virsh Attach device
Before this patch, the following command would crash the guest system
After applying the patch, everything seems to be working fine. |
["https://git.kernel.org/stable/c/5e2024b0b9b3d5709e3f7e9b92951d7e29154106","https://git.kernel.org/stable/c/c8fae27d141a32a1624d0d0d5419d94252824498","https://git.kernel.org/stable/c/5e2024b0b9b3d5709e3f7e9b92951d7e29154106","https://git.kernel.org/stable/c/c8fae27d141a32a1624d0d0d5419d94252824498"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42151
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: mark bpf_dummy_struct_ops.test_1 parameter as nullable
Test case dummy_st_ops/dummy_init_ret_value passes NULL as the first
parameter of the test_1() function. Mark this parameter as nullable to
make verifier aware of such possibility.
Otherwise, NULL check in the test_1() code:
SEC("struct_ops/test_1")
int BPF_PROG(test_1, struct bpf_dummy_ops_state *state)
{
if (!state)
return ...;
... access state ...
}
Might be removed by verifier, thus triggering NULL pointer dereference
under certain conditions. |
["https://git.kernel.org/stable/c/1479eaff1f16983d8fda7c5a08a586c21891087d","https://git.kernel.org/stable/c/7f79097b0de97a486b137b750d7dd7b20b519d23","https://git.kernel.org/stable/c/1479eaff1f16983d8fda7c5a08a586c21891087d","https://git.kernel.org/stable/c/7f79097b0de97a486b137b750d7dd7b20b519d23"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39468
|
Medium |
fixed |
- 5.10.221
- 5.15.162
- 6.1.94
- 6.6.34
- 6.9.5
|
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix deadlock in smb2_find_smb_tcon()
Unlock cifs_tcp_ses_lock before calling cifs_put_smb_ses() to avoid such
deadlock. |
["https://git.kernel.org/stable/c/02c418774f76a0a36a6195c9dbf8971eb4130a15","https://git.kernel.org/stable/c/21f5dd36e655d25a7b45b61c1e537198b671f720","https://git.kernel.org/stable/c/225de871ddf994f69a57f035709cad9c0ab8615a","https://git.kernel.org/stable/c/8d0f5f1ccf675454a833a573c53830a49b7d1a47","https://git.kernel.org/stable/c/b055752675cd1d1db4ac9c2750db3dc3e89ea261","https://git.kernel.org/stable/c/b09b556e48968317887a11243a5331a7bc00ece5","https://git.kernel.org/stable/c/02c418774f76a0a36a6195c9dbf8971eb4130a15","https://git.kernel.org/stable/c/21f5dd36e655d25a7b45b61c1e537198b671f720","https://git.kernel.org/stable/c/225de871ddf994f69a57f035709cad9c0ab8615a","https://git.kernel.org/stable/c/8d0f5f1ccf675454a833a573c53830a49b7d1a47","https://git.kernel.org/stable/c/b055752675cd1d1db4ac9c2750db3dc3e89ea261","https://git.kernel.org/stable/c/b09b556e48968317887a11243a5331a7bc00ece5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48718
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm: mxsfb: Fix NULL pointer dereference
mxsfb should not ever dereference the NULL pointer which
drm_atomic_get_new_bridge_state is allowed to return.
Assume a fixed format instead. |
["https://git.kernel.org/stable/c/622c9a3a7868e1eeca39c55305ca3ebec4742b64","https://git.kernel.org/stable/c/6f9267e01cca749137349d8ffb0d0ebbadf567f4","https://git.kernel.org/stable/c/86a337bb803040e4401b87c974a7fb92efe3d0e1","https://git.kernel.org/stable/c/622c9a3a7868e1eeca39c55305ca3ebec4742b64","https://git.kernel.org/stable/c/6f9267e01cca749137349d8ffb0d0ebbadf567f4","https://git.kernel.org/stable/c/86a337bb803040e4401b87c974a7fb92efe3d0e1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52744
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/irdma: Fix potential NULL-ptr-dereference
in_dev_get() can return NULL which will cause a failure once idev is
dereferenced in in_dev_for_each_ifa_rtnl(). This patch adds a
check for NULL value in idev beforehand.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/360682fe7df262d94fae54f737c487bec0f9190d","https://git.kernel.org/stable/c/5d9745cead1f121974322b94ceadfb4d1e67960e","https://git.kernel.org/stable/c/8f5fe1cd8e6a97f94840b55f59ed08cbc397086f","https://git.kernel.org/stable/c/360682fe7df262d94fae54f737c487bec0f9190d","https://git.kernel.org/stable/c/5d9745cead1f121974322b94ceadfb4d1e67960e","https://git.kernel.org/stable/c/8f5fe1cd8e6a97f94840b55f59ed08cbc397086f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35945
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: phy: phy_device: Prevent nullptr exceptions on ISR
If phydev->irq is set unconditionally, check
for valid interrupt handler or fall back to polling mode to prevent
nullptr exceptions in interrupt service routine. |
["https://git.kernel.org/stable/c/3419ee39e3d3162ab2ec9942bb537613ed5b6311","https://git.kernel.org/stable/c/61c81872815f46006982bb80460c0c80a949b35b","https://git.kernel.org/stable/c/7a71f61ebf95cedd3f245db6da397822971d8db5","https://git.kernel.org/stable/c/3419ee39e3d3162ab2ec9942bb537613ed5b6311","https://git.kernel.org/stable/c/61c81872815f46006982bb80460c0c80a949b35b","https://git.kernel.org/stable/c/7a71f61ebf95cedd3f245db6da397822971d8db5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35946
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: fix null pointer access when abort scan
During cancel scan we might use vif that weren't scanning.
Fix this by using the actual scanning vif. |
["https://git.kernel.org/stable/c/4f11c741908dab7dd48fa5a986b210d4fc74ca8d","https://git.kernel.org/stable/c/7e11a2966f51695c0af0b1f976a32d64dee243b2","https://git.kernel.org/stable/c/b34d64e9aa5505e3c84570aed5c757f1839573e8","https://git.kernel.org/stable/c/4f11c741908dab7dd48fa5a986b210d4fc74ca8d","https://git.kernel.org/stable/c/7e11a2966f51695c0af0b1f976a32d64dee243b2","https://git.kernel.org/stable/c/b34d64e9aa5505e3c84570aed5c757f1839573e8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35972
|
Medium |
fixed |
- 5.10.216
- 5.15.158
- 6.1.87
- 6.6.28
- 6.8.7
|
In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Fix possible memory leak in bnxt_rdma_aux_device_init()
If ulp = kzalloc() fails, the allocated edev will leak because it is
not properly assigned and the cleanup path will not be able to free it.
Fix it by assigning it properly immediately after allocation. |
["https://git.kernel.org/stable/c/10a9d6a7513f93d7faffcb341af0aa42be8218fe","https://git.kernel.org/stable/c/7ac10c7d728d75bc9daaa8fade3c7a3273b9a9ff","https://git.kernel.org/stable/c/c60ed825530b8c0cc2b524efd39b1d696ec54004","https://git.kernel.org/stable/c/10a9d6a7513f93d7faffcb341af0aa42be8218fe","https://git.kernel.org/stable/c/7ac10c7d728d75bc9daaa8fade3c7a3273b9a9ff","https://git.kernel.org/stable/c/c60ed825530b8c0cc2b524efd39b1d696ec54004"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38625
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Check 'folio' pointer for NULL
It can be NULL if bmap is called. |
["https://git.kernel.org/stable/c/1cd6c96219c429ebcfa8e79a865277376c563803","https://git.kernel.org/stable/c/6c8054d590668629bb2eb6fb4cbf22455d08ada8","https://git.kernel.org/stable/c/ff1068929459347f9e47f8d14c409dcf938c2641","https://git.kernel.org/stable/c/1cd6c96219c429ebcfa8e79a865277376c563803","https://git.kernel.org/stable/c/6c8054d590668629bb2eb6fb4cbf22455d08ada8","https://git.kernel.org/stable/c/ff1068929459347f9e47f8d14c409dcf938c2641"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3359
|
Medium |
fixed |
|
An issue was discovered in the Linux kernel brcm_nvram_parse in drivers/nvmem/brcm_nvram.c. Lacks for the check of the return value of kzalloc() can cause the NULL Pointer Dereference. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b0576ade3aaf24b376ea1a4406ae138e2a22b0c0","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b0576ade3aaf24b376ea1a4406ae138e2a22b0c0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48978
|
Medium |
fixed |
- 4.9.336
- 4.14.302
- 4.19.269
- 5.4.227
- 5.10.159
- 5.15.83
- 6.0.13
|
In the Linux kernel, the following vulnerability has been resolved:
HID: core: fix shift-out-of-bounds in hid_report_raw_event
Syzbot reported shift-out-of-bounds in hid_report_raw_event.
microsoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) >
32! (swapper/0)
======================================================================
UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20
shift exponent 127 is too large for 32-bit type 'int'
CPU: 0 PID: 0 Comm: swapper/0 Not tainted
6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0
Hardware name: Google Compute Engine/Google Compute Engine, BIOS
Google 10/26/2022
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106
ubsan_epilogue lib/ubsan.c:151 [inline]
__ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322
snto32 drivers/hid/hid-core.c:1323 [inline]
hid_input_fetch_field drivers/hid/hid-core.c:1572 [inline]
hid_process_report drivers/hid/hid-core.c:1665 [inline]
hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998
hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066
hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284
__usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671
dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988
call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474
expire_timers kernel/time/timer.c:1519 [inline]
__run_timers+0x76a/0x980 kernel/time/timer.c:1790
run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803
__do_softirq+0x277/0x75b kernel/softirq.c:571
__irq_exit_rcu+0xec/0x170 kernel/softirq.c:650
irq_exit_rcu+0x5/0x20 kernel/softirq.c:662
sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107
======================================================================
If the size of the integer (unsigned n) is bigger than 32 in snto32(),
shift exponent will be too large for 32-bit type 'int', resulting in a
shift-out-of-bounds bug.
Fix this by adding a check on the size of the integer (unsigned n) in
snto32(). To add support for n greater than 32 bits, set n to 32, if n
is greater than 32. |
["https://git.kernel.org/stable/c/151493fe5a6ed1a88decc929a7368a3f2a246914","https://git.kernel.org/stable/c/2b3b4d7aadaa1b6b58d0f34823bf86cfe8a31b4d","https://git.kernel.org/stable/c/809783f8b4b600c7fb3bccb10fefef822601ea3b","https://git.kernel.org/stable/c/8e14f20e12224ee2429f75a5c9418a700e26a8d3","https://git.kernel.org/stable/c/bc03f809da78fc79e4aee132d4e5c6a2b3aeec73","https://git.kernel.org/stable/c/db1ed1b3fb4ec0d19080a102956255769bc45c79","https://git.kernel.org/stable/c/ec61b41918587be530398b0d1c9a0d16619397e5","https://git.kernel.org/stable/c/f755d11c55b29049b77da5cd9ab2faae96eb33c3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49007
|
Medium |
fixed |
- 4.9.335
- 4.14.301
- 4.19.268
- 5.4.226
- 5.10.158
- 5.15.82
- 6.0.12
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry()
Syzbot reported a null-ptr-deref bug:
NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP
frequency < 30 seconds
general protection fault, probably for non-canonical address
0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
CPU: 1 PID: 3603 Comm: segctord Not tainted
6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0
Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google
10/11/2022
RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0
fs/nilfs2/alloc.c:608
Code: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00
00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 <80> 3c 02
00 0f 85 26 05 00 00 49 8b 46 10 be a6 00 00 00 48 c7 c7
RSP: 0018:ffffc90003dff830 EFLAGS: 00010212
RAX: dffffc0000000000 RBX: ffff88802594e218 RCX: 000000000000000d
RDX: 0000000000000002 RSI: 0000000000002000 RDI: 0000000000000010
RBP: ffff888071880222 R08: 0000000000000005 R09: 000000000000003f
R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158
R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004
FS: 0000000000000000(0000) GS:ffff8880b9b00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0
Call Trace:
<TASK>
nilfs_dat_commit_free fs/nilfs2/dat.c:114 [inline]
nilfs_dat_commit_end+0x464/0x5f0 fs/nilfs2/dat.c:193
nilfs_dat_commit_update+0x26/0x40 fs/nilfs2/dat.c:236
nilfs_btree_commit_update_v+0x87/0x4a0 fs/nilfs2/btree.c:1940
nilfs_btree_commit_propagate_v fs/nilfs2/btree.c:2016 [inline]
nilfs_btree_propagate_v fs/nilfs2/btree.c:2046 [inline]
nilfs_btree_propagate+0xa00/0xd60 fs/nilfs2/btree.c:2088
nilfs_bmap_propagate+0x73/0x170 fs/nilfs2/bmap.c:337
nilfs_collect_file_data+0x45/0xd0 fs/nilfs2/segment.c:568
nilfs_segctor_apply_buffers+0x14a/0x470 fs/nilfs2/segment.c:1018
nilfs_segctor_scan_file+0x3f4/0x6f0 fs/nilfs2/segment.c:1067
nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1197 [inline]
nilfs_segctor_collect fs/nilfs2/segment.c:1503 [inline]
nilfs_segctor_do_construct+0x12fc/0x6af0 fs/nilfs2/segment.c:2045
nilfs_segctor_construct+0x8e3/0xb30 fs/nilfs2/segment.c:2379
nilfs_segctor_thread_construct fs/nilfs2/segment.c:2487 [inline]
nilfs_segctor_thread+0x3c3/0xf30 fs/nilfs2/segment.c:2570
kthread+0x2e4/0x3a0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
</TASK>
...
If DAT metadata file is corrupted on disk, there is a case where
req->pr_desc_bh is NULL and blocknr is 0 at nilfs_dat_commit_end() during
a b-tree operation that cascadingly updates ancestor nodes of the b-tree,
because nilfs_dat_commit_alloc() for a lower level block can initialize
the blocknr on the same DAT entry between nilfs_dat_prepare_end() and
nilfs_dat_commit_end().
If this happens, nilfs_dat_commit_end() calls nilfs_dat_commit_free()
without valid buffer heads in req->pr_desc_bh and req->pr_bitmap_bh, and
causes the NULL pointer dereference above in
nilfs_palloc_commit_free_entry() function, which leads to a crash.
Fix this by adding a NULL check on req->pr_desc_bh and req->pr_bitmap_bh
before nilfs_palloc_commit_free_entry() in nilfs_dat_commit_free().
This also calls nilfs_error() in that case to notify that there is a fatal
flaw in the filesystem metadata and prevent further operations. |
["https://git.kernel.org/stable/c/165c7a3b27a3857ebf57f626b9f38b48b6792e68","https://git.kernel.org/stable/c/2f2c59506ae39496588ceb8b88bdbdbaed895d63","https://git.kernel.org/stable/c/33021419fd81efd3d729a7f19341ba4b98fe66ce","https://git.kernel.org/stable/c/381b84f60e549ea98cec4666c6c728b1b3318756","https://git.kernel.org/stable/c/9a130b72e6bd1fb07fc3cde839dc6fb53da76f07","https://git.kernel.org/stable/c/bc3fd3293887b4cf84a9109700faeb82de533c89","https://git.kernel.org/stable/c/e858917ab785afe83c14f5ac141301216ccda847","https://git.kernel.org/stable/c/f0a0ccda18d6fd826d7c7e7ad48a6ed61c20f8b4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49021
|
Medium |
fixed |
- 4.9.335
- 4.14.301
- 4.19.268
- 5.4.226
- 5.10.158
- 5.15.82
- 6.0.12
|
In the Linux kernel, the following vulnerability has been resolved:
net: phy: fix null-ptr-deref while probe() failed
I got a null-ptr-deref report as following when doing fault injection test:
BUG: kernel NULL pointer dereference, address: 0000000000000058
Oops: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G B N 6.1.0-rc3+
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:klist_put+0x2d/0xd0
Call Trace:
<TASK>
klist_remove+0xf1/0x1c0
device_release_driver_internal+0x23e/0x2d0
bus_remove_device+0x1bd/0x240
device_del+0x357/0x770
phy_device_remove+0x11/0x30
mdiobus_unregister+0xa5/0x140
release_nodes+0x6a/0xa0
devres_release_all+0xf8/0x150
device_unbind_cleanup+0x19/0xd0
//probe path:
phy_device_register()
device_add()
phy_connect
phy_attach_direct() //set device driver
probe() //it's failed, driver is not bound
device_bind_driver() // probe failed, it's not called
//remove path:
phy_device_remove()
device_del()
device_release_driver_internal()
__device_release_driver() //dev->drv is not NULL
klist_remove() <- knode_driver is not added yet, cause null-ptr-deref
In phy_attach_direct(), after setting the 'dev->driver', probe() fails,
device_bind_driver() is not called, so the knode_driver->n_klist is not
set, then it causes null-ptr-deref in __device_release_driver() while
deleting device. Fix this by setting dev->driver to NULL in the error
path in phy_attach_direct(). |
["https://git.kernel.org/stable/c/0744c7be4de564db03e24527b2e096b7e0e20972","https://git.kernel.org/stable/c/369eb2c9f1f72adbe91e0ea8efb130f0a2ba11a6","https://git.kernel.org/stable/c/3e21f85d87c836462bb52ef2078ea561260935c1","https://git.kernel.org/stable/c/51d7f6b20fae8bae64ad1136f1e30d1fd5ba78f7","https://git.kernel.org/stable/c/7730904f50c7187dd16c76949efb56b5fb55cd57","https://git.kernel.org/stable/c/8aaafe0f71314f46a066382a047ba8bb3840d273","https://git.kernel.org/stable/c/eaa5722549ac2604ffa56c2e946acc83226f130c","https://git.kernel.org/stable/c/fe6bc99c27c21348f548966118867ed26a9a372c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49033
|
Medium |
fixed |
- 4.14.301
- 4.19.268
- 5.4.226
- 5.10.158
- 5.15.82
- 6.0.12
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit()
Syzkaller reported BUG as follows:
BUG: sleeping function called from invalid context at
include/linux/sched/mm.h:274
Call Trace:
<TASK>
dump_stack_lvl+0xcd/0x134
__might_resched.cold+0x222/0x26b
kmem_cache_alloc+0x2e7/0x3c0
update_qgroup_limit_item+0xe1/0x390
btrfs_qgroup_inherit+0x147b/0x1ee0
create_subvol+0x4eb/0x1710
btrfs_mksubvol+0xfe5/0x13f0
__btrfs_ioctl_snap_create+0x2b0/0x430
btrfs_ioctl_snap_create_v2+0x25a/0x520
btrfs_ioctl+0x2a1c/0x5ce0
__x64_sys_ioctl+0x193/0x200
do_syscall_64+0x35/0x80
Fix this by calling qgroup_dirty() on @dstqgroup, and update limit item in
btrfs_run_qgroups() later outside of the spinlock context. |
["https://git.kernel.org/stable/c/01d7c41eac9129fba80d8aed0060caab4a7dbe09","https://git.kernel.org/stable/c/044da1a371a0da579e805e89c96865f62d8f6f69","https://git.kernel.org/stable/c/3c98e91be6aea4c7acf09da6eb0c107ea9186bb5","https://git.kernel.org/stable/c/588ae4fdd8b11788a797776b10d6c44ae12bc133","https://git.kernel.org/stable/c/89840b12c8fad7200eb6478525c13261512c01be","https://git.kernel.org/stable/c/8eb912af525042a7365295eb62f6d5270c2a6462","https://git.kernel.org/stable/c/f4b930a1602b05e77fee31f9616599b25e910a86","https://git.kernel.org/stable/c/f7e942b5bb35d8e3af54053d19a6bf04143a3955"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48875
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: sdata can be NULL during AMPDU start
ieee80211_tx_ba_session_handle_start() may get NULL for sdata when a
deauthentication is ongoing.
Here a trace triggering the race with the hostapd test
multi_ap_fronthaul_on_ap:
(gdb) list *drv_ampdu_action+0x46
0x8b16 is in drv_ampdu_action (net/mac80211/driver-ops.c:396).
391 int ret = -EOPNOTSUPP;
392
393 might_sleep();
394
395 sdata = get_bss_sdata(sdata);
396 if (!check_sdata_in_driver(sdata))
397 return -EIO;
398
399 trace_drv_ampdu_action(local, sdata, params);
400
wlan0: moving STA 02:00:00:00:03:00 to state 3
wlan0: associated
wlan0: deauthenticating from 02:00:00:00:03:00 by local choice (Reason: 3=DEAUTH_LEAVING)
wlan3.sta1: Open BA session requested for 02:00:00:00:00:00 tid 0
wlan3.sta1: dropped frame to 02:00:00:00:00:00 (unauthorized port)
wlan0: moving STA 02:00:00:00:03:00 to state 2
wlan0: moving STA 02:00:00:00:03:00 to state 1
wlan0: Removed STA 02:00:00:00:03:00
wlan0: Destroyed STA 02:00:00:00:03:00
BUG: unable to handle page fault for address: fffffffffffffb48
PGD 11814067 P4D 11814067 PUD 11816067 PMD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 2 PID: 133397 Comm: kworker/u16:1 Tainted: G W 6.1.0-rc8-wt+ #59
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014
Workqueue: phy3 ieee80211_ba_session_work [mac80211]
RIP: 0010:drv_ampdu_action+0x46/0x280 [mac80211]
Code: 53 48 89 f3 be 89 01 00 00 e8 d6 43 bf ef e8 21 46 81 f0 83 bb a0 1b 00 00 04 75 0e 48 8b 9b 28 0d 00 00 48 81 eb 10 0e 00 00 <8b> 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85
RSP: 0018:ffffc900025ebd20 EFLAGS: 00010287
RAX: 0000000000000000 RBX: fffffffffffff1f0 RCX: ffff888102228240
RDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40
RBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000000 R12: ffff888118c18ec0
R13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8
FS: 0000000000000000(0000) GS:ffff88817a600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0
Call Trace:
<TASK>
ieee80211_tx_ba_session_handle_start+0xd0/0x190 [mac80211]
ieee80211_ba_session_work+0xff/0x2e0 [mac80211]
process_one_work+0x29f/0x620
worker_thread+0x4d/0x3d0
? process_one_work+0x620/0x620
kthread+0xfb/0x120
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x22/0x30
</TASK> |
["https://git.kernel.org/stable/c/187523fa7c2d4c780f775cb869216865c4a909ef","https://git.kernel.org/stable/c/69403bad97aa0162e3d7911b27e25abe774093df","https://git.kernel.org/stable/c/a12fd43bd175fa52c82f9740179d38c34ca1b62e","https://git.kernel.org/stable/c/c838df8461a601b20dc1b9fb1834d2aad8e2f949"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44969
|
Medium |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.105
- 6.6.46
- 6.10.5
|
In the Linux kernel, the following vulnerability has been resolved:
s390/sclp: Prevent release of buffer in I/O
When a task waiting for completion of a Store Data operation is
interrupted, an attempt is made to halt this operation. If this attempt
fails due to a hardware or firmware problem, there is a chance that the
SCLP facility might store data into buffers referenced by the original
operation at a later time.
Handle this situation by not releasing the referenced data buffers if
the halt attempt fails. For current use cases, this might result in a
leak of few pages of memory in case of a rare hardware/firmware
malfunction. |
["https://git.kernel.org/stable/c/1e8b7fb427af6b2ddd54eff66a6b428a81c96633","https://git.kernel.org/stable/c/1ec5ea9e25f582fd6999393e2f2c3bf56f234e05","https://git.kernel.org/stable/c/2429ea3b4330e3653b72b210a0d5f2a717359506","https://git.kernel.org/stable/c/46f67233b011385d53cf14d272431755de3a7c79","https://git.kernel.org/stable/c/7a7e60ed23d471a07dbbe72565d2992ee8244bbe","https://git.kernel.org/stable/c/a3e52a4c22c846858a6875e1c280030a3849e148","https://git.kernel.org/stable/c/a88a49473c94ccfd8dce1e766aacf3c627278463","https://git.kernel.org/stable/c/bf365071ea92b9579d5a272679b74052a5643e35"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46770
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ice: Add netif_device_attach/detach into PF reset flow
Ethtool callbacks can be executed while reset is in progress and try to
access deleted resources, e.g. getting coalesce settings can result in a
NULL pointer dereference seen below.
Reproduction steps:
Once the driver is fully initialized, trigger reset:
# echo 1 > /sys/class/net/<interface>/device/reset
when reset is in progress try to get coalesce settings using ethtool:
# ethtool -c <interface>
BUG: kernel NULL pointer dereference, address: 0000000000000020
PGD 0 P4D 0
Oops: Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 11 PID: 19713 Comm: ethtool Tainted: G S 6.10.0-rc7+ #7
RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice]
RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206
RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000
R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40
FS: 00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0
Call Trace:
<TASK>
ice_get_coalesce+0x17/0x30 [ice]
coalesce_prepare_data+0x61/0x80
ethnl_default_doit+0xde/0x340
genl_family_rcv_msg_doit+0xf2/0x150
genl_rcv_msg+0x1b3/0x2c0
netlink_rcv_skb+0x5b/0x110
genl_rcv+0x28/0x40
netlink_unicast+0x19c/0x290
netlink_sendmsg+0x222/0x490
__sys_sendto+0x1df/0x1f0
__x64_sys_sendto+0x24/0x30
do_syscall_64+0x82/0x160
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7faee60d8e27
Calling netif_device_detach() before reset makes the net core not call
the driver when ethtool command is issued, the attempt to execute an
ethtool command during reset will result in the following message:
netlink error: No such device
instead of NULL pointer dereference. Once reset is done and
ice_rebuild() is executing, the netif_device_attach() is called to allow
for ethtool operations to occur again in a safe manner. |
["https://git.kernel.org/stable/c/36486c9e8e01b84faaee47203eac0b7e9cc7fa4a","https://git.kernel.org/stable/c/9e3ffb839249eca113062587659224f856fe14e5","https://git.kernel.org/stable/c/d11a67634227f9f9da51938af085fb41a733848f","https://git.kernel.org/stable/c/efe8effe138044a4747d1112ebb8c454d1663723"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46848
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/intel: Limit the period on Haswell
Running the ltp test cve-2015-3290 concurrently reports the following
warnings.
perfevents: irq loop stuck!
WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174
intel_pmu_handle_irq+0x285/0x370
Call Trace:
<NMI>
? __warn+0xa4/0x220
? intel_pmu_handle_irq+0x285/0x370
? __report_bug+0x123/0x130
? intel_pmu_handle_irq+0x285/0x370
? __report_bug+0x123/0x130
? intel_pmu_handle_irq+0x285/0x370
? report_bug+0x3e/0xa0
? handle_bug+0x3c/0x70
? exc_invalid_op+0x18/0x50
? asm_exc_invalid_op+0x1a/0x20
? irq_work_claim+0x1e/0x40
? intel_pmu_handle_irq+0x285/0x370
perf_event_nmi_handler+0x3d/0x60
nmi_handle+0x104/0x330
Thanks to Thomas Gleixner's analysis, the issue is caused by the low
initial period (1) of the frequency estimation algorithm, which triggers
the defects of the HW, specifically erratum HSW11 and HSW143. (For the
details, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)
The HSW11 requires a period larger than 100 for the INST_RETIRED.ALL
event, but the initial period in the freq mode is 1. The erratum is the
same as the BDM11, which has been supported in the kernel. A minimum
period of 128 is enforced as well on HSW.
HSW143 is regarding that the fixed counter 1 may overcount 32 with the
Hyper-Threading is enabled. However, based on the test, the hardware
has more issues than it tells. Besides the fixed counter 1, the message
'interrupt took too long' can be observed on any counter which was armed
with a period < 32 and two events expired in the same NMI. A minimum
period of 32 is enforced for the rest of the events.
The recommended workaround code of the HSW143 is not implemented.
Because it only addresses the issue for the fixed counter. It brings
extra overhead through extra MSR writing. No related overcounting issue
has been reported so far. |
["https://git.kernel.org/stable/c/0eaf812aa1506704f3b78be87036860e5d0fe81d","https://git.kernel.org/stable/c/15210b7c8caff4929f25d049ef8404557f8ae468","https://git.kernel.org/stable/c/25dfc9e357af8aed1ca79b318a73f2c59c1f0b2b","https://git.kernel.org/stable/c/8717dc35c0e5896f4110f4b3882f7ff787a5f73d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48841
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ice: fix NULL pointer dereference in ice_update_vsi_tx_ring_stats()
It is possible to do NULL pointer dereference in routine that updates
Tx ring stats. Currently only stats and bytes are updated when ring
pointer is valid, but later on ring is accessed to propagate gathered Tx
stats onto VSI stats.
Change the existing logic to move to next ring when ring is NULL. |
["https://git.kernel.org/stable/c/2397270ec97c5e3009a58ac110a25e1869e9d6ff","https://git.kernel.org/stable/c/f153546913bada41a811722f2c6d17c3243a0333","https://git.kernel.org/stable/c/2397270ec97c5e3009a58ac110a25e1869e9d6ff","https://git.kernel.org/stable/c/f153546913bada41a811722f2c6d17c3243a0333"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48969
|
Medium |
fixed |
- 4.19.269
- 5.4.227
- 5.10.159
- 5.15.83
- 6.0.13
|
In the Linux kernel, the following vulnerability has been resolved:
xen-netfront: Fix NULL sring after live migration
A NAPI is setup for each network sring to poll data to kernel
The sring with source host is destroyed before live migration and
new sring with target host is setup after live migration.
The NAPI for the old sring is not deleted until setup new sring
with target host after migration. With busy_poll/busy_read enabled,
the NAPI can be polled before got deleted when resume VM.
BUG: unable to handle kernel NULL pointer dereference at
0000000000000008
IP: xennet_poll+0xae/0xd20
PGD 0 P4D 0
Oops: 0000 [#1] SMP PTI
Call Trace:
finish_task_switch+0x71/0x230
timerqueue_del+0x1d/0x40
hrtimer_try_to_cancel+0xb5/0x110
xennet_alloc_rx_buffers+0x2a0/0x2a0
napi_busy_loop+0xdb/0x270
sock_poll+0x87/0x90
do_sys_poll+0x26f/0x580
tracing_map_insert+0x1d4/0x2f0
event_hist_trigger+0x14a/0x260
finish_task_switch+0x71/0x230
__schedule+0x256/0x890
recalc_sigpending+0x1b/0x50
xen_sched_clock+0x15/0x20
__rb_reserve_next+0x12d/0x140
ring_buffer_lock_reserve+0x123/0x3d0
event_triggers_call+0x87/0xb0
trace_event_buffer_commit+0x1c4/0x210
xen_clocksource_get_cycles+0x15/0x20
ktime_get_ts64+0x51/0xf0
SyS_ppoll+0x160/0x1a0
SyS_ppoll+0x160/0x1a0
do_syscall_64+0x73/0x130
entry_SYSCALL_64_after_hwframe+0x41/0xa6
...
RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900
CR2: 0000000000000008
---[ end trace f8601785b354351c ]---
xen frontend should remove the NAPIs for the old srings before live
migration as the bond srings are destroyed
There is a tiny window between the srings are set to NULL and
the NAPIs are disabled, It is safe as the NAPI threads are still
frozen at that time |
["https://git.kernel.org/stable/c/99859947517e446058ad7243ee81d2f9801fa3dd","https://git.kernel.org/stable/c/d50b7914fae04d840ce36491d22133070b18cca9","https://git.kernel.org/stable/c/e6860c889f4ad50b6ab696f5ea154295d72cf27a","https://git.kernel.org/stable/c/e6e897d4fe2f89c0bd94600a40bedf5e6e75e050","https://git.kernel.org/stable/c/ed773dd798bf720756d20021b8d8a4a3d7184bda","https://git.kernel.org/stable/c/f2dd60fd3fe98bd36a91b0c6e10bfe9d66258f84"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36476
|
Medium |
fixed |
- 5.10.233
- 5.15.176
- 6.1.124
- 6.6.70
- 6.12.9
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rtrs: Ensure 'ib_sge list' is accessible
Move the declaration of the 'ib_sge list' variable outside the
'always_invalidate' block to ensure it remains accessible for use
throughout the function.
Previously, 'ib_sge list' was declared within the 'always_invalidate'
block, limiting its accessibility, then caused a
'BUG: kernel NULL pointer dereference'[1].
? __die_body.cold+0x19/0x27
? page_fault_oops+0x15a/0x2d0
? search_module_extables+0x19/0x60
? search_bpf_extables+0x5f/0x80
? exc_page_fault+0x7e/0x180
? asm_exc_page_fault+0x26/0x30
? memcpy_orig+0xd5/0x140
rxe_mr_copy+0x1c3/0x200 [rdma_rxe]
? rxe_pool_get_index+0x4b/0x80 [rdma_rxe]
copy_data+0xa5/0x230 [rdma_rxe]
rxe_requester+0xd9b/0xf70 [rdma_rxe]
? finish_task_switch.isra.0+0x99/0x2e0
rxe_sender+0x13/0x40 [rdma_rxe]
do_task+0x68/0x1e0 [rdma_rxe]
process_one_work+0x177/0x330
worker_thread+0x252/0x390
? __pfx_worker_thread+0x10/0x10
This change ensures the variable is available for subsequent operations
that require it.
[1] https://lore.kernel.org/linux-rdma/6a1f3e8f-deb0-49f9-bc69-a9b03ecfcda7@fujitsu.com/ |
["https://git.kernel.org/stable/c/143378075904e78b3b2a810099bcc3b3d82d762f","https://git.kernel.org/stable/c/32e1e748a85bd52b20b3857d80fd166d22fa455a","https://git.kernel.org/stable/c/6ffb5c1885195ae5211a12b4acd2d51843ca41b0","https://git.kernel.org/stable/c/7eaa71f56a6f7ab87957213472dc6d4055862722","https://git.kernel.org/stable/c/b238f61cc394d5fef27b26d7d9aa383ebfddabb0","https://git.kernel.org/stable/c/fb514b31395946022f13a08e06a435f53cf9e8b3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-55916
|
Medium |
fixed |
- 5.4.289
- 5.10.233
- 5.15.176
- 6.1.122
- 6.6.68
- 6.12.7
|
In the Linux kernel, the following vulnerability has been resolved:
Drivers: hv: util: Avoid accessing a ringbuffer not initialized yet
If the KVP (or VSS) daemon starts before the VMBus channel's ringbuffer is
fully initialized, we can hit the panic below:
hv_utils: Registering HyperV Utility Driver
hv_vmbus: registering driver hv_utils
...
BUG: kernel NULL pointer dereference, address: 0000000000000000
CPU: 44 UID: 0 PID: 2552 Comm: hv_kvp_daemon Tainted: G E 6.11.0-rc3+ #1
RIP: 0010:hv_pkt_iter_first+0x12/0xd0
Call Trace:
...
vmbus_recvpacket
hv_kvp_onchannelcallback
vmbus_on_event
tasklet_action_common
tasklet_action
handle_softirqs
irq_exit_rcu
sysvec_hyperv_stimer0
</IRQ>
<TASK>
asm_sysvec_hyperv_stimer0
...
kvp_register_done
hvt_op_read
vfs_read
ksys_read
__x64_sys_read
This can happen because the KVP/VSS channel callback can be invoked
even before the channel is fully opened:
1) as soon as hv_kvp_init() -> hvutil_transport_init() creates
/dev/vmbus/hv_kvp, the kvp daemon can open the device file immediately and
register itself to the driver by writing a message KVP_OP_REGISTER1 to the
file (which is handled by kvp_on_msg() ->kvp_handle_handshake()) and
reading the file for the driver's response, which is handled by
hvt_op_read(), which calls hvt->on_read(), i.e. kvp_register_done().
2) the problem with kvp_register_done() is that it can cause the
channel callback to be called even before the channel is fully opened,
and when the channel callback is starting to run, util_probe()->
vmbus_open() may have not initialized the ringbuffer yet, so the
callback can hit the panic of NULL pointer dereference.
To reproduce the panic consistently, we can add a "ssleep(10)" for KVP in
__vmbus_open(), just before the first hv_ringbuffer_init(), and then we
unload and reload the driver hv_utils, and run the daemon manually within
the 10 seconds.
Fix the panic by reordering the steps in util_probe() so the char dev
entry used by the KVP or VSS daemon is not created until after
vmbus_open() has completed. This reordering prevents the race condition
from happening. |
["https://git.kernel.org/stable/c/042253c57be901bfd19f15b68267442b70f510d5","https://git.kernel.org/stable/c/07a756a49f4b4290b49ea46e089cbe6f79ff8d26","https://git.kernel.org/stable/c/3dd7a30c6d7f90afcf19e9b072f572ba524d7ec6","https://git.kernel.org/stable/c/718fe694a334be9d1a89eed22602369ac18d6583","https://git.kernel.org/stable/c/89fcec5e466b3ac9b376e0d621c71effa1a7983f","https://git.kernel.org/stable/c/d81f4e73aff9b861671df60e5100ad25cc16fbf8","https://git.kernel.org/stable/c/f091a224a2c82f1e302b1768d73bb6332f687321"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56763
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
tracing: Prevent bad count for tracing_cpumask_write
If a large count is provided, it will trigger a warning in bitmap_parse_user.
Also check zero for it. |
["https://git.kernel.org/stable/c/03041e474a6a8f1bfd4b96b164bb3165c48fa1a3","https://git.kernel.org/stable/c/1cca920af19df5dd91254e5ff35e68e911683706","https://git.kernel.org/stable/c/2558d753df0628d4187d8e1fd989339460f4f364","https://git.kernel.org/stable/c/3d15f4c2449558ffe83b4dba30614ef1cd6937c3","https://git.kernel.org/stable/c/98feccbf32cfdde8c722bc4587aaa60ee5ac33f0","https://git.kernel.org/stable/c/f60172b447317cb6c5e74b5601a151866269baf6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56767
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: at_xdmac: avoid null_prt_deref in at_xdmac_prep_dma_memset
The at_xdmac_memset_create_desc may return NULL, which will lead to a
null pointer dereference. For example, the len input is error, or the
atchan->free_descs_list is empty and memory is exhausted. Therefore, add
check to avoid this. |
["https://git.kernel.org/stable/c/3d229600c54e9e0909080ecaf1aab0642aefa5f0","https://git.kernel.org/stable/c/54376d8d26596f98ed7432a788314bb9154bf3e3","https://git.kernel.org/stable/c/8d364597de9ce2a5f52714224bfe6c2e7a29b303","https://git.kernel.org/stable/c/c43ec96e8d34399bd9dab2f2dc316b904892133f","https://git.kernel.org/stable/c/e658f1c133b854b2ae799147301d82dddb8f3162","https://git.kernel.org/stable/c/ed1a8aaa344522c0c349ac9042db27ad130ef913","https://git.kernel.org/stable/c/fdba6d5e455388377ec7e82a5913ddfcc7edd93b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56769
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-frontends: dib3000mb: fix uninit-value in dib3000_write_reg
Syzbot reports [1] an uninitialized value issue found by KMSAN in
dib3000_read_reg().
Local u8 rb[2] is used in i2c_transfer() as a read buffer; in case
that call fails, the buffer may end up with some undefined values.
Since no elaborate error handling is expected in dib3000_write_reg(),
simply zero out rb buffer to mitigate the problem.
[1] Syzkaller report
dvb-usb: bulk message failed: -22 (6/0)
=====================================================
BUG: KMSAN: uninit-value in dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758
dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758
dibusb_dib3000mb_frontend_attach+0x155/0x2f0 drivers/media/usb/dvb-usb/dibusb-mb.c:31
dvb_usb_adapter_frontend_init+0xed/0x9a0 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:290
dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:90 [inline]
dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:186 [inline]
dvb_usb_device_init+0x25a8/0x3760 drivers/media/usb/dvb-usb/dvb-usb-init.c:310
dibusb_probe+0x46/0x250 drivers/media/usb/dvb-usb/dibusb-mb.c:110
...
Local variable rb created at:
dib3000_read_reg+0x86/0x4e0 drivers/media/dvb-frontends/dib3000mb.c:54
dib3000mb_attach+0x123/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758
... |
["https://git.kernel.org/stable/c/035772fcd631eee2756b31cb6df249c0a8d453d7","https://git.kernel.org/stable/c/1d6de21f00293d819b5ca6dbe75ff1f3b6392140","https://git.kernel.org/stable/c/2dd59fe0e19e1ab955259978082b62e5751924c7","https://git.kernel.org/stable/c/3876e3a1c31a58a352c6bf5d2a90e3304445a637","https://git.kernel.org/stable/c/53106510736e734ce8b731ba871363389bfbf4c9","https://git.kernel.org/stable/c/c1197c1457bb7098cf46366e898eb52b41b6876a","https://git.kernel.org/stable/c/e11778189513cd7fb2edced5bd053bc18ede8418"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56779
|
Medium |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.12.4
|
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur
The action force umount(umount -f) will attempt to kill all rpc_task even
umount operation may ultimately fail if some files remain open.
Consequently, if an action attempts to open a file, it can potentially
send two rpc_task to nfs server.
NFS CLIENT
thread1 thread2
open("file")
...
nfs4_do_open
_nfs4_do_open
_nfs4_open_and_get_state
_nfs4_proc_open
nfs4_run_open_task
/* rpc_task1 */
rpc_run_task
rpc_wait_for_completion_task
umount -f
nfs_umount_begin
rpc_killall_tasks
rpc_signal_task
rpc_task1 been wakeup
and return -512
_nfs4_do_open // while loop
...
nfs4_run_open_task
/* rpc_task2 */
rpc_run_task
rpc_wait_for_completion_task
While processing an open request, nfsd will first attempt to find or
allocate an nfs4_openowner. If it finds an nfs4_openowner that is not
marked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since
two rpc_task can attempt to open the same file simultaneously from the
client to server, and because two instances of nfsd can run
concurrently, this situation can lead to lots of memory leak.
Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be
triggered.
NFS SERVER
nfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threads
nfsd4_open
nfsd4_process_open1
find_or_alloc_open_stateowner
// alloc oo1, stateid1
nfsd4_open
nfsd4_process_open1
find_or_alloc_open_stateowner
// find oo1, without NFS4_OO_CONFIRMED
release_openowner
unhash_openowner_locked
list_del_init(&oo->oo_perclient)
// cannot find this oo
// from client, LEAK!!!
alloc_stateowner // alloc oo2
nfsd4_process_open2
init_open_stateid
// associate oo1
// with stateid1, stateid1 LEAK!!!
nfs4_get_vfs_file
// alloc nfsd_file1 and nfsd_file_mark1
// all LEAK!!!
nfsd4_process_open2
...
write_threads
...
nfsd_destroy_serv
nfsd_shutdown_net
nfs4_state_shutdown_net
nfs4_state_destroy_net
destroy_client
__destroy_client
// won't find oo1!!!
nfsd_shutdown_generic
nfsd_file_cache_shutdown
kmem_cache_destroy
for nfsd_file_slab
and nfsd_file_mark_slab
// bark since nfsd_file1
// and nfsd_file_mark1
// still alive
=======================================================================
BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on
__kmem_cache_shutdown()
-----------------------------------------------------------------------
Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28
flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)
CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.1-2.fc37 04/01/2014
Call Trace:
<TASK>
dum
---truncated--- |
["https://git.kernel.org/stable/c/0ab0a3ad24e970e894abcac58f85c332d1726749","https://git.kernel.org/stable/c/2d505a801e57428057563762f67a5a62009b2600","https://git.kernel.org/stable/c/37dfc81266d3a32294524bfadd3396614f8633ee","https://git.kernel.org/stable/c/45abb68c941ebc9a35c6d3a7b08196712093c636","https://git.kernel.org/stable/c/6f73f920b7ad0084373e46121d7ac34117aed652","https://git.kernel.org/stable/c/98100e88dd8865999dc6379a3356cd799795fe7b","https://git.kernel.org/stable/c/a85364f0d30dee01c5d5b4afa55a9629a8f36d8e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56781
|
Medium |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
powerpc/prom_init: Fixup missing powermac #size-cells
On some powermacs `escc` nodes are missing `#size-cells` properties,
which is deprecated and now triggers a warning at boot since commit
045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells
handling").
For example:
Missing '#size-cells' in /pci@f2000000/mac-io@c/escc@13000
WARNING: CPU: 0 PID: 0 at drivers/of/base.c:133 of_bus_n_size_cells+0x98/0x108
Hardware name: PowerMac3,1 7400 0xc0209 PowerMac
...
Call Trace:
of_bus_n_size_cells+0x98/0x108 (unreliable)
of_bus_default_count_cells+0x40/0x60
__of_get_address+0xc8/0x21c
__of_address_to_resource+0x5c/0x228
pmz_init_port+0x5c/0x2ec
pmz_probe.isra.0+0x144/0x1e4
pmz_console_init+0x10/0x48
console_init+0xcc/0x138
start_kernel+0x5c4/0x694
As powermacs boot via prom_init it's possible to add the missing
properties to the device tree during boot, avoiding the warning. Note
that `escc-legacy` nodes are also missing `#size-cells` properties, but
they are skipped by the macio driver, so leave them alone.
Depends-on: 045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells handling") |
["https://git.kernel.org/stable/c/0b94d838018fb0a824e0cd3149034928c99fb1b7","https://git.kernel.org/stable/c/296a109fa77110ba5267fe0e90a26005eecc2726","https://git.kernel.org/stable/c/691284c2cd33ffaa0b35ce53b3286b90621e9dc9","https://git.kernel.org/stable/c/6d5f0453a2228607333bff0c85238a3cb495d194","https://git.kernel.org/stable/c/a79a7e3c03ae2a07f68b5f24d5ed549f9799ec89","https://git.kernel.org/stable/c/cf89c9434af122f28a3552e6f9cc5158c33ce50a","https://git.kernel.org/stable/c/ee68554d2c03e32077f7b984e5289fdb005036d2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56785
|
Medium |
fixed |
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
MIPS: Loongson64: DTS: Really fix PCIe port nodes for ls7a
Fix the dtc warnings:
arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider
arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider
arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite 'interrupt_provider'
And a runtime warning introduced in commit 045b14ca5c36 ("of: WARN on
deprecated #address-cells/#size-cells handling"):
WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0
Missing '#address-cells' in /bus@10000000/pci@1a000000/pci_bridge@9,0
The fix is similar to commit d89a415ff8d5 ("MIPS: Loongson64: DTS: Fix PCIe
port nodes for ls7a"), which has fixed the issue for ls2k (despite its
subject mentions ls7a). |
["https://git.kernel.org/stable/c/01575f2ff8ba578a3436f230668bd056dc2eb823","https://git.kernel.org/stable/c/4fbd66d8254cedfd1218393f39d83b6c07a01917","https://git.kernel.org/stable/c/5a2eaa3ad2b803c7ea442c6db7379466ee73c024","https://git.kernel.org/stable/c/8ef9ea1503d0a129cc6f5cf48fb63633efa5d766","https://git.kernel.org/stable/c/a7fd78075031871bc68fc56fdaa6e7a3934064b1","https://git.kernel.org/stable/c/c8ee41fc3522c6659e324d90bc2ccd3b6310d7fc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57802
|
Medium |
fixed |
- 5.4.289
- 5.10.233
- 5.15.176
- 6.1.124
- 6.6.70
- 6.12.9
|
In the Linux kernel, the following vulnerability has been resolved:
netrom: check buffer length before accessing it
Syzkaller reports an uninit value read from ax25cmp when sending raw message
through ieee802154 implementation.
=====================================================
BUG: KMSAN: uninit-value in ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119
ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119
nr_dev_get+0x20e/0x450 net/netrom/nr_route.c:601
nr_route_frame+0x1a2/0xfc0 net/netrom/nr_route.c:774
nr_xmit+0x5a/0x1c0 net/netrom/nr_dev.c:144
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
xmit_one net/core/dev.c:3548 [inline]
dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
raw_sendmsg+0x654/0xc10 net/ieee802154/socket.c:299
ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
__sys_sendmsg net/socket.c:2667 [inline]
__do_sys_sendmsg net/socket.c:2676 [inline]
__se_sys_sendmsg net/socket.c:2674 [inline]
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2674
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at:
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
slab_alloc_node mm/slub.c:3478 [inline]
kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
__alloc_skb+0x318/0x740 net/core/skbuff.c:651
alloc_skb include/linux/skbuff.h:1286 [inline]
alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334
sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2780
sock_alloc_send_skb include/net/sock.h:1884 [inline]
raw_sendmsg+0x36d/0xc10 net/ieee802154/socket.c:282
ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
__sys_sendmsg net/socket.c:2667 [inline]
__do_sys_sendmsg net/socket.c:2676 [inline]
__se_sys_sendmsg net/socket.c:2674 [inline]
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2674
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
CPU: 0 PID: 5037 Comm: syz-executor166 Not tainted 6.7.0-rc7-syzkaller-00003-gfbafc3e621c3 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
=====================================================
This issue occurs because the skb buffer is too small, and it's actual
allocation is aligned. This hides an actual issue, which is that nr_route_frame
does not validate the buffer size before using it.
Fix this issue by checking skb->len before accessing any fields in skb->data.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller. |
["https://git.kernel.org/stable/c/3ba7f80d98d4965349cfcd258dd78418496c1625","https://git.kernel.org/stable/c/64e9f54a14f2887be8634fb85cd2f13bec18a184","https://git.kernel.org/stable/c/769e36c2119a51070faf58819c58274f57a088db","https://git.kernel.org/stable/c/78a110332ae268d0b005247c3b9a7d703b875c49","https://git.kernel.org/stable/c/a4fd163aed2edd967a244499754dec991d8b4c7d","https://git.kernel.org/stable/c/cf6befa7c569787f53440274bbed1405fc07738d","https://git.kernel.org/stable/c/f647d72245aadce30618f4c8fd3803904418dbec"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57890
|
Medium |
fixed |
- 5.4.289
- 5.10.233
- 5.15.176
- 6.1.124
- 6.6.70
- 6.12.9
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/uverbs: Prevent integer overflow issue
In the expression "cmd.wqe_size * cmd.wr_count", both variables are u32
values that come from the user so the multiplication can lead to integer
wrapping. Then we pass the result to uverbs_request_next_ptr() which also
could potentially wrap. The "cmd.sge_count * sizeof(struct ib_uverbs_sge)"
multiplication can also overflow on 32bit systems although it's fine on
64bit systems.
This patch does two things. First, I've re-arranged the condition in
uverbs_request_next_ptr() so that the use controlled variable "len" is on
one side of the comparison by itself without any math. Then I've modified
all the callers to use size_mul() for the multiplications. |
["https://git.kernel.org/stable/c/346db03e9926ab7117ed9bf19665699c037c773c","https://git.kernel.org/stable/c/42a6eb4ed7a9a41ba0b83eb0c7e0225b5fca5608","https://git.kernel.org/stable/c/b3ef4ae713360501182695dd47d6b4f6e1a43eb8","https://git.kernel.org/stable/c/b92667f755749cf10d9ef1088865c555ae83ffb7","https://git.kernel.org/stable/c/c2f961c46ea0e5274c5c320d007c2dd949cf627a","https://git.kernel.org/stable/c/c57721b24bd897338a81a0ca5fff41600f0f1ad1","https://git.kernel.org/stable/c/d0257e089d1bbd35c69b6c97ff73e3690ab149a9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27011
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: fix memleak in map from abort path
The delete set command does not rely on the transaction object for
element removal, therefore, a combination of delete element + delete set
from the abort path could result in restoring twice the refcount of the
mapping.
Check for inactive element in the next generation for the delete element
command in the abort path, skip restoring state if next generation bit
has been already cleared. This is similar to the activate logic using
the set walk iterator.
[ 6170.286929] ------------[ cut here ]------------
[ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.287071] Modules linked in: [...]
[ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365
[ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 <0f> 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f
[ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202
[ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000
[ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750
[ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55
[ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10
[ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100
[ 6170.287940] FS: 0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000
[ 6170.287948] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0
[ 6170.287962] Call Trace:
[ 6170.287967] <TASK>
[ 6170.287973] ? __warn+0x9f/0x1a0
[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.288092] ? report_bug+0x1b1/0x1e0
[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.288092] ? report_bug+0x1b1/0x1e0
[ 6170.288104] ? handle_bug+0x3c/0x70
[ 6170.288112] ? exc_invalid_op+0x17/0x40
[ 6170.288120] ? asm_exc_invalid_op+0x1a/0x20
[ 6170.288132] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]
[ 6170.288243] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.288366] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]
[ 6170.288483] nf_tables_trans_destroy_work+0x588/0x590 [nf_tables] |
["https://git.kernel.org/stable/c/49d0e656d19dfb2d4d7c230e4a720d37b3decff6","https://git.kernel.org/stable/c/86a1471d7cde792941109b93b558b5dc078b9ee9","https://git.kernel.org/stable/c/a1bd2a38a1c6388fc8556816dc203c3e9dc52237","https://git.kernel.org/stable/c/49d0e656d19dfb2d4d7c230e4a720d37b3decff6","https://git.kernel.org/stable/c/86a1471d7cde792941109b93b558b5dc078b9ee9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-33655
|
Medium |
fixed |
|
When sending malicous data to kernel by ioctl cmd FBIOPUT_VSCREENINFO,kernel will write memory out of bounds. |
["http://www.openwall.com/lists/oss-security/2022/07/19/2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=086ff84617185393a0bbf25830c4f36412a7d3f4","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://www.debian.org/security/2022/dsa-5191","http://www.openwall.com/lists/oss-security/2022/07/19/2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=086ff84617185393a0bbf25830c4f36412a7d3f4","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://www.debian.org/security/2022/dsa-5191"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47723
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix out-of-bounds in dbNextAG() and diAlloc()
In dbNextAG() , there is no check for the case where bmp->db_numag is
greater or same than MAXAG due to a polluted image, which causes an
out-of-bounds. Therefore, a bounds check should be added in dbMount().
And in dbNextAG(), a check for the case where agpref is greater than
bmp->db_numag should be added, so an out-of-bounds exception should be
prevented.
Additionally, a check for the case where agno is greater or same than
MAXAG should be added in diAlloc() to prevent out-of-bounds. |
["https://git.kernel.org/stable/c/0338e66cba272351ca9d7d03f3628e390e70963b","https://git.kernel.org/stable/c/128d5cfdcf844cb690c9295a3a1c1114c21fc15a","https://git.kernel.org/stable/c/5ad6284c8d433f8a213111c5c44ead4d9705b622","https://git.kernel.org/stable/c/6ce8b6ab44a8b5918c0ee373d4ad19d19017931b","https://git.kernel.org/stable/c/96855f40e152989c9e7c20c4691ace5581098acc","https://git.kernel.org/stable/c/c1ba4b8ca799ff1d99d01f37d7ccb7d5ba5533d2","https://git.kernel.org/stable/c/d1017d2a0f3f16dc1db5120e7ddbe7c6680425b0","https://git.kernel.org/stable/c/e63866a475562810500ea7f784099bfe341e761a","https://git.kernel.org/stable/c/ead82533278502428883085a787d5a00f15e5eb9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49900
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
jfs: Fix uninit-value access of new_ea in ea_buffer
syzbot reports that lzo1x_1_do_compress is using uninit-value:
=====================================================
BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178
...
Uninit was stored to memory at:
ea_put fs/jfs/xattr.c:639 [inline]
...
Local variable ea_buf created at:
__jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662
__jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934
=====================================================
The reason is ea_buf->new_ea is not initialized properly.
Fix this by using memset to empty its content at the beginning
in ea_get(). |
["https://git.kernel.org/stable/c/2b59ffad47db1c46af25ccad157bb3b25147c35c","https://git.kernel.org/stable/c/6041536d18c5f51a84bc37cd568cbab61870031e","https://git.kernel.org/stable/c/7b24d41d47a6805c45378debf8bd115675d41da8","https://git.kernel.org/stable/c/7c244d5b48284a770d96ff703df2dfeadf804a73","https://git.kernel.org/stable/c/8ad8b531de79c348bcb8133e7f5e827b884226af","https://git.kernel.org/stable/c/8b1dcf25c26d42e4a68c4725ce52a0543c7878cc","https://git.kernel.org/stable/c/c076b3746224982eebdba5c9e4b1467e146c0d64","https://git.kernel.org/stable/c/d7444f91a9f93eaa48827087ed0f3381c194181d","https://git.kernel.org/stable/c/dac398ed272a378d2f42ac68ae408333a51baf52"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48967
|
High |
fixed |
- 4.9.336
- 4.14.302
- 4.19.269
- 5.4.227
- 5.10.159
- 5.15.83
- 6.0.13
|
In the Linux kernel, the following vulnerability has been resolved:
NFC: nci: Bounds check struct nfc_target arrays
While running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported:
memcpy: detected field-spanning write (size 129) of single field "target->sensf_res" at net/nfc/nci/ntf.c:260 (size 18)
This appears to be a legitimate lack of bounds checking in
nci_add_new_protocol(). Add the missing checks. |
["https://git.kernel.org/stable/c/27eb2d7a1b9987b6d0429b7716b1ff3b82c4ffc9","https://git.kernel.org/stable/c/6778434706940b8fad7ef35f410d2b9929f256d2","https://git.kernel.org/stable/c/6b37f0dc0638d13a006f2f24d2f6ca61e83bc714","https://git.kernel.org/stable/c/908b2da426fe9c3ce74cf541ba40e7a4251db191","https://git.kernel.org/stable/c/cff35329070b96b4484d23f9f48a5ca2c947e750","https://git.kernel.org/stable/c/dbdcfb9f6748218a149f62468d6297ce3f014e9c","https://git.kernel.org/stable/c/e329e71013c9b5a4535b099208493c7826ee4a64","https://git.kernel.org/stable/c/f41547546db9af99da2c34e3368664d7a79cefae"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-58007
|
High |
fixed |
- 6.1.129
- 6.6.78
- 6.12.14
- 6.13.3
|
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: socinfo: Avoid out of bounds read of serial number
On MSM8916 devices, the serial number exposed in sysfs is constant and does
not change across individual devices. It's always:
db410c:/sys/devices/soc0$ cat serial_number
2644893864
The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not
have support for the serial_num field in the socinfo struct. There is an
existing check to avoid exposing the serial number in that case, but it's
not correct: When checking the item_size returned by SMEM, we need to make
sure the *end* of the serial_num is within bounds, instead of comparing
with the *start* offset. The serial_number currently exposed on MSM8916
devices is just an out of bounds read of whatever comes after the socinfo
struct in SMEM.
Fix this by changing offsetof() to offsetofend(), so that the size of the
field is also taken into account. |
["https://git.kernel.org/stable/c/0a92feddae0634a0b87c04b19d343f6af97af700","https://git.kernel.org/stable/c/22cf4fae6660b6e1a583a41cbf84e3046ca9ccd0","https://git.kernel.org/stable/c/2495c6598731b6d7f565140f2bd63ef4bc36ce7d","https://git.kernel.org/stable/c/2d09d3c9afa2fc422ac3df7c9b8534f350ee19dd","https://git.kernel.org/stable/c/407c928305c1a37232a63811c400ef616f85ccbc","https://git.kernel.org/stable/c/47470acd719d45c4c8c418c07962f74cc995652b","https://git.kernel.org/stable/c/7445fa05317534bbd8b373c0eff8319187916030","https://git.kernel.org/stable/c/9c88b3a3fae4d60641c3a45be66269d00eff33cd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21782
|
High |
fixed |
- 6.1.129
- 6.6.79
- 6.12.16
- 6.13.4
|
In the Linux kernel, the following vulnerability has been resolved:
orangefs: fix a oob in orangefs_debug_write
I got a syzbot report: slab-out-of-bounds Read in
orangefs_debug_write... several people suggested fixes,
I tested Al Viro's suggestion and made this patch. |
["https://git.kernel.org/stable/c/09d472a18c0ee1d5b83612cb919e33a1610fea16","https://git.kernel.org/stable/c/18b7f841109f697840fe8633cf7ed7d32bd3f91b","https://git.kernel.org/stable/c/1c5244299241cf49d8ae7b5054e299cc8faa4e09","https://git.kernel.org/stable/c/1da2697307dad281dd690a19441b5ca4af92d786","https://git.kernel.org/stable/c/2b84a231910cef2e0a16d29294afabfb69112087","https://git.kernel.org/stable/c/8725882b0f691f8113b230aea9df0256030a63a6","https://git.kernel.org/stable/c/897f496b946fdcfab5983c983e4b513ab6682364","https://git.kernel.org/stable/c/f7c848431632598ff9bce57a659db6af60d75b39"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48650
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix memory leak in __qlt_24xx_handle_abts()
Commit 8f394da36a36 ("scsi: qla2xxx: Drop TARGET_SCF_LOOKUP_LUN_FROM_TAG")
made the __qlt_24xx_handle_abts() function return early if
tcm_qla2xxx_find_cmd_by_tag() didn't find a command, but it missed to clean
up the allocated memory for the management command. |
["https://git.kernel.org/stable/c/601be20fc6a1b762044d2398befffd6bf236cebf","https://git.kernel.org/stable/c/6a4236ed47f5b0a57eb6b8fb1c351b15b3d341d7","https://git.kernel.org/stable/c/89df49e561b4a8948521fc3f8a013012eaa08f82","https://git.kernel.org/stable/c/601be20fc6a1b762044d2398befffd6bf236cebf","https://git.kernel.org/stable/c/6a4236ed47f5b0a57eb6b8fb1c351b15b3d341d7","https://git.kernel.org/stable/c/89df49e561b4a8948521fc3f8a013012eaa08f82"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52481
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
arm64: errata: Add Cortex-A520 speculative unprivileged load workaround
Implement the workaround for ARM Cortex-A520 erratum 2966298. On an
affected Cortex-A520 core, a speculatively executed unprivileged load
might leak data from a privileged load via a cache side channel. The
issue only exists for loads within a translation regime with the same
translation (e.g. same ASID and VMID). Therefore, the issue only affects
the return to EL0.
The workaround is to execute a TLBI before returning to EL0 after all
loads of privileged data. A non-shareable TLBI to any address is
sufficient.
The workaround isn't necessary if page table isolation (KPTI) is
enabled, but for simplicity it will be. Page table isolation should
normally be disabled for Cortex-A520 as it supports the CSV3 feature
and the E0PD feature (used when KASLR is enabled). |
["https://git.kernel.org/stable/c/32b0a4ffcaea44a00a61e40c0d1bcc50362aee25","https://git.kernel.org/stable/c/471470bc7052d28ce125901877dd10e4c048e513","https://git.kernel.org/stable/c/6e3ae2927b432a3b7c8374f14dbc1bd9ebe4372c","https://git.kernel.org/stable/c/32b0a4ffcaea44a00a61e40c0d1bcc50362aee25","https://git.kernel.org/stable/c/471470bc7052d28ce125901877dd10e4c048e513","https://git.kernel.org/stable/c/6e3ae2927b432a3b7c8374f14dbc1bd9ebe4372c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27030
|
Medium |
fixed |
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: Use separate handlers for interrupts
For PF to AF interrupt vector and VF to AF vector same
interrupt handler is registered which is causing race condition.
When two interrupts are raised to two CPUs at same time
then two cores serve same event corrupting the data. |
["https://git.kernel.org/stable/c/29d2550d79a8cbd31e0fbaa5c0e2a2efdc444e44","https://git.kernel.org/stable/c/4fedae8f9eafa2ac8cdaca58e315f52a7e2a8701","https://git.kernel.org/stable/c/50e60de381c342008c0956fd762e1c26408f372c","https://git.kernel.org/stable/c/766c2627acb2d9d1722cce2e24837044d52d888a","https://git.kernel.org/stable/c/772f18ded0e240cc1fa2b7020cc640e3e5c32b70","https://git.kernel.org/stable/c/94cb17e5cf3a3c484063abc0ce4b8a2b2e8c1cb2","https://git.kernel.org/stable/c/ad6759e233db6fcc131055f8e23b4eafbe81053c","https://git.kernel.org/stable/c/dc29dd00705a62c77de75b6d752259b869aac49d","https://git.kernel.org/stable/c/29d2550d79a8cbd31e0fbaa5c0e2a2efdc444e44","https://git.kernel.org/stable/c/4fedae8f9eafa2ac8cdaca58e315f52a7e2a8701","https://git.kernel.org/stable/c/50e60de381c342008c0956fd762e1c26408f372c","https://git.kernel.org/stable/c/766c2627acb2d9d1722cce2e24837044d52d888a","https://git.kernel.org/stable/c/772f18ded0e240cc1fa2b7020cc640e3e5c32b70","https://git.kernel.org/stable/c/94cb17e5cf3a3c484063abc0ce4b8a2b2e8c1cb2","https://git.kernel.org/stable/c/ad6759e233db6fcc131055f8e23b4eafbe81053c","https://git.kernel.org/stable/c/dc29dd00705a62c77de75b6d752259b869aac49d","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50234
|
High |
fixed |
- 4.19.323
- 5.4.285
- 5.10.229
- 5.15.171
- 6.1.116
- 6.6.60
- 6.11.7
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlegacy: Clear stale interrupts before resuming device
iwl4965 fails upon resume from hibernation on my laptop. The reason
seems to be a stale interrupt which isn't being cleared out before
interrupts are enabled. We end up with a race beween the resume
trying to bring things back up, and the restart work (queued form
the interrupt handler) trying to bring things down. Eventually
the whole thing blows up.
Fix the problem by clearing out any stale interrupts before
interrupts get enabled during resume.
Here's a debug log of the indicent:
[ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000
[ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000
[ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio.
[ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload
[ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282
[ 12.052207] ieee80211 phy0: il4965_mac_start enter
[ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff
[ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready
[ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions
[ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S
[ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm
[ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm
[ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK
[ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations
[ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up
[ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done.
[ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down
[ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout
[ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort
[ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver
[ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared
[ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state
[ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master
[ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear.
[ 12.058869] ieee80211 phy0: Hardware restart was requested
[ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms.
[ 16.132303] ------------[ cut here ]------------
[ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue.
[ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211]
[ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev
[ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143
[ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010
[ 16.132463] Workqueue: async async_run_entry_fn
[ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211]
[ 16.132501] Code: da 02 00 0
---truncated--- |
["https://git.kernel.org/stable/c/07c90acb071b9954e1fecb1e4f4f13d12c544b34","https://git.kernel.org/stable/c/23f9cef17ee315777dbe88d5c11ff6166e4d0699","https://git.kernel.org/stable/c/271d282ecc15d7012e71ca82c89a6c0e13a063dd","https://git.kernel.org/stable/c/8ac22fe1e2b104c37e4fecd97735f64bd6349ebc","https://git.kernel.org/stable/c/8af8294d369a871cdbcdbb4d13b87d2d6e490a1f","https://git.kernel.org/stable/c/9d89941e51259c2b0b8e9c10c6f1f74200d7444f","https://git.kernel.org/stable/c/cedf0f1db8d5f3524339c2c6e35a8505b0f1ab73","https://git.kernel.org/stable/c/d0231f43df473e2f80372d0ca150eb3619932ef9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49903
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
jfs: Fix uaf in dbFreeBits
[syzbot reported]
==================================================================
BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline]
BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752
Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216
CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:93 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x169/0x550 mm/kasan/report.c:488
kasan_report+0x143/0x180 mm/kasan/report.c:601
__mutex_lock_common kernel/locking/mutex.c:587 [inline]
__mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752
dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390
dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline]
dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409
dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650
jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100
jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
Freed by task 5218:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
poison_slab_object+0xe0/0x150 mm/kasan/common.c:240
__kasan_slab_free+0x37/0x60 mm/kasan/common.c:256
kasan_slab_free include/linux/kasan.h:184 [inline]
slab_free_hook mm/slub.c:2252 [inline]
slab_free mm/slub.c:4473 [inline]
kfree+0x149/0x360 mm/slub.c:4594
dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278
jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247
jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454
reconfigure_super+0x445/0x880 fs/super.c:1083
vfs_cmd_reconfigure fs/fsopen.c:263 [inline]
vfs_fsconfig_locked fs/fsopen.c:292 [inline]
__do_sys_fsconfig fs/fsopen.c:473 [inline]
__se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
[Analysis]
There are two paths (dbUnmount and jfs_ioc_trim) that generate race
condition when accessing bmap, which leads to the occurrence of uaf.
Use the lock s_umount to synchronize them, in order to avoid uaf caused
by race condition. |
["https://git.kernel.org/stable/c/0c238da83f56bb895cab1e5851d034ac45b158d1","https://git.kernel.org/stable/c/3126ccde51f51b0648c8cdccaf916e8bd062e972","https://git.kernel.org/stable/c/4218b31ecc7af7e191768d32e32ed4386d8f9b76","https://git.kernel.org/stable/c/4ac58f7734937f3249da734ede946dfb3b1af5e4","https://git.kernel.org/stable/c/95accb7183badca387f7a8d19a2475cf3089f148","https://git.kernel.org/stable/c/a9603a6f75df2fd8125cd208c98cfaa0fe3f7505","https://git.kernel.org/stable/c/d6c1b3599b2feb5c7291f5ac3a36e5fa7cedb234","https://git.kernel.org/stable/c/e7ae14f7ee76c6ef5a48aebab1a278ad78f42619","https://git.kernel.org/stable/c/fd026b6b6758d5569705c02540b40f3bbf822b9a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49981
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
media: venus: fix use after free bug in venus_remove due to race condition
in venus_probe, core->work is bound with venus_sys_error_handler, which is
used to handle error. The code use core->sys_err_done to make sync work.
The core->work is started in venus_event_notify.
If we call venus_remove, there might be an unfished work. The possible
sequence is as follows:
CPU0 CPU1
|venus_sys_error_handler
venus_remove |
hfi_destroy |
venus_hfi_destroy |
kfree(hdev); |
|hfi_reinit
|venus_hfi_queues_reinit
|//use hdev
Fix it by canceling the work in venus_remove. |
["https://git.kernel.org/stable/c/10941d4f99a5a34999121b314afcd9c0a1c14f15","https://git.kernel.org/stable/c/2a541fcc0bd2b05a458e9613376df1289ec11621","https://git.kernel.org/stable/c/5098b9e6377577fe13d03e1d8914930f014a3314","https://git.kernel.org/stable/c/60b6968341a6dd5353554f3e72db554693a128a5","https://git.kernel.org/stable/c/63bbe26471ebdcc3c20bb4cc3950d666279ad658","https://git.kernel.org/stable/c/b0686aedc5f1343442d044bd64eeac7e7a391f4e","https://git.kernel.org/stable/c/bf6be32e2d39f6301ff1831e249d32a8744ab28a","https://git.kernel.org/stable/c/c5a85ed88e043474161bbfe54002c89c1cb50ee2","https://git.kernel.org/stable/c/d925e9f7fb5a2dbefd1a73fc01061f38c7becd4c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-41849
|
Medium |
|
N/A
|
drivers/video/fbdev/smscufx.c in the Linux kernel through 5.19.12 has a race condition and resultant use-after-free if a physically proximate attacker removes a USB device while calling open(), aka a race condition between ufx_ops_open and ufx_usb_disconnect. |
["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5610bcfe8693c02e2e4c8b31427f1bdbdecc839c","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://lore.kernel.org/all/20220925133243.GA383897%40ubuntu/T/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5610bcfe8693c02e2e4c8b31427f1bdbdecc839c","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://lore.kernel.org/all/20220925133243.GA383897%40ubuntu/T/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48646
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
sfc/siena: fix null pointer dereference in efx_hard_start_xmit
Like in previous patch for sfc, prevent potential (but unlikely) NULL
pointer dereference. |
["https://git.kernel.org/stable/c/589c6eded10c77a12b7b2cf235b6b19a2bdb91fa","https://git.kernel.org/stable/c/a4eadca702dff0768dd01be6789bbec2a18e5b0a","https://git.kernel.org/stable/c/589c6eded10c77a12b7b2cf235b6b19a2bdb91fa","https://git.kernel.org/stable/c/a4eadca702dff0768dd01be6789bbec2a18e5b0a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35982
|
Medium |
fixed |
- 4.19.313
- 5.4.275
- 5.10.216
- 5.15.156
- 6.1.87
- 6.6.28
- 6.8.7
|
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: Avoid infinite loop trying to resize local TT
If the MTU of one of an attached interface becomes too small to transmit
the local translation table then it must be resized to fit inside all
fragments (when enabled) or a single packet.
But if the MTU becomes too low to transmit even the header + the VLAN
specific part then the resizing of the local TT will never succeed. This
can for example happen when the usable space is 110 bytes and 11 VLANs are
on top of batman-adv. In this case, at least 116 byte would be needed.
There will just be an endless spam of
batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)
in the log but the function will never finish. Problem here is that the
timeout will be halved all the time and will then stagnate at 0 and
therefore never be able to reduce the table even more.
There are other scenarios possible with a similar result. The number of
BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too
high to fit inside a packet. Such a scenario can therefore happen also with
only a single VLAN + 7 non-purgable addresses - requiring at least 120
bytes.
While this should be handled proactively when:
* interface with too low MTU is added
* VLAN is added
* non-purgeable local mac is added
* MTU of an attached interface is reduced
* fragmentation setting gets disabled (which most likely requires dropping
attached interfaces)
not all of these scenarios can be prevented because batman-adv is only
consuming events without the the possibility to prevent these actions
(non-purgable MAC address added, MTU of an attached interface is reduced).
It is therefore necessary to also make sure that the code is able to handle
also the situations when there were already incompatible system
configuration are present. |
["https://git.kernel.org/stable/c/04720ea2e6c64459a90ca28570ea78335eccd924","https://git.kernel.org/stable/c/3fe79b2c83461edbbf86ed8a6f3924820ff89259","https://git.kernel.org/stable/c/4ca2a5fb54ea2cc43edea614207fcede562d91c2","https://git.kernel.org/stable/c/70a8be9dc2fb65d67f8c1e0c88c587e08e2e575d","https://git.kernel.org/stable/c/87b6af1a7683e021710c08fc0551fc078346032f","https://git.kernel.org/stable/c/b1f532a3b1e6d2e5559c7ace49322922637a28aa","https://git.kernel.org/stable/c/b3ddf6904073990492454b1dd1c10a24be8c74c6","https://git.kernel.org/stable/c/ca54e2671548616ad34885f90d4f26f7adb088f0","https://git.kernel.org/stable/c/04720ea2e6c64459a90ca28570ea78335eccd924","https://git.kernel.org/stable/c/3fe79b2c83461edbbf86ed8a6f3924820ff89259","https://git.kernel.org/stable/c/4ca2a5fb54ea2cc43edea614207fcede562d91c2","https://git.kernel.org/stable/c/70a8be9dc2fb65d67f8c1e0c88c587e08e2e575d","https://git.kernel.org/stable/c/87b6af1a7683e021710c08fc0551fc078346032f","https://git.kernel.org/stable/c/b1f532a3b1e6d2e5559c7ace49322922637a28aa","https://git.kernel.org/stable/c/b3ddf6904073990492454b1dd1c10a24be8c74c6","https://git.kernel.org/stable/c/ca54e2671548616ad34885f90d4f26f7adb088f0","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56774
|
Medium |
fixed |
- 5.15.174
- 6.1.120
- 6.6.64
- 6.12.4
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: add a sanity check for btrfs root in btrfs_search_slot()
Syzbot reports a null-ptr-deref in btrfs_search_slot().
The reproducer is using rescue=ibadroots, and the extent tree root is
corrupted thus the extent tree is NULL.
When scrub tries to search the extent tree to gather the needed extent
info, btrfs_search_slot() doesn't check if the target root is NULL or
not, resulting the null-ptr-deref.
Add sanity check for btrfs root before using it in btrfs_search_slot(). |
["https://git.kernel.org/stable/c/3ed51857a50f530ac7a1482e069dfbd1298558d4","https://git.kernel.org/stable/c/757171d1369b3b47f36932d40a05a0715496dcab","https://git.kernel.org/stable/c/93992c3d9629b02dccf6849238559d5c24f2dece","https://git.kernel.org/stable/c/c71d114ef68c95da5a82ec85a721ab31f5bd905b","https://git.kernel.org/stable/c/db66fb87c21e8ae724886e6a464dcbac562a64c6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56776
|
Medium |
fixed |
- 5.15.174
- 6.1.120
- 6.6.64
- 6.12.4
|
In the Linux kernel, the following vulnerability has been resolved:
drm/sti: avoid potential dereference of error pointers
The return value of drm_atomic_get_crtc_state() needs to be
checked. To avoid use of error pointer 'crtc_state' in case
of the failure. |
["https://git.kernel.org/stable/c/40725c5fabee804fecce41d4d5c5bae80c45e1c4","https://git.kernel.org/stable/c/831214f77037de02afc287eae93ce97f218d8c04","https://git.kernel.org/stable/c/8ab73ac97c0fa528f66eeccd9bb53eb6eb7d20dc","https://git.kernel.org/stable/c/e98ff67f5a68114804607de549c2350d27628fc7","https://git.kernel.org/stable/c/f67786293193cf01ebcc6fdbcbd1587b24f52679"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56777
|
Medium |
fixed |
- 5.15.174
- 6.1.120
- 6.6.64
- 6.12.4
|
In the Linux kernel, the following vulnerability has been resolved:
drm/sti: avoid potential dereference of error pointers in sti_gdp_atomic_check
The return value of drm_atomic_get_crtc_state() needs to be
checked. To avoid use of error pointer 'crtc_state' in case
of the failure. |
["https://git.kernel.org/stable/c/3cf2e7c448e246f7e700c7aa47450d1e27579559","https://git.kernel.org/stable/c/997b64c3f4c1827c5cfda8ae7f5d13f78d28b541","https://git.kernel.org/stable/c/b79612ed6bc1a184c45427105c851b5b2d4342ca","https://git.kernel.org/stable/c/e965e771b069421c233d674c3c8cd8c7f7245f42","https://git.kernel.org/stable/c/f5804567cf9605d6e5ec46c0bb786f7d50f18c13"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56778
|
Medium |
fixed |
- 5.15.174
- 6.1.120
- 6.6.64
- 6.12.4
|
In the Linux kernel, the following vulnerability has been resolved:
drm/sti: avoid potential dereference of error pointers in sti_hqvdp_atomic_check
The return value of drm_atomic_get_crtc_state() needs to be
checked. To avoid use of error pointer 'crtc_state' in case
of the failure. |
["https://git.kernel.org/stable/c/31c857e7496d34e5a32a6f75bc024d0b06fd646a","https://git.kernel.org/stable/c/6b0d0d6e9d3c26697230bf7dc9e6b52bdb24086f","https://git.kernel.org/stable/c/82a5312f874fb18f045d9658e9bd290e3b0621c0","https://git.kernel.org/stable/c/837eb99ad3340c7a9febf454f41c8e3edb68ac1e","https://git.kernel.org/stable/c/c1ab40a1fdfee732c7e6ff2fb8253760293e47e8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56787
|
Medium |
fixed |
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
soc: imx8m: Probe the SoC driver as platform driver
With driver_async_probe=* on kernel command line, the following trace is
produced because on i.MX8M Plus hardware because the soc-imx8m.c driver
calls of_clk_get_by_name() which returns -EPROBE_DEFER because the clock
driver is not yet probed. This was not detected during regular testing
without driver_async_probe.
Convert the SoC code to platform driver and instantiate a platform device
in its current device_initcall() to probe the platform driver. Rework
.soc_revision callback to always return valid error code and return SoC
revision via parameter. This way, if anything in the .soc_revision callback
return -EPROBE_DEFER, it gets propagated to .probe and the .probe will get
retried later.
"
------------[ cut here ]------------
WARNING: CPU: 1 PID: 1 at drivers/soc/imx/soc-imx8m.c:115 imx8mm_soc_revision+0xdc/0x180
CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-next-20240924-00002-g2062bb554dea #603
Hardware name: DH electronics i.MX8M Plus DHCOM Premium Developer Kit (3) (DT)
pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : imx8mm_soc_revision+0xdc/0x180
lr : imx8mm_soc_revision+0xd0/0x180
sp : ffff8000821fbcc0
x29: ffff8000821fbce0 x28: 0000000000000000 x27: ffff800081810120
x26: ffff8000818a9970 x25: 0000000000000006 x24: 0000000000824311
x23: ffff8000817f42c8 x22: ffff0000df8be210 x21: fffffffffffffdfb
x20: ffff800082780000 x19: 0000000000000001 x18: ffffffffffffffff
x17: ffff800081fff418 x16: ffff8000823e1000 x15: ffff0000c03b65e8
x14: ffff0000c00051b0 x13: ffff800082790000 x12: 0000000000000801
x11: ffff80008278ffff x10: ffff80008209d3a6 x9 : ffff80008062e95c
x8 : ffff8000821fb9a0 x7 : 0000000000000000 x6 : 00000000000080e3
x5 : ffff0000df8c03d8 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000000000 x1 : fffffffffffffdfb x0 : fffffffffffffdfb
Call trace:
imx8mm_soc_revision+0xdc/0x180
imx8_soc_init+0xb0/0x1e0
do_one_initcall+0x94/0x1a8
kernel_init_freeable+0x240/0x2a8
kernel_init+0x28/0x140
ret_from_fork+0x10/0x20
---[ end trace 0000000000000000 ]---
SoC: i.MX8MP revision 1.1
" |
["https://git.kernel.org/stable/c/2129f6faa5dfe8c6b87aad11720bf75edd77d3e4","https://git.kernel.org/stable/c/997a3c04d7fa3d1d385c14691350d096fada648c","https://git.kernel.org/stable/c/9cc832d37799dbea950c4c8a34721b02b8b5a8ff","https://git.kernel.org/stable/c/e497edb8f31ec2c2b6f4ce930e175aa2da8be334","https://git.kernel.org/stable/c/ea2ff66feb5f9b183f9e2f9d06c21340bd88de12"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57895
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: set ATTR_CTIME flags when setting mtime
David reported that the new warning from setattr_copy_mgtime is coming
like the following.
[ 113.215316] ------------[ cut here ]------------
[ 113.215974] WARNING: CPU: 1 PID: 31 at fs/attr.c:300 setattr_copy+0x1ee/0x200
[ 113.219192] CPU: 1 UID: 0 PID: 31 Comm: kworker/1:1 Not tainted 6.13.0-rc1+ #234
[ 113.220127] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
[ 113.221530] Workqueue: ksmbd-io handle_ksmbd_work [ksmbd]
[ 113.222220] RIP: 0010:setattr_copy+0x1ee/0x200
[ 113.222833] Code: 24 28 49 8b 44 24 30 48 89 53 58 89 43 6c 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 48 89 df e8 77 d6 ff ff e9 cd fe ff ff <0f> 0b e9 be fe ff ff 66 0
[ 113.225110] RSP: 0018:ffffaf218010fb68 EFLAGS: 00010202
[ 113.225765] RAX: 0000000000000120 RBX: ffffa446815f8568 RCX: 0000000000000003
[ 113.226667] RDX: ffffaf218010fd38 RSI: ffffa446815f8568 RDI: ffffffff94eb03a0
[ 113.227531] RBP: ffffaf218010fb90 R08: 0000001a251e217d R09: 00000000675259fa
[ 113.228426] R10: 0000000002ba8a6d R11: ffffa4468196c7a8 R12: ffffaf218010fd38
[ 113.229304] R13: 0000000000000120 R14: ffffffff94eb03a0 R15: 0000000000000000
[ 113.230210] FS: 0000000000000000(0000) GS:ffffa44739d00000(0000) knlGS:0000000000000000
[ 113.231215] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 113.232055] CR2: 00007efe0053d27e CR3: 000000000331a000 CR4: 00000000000006b0
[ 113.232926] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 113.233812] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 113.234797] Call Trace:
[ 113.235116] <TASK>
[ 113.235393] ? __warn+0x73/0xd0
[ 113.235802] ? setattr_copy+0x1ee/0x200
[ 113.236299] ? report_bug+0xf3/0x1e0
[ 113.236757] ? handle_bug+0x4d/0x90
[ 113.237202] ? exc_invalid_op+0x13/0x60
[ 113.237689] ? asm_exc_invalid_op+0x16/0x20
[ 113.238185] ? setattr_copy+0x1ee/0x200
[ 113.238692] btrfs_setattr+0x80/0x820 [btrfs]
[ 113.239285] ? get_stack_info_noinstr+0x12/0xf0
[ 113.239857] ? __module_address+0x22/0xa0
[ 113.240368] ? handle_ksmbd_work+0x6e/0x460 [ksmbd]
[ 113.240993] ? __module_text_address+0x9/0x50
[ 113.241545] ? __module_address+0x22/0xa0
[ 113.242033] ? unwind_next_frame+0x10e/0x920
[ 113.242600] ? __pfx_stack_trace_consume_entry+0x10/0x10
[ 113.243268] notify_change+0x2c2/0x4e0
[ 113.243746] ? stack_depot_save_flags+0x27/0x730
[ 113.244339] ? set_file_basic_info+0x130/0x2b0 [ksmbd]
[ 113.244993] set_file_basic_info+0x130/0x2b0 [ksmbd]
[ 113.245613] ? process_scheduled_works+0xbe/0x310
[ 113.246181] ? worker_thread+0x100/0x240
[ 113.246696] ? kthread+0xc8/0x100
[ 113.247126] ? ret_from_fork+0x2b/0x40
[ 113.247606] ? ret_from_fork_asm+0x1a/0x30
[ 113.248132] smb2_set_info+0x63f/0xa70 [ksmbd]
ksmbd is trying to set the atime and mtime via notify_change without also
setting the ctime. so This patch add ATTR_CTIME flags when setting mtime
to avoid a warning. |
["https://git.kernel.org/stable/c/1d7ee876b8b96efc14e177a7fe8d45ac25d68849","https://git.kernel.org/stable/c/21e46a79bbe6c4e1aa73b3ed998130f2ff07b128","https://git.kernel.org/stable/c/52cefcff6a4a814f4f8e357422fcfb71fd2ebf75"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50138
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Use raw_spinlock_t in ringbuf
The function __bpf_ringbuf_reserve is invoked from a tracepoint, which
disables preemption. Using spinlock_t in this context can lead to a
"sleep in atomic" warning in the RT variant. This issue is illustrated
in the example below:
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556208, name: test_progs
preempt_count: 1, expected: 0
RCU nest depth: 1, expected: 1
INFO: lockdep is turned off.
Preemption disabled at:
[<ffffd33a5c88ea44>] migrate_enable+0xc0/0x39c
CPU: 7 PID: 556208 Comm: test_progs Tainted: G
Hardware name: Qualcomm SA8775P Ride (DT)
Call trace:
dump_backtrace+0xac/0x130
show_stack+0x1c/0x30
dump_stack_lvl+0xac/0xe8
dump_stack+0x18/0x30
__might_resched+0x3bc/0x4fc
rt_spin_lock+0x8c/0x1a4
__bpf_ringbuf_reserve+0xc4/0x254
bpf_ringbuf_reserve_dynptr+0x5c/0xdc
bpf_prog_ac3d15160d62622a_test_read_write+0x104/0x238
trace_call_bpf+0x238/0x774
perf_call_bpf_enter.isra.0+0x104/0x194
perf_syscall_enter+0x2f8/0x510
trace_sys_enter+0x39c/0x564
syscall_trace_enter+0x220/0x3c0
do_el0_svc+0x138/0x1dc
el0_svc+0x54/0x130
el0t_64_sync_handler+0x134/0x150
el0t_64_sync+0x17c/0x180
Switch the spinlock to raw_spinlock_t to avoid this error. |
["https://git.kernel.org/stable/c/5eb34999d118e69a20dc0c6556f315fcb0a1f8d3","https://git.kernel.org/stable/c/8b62645b09f870d70c7910e7550289d444239a46","https://git.kernel.org/stable/c/ca30e682e5d6de44d12c4610767811c9a21d59ba","https://git.kernel.org/stable/c/f9543375d9b150b2bcf16bb182e6b62309db0888"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36023
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
Julia Lawall reported this null pointer dereference, this should fix it. |
["https://git.kernel.org/stable/c/214a6c4a28c11d67044e6cf3a0ab415050d9f03a","https://git.kernel.org/stable/c/2e2177f94c0e0bc41323d7b6975a5f4820ed347e","https://git.kernel.org/stable/c/9bf93dcfc453fae192fe5d7874b89699e8f800ac","https://git.kernel.org/stable/c/b972e8ac3f44f693127a2806031962d100dfc4d1","https://git.kernel.org/stable/c/214a6c4a28c11d67044e6cf3a0ab415050d9f03a","https://git.kernel.org/stable/c/2e2177f94c0e0bc41323d7b6975a5f4820ed347e","https://git.kernel.org/stable/c/9bf93dcfc453fae192fe5d7874b89699e8f800ac","https://git.kernel.org/stable/c/b972e8ac3f44f693127a2806031962d100dfc4d1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41066
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: Add tx check to prevent skb leak
Below is a summary of how the driver stores a reference to an skb during
transmit:
tx_buff[free_map[consumer_index]]->skb = new_skb;
free_map[consumer_index] = IBMVNIC_INVALID_MAP;
consumer_index ++;
Where variable data looks like this:
free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3]
consumer_index^
tx_buff == [skb=null, skb=<ptr>, skb=<ptr>, skb=null, skb=null]
The driver has checks to ensure that free_map[consumer_index] pointed to
a valid index but there was no check to ensure that this index pointed
to an unused/null skb address. So, if, by some chance, our free_map and
tx_buff lists become out of sync then we were previously risking an
skb memory leak. This could then cause tcp congestion control to stop
sending packets, eventually leading to ETIMEDOUT.
Therefore, add a conditional to ensure that the skb address is null. If
not then warn the user (because this is still a bug that should be
patched) and free the old pointer to prevent memleak/tcp problems. |
["https://git.kernel.org/stable/c/0983d288caf984de0202c66641577b739caad561","https://git.kernel.org/stable/c/16ad1557cae582e79bb82dddd612d9bdfaa11d4c","https://git.kernel.org/stable/c/267c61c4afed0ff9a2e83462abad3f41d8ca1f06","https://git.kernel.org/stable/c/e7b75def33eae61ddaad6cb616c517dc3882eb2a","https://git.kernel.org/stable/c/0983d288caf984de0202c66641577b739caad561","https://git.kernel.org/stable/c/16ad1557cae582e79bb82dddd612d9bdfaa11d4c","https://git.kernel.org/stable/c/267c61c4afed0ff9a2e83462abad3f41d8ca1f06","https://git.kernel.org/stable/c/e7b75def33eae61ddaad6cb616c517dc3882eb2a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41076
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
NFSv4: Fix memory leak in nfs4_set_security_label
We leak nfs_fattr and nfs4_label every time we set a security xattr. |
["https://git.kernel.org/stable/c/899604a7c958771840941caff9ee3dd8193d984c","https://git.kernel.org/stable/c/aad11473f8f4be3df86461081ce35ec5b145ba68","https://git.kernel.org/stable/c/b98090699319e64f5de1e8db5bb75870f1eb1c6e","https://git.kernel.org/stable/c/d130220ccc94d74d70da984a199477937e7bf03c","https://git.kernel.org/stable/c/899604a7c958771840941caff9ee3dd8193d984c","https://git.kernel.org/stable/c/aad11473f8f4be3df86461081ce35ec5b145ba68","https://git.kernel.org/stable/c/b98090699319e64f5de1e8db5bb75870f1eb1c6e","https://git.kernel.org/stable/c/d130220ccc94d74d70da984a199477937e7bf03c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42067
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()
set_memory_rox() can fail, leaving memory unprotected.
Check return and bail out when bpf_jit_binary_lock_ro() returns
an error. |
["https://git.kernel.org/stable/c/044da7ae7afd4ef60806d73654a2e6a79aa4ed7a","https://git.kernel.org/stable/c/e60adf513275c3a38e5cb67f7fd12387e43a3ff5","https://git.kernel.org/stable/c/044da7ae7afd4ef60806d73654a2e6a79aa4ed7a","https://git.kernel.org/stable/c/08f6c05feb1db21653e98ca84ea04ca032d014c7","https://git.kernel.org/stable/c/9fef36cad60d4226f9d06953cd56d1d2f9119730","https://git.kernel.org/stable/c/e60adf513275c3a38e5cb67f7fd12387e43a3ff5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46726
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Ensure index calculation will not overflow
[WHY & HOW]
Make sure vmid0p72_idx, vnom0p8_idx and vmax0p9_idx calculation will
never overflow and exceess array size.
This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity. |
["https://git.kernel.org/stable/c/3dc6bb57dab36b38b7374af0ac916174c146b6ed","https://git.kernel.org/stable/c/733ae185502d30bbe79575167b6178cfb6c5d6bd","https://git.kernel.org/stable/c/8e2734bf444767fed787305ccdcb36a2be5301a2","https://git.kernel.org/stable/c/d705b5869f6b1b46ad5ceb1bd2a08c04f7e5003b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50188
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
net: phy: dp83869: fix memory corruption when enabling fiber
When configuring the fiber port, the DP83869 PHY driver incorrectly
calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit
number (10). This corrupts some other memory location -- in case of
arm64 the priv pointer in the same structure.
Since the advertising flags are updated from supported at the end of the
function the incorrect line isn't needed at all and can be removed. |
["https://git.kernel.org/stable/c/21b5af7f0c99b3bf1fd02016e6708b613acbcaf4","https://git.kernel.org/stable/c/9ca634676ff66e1d616259e136f96f96b2a1759a","https://git.kernel.org/stable/c/a842e443ca8184f2dc82ab307b43a8b38defd6a5","https://git.kernel.org/stable/c/ad0d76b8ee5db063791cc2e7a30ffc9852ac37c4","https://git.kernel.org/stable/c/c1944b4253649fc6f2fb53e7d6302eb414d2182c","https://git.kernel.org/stable/c/e3f2de32dae35bc7d173377dc97b5bc9fcd9fc84"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52913
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/i915: Fix potential context UAFs
gem_context_register() makes the context visible to userspace, and which
point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
So we need to ensure that nothing uses the ctx ptr after this. And we
need to ensure that adding the ctx to the xarray is the *last* thing
that gem_context_register() does with the ctx pointer.
[tursulin: Stable and fixes tags add/tidy.]
(cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c) |
["https://git.kernel.org/stable/c/ae278887193110dfeb857ea63e243a3851fbb0bc","https://git.kernel.org/stable/c/afce71ff6daa9c0f852df0727fe32c6fb107f0fa","https://git.kernel.org/stable/c/b696c627b3f56e173f7f70b8487d66da8ff22506"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50243
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix general protection fault in run_is_mapped_full
Fixed deleating of a non-resident attribute in ntfs_create_inode()
rollback. |
["https://git.kernel.org/stable/c/509c1c6b499a4d9026b58c6e1c3a10ed8db1839f","https://git.kernel.org/stable/c/68b39c0765de7c97b34889c1f5e81c2a223fdacc","https://git.kernel.org/stable/c/8e87c9aa8cf92cfceaff0aab244318bbb8b35137","https://git.kernel.org/stable/c/a33fb016e49e37aafab18dc3c8314d6399cb4727"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48839
|
Medium |
fixed |
- 4.9.308
- 4.14.273
- 4.19.236
- 5.4.187
- 5.10.108
- 5.15.31
- 5.16.17
|
In the Linux kernel, the following vulnerability has been resolved:
net/packet: fix slab-out-of-bounds access in packet_recvmsg()
syzbot found that when an AF_PACKET socket is using PACKET_COPY_THRESH
and mmap operations, tpacket_rcv() is queueing skbs with
garbage in skb->cb[], triggering a too big copy [1]
Presumably, users of af_packet using mmap() already gets correct
metadata from the mapped buffer, we can simply make sure
to clear 12 bytes that might be copied to user space later.
BUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:225 [inline]
BUG: KASAN: stack-out-of-bounds in packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489
Write of size 165 at addr ffffc9000385fb78 by task syz-executor233/3631
CPU: 0 PID: 3631 Comm: syz-executor233 Not tainted 5.17.0-rc7-syzkaller-02396-g0b3660695e80 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description.constprop.0.cold+0xf/0x336 mm/kasan/report.c:255
__kasan_report mm/kasan/report.c:442 [inline]
kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
check_region_inline mm/kasan/generic.c:183 [inline]
kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189
memcpy+0x39/0x60 mm/kasan/shadow.c:66
memcpy include/linux/fortify-string.h:225 [inline]
packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489
sock_recvmsg_nosec net/socket.c:948 [inline]
sock_recvmsg net/socket.c:966 [inline]
sock_recvmsg net/socket.c:962 [inline]
____sys_recvmsg+0x2c4/0x600 net/socket.c:2632
___sys_recvmsg+0x127/0x200 net/socket.c:2674
__sys_recvmsg+0xe2/0x1a0 net/socket.c:2704
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7fdfd5954c29
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 41 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffcf8e71e48 EFLAGS: 00000246 ORIG_RAX: 000000000000002f
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdfd5954c29
RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000005
RBP: 0000000000000000 R08: 000000000000000d R09: 000000000000000d
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffcf8e71e60
R13: 00000000000f4240 R14: 000000000000c1ff R15: 00007ffcf8e71e54
</TASK>
addr ffffc9000385fb78 is located in stack of task syz-executor233/3631 at offset 32 in frame:
____sys_recvmsg+0x0/0x600 include/linux/uio.h:246
this frame has 1 object:
[32, 160) 'addr'
Memory state around the buggy address:
ffffc9000385fa80: 00 04 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00
ffffc9000385fb00: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00
>ffffc9000385fb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3
^
ffffc9000385fc00: f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 f1
ffffc9000385fc80: f1 f1 f1 00 f2 f2 f2 00 f2 f2 f2 00 00 00 00 00
================================================================== |
["https://git.kernel.org/stable/c/268dcf1f7b3193bc446ec3d14e08a240e9561e4d","https://git.kernel.org/stable/c/70b7b3c055fd4a464da8da55ff4c1f84269f9b02","https://git.kernel.org/stable/c/a055f5f2841f7522b44a2b1eccb1951b4b03d51a","https://git.kernel.org/stable/c/a33dd1e6693f80d805155b3f69c18c2f642915da","https://git.kernel.org/stable/c/b1e27cda1e3c12b705875bb7e247a97168580e33","https://git.kernel.org/stable/c/b9d5772d60f8e7ef34e290f72fc20e3a4883e7d0","https://git.kernel.org/stable/c/c700525fcc06b05adfea78039de02628af79e07a","https://git.kernel.org/stable/c/ef591b35176029fdefea38e8388ffa371e18f4b2","https://git.kernel.org/stable/c/268dcf1f7b3193bc446ec3d14e08a240e9561e4d","https://git.kernel.org/stable/c/70b7b3c055fd4a464da8da55ff4c1f84269f9b02","https://git.kernel.org/stable/c/a055f5f2841f7522b44a2b1eccb1951b4b03d51a","https://git.kernel.org/stable/c/a33dd1e6693f80d805155b3f69c18c2f642915da","https://git.kernel.org/stable/c/b1e27cda1e3c12b705875bb7e247a97168580e33","https://git.kernel.org/stable/c/b9d5772d60f8e7ef34e290f72fc20e3a4883e7d0","https://git.kernel.org/stable/c/c700525fcc06b05adfea78039de02628af79e07a","https://git.kernel.org/stable/c/ef591b35176029fdefea38e8388ffa371e18f4b2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48845
|
Medium |
fixed |
- 4.9.308
- 4.14.273
- 4.19.236
- 5.4.186
- 5.10.107
- 5.15.30
- 5.16.16
|
In the Linux kernel, the following vulnerability has been resolved:
MIPS: smp: fill in sibling and core maps earlier
After enabling CONFIG_SCHED_CORE (landed during 5.14 cycle),
2-core 2-thread-per-core interAptiv (CPS-driven) started emitting
the following:
[ 0.025698] CPU1 revision is: 0001a120 (MIPS interAptiv (multi))
[ 0.048183] ------------[ cut here ]------------
[ 0.048187] WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240
[ 0.048220] Modules linked in:
[ 0.048233] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc3+ #35 b7b319f24073fd9a3c2aa7ad15fb7993eec0b26f
[ 0.048247] Stack : 817f0000 00000004 327804c8 810eb050 00000000 00000004 00000000 c314fdd1
[ 0.048278] 830cbd64 819c0000 81800000 817f0000 83070bf4 00000001 830cbd08 00000000
[ 0.048307] 00000000 00000000 815fcbc4 00000000 00000000 00000000 00000000 00000000
[ 0.048334] 00000000 00000000 00000000 00000000 817f0000 00000000 00000000 817f6f34
[ 0.048361] 817f0000 818a3c00 817f0000 00000004 00000000 00000000 4dc33260 0018c933
[ 0.048389] ...
[ 0.048396] Call Trace:
[ 0.048399] [<8105a7bc>] show_stack+0x3c/0x140
[ 0.048424] [<8131c2a0>] dump_stack_lvl+0x60/0x80
[ 0.048440] [<8108b5c0>] __warn+0xc0/0xf4
[ 0.048454] [<8108b658>] warn_slowpath_fmt+0x64/0x10c
[ 0.048467] [<810bd418>] sched_core_cpu_starting+0x198/0x240
[ 0.048483] [<810c6514>] sched_cpu_starting+0x14/0x80
[ 0.048497] [<8108c0f8>] cpuhp_invoke_callback_range+0x78/0x140
[ 0.048510] [<8108d914>] notify_cpu_starting+0x94/0x140
[ 0.048523] [<8106593c>] start_secondary+0xbc/0x280
[ 0.048539]
[ 0.048543] ---[ end trace 0000000000000000 ]---
[ 0.048636] Synchronize counters for CPU 1: done.
...for each but CPU 0/boot.
Basic debug printks right before the mentioned line say:
[ 0.048170] CPU: 1, smt_mask:
So smt_mask, which is sibling mask obviously, is empty when entering
the function.
This is critical, as sched_core_cpu_starting() calculates
core-scheduling parameters only once per CPU start, and it's crucial
to have all the parameters filled in at that moment (at least it
uses cpu_smt_mask() which in fact is `&cpu_sibling_map[cpu]` on
MIPS).
A bit of debugging led me to that set_cpu_sibling_map() performing
the actual map calculation, was being invocated after
notify_cpu_start(), and exactly the latter function starts CPU HP
callback round (sched_core_cpu_starting() is basically a CPU HP
callback).
While the flow is same on ARM64 (maps after the notifier, although
before calling set_cpu_online()), x86 started calculating sibling
maps earlier than starting the CPU HP callbacks in Linux 4.14 (see
[0] for the reference). Neither me nor my brief tests couldn't find
any potential caveats in calculating the maps right after performing
delay calibration, but the WARN splat is now gone.
The very same debug prints now yield exactly what I expected from
them:
[ 0.048433] CPU: 1, smt_mask: 0-1
[0] https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=76ce7cfe35ef |
["https://git.kernel.org/stable/c/32813321f18d5432cec1b1a6ecc964f9ea26d565","https://git.kernel.org/stable/c/56eaacb8137ba2071ce48d4e3d91979270e139a7","https://git.kernel.org/stable/c/7315f8538db009605ffba00370678142ef00ac98","https://git.kernel.org/stable/c/94647aec80d03d6914aa664b7b8e103cd9d63239","https://git.kernel.org/stable/c/be538b764a46be1d0700fd3b6e82fb76bd17f13a","https://git.kernel.org/stable/c/c2420bc3333111184cdcb112282d13afe1338dd7","https://git.kernel.org/stable/c/e8ad9ecc406974deb5e7c070f51cc1d09d21dc4b","https://git.kernel.org/stable/c/f2703def339c793674010cc9f01bfe4980231808","https://git.kernel.org/stable/c/32813321f18d5432cec1b1a6ecc964f9ea26d565","https://git.kernel.org/stable/c/56eaacb8137ba2071ce48d4e3d91979270e139a7","https://git.kernel.org/stable/c/7315f8538db009605ffba00370678142ef00ac98","https://git.kernel.org/stable/c/94647aec80d03d6914aa664b7b8e103cd9d63239","https://git.kernel.org/stable/c/be538b764a46be1d0700fd3b6e82fb76bd17f13a","https://git.kernel.org/stable/c/c2420bc3333111184cdcb112282d13afe1338dd7","https://git.kernel.org/stable/c/e8ad9ecc406974deb5e7c070f51cc1d09d21dc4b","https://git.kernel.org/stable/c/f2703def339c793674010cc9f01bfe4980231808"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52753
|
Medium |
fixed |
- 4.19.300
- 5.4.262
- 5.10.202
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Avoid NULL dereference of timing generator
[Why & How]
Check whether assigned timing generator is NULL or not before
accessing its funcs to prevent NULL dereference. |
["https://git.kernel.org/stable/c/09909f515032fa80b921fd3118efe66b185d10fd","https://git.kernel.org/stable/c/4e497f1acd99075b13605b2e7fa0cba721a2cfd9","https://git.kernel.org/stable/c/6d8653b1a7a8dc938b566ae8c4f373b36e792c68","https://git.kernel.org/stable/c/79b6a90f4f2433312154cd68452b0ba501fa74db","https://git.kernel.org/stable/c/8a06894666e0b462c9316b26ab615cefdd0d676c","https://git.kernel.org/stable/c/b1904ed480cee3f9f4036ea0e36d139cb5fee2d6","https://git.kernel.org/stable/c/df8bc953eed72371e43ca407bd063507f760cf89","https://git.kernel.org/stable/c/eac3e4760aa12159f7f5475d55a67b7933abc195","https://git.kernel.org/stable/c/09909f515032fa80b921fd3118efe66b185d10fd","https://git.kernel.org/stable/c/4e497f1acd99075b13605b2e7fa0cba721a2cfd9","https://git.kernel.org/stable/c/6d8653b1a7a8dc938b566ae8c4f373b36e792c68","https://git.kernel.org/stable/c/79b6a90f4f2433312154cd68452b0ba501fa74db","https://git.kernel.org/stable/c/8a06894666e0b462c9316b26ab615cefdd0d676c","https://git.kernel.org/stable/c/b1904ed480cee3f9f4036ea0e36d139cb5fee2d6","https://git.kernel.org/stable/c/df8bc953eed72371e43ca407bd063507f760cf89","https://git.kernel.org/stable/c/eac3e4760aa12159f7f5475d55a67b7933abc195"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52821
|
Medium |
fixed |
- 5.10.202
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/panel: fix a possible null pointer dereference
In versatile_panel_get_modes(), the return value of drm_mode_duplicate()
is assigned to mode, which will lead to a NULL pointer dereference
on failure of drm_mode_duplicate(). Add a check to avoid npd. |
["https://git.kernel.org/stable/c/2381f6b628b3214f07375e0adf5ce17093c31190","https://git.kernel.org/stable/c/4fa930ba046d20fc1899770396ee11e905fa96e4","https://git.kernel.org/stable/c/79813cd59398015867d51e6d7dcc14d287d4c402","https://git.kernel.org/stable/c/8a9dd36fcb4f3906982b82593393578db4479992","https://git.kernel.org/stable/c/924e5814d1f84e6fa5cb19c6eceb69f066225229","https://git.kernel.org/stable/c/c7dc0aca5962fb37dbea9769dd26ec37813faae1","https://git.kernel.org/stable/c/2381f6b628b3214f07375e0adf5ce17093c31190","https://git.kernel.org/stable/c/4fa930ba046d20fc1899770396ee11e905fa96e4","https://git.kernel.org/stable/c/79813cd59398015867d51e6d7dcc14d287d4c402","https://git.kernel.org/stable/c/8a9dd36fcb4f3906982b82593393578db4479992","https://git.kernel.org/stable/c/924e5814d1f84e6fa5cb19c6eceb69f066225229","https://git.kernel.org/stable/c/c7dc0aca5962fb37dbea9769dd26ec37813faae1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26978
|
Medium |
fixed |
- 5.4.274
- 5.10.215
- 6.1.84
- 6.6.24
- 6.7.12
|
In the Linux kernel, the following vulnerability has been resolved:
serial: max310x: fix NULL pointer dereference in I2C instantiation
When trying to instantiate a max14830 device from userspace:
echo max14830 0x60 > /sys/bus/i2c/devices/i2c-2/new_device
we get the following error:
Unable to handle kernel NULL pointer dereference at virtual address...
...
Call trace:
max310x_i2c_probe+0x48/0x170 [max310x]
i2c_device_probe+0x150/0x2a0
...
Add check for validity of devtype to prevent the error, and abort probe
with a meaningful error message. |
["https://git.kernel.org/stable/c/0d27056c24efd3d63a03f3edfbcfc4827086b110","https://git.kernel.org/stable/c/12609c76b755dbeb1645c0aacc0f0f4743b2eff3","https://git.kernel.org/stable/c/2160ad6861c4a21d3fa553d7b2aaec6634a37f8a","https://git.kernel.org/stable/c/5cd8af02b466e1beeae13e2de3dc58fcc7925e5a","https://git.kernel.org/stable/c/7d271b798add90c6196539167c019d0817285cf0","https://git.kernel.org/stable/c/aeca49661fd02fd56fb026768b580ce301b45733","https://git.kernel.org/stable/c/c45e53c27b78afd6c81fc25608003576f27b5735","https://git.kernel.org/stable/c/0d27056c24efd3d63a03f3edfbcfc4827086b110","https://git.kernel.org/stable/c/12609c76b755dbeb1645c0aacc0f0f4743b2eff3","https://git.kernel.org/stable/c/2160ad6861c4a21d3fa553d7b2aaec6634a37f8a","https://git.kernel.org/stable/c/5cd8af02b466e1beeae13e2de3dc58fcc7925e5a","https://git.kernel.org/stable/c/7d271b798add90c6196539167c019d0817285cf0","https://git.kernel.org/stable/c/aeca49661fd02fd56fb026768b580ce301b45733","https://git.kernel.org/stable/c/c45e53c27b78afd6c81fc25608003576f27b5735","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41060
|
Medium |
fixed |
- 5.15.164
- 6.1.101
- 6.6.42
- 6.9.11
|
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: check bo_va->bo is non-NULL before using it
The call to radeon_vm_clear_freed might clear bo_va->bo, so
we have to check it before dereferencing it. |
["https://git.kernel.org/stable/c/6fb15dcbcf4f212930350eaee174bb60ed40a536","https://git.kernel.org/stable/c/8a500b3a5f0a58c6f99039091fbd715f64f2f8af","https://git.kernel.org/stable/c/a2b201f83971df03c8e81a480b2f2846ae8ce1a3","https://git.kernel.org/stable/c/a9100f17428cb733c4f6fbb132d98bed76318342","https://git.kernel.org/stable/c/e8d3c53c6f1cccea9c03113f06dd39521c228831","https://git.kernel.org/stable/c/f13c96e0e325a057c03f8a47734adb360e112efe","https://git.kernel.org/stable/c/6fb15dcbcf4f212930350eaee174bb60ed40a536","https://git.kernel.org/stable/c/8a500b3a5f0a58c6f99039091fbd715f64f2f8af","https://git.kernel.org/stable/c/a2b201f83971df03c8e81a480b2f2846ae8ce1a3","https://git.kernel.org/stable/c/a9100f17428cb733c4f6fbb132d98bed76318342","https://git.kernel.org/stable/c/f13c96e0e325a057c03f8a47734adb360e112efe"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41089
|
Medium |
fixed |
- 4.19.317
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.97
- 6.6.37
- 6.9.8
|
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes
In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is
assigned to mode, which will lead to a possible NULL pointer dereference
on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().
Add a check to avoid null pointer dereference. |
["https://git.kernel.org/stable/c/1c9f2e60150b4f13789064370e37f39e6e060f50","https://git.kernel.org/stable/c/30cbf6ffafbbdd8a6e4e5f0a2e9a9827ee83f3ad","https://git.kernel.org/stable/c/56fc4d3b0bdef691831cd95715a7ca3ebea98b2d","https://git.kernel.org/stable/c/5eecb49a6c268dc229005bf6e8167d4001dc09a0","https://git.kernel.org/stable/c/6d411c8ccc0137a612e0044489030a194ff5c843","https://git.kernel.org/stable/c/6e49a157d541e7e97b815a56f4bdfcbc89844a59","https://git.kernel.org/stable/c/7ece609b0ce7a7ea8acdf512a77d1fee26621637","https://git.kernel.org/stable/c/ffabad4aa91e33ced3c6ae793fb37771b3e9cb51","https://git.kernel.org/stable/c/1c9f2e60150b4f13789064370e37f39e6e060f50","https://git.kernel.org/stable/c/30cbf6ffafbbdd8a6e4e5f0a2e9a9827ee83f3ad","https://git.kernel.org/stable/c/56fc4d3b0bdef691831cd95715a7ca3ebea98b2d","https://git.kernel.org/stable/c/5eecb49a6c268dc229005bf6e8167d4001dc09a0","https://git.kernel.org/stable/c/6d411c8ccc0137a612e0044489030a194ff5c843","https://git.kernel.org/stable/c/6e49a157d541e7e97b815a56f4bdfcbc89844a59","https://git.kernel.org/stable/c/7ece609b0ce7a7ea8acdf512a77d1fee26621637","https://git.kernel.org/stable/c/ffabad4aa91e33ced3c6ae793fb37771b3e9cb51"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41095
|
Medium |
fixed |
- 4.19.317
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.97
- 6.6.37
- 6.9.8
|
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes
In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is
assigned to mode, which will lead to a possible NULL pointer dereference
on failure of drm_mode_duplicate(). Add a check to avoid npd. |
["https://git.kernel.org/stable/c/0d17604f2e44b3df21e218fe8fb3b836d41bac49","https://git.kernel.org/stable/c/259549b2ccf795b7f91f7b5aba47286addcfa389","https://git.kernel.org/stable/c/66edf3fb331b6c55439b10f9862987b0916b3726","https://git.kernel.org/stable/c/9289cd3450d1da3e271ef4b054d4d2932c41243e","https://git.kernel.org/stable/c/bdda5072494f2a7215d94fc4124ad1949a218714","https://git.kernel.org/stable/c/cb751e48bbcffd292090f7882b23b215111b3d72","https://git.kernel.org/stable/c/dbd75f32252508ed6c46c3288a282c301a57ceeb","https://git.kernel.org/stable/c/f95ed0f54b3d3faecae1140ddab854f904a6e7c8","https://git.kernel.org/stable/c/0d17604f2e44b3df21e218fe8fb3b836d41bac49","https://git.kernel.org/stable/c/259549b2ccf795b7f91f7b5aba47286addcfa389","https://git.kernel.org/stable/c/66edf3fb331b6c55439b10f9862987b0916b3726","https://git.kernel.org/stable/c/9289cd3450d1da3e271ef4b054d4d2932c41243e","https://git.kernel.org/stable/c/bdda5072494f2a7215d94fc4124ad1949a218714","https://git.kernel.org/stable/c/cb751e48bbcffd292090f7882b23b215111b3d72","https://git.kernel.org/stable/c/dbd75f32252508ed6c46c3288a282c301a57ceeb","https://git.kernel.org/stable/c/f95ed0f54b3d3faecae1140ddab854f904a6e7c8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42068
|
Medium |
fixed |
- 5.15.162
- 6.1.97
- 6.6.37
- 6.9.8
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro()
set_memory_ro() can fail, leaving memory unprotected.
Check its return and take it into account as an error. |
["https://git.kernel.org/stable/c/05412471beba313ecded95aa17b25fe84bb2551a","https://git.kernel.org/stable/c/7d2cc63eca0c993c99d18893214abf8f85d566d8","https://git.kernel.org/stable/c/a359696856ca9409fb97655c5a8ef0f549cb6e03","https://git.kernel.org/stable/c/e4f602e3ff749ba770bf8ff10196e18358de6720","https://git.kernel.org/stable/c/05412471beba313ecded95aa17b25fe84bb2551a","https://git.kernel.org/stable/c/7d2cc63eca0c993c99d18893214abf8f85d566d8","https://git.kernel.org/stable/c/a359696856ca9409fb97655c5a8ef0f549cb6e03","https://git.kernel.org/stable/c/e3540e5a7054d6daaf9a1415a48aacb092112a89","https://git.kernel.org/stable/c/e4f602e3ff749ba770bf8ff10196e18358de6720","https://git.kernel.org/stable/c/fdd411af8178edc6b7bf260f8fa4fba1bedd0a6d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42070
|
Medium |
fixed |
- 3.13
- 4.19.317
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.97
- 6.6.37
- 6.9.8
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers
register store validation for NFT_DATA_VALUE is conditional, however,
the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This
only requires a new helper function to infer the register type from the
set datatype so this conditional check can be removed. Otherwise,
pointer to chain object can be leaked through the registers. |
["https://git.kernel.org/stable/c/23752737c6a618e994f9a310ec2568881a6b49c4","https://git.kernel.org/stable/c/40188a25a9847dbeb7ec67517174a835a677752f","https://git.kernel.org/stable/c/41a6375d48deaf7f730304b5153848bfa1c2980f","https://git.kernel.org/stable/c/461302e07f49687ffe7d105fa0a330c07c7646d8","https://git.kernel.org/stable/c/5d43d789b57943720dca4181a05f6477362b94cf","https://git.kernel.org/stable/c/7931d32955e09d0a11b1fe0b6aac1bfa061c005c","https://git.kernel.org/stable/c/952bf8df222599baadbd4f838a49c4fef81d2564","https://git.kernel.org/stable/c/efb27ad05949403848f487823b597ed67060e007","https://git.kernel.org/stable/c/23752737c6a618e994f9a310ec2568881a6b49c4","https://git.kernel.org/stable/c/40188a25a9847dbeb7ec67517174a835a677752f","https://git.kernel.org/stable/c/41a6375d48deaf7f730304b5153848bfa1c2980f","https://git.kernel.org/stable/c/461302e07f49687ffe7d105fa0a330c07c7646d8","https://git.kernel.org/stable/c/5d43d789b57943720dca4181a05f6477362b94cf","https://git.kernel.org/stable/c/7931d32955e09d0a11b1fe0b6aac1bfa061c005c","https://git.kernel.org/stable/c/952bf8df222599baadbd4f838a49c4fef81d2564","https://git.kernel.org/stable/c/efb27ad05949403848f487823b597ed67060e007"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42077
|
Medium |
fixed |
- 4.6
- 5.10.221
- 5.15.162
- 6.1.97
- 6.6.37
- 6.9.8
|
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix DIO failure due to insufficient transaction credits
The code in ocfs2_dio_end_io_write() estimates number of necessary
transaction credits using ocfs2_calc_extend_credits(). This however does
not take into account that the IO could be arbitrarily large and can
contain arbitrary number of extents.
Extent tree manipulations do often extend the current transaction but not
in all of the cases. For example if we have only single block extents in
the tree, ocfs2_mark_extent_written() will end up calling
ocfs2_replace_extent_rec() all the time and we will never extend the
current transaction and eventually exhaust all the transaction credits if
the IO contains many single block extents. Once that happens a
WARN_ON(jbd2_handle_buffer_credits(handle) <= 0) is triggered in
jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to
this error. This was actually triggered by one of our customers on a
heavily fragmented OCFS2 filesystem.
To fix the issue make sure the transaction always has enough credits for
one extent insert before each call of ocfs2_mark_extent_written().
Heming Zhao said:
------
PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error"
PID: xxx TASK: xxxx CPU: 5 COMMAND: "SubmitThread-CA"
#0 machine_kexec at ffffffff8c069932
#1 __crash_kexec at ffffffff8c1338fa
#2 panic at ffffffff8c1d69b9
#3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2]
#4 __ocfs2_abort at ffffffffc0c88387 [ocfs2]
#5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2]
#6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2]
#7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2]
#8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2]
#9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2]
#10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2]
#11 dio_complete at ffffffff8c2b9fa7
#12 do_blockdev_direct_IO at ffffffff8c2bc09f
#13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2]
#14 generic_file_direct_write at ffffffff8c1dcf14
#15 __generic_file_write_iter at ffffffff8c1dd07b
#16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2]
#17 aio_write at ffffffff8c2cc72e
#18 kmem_cache_alloc at ffffffff8c248dde
#19 do_io_submit at ffffffff8c2ccada
#20 do_syscall_64 at ffffffff8c004984
#21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba |
["https://git.kernel.org/stable/c/320273b5649bbcee87f9e65343077189699d2a7a","https://git.kernel.org/stable/c/331d1079d58206ff7dc5518185f800b412f89bc6","https://git.kernel.org/stable/c/9ea2d1c6789722d58ec191f14f9a02518d55b6b4","https://git.kernel.org/stable/c/a68b896aa56e435506453ec8835bc991ec3ae687","https://git.kernel.org/stable/c/be346c1a6eeb49d8fda827d2a9522124c2f72f36","https://git.kernel.org/stable/c/c05ffb693bfb42a48ef3ee88a55b57392984e111","https://git.kernel.org/stable/c/320273b5649bbcee87f9e65343077189699d2a7a","https://git.kernel.org/stable/c/331d1079d58206ff7dc5518185f800b412f89bc6","https://git.kernel.org/stable/c/9ea2d1c6789722d58ec191f14f9a02518d55b6b4","https://git.kernel.org/stable/c/a68b896aa56e435506453ec8835bc991ec3ae687","https://git.kernel.org/stable/c/be346c1a6eeb49d8fda827d2a9522124c2f72f36","https://git.kernel.org/stable/c/c05ffb693bfb42a48ef3ee88a55b57392984e111"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42082
|
Medium |
fixed |
- 4.18
- 5.10.221
- 5.15.162
- 6.1.97
- 6.6.37
- 6.9.8
|
In the Linux kernel, the following vulnerability has been resolved:
xdp: Remove WARN() from __xdp_reg_mem_model()
syzkaller reports a warning in __xdp_reg_mem_model().
The warning occurs only if __mem_id_init_hash_table() returns an error. It
returns the error in two cases:
1. memory allocation fails;
2. rhashtable_init() fails when some fields of rhashtable_params
struct are not initialized properly.
The second case cannot happen since there is a static const rhashtable_params
struct with valid fields. So, warning is only triggered when there is a
problem with memory allocation.
Thus, there is no sense in using WARN() to handle this error and it can be
safely removed.
WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299
CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
RIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299
Call Trace:
xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344
xdp_test_run_setup net/bpf/test_run.c:188 [inline]
bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377
bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267
bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240
__sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649
__do_sys_bpf kernel/bpf/syscall.c:5738 [inline]
__se_sys_bpf kernel/bpf/syscall.c:5736 [inline]
__x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736
do_syscall_64+0xfb/0x240
entry_SYSCALL_64_after_hwframe+0x6d/0x75
Found by Linux Verification Center (linuxtesting.org) with syzkaller. |
["https://git.kernel.org/stable/c/1095b8efbb13a6a5fa583ed373ee1ccab29da2d0","https://git.kernel.org/stable/c/14e51ea78b4ccacb7acb1346b9241bb790a2054c","https://git.kernel.org/stable/c/1d3e3b3aa2cbe9bc7db9a7f8673a9fa6d2990d54","https://git.kernel.org/stable/c/4e0c539ee265d5c6e7fa7d229cd4aa7bc01816e2","https://git.kernel.org/stable/c/7e9f79428372c6eab92271390851be34ab26bfb4","https://git.kernel.org/stable/c/f92298b0467fd77edc4c1a2c3e48833e69840ec4","https://git.kernel.org/stable/c/1095b8efbb13a6a5fa583ed373ee1ccab29da2d0","https://git.kernel.org/stable/c/14e51ea78b4ccacb7acb1346b9241bb790a2054c","https://git.kernel.org/stable/c/1d3e3b3aa2cbe9bc7db9a7f8673a9fa6d2990d54","https://git.kernel.org/stable/c/4e0c539ee265d5c6e7fa7d229cd4aa7bc01816e2","https://git.kernel.org/stable/c/7e9f79428372c6eab92271390851be34ab26bfb4","https://git.kernel.org/stable/c/f92298b0467fd77edc4c1a2c3e48833e69840ec4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46763
|
Medium |
fixed |
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
fou: Fix null-ptr-deref in GRO.
We observed a null-ptr-deref in fou_gro_receive() while shutting down
a host. [0]
The NULL pointer is sk->sk_user_data, and the offset 8 is of protocol
in struct fou.
When fou_release() is called due to netns dismantle or explicit tunnel
teardown, udp_tunnel_sock_release() sets NULL to sk->sk_user_data.
Then, the tunnel socket is destroyed after a single RCU grace period.
So, in-flight udp4_gro_receive() could find the socket and execute the
FOU GRO handler, where sk->sk_user_data could be NULL.
Let's use rcu_dereference_sk_user_data() in fou_from_sock() and add NULL
checks in FOU GRO handlers.
[0]:
BUG: kernel NULL pointer dereference, address: 0000000000000008
PF: supervisor read access in kernel mode
PF: error_code(0x0000) - not-present page
PGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0
SMP PTI
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1
Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017
RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]
Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42
RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297
RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010
RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08
RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002
R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400
R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0
FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<IRQ>
? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259)
? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420)
? no_context (arch/x86/mm/fault.c:752)
? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483)
? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571)
? fou_gro_receive (net/ipv4/fou.c:233) [fou]
udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559)
udp4_gro_receive (net/ipv4/udp_offload.c:604)
inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7))
dev_gro_receive (net/core/dev.c:6035 (discriminator 4))
napi_gro_receive (net/core/dev.c:6170)
ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena]
ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena]
napi_poll (net/core/dev.c:6847)
net_rx_action (net/core/dev.c:6917)
__do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299)
asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809)
</IRQ>
do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77)
irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435)
common_interrupt (arch/x86/kernel/irq.c:239)
asm_common_interrupt (arch/x86/include/asm/idtentry.h:626)
RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575)
Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 <fa> c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00
RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246
RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900
RDX: ffff93daee800000 RSI: ffff93d
---truncated--- |
["https://git.kernel.org/stable/c/1df42be305fe478ded1ee0c1d775f4ece713483b","https://git.kernel.org/stable/c/231c235d2f7a66f018f172e26ffd47c363f244ef","https://git.kernel.org/stable/c/4494bccb52ffda22ce5a1163a776d970e6229e08","https://git.kernel.org/stable/c/7e4196935069947d8b70b09c1660b67b067e75cb","https://git.kernel.org/stable/c/c46cd6aaca81040deaea3500ba75126963294bd9","https://git.kernel.org/stable/c/d7567f098f54cb53ee3cee1c82e3d0ed9698b6b3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46771
|
Medium |
fixed |
- 4.19.322
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: Remove proc entry when dev is unregistered.
syzkaller reported a warning in bcm_connect() below. [0]
The repro calls connect() to vxcan1, removes vxcan1, and calls
connect() with ifindex == 0.
Calling connect() for a BCM socket allocates a proc entry.
Then, bcm_sk(sk)->bound is set to 1 to prevent further connect().
However, removing the bound device resets bcm_sk(sk)->bound to 0
in bcm_notify().
The 2nd connect() tries to allocate a proc entry with the same
name and sets NULL to bcm_sk(sk)->bcm_proc_read, leaking the
original proc entry.
Since the proc entry is available only for connect()ed sockets,
let's clean up the entry when the bound netdev is unregistered.
[0]:
proc_dir_entry 'can-bcm/2456' already registered
WARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375
Modules linked in:
CPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
RIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375
Code: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 <0f> 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48
RSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246
RAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002
RBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0
R10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ec
FS: 00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<TASK>
proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220
bcm_connect+0x472/0x840 net/can/bcm.c:1673
__sys_connect_file net/socket.c:2049 [inline]
__sys_connect+0x5d2/0x690 net/socket.c:2066
__do_sys_connect net/socket.c:2076 [inline]
__se_sys_connect net/socket.c:2073 [inline]
__x64_sys_connect+0x8f/0x100 net/socket.c:2073
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x7fbd708b0e5d
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48
RSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5d
RDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040
R10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098
R13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000
</TASK>
remove_proc_entry: removing non-empty directory 'net/can-bcm', leaking at least '2456' |
["https://git.kernel.org/stable/c/10bfacbd5e8d821011d857bee73310457c9c989a","https://git.kernel.org/stable/c/33ed4ba73caae39f34ab874ba79138badc2c65dd","https://git.kernel.org/stable/c/3b39dc2901aa7a679a5ca981a3de9f8d5658afe8","https://git.kernel.org/stable/c/4377b79323df62eb5d310354f19b4d130ff58d50","https://git.kernel.org/stable/c/5c680022c4e28ba18ea500f3e29f0428271afa92","https://git.kernel.org/stable/c/76fe372ccb81b0c89b6cd2fec26e2f38c958be85","https://git.kernel.org/stable/c/abb0a615569ec008e8a93d9f3ab2d5b418ea94d4","https://git.kernel.org/stable/c/aec92dbebdbec7567d9f56d7c9296a572b8fd849"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46781
|
Medium |
fixed |
- 4.19.322
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix missing cleanup on rollforward recovery error
In an error injection test of a routine for mount-time recovery, KASAN
found a use-after-free bug.
It turned out that if data recovery was performed using partial logs
created by dsync writes, but an error occurred before starting the log
writer to create a recovered checkpoint, the inodes whose data had been
recovered were left in the ns_dirty_files list of the nilfs object and
were not freed.
Fix this issue by cleaning up inodes that have read the recovery data if
the recovery routine fails midway before the log writer starts. |
["https://git.kernel.org/stable/c/07e4dc2fe000ab008bcfe90be4324ef56b5b4355","https://git.kernel.org/stable/c/1cf1f7e8cd47244fa947d357ef1f642d91e219a3","https://git.kernel.org/stable/c/35a9a7a7d94662146396199b0cfd95f9517cdd14","https://git.kernel.org/stable/c/5787fcaab9eb5930f5378d6a1dd03d916d146622","https://git.kernel.org/stable/c/8e2d1e9d93c4ec51354229361ac3373058529ec4","https://git.kernel.org/stable/c/9d8c3a585d564d776ee60d4aabec59b404be7403","https://git.kernel.org/stable/c/ca92c4bff2833cb30d493b935168d6cccd5c805d","https://git.kernel.org/stable/c/da02f9eb333333b2e4f25d2a14967cff785ac82e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46784
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: mana: Fix error handling in mana_create_txq/rxq's NAPI cleanup
Currently napi_disable() gets called during rxq and txq cleanup,
even before napi is enabled and hrtimer is initialized. It causes
kernel panic.
? page_fault_oops+0x136/0x2b0
? page_counter_cancel+0x2e/0x80
? do_user_addr_fault+0x2f2/0x640
? refill_obj_stock+0xc4/0x110
? exc_page_fault+0x71/0x160
? asm_exc_page_fault+0x27/0x30
? __mmdrop+0x10/0x180
? __mmdrop+0xec/0x180
? hrtimer_active+0xd/0x50
hrtimer_try_to_cancel+0x2c/0xf0
hrtimer_cancel+0x15/0x30
napi_disable+0x65/0x90
mana_destroy_rxq+0x4c/0x2f0
mana_create_rxq.isra.0+0x56c/0x6d0
? mana_uncfg_vport+0x50/0x50
mana_alloc_queues+0x21b/0x320
? skb_dequeue+0x5f/0x80 |
["https://git.kernel.org/stable/c/386617efacab10bf5bb40bde403467c57cc00470","https://git.kernel.org/stable/c/4982a47154f0b50de81ee0a0b169a3fc74120a65","https://git.kernel.org/stable/c/9178eb8ebcd887ab75e54ac40d538e54bb9c7788","https://git.kernel.org/stable/c/9e0bff4900b5d412a9bafe4baeaa6facd34f671c","https://git.kernel.org/stable/c/b6ecc662037694488bfff7c9fd21c405df8411f2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46855
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_socket: fix sk refcount leaks
We must put 'sk' reference before returning. |
["https://git.kernel.org/stable/c/1f68e097e20d3c695281a9c6433acc37be47fe11","https://git.kernel.org/stable/c/33c2258bf8cb17fba9e58b111d4c4f4cf43a4896","https://git.kernel.org/stable/c/83e6fb59040e8964888afcaa5612cc1243736715","https://git.kernel.org/stable/c/8b26ff7af8c32cb4148b3e147c52f9e4c695209c","https://git.kernel.org/stable/c/ddc7c423c4a5386bf865474c694b48178efd311a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35998
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
smb3: fix lock ordering potential deadlock in cifs_sync_mid_result
Coverity spotted that the cifs_sync_mid_result function could deadlock
"Thread deadlock (ORDER_REVERSAL) lock_order: Calling spin_lock acquires
lock TCP_Server_Info.srv_lock while holding lock TCP_Server_Info.mid_lock"
Addresses-Coverity: 1590401 ("Thread deadlock (ORDER_REVERSAL)") |
["https://git.kernel.org/stable/c/699f8958dece132709c0bff6a9700999a2a63b75","https://git.kernel.org/stable/c/8248224ab5b8ca7559b671917c224296a4d671fc","https://git.kernel.org/stable/c/8861fd5180476f45f9e8853db154600469a0284f","https://git.kernel.org/stable/c/c7a4bca289e50bb4b2650f845c41bb3e453f4c66","https://git.kernel.org/stable/c/699f8958dece132709c0bff6a9700999a2a63b75","https://git.kernel.org/stable/c/8248224ab5b8ca7559b671917c224296a4d671fc","https://git.kernel.org/stable/c/8861fd5180476f45f9e8853db154600469a0284f","https://git.kernel.org/stable/c/c7a4bca289e50bb4b2650f845c41bb3e453f4c66"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35999
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
smb3: missing lock when picking channel
Coverity spotted a place where we should have been holding the
channel lock when accessing the ses channel index.
Addresses-Coverity: 1582039 ("Data race condition (MISSING_LOCK)") |
["https://git.kernel.org/stable/c/0fcf7e219448e937681216353c9a58abae6d3c2e","https://git.kernel.org/stable/c/60ab245292280905603bc0d3654f4cf8fceccb00","https://git.kernel.org/stable/c/8094a600245e9b28eb36a13036f202ad67c1f887","https://git.kernel.org/stable/c/98c7ed29cd754ae7475dc7cb3f33399fda902729","https://git.kernel.org/stable/c/0fcf7e219448e937681216353c9a58abae6d3c2e","https://git.kernel.org/stable/c/60ab245292280905603bc0d3654f4cf8fceccb00","https://git.kernel.org/stable/c/8094a600245e9b28eb36a13036f202ad67c1f887","https://git.kernel.org/stable/c/98c7ed29cd754ae7475dc7cb3f33399fda902729"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36924
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()
lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the
hbalock. Thus, lpfc_worker_wake_up() should not be called while holding the
hbalock to avoid potential deadlock. |
["https://git.kernel.org/stable/c/6503c39398506cadda9f4c81695a9655ca5fb4fd","https://git.kernel.org/stable/c/ded20192dff31c91cef2a04f7e20e60e9bb887d3","https://git.kernel.org/stable/c/e8bf2c05e8ad68e90f9d5889a9e4ef3f6fe00683","https://git.kernel.org/stable/c/ee833d7e62de2b84ed1332d501b67f12e7e5678f","https://git.kernel.org/stable/c/6503c39398506cadda9f4c81695a9655ca5fb4fd","https://git.kernel.org/stable/c/ded20192dff31c91cef2a04f7e20e60e9bb887d3","https://git.kernel.org/stable/c/e8bf2c05e8ad68e90f9d5889a9e4ef3f6fe00683","https://git.kernel.org/stable/c/ee833d7e62de2b84ed1332d501b67f12e7e5678f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38628
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: u_audio: Fix race condition use of controls after free during gadget unbind.
Hang on to the control IDs instead of pointers since those are correctly
handled with locks. |
["https://git.kernel.org/stable/c/1b739388aa3f8dfb63a9fca777e6dfa6912d0464","https://git.kernel.org/stable/c/453d3fa9266e53f85377b911c19b9a4563fa88c0","https://git.kernel.org/stable/c/89e66809684485590ea0b32c3178e42cba36ac09","https://git.kernel.org/stable/c/bea73b58ab67fe581037ad9cdb93c2557590c068","https://git.kernel.org/stable/c/1b739388aa3f8dfb63a9fca777e6dfa6912d0464","https://git.kernel.org/stable/c/453d3fa9266e53f85377b911c19b9a4563fa88c0","https://git.kernel.org/stable/c/89e66809684485590ea0b32c3178e42cba36ac09","https://git.kernel.org/stable/c/bea73b58ab67fe581037ad9cdb93c2557590c068"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44938
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
jfs: Fix shift-out-of-bounds in dbDiscardAG
When searching for the next smaller log2 block, BLKSTOL2() returned 0,
causing shift exponent -1 to be negative.
This patch fixes the issue by exiting the loop directly when negative
shift is found. |
["https://git.kernel.org/stable/c/234e6ea0855cdb5673d54ecaf7dc5c78f3e84630","https://git.kernel.org/stable/c/4de2c04c3acd5b84f50b0d2f8f09e9b2f42374b9","https://git.kernel.org/stable/c/7063b80268e2593e58bee8a8d709c2f3ff93e2f2","https://git.kernel.org/stable/c/bb7c605a754823b86dd74f6537ccb9d38a9dec5a","https://git.kernel.org/stable/c/bd04a149e3a29e7f71b7956ed41dba34e42d539e","https://git.kernel.org/stable/c/f650148b43949ca9e37e820804bb6026fff404f3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48887
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Remove rcu locks from user resources
User resource lookups used rcu to avoid two extra atomics. Unfortunately
the rcu paths were buggy and it was easy to make the driver crash by
submitting command buffers from two different threads. Because the
lookups never show up in performance profiles replace them with a
regular spin lock which fixes the races in accesses to those shared
resources.
Fixes kernel oops'es in IGT's vmwgfx execution_buffer stress test and
seen crashes with apps using shared resources. |
["https://git.kernel.org/stable/c/7ac9578e45b20e3f3c0c8eb71f5417a499a7226a","https://git.kernel.org/stable/c/a309c7194e8a2f8bd4539b9449917913f6c2cd50"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48909
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix connection leak
There's a potential leak issue under following execution sequence :
smc_release smc_connect_work
if (sk->sk_state == SMC_INIT)
send_clc_confirim
tcp_abort();
...
sk.sk_state = SMC_ACTIVE
smc_close_active
switch(sk->sk_state) {
...
case SMC_ACTIVE:
smc_close_final()
// then wait peer closed
Unfortunately, tcp_abort() may discard CLC CONFIRM messages that are
still in the tcp send buffer, in which case our connection token cannot
be delivered to the server side, which means that we cannot get a
passive close message at all. Therefore, it is impossible for the to be
disconnected at all.
This patch tries a very simple way to avoid this issue, once the state
has changed to SMC_ACTIVE after tcp_abort(), we can actively abort the
smc connection, considering that the state is SMC_INIT before
tcp_abort(), abandoning the complete disconnection process should not
cause too much problem.
In fact, this problem may exist as long as the CLC CONFIRM message is
not received by the server. Whether a timer should be added after
smc_close_final() needs to be discussed in the future. But even so, this
patch provides a faster release for connection in above case, it should
also be valuable. |
["https://git.kernel.org/stable/c/2e8d465b83db307f04ad265848f8ab3f78f6918f","https://git.kernel.org/stable/c/80895b6f9154fb22d36fab311ccbb75503a2c87b","https://git.kernel.org/stable/c/9f1c50cf39167ff71dc5953a3234f3f6eeb8fcb5","https://git.kernel.org/stable/c/e98d46ccfa84b35a9e4b1ccdd83961b41a5d7ce5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46811
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix index may exceed array range within fpu_update_bw_bounding_box
[Why]
Coverity reports OVERRUN warning. soc.num_states could
be 40. But array range of bw_params->clk_table.entries is 8.
[How]
Assert if soc.num_states greater than 8. |
["https://git.kernel.org/stable/c/188fd1616ec43033cedbe343b6579e9921e2d898","https://git.kernel.org/stable/c/4003bac784380fed1f94f197350567eaa73a409d","https://git.kernel.org/stable/c/aba188d6f4ebaf52acf13f204db2bd2c22072504"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57980
|
High |
fixed |
- 6.1.129
- 6.6.76
- 6.12.13
- 6.13.2
|
In the Linux kernel, the following vulnerability has been resolved:
media: uvcvideo: Fix double free in error path
If the uvc_status_init() function fails to allocate the int_urb, it will
free the dev->status pointer but doesn't reset the pointer to NULL. This
results in the kfree() call in uvc_status_cleanup() trying to
double-free the memory. Fix it by resetting the dev->status pointer to
NULL after freeing it.
Reviewed by: Ricardo Ribalda <ribalda@chromium.org> |
["https://git.kernel.org/stable/c/3ba8884a56a3eb97c22f0ce0e4dd410d4ca4c277","https://git.kernel.org/stable/c/6c36dcd662ec5276782838660f8533a7cb26be49","https://git.kernel.org/stable/c/87522ef165e5b6de8ef98cc318f3335166a1512c","https://git.kernel.org/stable/c/9232719ac9ce4d5c213cebda23d72aec3e1c4c0d","https://git.kernel.org/stable/c/c6ef3a7fa97ec823a1e1af9085cf13db9f7b3bac","https://git.kernel.org/stable/c/d1f8e69eec91d5a75ef079778a5d0151db2a7f22","https://git.kernel.org/stable/c/d6e5ba2516c5bef87c1fcb8189b6f3cad7c64b2d","https://git.kernel.org/stable/c/d8e63dd7b6683969d3d47c7b8e9635f96d554ad4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-58055
|
High |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.129
- 6.6.76
- 6.12.13
- 6.13.2
|
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_tcm: Don't free command immediately
Don't prematurely free the command. Wait for the status completion of
the sense status. It can be freed then. Otherwise we will double-free
the command. |
["https://git.kernel.org/stable/c/16907219ad6763f401700e1b57b2da4f3e07f047","https://git.kernel.org/stable/c/38229c35a6d7875697dfb293356407330cfcd23e","https://git.kernel.org/stable/c/7cb72dc08ed8da60fd6d1f6adf13bf0e6ee0f694","https://git.kernel.org/stable/c/929b69810eec132b284ffd19047a85d961df9e4d","https://git.kernel.org/stable/c/bbb7f49839b57d66ccaf7b5752d9b63d3031dd0a","https://git.kernel.org/stable/c/c225d006a31949d673e646d585d9569bc28feeb9","https://git.kernel.org/stable/c/e6693595bd1b55af62d057a4136a89d5c2ddf0e9","https://git.kernel.org/stable/c/f0c33e7d387ccbb6870e73a43c558fefede06614"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-58069
|
High |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.129
- 6.6.76
- 6.12.13
- 6.13.2
|
In the Linux kernel, the following vulnerability has been resolved:
rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read
The nvmem interface supports variable buffer sizes, while the regmap
interface operates with fixed-size storage. If an nvmem client uses a
buffer size less than 4 bytes, regmap_read will write out of bounds
as it expects the buffer to point at an unsigned int.
Fix this by using an intermediary unsigned int to hold the value. |
["https://git.kernel.org/stable/c/21cd59fcb9952eb7505da2bdfc1eb9c619df3ff4","https://git.kernel.org/stable/c/3ab8c5ed4f84fa20cd16794fe8dc31f633fbc70c","https://git.kernel.org/stable/c/517aedb365f2c94e2d7e0b908ac7127df76203a1","https://git.kernel.org/stable/c/6f2a8ca9a0a38589f52a7f0fb9425b9ba987ae7c","https://git.kernel.org/stable/c/9adefa7b9559d0f21034a5d5ec1b55840c9348b9","https://git.kernel.org/stable/c/c72b7a474d3f445bf0c5bcf8ffed332c78eb28a1","https://git.kernel.org/stable/c/e5536677da803ed54a29a446515c28dce7d3d574","https://git.kernel.org/stable/c/e5e06455760f2995b16a176033909347929d1128"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-58083
|
High |
fixed |
- 4.15
- 4.20
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.129
- 6.6.78
- 6.12.14
- 6.13.3
|
In the Linux kernel, the following vulnerability has been resolved:
KVM: Explicitly verify target vCPU is online in kvm_get_vcpu()
Explicitly verify the target vCPU is fully online _prior_ to clamping the
index in kvm_get_vcpu(). If the index is "bad", the nospec clamping will
generate '0', i.e. KVM will return vCPU0 instead of NULL.
In practice, the bug is unlikely to cause problems, as it will only come
into play if userspace or the guest is buggy or misbehaving, e.g. KVM may
send interrupts to vCPU0 instead of dropping them on the floor.
However, returning vCPU0 when it shouldn't exist per online_vcpus is
problematic now that KVM uses an xarray for the vCPUs array, as KVM needs
to insert into the xarray before publishing the vCPU to userspace (see
commit c5b077549136 ("KVM: Convert the kvm->vcpus array to a xarray")),
i.e. before vCPU creation is guaranteed to succeed.
As a result, incorrectly providing access to vCPU0 will trigger a
use-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu()
bails out of vCPU creation due to an error and frees vCPU0. Commit
afb2acb2e3a3 ("KVM: Fix vcpu_array[0] races") papered over that issue, but
in doing so introduced an unsolvable teardown conundrum. Preventing
accesses to vCPU0 before it's fully online will allow reverting commit
afb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race. |
["https://git.kernel.org/stable/c/09d50ccf0b2d739db4a485b08afe7520a4402a63","https://git.kernel.org/stable/c/125da53b3c0c9d7f58353aea0076e9efd6498ba7","https://git.kernel.org/stable/c/1e7381f3617d14b3c11da80ff5f8a93ab14cfc46","https://git.kernel.org/stable/c/5cce2ed69b00e022b5cdf0c49c82986abd2941a8","https://git.kernel.org/stable/c/7c4899239d0f70f88ac42665b3da51678d122480","https://git.kernel.org/stable/c/ca8da90ed1432ff3d000de4f1e2275d4e7d21b96","https://git.kernel.org/stable/c/d817e510662fd1c9797952408d94806f97a5fffd","https://git.kernel.org/stable/c/f2f805ada63b536bc192458a7098388286568ad4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21715
|
High |
fixed |
- 4.5
- 4.10
- 4.15
- 4.20
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.129
- 6.6.76
- 6.12.13
- 6.13.2
|
In the Linux kernel, the following vulnerability has been resolved:
net: davicom: fix UAF in dm9000_drv_remove
dm is netdev private data and it cannot be
used after free_netdev() call. Using dm after free_netdev()
can cause UAF bug. Fix it by moving free_netdev() at the end of the
function.
This is similar to the issue fixed in commit
ad297cd2db89 ("net: qcom/emac: fix UAF in emac_remove").
This bug is detected by our static analysis tool. |
["https://git.kernel.org/stable/c/19e65c45a1507a1a2926649d2db3583ed9d55fd9","https://git.kernel.org/stable/c/2013c95df6752d9c88221d0f0f37b6f197969390","https://git.kernel.org/stable/c/5a54367a7c2378c65aaa4d3cfd952f26adef7aa7","https://git.kernel.org/stable/c/7d7d201eb3b766abe590ac0dda7a508b7db3e357","https://git.kernel.org/stable/c/a53cb72043443ac787ec0b5fa17bb3f8ff3d462b","https://git.kernel.org/stable/c/c411f9a5fdc9158e8f7c57eac961d3df3eb4d8ca","https://git.kernel.org/stable/c/c94ab07edc2843e2f3d46dbd82e5c681503aaadf","https://git.kernel.org/stable/c/db79e982c5f9e39ab710cbce55b05f2f5e6f1ca9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21731
|
High |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.129
- 6.6.76
- 6.12.13
- 6.13.2
|
In the Linux kernel, the following vulnerability has been resolved:
nbd: don't allow reconnect after disconnect
Following process can cause nbd_config UAF:
1) grab nbd_config temporarily;
2) nbd_genl_disconnect() flush all recv_work() and release the
initial reference:
nbd_genl_disconnect
nbd_disconnect_and_put
nbd_disconnect
flush_workqueue(nbd->recv_workq)
if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...))
nbd_config_put
-> due to step 1), reference is still not zero
3) nbd_genl_reconfigure() queue recv_work() again;
nbd_genl_reconfigure
config = nbd_get_config_unlocked(nbd)
if (!config)
-> succeed
if (!test_bit(NBD_RT_BOUND, ...))
-> succeed
nbd_reconnect_socket
queue_work(nbd->recv_workq, &args->work)
4) step 1) release the reference;
5) Finially, recv_work() will trigger UAF:
recv_work
nbd_config_put(nbd)
-> nbd_config is freed
atomic_dec(&config->recv_threads)
-> UAF
Fix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), so
that nbd_genl_reconfigure() will fail. |
["https://git.kernel.org/stable/c/6bef6222a3f6c7adb6396f77f25a3579d821b09a","https://git.kernel.org/stable/c/844b8cdc681612ff24df62cdefddeab5772fadf1","https://git.kernel.org/stable/c/9793bd5ae4bdbdb2dde401a3cab94a6bfd05e302","https://git.kernel.org/stable/c/a8ee6ecde2b7bfb58c8a3afe8a9d2b848f580739","https://git.kernel.org/stable/c/d208d2c52b652913b5eefc8ca434b0d6b757f68f","https://git.kernel.org/stable/c/e3be8862d73cac833e0fb7602636c19c6cb94b11","https://git.kernel.org/stable/c/e70a578487a47d7cf058904141e586684d1c3381","https://git.kernel.org/stable/c/e7343fa33751cb07c1c56b666bf37cfca357130e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21753
|
High |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.129
- 6.6.78
- 6.12.14
- 6.13.3
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix use-after-free when attempting to join an aborted transaction
When we are trying to join the current transaction and if it's aborted,
we read its 'aborted' field after unlocking fs_info->trans_lock and
without holding any extra reference count on it. This means that a
concurrent task that is aborting the transaction may free the transaction
before we read its 'aborted' field, leading to a use-after-free.
Fix this by reading the 'aborted' field while holding fs_info->trans_lock
since any freeing task must first acquire that lock and set
fs_info->running_transaction to NULL before freeing the transaction.
This was reported by syzbot and Dmitry with the following stack traces
from KASAN:
==================================================================
BUG: KASAN: slab-use-after-free in join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278
Read of size 4 at addr ffff888011839024 by task kworker/u4:9/1128
CPU: 0 UID: 0 PID: 1128 Comm: kworker/u4:9 Not tainted 6.13.0-rc7-syzkaller-00019-gc45323b7560e #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Workqueue: events_unbound btrfs_async_reclaim_data_space
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0x169/0x550 mm/kasan/report.c:489
kasan_report+0x143/0x180 mm/kasan/report.c:602
join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278
start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697
flush_space+0x448/0xcf0 fs/btrfs/space-info.c:803
btrfs_async_reclaim_data_space+0x159/0x510 fs/btrfs/space-info.c:1321
process_one_work kernel/workqueue.c:3236 [inline]
process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317
worker_thread+0x870/0xd30 kernel/workqueue.c:3398
kthread+0x2f0/0x390 kernel/kthread.c:389
ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
</TASK>
Allocated by task 5315:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
__kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394
kasan_kmalloc include/linux/kasan.h:260 [inline]
__kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329
kmalloc_noprof include/linux/slab.h:901 [inline]
join_transaction+0x144/0xda0 fs/btrfs/transaction.c:308
start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697
btrfs_create_common+0x1b2/0x2e0 fs/btrfs/inode.c:6572
lookup_open fs/namei.c:3649 [inline]
open_last_lookups fs/namei.c:3748 [inline]
path_openat+0x1c03/0x3590 fs/namei.c:3984
do_filp_open+0x27f/0x4e0 fs/namei.c:4014
do_sys_openat2+0x13e/0x1d0 fs/open.c:1402
do_sys_open fs/open.c:1417 [inline]
__do_sys_creat fs/open.c:1495 [inline]
__se_sys_creat fs/open.c:1489 [inline]
__x64_sys_creat+0x123/0x170 fs/open.c:1489
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 5336:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582
poison_slab_object mm/kasan/common.c:247 [inline]
__kasan_slab_free+0x59/0x70 mm/kasan/common.c:264
kasan_slab_free include/linux/kasan.h:233 [inline]
slab_free_hook mm/slub.c:2353 [inline]
slab_free mm/slub.c:4613 [inline]
kfree+0x196/0x430 mm/slub.c:4761
cleanup_transaction fs/btrfs/transaction.c:2063 [inline]
btrfs_commit_transaction+0x2c97/0x3720 fs/btrfs/transaction.c:2598
insert_balance_item+0x1284/0x20b0 fs/btrfs/volumes.c:3757
btrfs_balance+0x992/
---truncated--- |
["https://git.kernel.org/stable/c/6ba4663ada6c6315af23a6669d386146634808ec","https://git.kernel.org/stable/c/7e954b6bb95d67ae4d1a20e9cfd83c182cf929bc","https://git.kernel.org/stable/c/86d71a026a7f63da905db9add845c8ee88801eca","https://git.kernel.org/stable/c/8f5cff471039caa2b088060c074c2bf2081bcb01","https://git.kernel.org/stable/c/c7a53757717e68af94a56929d57f1e6daff220ec","https://git.kernel.org/stable/c/ce628048390dad80320d5a1f74de6ca1e1be91e7","https://git.kernel.org/stable/c/cee55b1219568c80bf0d5dc55066e4a859baf753","https://git.kernel.org/stable/c/e2f0943cf37305dbdeaf9846e3c941451bcdef63"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21760
|
High |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.129
- 6.6.79
- 6.12.16
- 6.13.4
|
In the Linux kernel, the following vulnerability has been resolved:
ndisc: extend RCU protection in ndisc_send_skb()
ndisc_send_skb() can be called without RTNL or RCU held.
Acquire rcu_read_lock() earlier, so that we can use dev_net_rcu()
and avoid a potential UAF. |
["https://git.kernel.org/stable/c/04e05112f10354ffc3bb6cc796d553bab161594c","https://git.kernel.org/stable/c/10a1f3fece2f0d23a3a618b72b2b4e6f408ef7d1","https://git.kernel.org/stable/c/4d576202b90b1b95a7c428a80b536f91b8201bcc","https://git.kernel.org/stable/c/789230e5a8c1097301afc802e242c79bc8835c67","https://git.kernel.org/stable/c/a9319d800b5701e7f5e3fa71a5b7c4831fc20d6d","https://git.kernel.org/stable/c/ae38982f521621c216fc2f5182cd091f4734641d","https://git.kernel.org/stable/c/e24d225e4cb8cf108bde00b76594499b98f0a74d","https://git.kernel.org/stable/c/ed6ae1f325d3c43966ec1b62ac1459e2b8e45640"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21761
|
High |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.129
- 6.6.79
- 6.12.16
- 6.13.4
|
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: use RCU protection in ovs_vport_cmd_fill_info()
ovs_vport_cmd_fill_info() can be called without RTNL or RCU.
Use RCU protection and dev_net_rcu() to avoid potential UAF. |
["https://git.kernel.org/stable/c/5828937742af74666192835d657095d95c53dbd0","https://git.kernel.org/stable/c/7e01abc34e87abd091e619161a20f54ed4e3e2da","https://git.kernel.org/stable/c/8ec57509c36c8b9a23e50b7858dda0c520a2d074","https://git.kernel.org/stable/c/90b2f49a502fa71090d9f4fe29a2f51fe5dff76d","https://git.kernel.org/stable/c/a849a10de5e04d798f7f286a2f1ca174719a617a","https://git.kernel.org/stable/c/a8816b3f1f151373fd30f1996f00480126c8bb11","https://git.kernel.org/stable/c/a884f57600e463f69d7b279c4598b865260b62a1","https://git.kernel.org/stable/c/e85a25d1a9985645e796039e843d1de581d2de1e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21762
|
High |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.129
- 6.6.79
- 6.12.16
- 6.13.4
|
In the Linux kernel, the following vulnerability has been resolved:
arp: use RCU protection in arp_xmit()
arp_xmit() can be called without RTNL or RCU protection.
Use RCU protection to avoid potential UAF. |
["https://git.kernel.org/stable/c/01d1b5c9abcaff29a43f1d17a19c33eec92c7dbe","https://git.kernel.org/stable/c/10f555e3f573d004ae9d89b3276abb58c4ede5c3","https://git.kernel.org/stable/c/2c331718d3389b6c5f6855078ab7171849e016bd","https://git.kernel.org/stable/c/307cd1e2d3cb1cbc6c40c679cada6d7168b18431","https://git.kernel.org/stable/c/a42b69f692165ec39db42d595f4f65a4c8f42e44","https://git.kernel.org/stable/c/d9366ac2f956a1948b68c0500f84a3462ff2ed8a","https://git.kernel.org/stable/c/e9f4dee534eb1b225b0a120395ad9bc2afe164d3","https://git.kernel.org/stable/c/f189654459423d4d48bef2d120b4bfba559e6039"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21763
|
High |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.129
- 6.6.79
- 6.12.16
- 6.13.4
|
In the Linux kernel, the following vulnerability has been resolved:
neighbour: use RCU protection in __neigh_notify()
__neigh_notify() can be called without RTNL or RCU protection.
Use RCU protection to avoid potential UAF. |
["https://git.kernel.org/stable/c/1cbb2aa90cd3fba15ad7efb5cdda28f3d1082379","https://git.kernel.org/stable/c/40d8f2f2a373b6c294ffac394d2bb814b572ead1","https://git.kernel.org/stable/c/559307d25235e24b5424778c7332451b6c741159","https://git.kernel.org/stable/c/784eb2376270e086f7db136d154b8404edacf97b","https://git.kernel.org/stable/c/8666e9aab801328c1408a19fbf4070609dc0695a","https://git.kernel.org/stable/c/becbd5850c03ed33b232083dd66c6e38c0c0e569","https://git.kernel.org/stable/c/cdd5c2a12ddad8a77ce1838ff9f29aa587de82df","https://git.kernel.org/stable/c/e1aed6be381bcd7f46d4ca9d7ef0f5f3d6a1be32"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21764
|
High |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.129
- 6.6.79
- 6.12.16
- 6.13.4
|
In the Linux kernel, the following vulnerability has been resolved:
ndisc: use RCU protection in ndisc_alloc_skb()
ndisc_alloc_skb() can be called without RTNL or RCU being held.
Add RCU protection to avoid possible UAF. |
["https://git.kernel.org/stable/c/3c2d705f5adf5d860aaef90cb4211c0fde2ba66d","https://git.kernel.org/stable/c/628e6d18930bbd21f2d4562228afe27694f66da9","https://git.kernel.org/stable/c/96fc896d0e5b37c12808df797397fb16f3080879","https://git.kernel.org/stable/c/9e0ec817eb41a55327a46cd3ce331a9868d60304","https://git.kernel.org/stable/c/b870256dd2a5648d5ed2f22316b3ac29a7e5ed63","https://git.kernel.org/stable/c/bbec88e4108e8d6fb468d3817fa652140a44ff28","https://git.kernel.org/stable/c/c30893ef3d9cde8e7e8e4fd06b53d2c935bbccb1","https://git.kernel.org/stable/c/cd1065f92eb7ff21b9ba5308a86f33d1670bf926"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53171
|
High |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
ubifs: authentication: Fix use-after-free in ubifs_tnc_end_commit
After an insertion in TNC, the tree might split and cause a node to
change its `znode->parent`. A further deletion of other nodes in the
tree (which also could free the nodes), the aforementioned node's
`znode->cparent` could still point to a freed node. This
`znode->cparent` may not be updated when getting nodes to commit in
`ubifs_tnc_start_commit()`. This could then trigger a use-after-free
when accessing the `znode->cparent` in `write_index()` in
`ubifs_tnc_end_commit()`.
This can be triggered by running
rm -f /etc/test-file.bin
dd if=/dev/urandom of=/etc/test-file.bin bs=1M count=60 conv=fsync
in a loop, and with `CONFIG_UBIFS_FS_AUTHENTICATION`. KASAN then
reports:
BUG: KASAN: use-after-free in ubifs_tnc_end_commit+0xa5c/0x1950
Write of size 32 at addr ffffff800a3af86c by task ubifs_bgt0_20/153
Call trace:
dump_backtrace+0x0/0x340
show_stack+0x18/0x24
dump_stack_lvl+0x9c/0xbc
print_address_description.constprop.0+0x74/0x2b0
kasan_report+0x1d8/0x1f0
kasan_check_range+0xf8/0x1a0
memcpy+0x84/0xf4
ubifs_tnc_end_commit+0xa5c/0x1950
do_commit+0x4e0/0x1340
ubifs_bg_thread+0x234/0x2e0
kthread+0x36c/0x410
ret_from_fork+0x10/0x20
Allocated by task 401:
kasan_save_stack+0x38/0x70
__kasan_kmalloc+0x8c/0xd0
__kmalloc+0x34c/0x5bc
tnc_insert+0x140/0x16a4
ubifs_tnc_add+0x370/0x52c
ubifs_jnl_write_data+0x5d8/0x870
do_writepage+0x36c/0x510
ubifs_writepage+0x190/0x4dc
__writepage+0x58/0x154
write_cache_pages+0x394/0x830
do_writepages+0x1f0/0x5b0
filemap_fdatawrite_wbc+0x170/0x25c
file_write_and_wait_range+0x140/0x190
ubifs_fsync+0xe8/0x290
vfs_fsync_range+0xc0/0x1e4
do_fsync+0x40/0x90
__arm64_sys_fsync+0x34/0x50
invoke_syscall.constprop.0+0xa8/0x260
do_el0_svc+0xc8/0x1f0
el0_svc+0x34/0x70
el0t_64_sync_handler+0x108/0x114
el0t_64_sync+0x1a4/0x1a8
Freed by task 403:
kasan_save_stack+0x38/0x70
kasan_set_track+0x28/0x40
kasan_set_free_info+0x28/0x4c
__kasan_slab_free+0xd4/0x13c
kfree+0xc4/0x3a0
tnc_delete+0x3f4/0xe40
ubifs_tnc_remove_range+0x368/0x73c
ubifs_tnc_remove_ino+0x29c/0x2e0
ubifs_jnl_delete_inode+0x150/0x260
ubifs_evict_inode+0x1d4/0x2e4
evict+0x1c8/0x450
iput+0x2a0/0x3c4
do_unlinkat+0x2cc/0x490
__arm64_sys_unlinkat+0x90/0x100
invoke_syscall.constprop.0+0xa8/0x260
do_el0_svc+0xc8/0x1f0
el0_svc+0x34/0x70
el0t_64_sync_handler+0x108/0x114
el0t_64_sync+0x1a4/0x1a8
The offending `memcpy()` in `ubifs_copy_hash()` has a use-after-free
when a node becomes root in TNC but still has a `cparent` to an already
freed node. More specifically, consider the following TNC:
zroot
/
/
zp1
/
/
zn
Inserting a new node `zn_new` with a key smaller then `zn` will trigger
a split in `tnc_insert()` if `zp1` is full:
zroot
/ \
/ \
zp1 zp2
/ \
/ \
zn_new zn
`zn->parent` has now been moved to `zp2`, *but* `zn->cparent` still
points to `zp1`.
Now, consider a removal of all the nodes _except_ `zn`. Just when
`tnc_delete()` is about to delete `zroot` and `zp2`:
zroot
\
\
zp2
\
\
zn
`zroot` and `zp2` get freed and the tree collapses:
zn
`zn` now becomes the new `zroot`.
`get_znodes_to_commit()` will now only find `zn`, the new `zroot`, and
`write_index()` will check its `znode->cparent` that wrongly points to
the already freed `zp1`. `ubifs_copy_hash()` thus gets wrongly called
with `znode->cparent->zbranch[znode->iip].hash` that triggers the
use-after-free!
Fix this by explicitly setting `znode->cparent` to `NULL` in
`get_znodes_to_commit()` for the root node. The search for the dirty
nodes
---truncated--- |
["https://git.kernel.org/stable/c/01d3a2293d7e4edfff96618c15727db7e51f11b6","https://git.kernel.org/stable/c/2497479aecebe869d23a0064e0fd1a03e34f0e2a","https://git.kernel.org/stable/c/398a91599d263e41c5f95a2fd4ebdb6280b5c6c3","https://git.kernel.org/stable/c/4617fb8fc15effe8eda4dd898d4e33eb537a7140","https://git.kernel.org/stable/c/4d9807048b851d7a58d5bd089c16254af896e4df","https://git.kernel.org/stable/c/74981f7577d183acad1cd58f74c10d263711a215","https://git.kernel.org/stable/c/8d8b3f5f4cbfbf6cb0ea4a4d5dc296872b4151eb","https://git.kernel.org/stable/c/daac4aa1825de0dbc1a6eede2fa7f9fc53f14223"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57795
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Remove the direct link to net_device
The similar patch in siw is in the link:
https://git.kernel.org/rdma/rdma/c/16b87037b48889
This problem also occurred in RXE. The following analyze this problem.
In the following Call Traces:
"
BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0 net/core/dev.c:8782
Read of size 4 at addr ffff8880554640b0 by task kworker/1:4/5295
CPU: 1 UID: 0 PID: 5295 Comm: kworker/1:4 Not tainted
6.12.0-rc3-syzkaller-00399-g9197b73fd7bb #0
Hardware name: Google Compute Engine/Google Compute Engine,
BIOS Google 09/13/2024
Workqueue: infiniband ib_cache_event_task
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x169/0x550 mm/kasan/report.c:488
kasan_report+0x143/0x180 mm/kasan/report.c:601
dev_get_flags+0x188/0x1d0 net/core/dev.c:8782
rxe_query_port+0x12d/0x260 drivers/infiniband/sw/rxe/rxe_verbs.c:60
__ib_query_port drivers/infiniband/core/device.c:2111 [inline]
ib_query_port+0x168/0x7d0 drivers/infiniband/core/device.c:2143
ib_cache_update+0x1a9/0xb80 drivers/infiniband/core/cache.c:1494
ib_cache_event_task+0xf3/0x1e0 drivers/infiniband/core/cache.c:1568
process_one_work kernel/workqueue.c:3229 [inline]
process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310
worker_thread+0x870/0xd30 kernel/workqueue.c:3391
kthread+0x2f2/0x390 kernel/kthread.c:389
ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
</TASK>
"
1). In the link [1],
"
infiniband syz2: set down
"
This means that on 839.350575, the event ib_cache_event_task was sent andi
queued in ib_wq.
2). In the link [1],
"
team0 (unregistering): Port device team_slave_0 removed
"
It indicates that before 843.251853, the net device should be freed.
3). In the link [1],
"
BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0
"
This means that on 850.559070, this slab-use-after-free problem occurred.
In all, on 839.350575, the event ib_cache_event_task was sent and queued
in ib_wq,
before 843.251853, the net device veth was freed.
on 850.559070, this event was executed, and the mentioned freed net device
was called. Thus, the above call trace occurred.
[1] https://syzkaller.appspot.com/x/log.txt?x=12e7025f980000 |
["https://git.kernel.org/stable/c/2ac5415022d16d63d912a39a06f32f1f51140261","https://git.kernel.org/stable/c/9f6f54e6a6863131442b40e14d1792b090c7ce21"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57857
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/siw: Remove direct link to net_device
Do not manage a per device direct link to net_device. Rely
on associated ib_devices net_device management, not doubling
the effort locally. A badly managed local link to net_device
was causing a 'KASAN: slab-use-after-free' exception during
siw_query_port() call. |
["https://git.kernel.org/stable/c/16b87037b48889d21854c8e97aec8a1baf2642b3","https://git.kernel.org/stable/c/4eafeb4f021c50d13f199239d913b37de3c83135"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49859
|
Medium |
fixed |
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to check atomic_file in f2fs ioctl interfaces
Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(),
f2fs_move_file_range(), and f2fs_defragment_range() missed to
check atomic_write status, which may cause potential race issue,
fix it. |
["https://git.kernel.org/stable/c/10569b682ebe9c75ef06ddd322ae844e9be6374b","https://git.kernel.org/stable/c/26b07bd2e1f124b0e430c8d250023f7205c549c3","https://git.kernel.org/stable/c/7cb51731f24b216b0b87942f519f2c67a17107ee","https://git.kernel.org/stable/c/bfe5c02654261bfb8bd9cb174a67f3279ea99e58","https://git.kernel.org/stable/c/d6f08c88047accc6127dddb6798a3ff11321539d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-3714
|
Medium |
|
N/A
|
A flaw was found in the Linux kernels memory deduplication mechanism. Previous work has shown that memory deduplication can be attacked via a local exploitation mechanism. The same technique can be used if an attacker can upload page sized files and detect the change in access time from a networked service to determine if the page has been merged. |
["https://access.redhat.com/security/cve/CVE-2021-3714","https://arxiv.org/abs/2111.08553","https://arxiv.org/pdf/2111.08553.pdf","https://bugzilla.redhat.com/show_bug.cgi?id=1931327","https://access.redhat.com/security/cve/CVE-2021-3714","https://arxiv.org/abs/2111.08553","https://arxiv.org/pdf/2111.08553.pdf","https://bugzilla.redhat.com/show_bug.cgi?id=1931327"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50256
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()
I got a syzbot report without a repro [1] crashing in nf_send_reset6()
I think the issue is that dev->hard_header_len is zero, and we attempt
later to push an Ethernet header.
Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c.
[1]
skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun
kernel BUG at net/core/skbuff.c:206 !
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]
RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216
Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3
RSP: 0018:ffffc900045269b0 EFLAGS: 00010282
RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800
RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000
RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc
R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140
R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c
FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
skb_push+0xe5/0x100 net/core/skbuff.c:2636
eth_header+0x38/0x1f0 net/ethernet/eth.c:83
dev_hard_header include/linux/netdevice.h:3208 [inline]
nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358
nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48
expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288
nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161
nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626
nf_hook include/linux/netfilter.h:269 [inline]
NF_HOOK include/linux/netfilter.h:312 [inline]
br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184
nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
nf_hook_bridge_pre net/bridge/br_input.c:277 [inline]
br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424
__netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562
__netif_receive_skb_one_core net/core/dev.c:5666 [inline]
__netif_receive_skb+0x12f/0x650 net/core/dev.c:5781
netif_receive_skb_internal net/core/dev.c:5867 [inline]
netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926
tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550
tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007
tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053
new_sync_write fs/read_write.c:590 [inline]
vfs_write+0xa6d/0xc90 fs/read_write.c:683
ksys_write+0x183/0x2b0 fs/read_write.c:736
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fdbeeb7d1ff
Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48
RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff
RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8
RBP: 00007fdbeebf12be R08: 0000000
---truncated--- |
["https://git.kernel.org/stable/c/4ed234fe793f27a3b151c43d2106df2ff0d81aac","https://git.kernel.org/stable/c/4f7b586aae53c2ed820661803da8ce18b1361921","https://git.kernel.org/stable/c/f85b057e34419e5ec0583a65078a11ccc1d4540a","https://git.kernel.org/stable/c/fef63832317d9d24e1214cdd8f204d02ebdf8499"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57973
|
Medium |
fixed |
- 6.1.129
- 6.6.76
- 6.12.13
- 6.13.2
|
In the Linux kernel, the following vulnerability has been resolved:
rdma/cxgb4: Prevent potential integer overflow on 32bit
The "gl->tot_len" variable is controlled by the user. It comes from
process_responses(). On 32bit systems, the "gl->tot_len + sizeof(struct
cpl_pass_accept_req) + sizeof(struct rss_header)" addition could have an
integer wrapping bug. Use size_add() to prevent this. |
["https://git.kernel.org/stable/c/2b759f78b83221f4a1cae3aeb20b500e375f3ee6","https://git.kernel.org/stable/c/4422f452d028850b9cc4fd8f1cf45a8ff91855eb","https://git.kernel.org/stable/c/aeb814484387811b3579d5c78ad4eb301e3bf1c8","https://git.kernel.org/stable/c/bd96a3935e89486304461a21752f824fc25e0f0b","https://git.kernel.org/stable/c/d64148a10a85952352de6091ceed99fb9ce2d3ee","https://git.kernel.org/stable/c/dd352107f22bfbecbbf3b74bde14f3f932296309","https://git.kernel.org/stable/c/de8d88b68d0cfd41152a7a63d6aec0ed3e1b837a","https://git.kernel.org/stable/c/e53ca458f543aa352d09b484550de173cb9085c2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57981
|
Medium |
fixed |
- 6.1.129
- 6.6.76
- 6.12.13
- 6.13.2
|
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Fix NULL pointer dereference on certain command aborts
If a command is queued to the final usable TRB of a ring segment, the
enqueue pointer is advanced to the subsequent link TRB and no further.
If the command is later aborted, when the abort completion is handled
the dequeue pointer is advanced to the first TRB of the next segment.
If no further commands are queued, xhci_handle_stopped_cmd_ring() sees
the ring pointers unequal and assumes that there is a pending command,
so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL.
Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbell
ring likely is unnecessary too, but it's harmless. Leave it alone.
This is probably Bug 219532, but no confirmation has been received.
The issue has been independently reproduced and confirmed fixed using
a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever.
Everything continued working normally after several prevented crashes. |
["https://git.kernel.org/stable/c/0ce5c0dac768be14afe2426101b568a0f66bfc4d","https://git.kernel.org/stable/c/1e0a19912adb68a4b2b74fd77001c96cd83eb073","https://git.kernel.org/stable/c/4ff18870af793ce2034a6ad746e91d0a3d985b88","https://git.kernel.org/stable/c/ae069cd2ba09a2bd6a87a68c59ef0b7ea39cd641","https://git.kernel.org/stable/c/b44253956407046e5907d4d72c8fa5b93ae94485","https://git.kernel.org/stable/c/b649f0d5bc256f691c7d234c3986685d54053de1","https://git.kernel.org/stable/c/cf30300a216a4f8dce94e11781a866a09d4b50d4","https://git.kernel.org/stable/c/fd8bfaeba4a85b14427899adec0efb3954300653"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-58052
|
Medium |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.129
- 6.6.76
- 6.12.13
- 6.13.2
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table
The function atomctrl_get_smc_sclk_range_table() does not check the return
value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to
retrieve SMU_Info table, it returns NULL which is later dereferenced.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
In practice this should never happen as this code only gets called
on polaris chips and the vbios data table will always be present on
those chips. |
["https://git.kernel.org/stable/c/0b97cd8a61b2b40fd73cf92a4bb2256462d22adb","https://git.kernel.org/stable/c/2396bc91935c6da0588ce07850d07897974bd350","https://git.kernel.org/stable/c/357445e28ff004d7f10967aa93ddb4bffa5c3688","https://git.kernel.org/stable/c/396350adf0e5ad4bf05f01e4d79bfb82f0f6c41a","https://git.kernel.org/stable/c/6a30634a2e0f1dd3c6b39fd0f114c32893a9907a","https://git.kernel.org/stable/c/a713ba7167c2d74c477dd7764dbbdbe3199f17f4","https://git.kernel.org/stable/c/ae522ad211ec4b72eaf742b25f24b0a406afcba1","https://git.kernel.org/stable/c/c47066ed7c8f3b320ef87fa6217a2b8b24e127cc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-58058
|
Medium |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.129
- 6.6.76
- 6.12.13
- 6.13.2
|
In the Linux kernel, the following vulnerability has been resolved:
ubifs: skip dumping tnc tree when zroot is null
Clearing slab cache will free all znode in memory and make
c->zroot.znode = NULL, then dumping tnc tree will access
c->zroot.znode which cause null pointer dereference. |
["https://git.kernel.org/stable/c/1787cd67bb94b106555ffe64f887f6aa24b47010","https://git.kernel.org/stable/c/2a987950df825d0144370e700dc5fb337684ffba","https://git.kernel.org/stable/c/40e25a3c0063935763717877bb2a814c081509ff","https://git.kernel.org/stable/c/428aff8f7cfb0d9a8854477648022cef96bcab28","https://git.kernel.org/stable/c/6211c11fc20424bbc6d79c835c7c212b553ae898","https://git.kernel.org/stable/c/77e5266e3d3faa6bdcf20d9c68a8972f6aa06522","https://git.kernel.org/stable/c/bdb0ca39e0acccf6771db49c3f94ed787d05f2d7","https://git.kernel.org/stable/c/e01b55f261ccc96e347eba4931e4429d080d879d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-58063
|
Medium |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.129
- 6.6.76
- 6.12.13
- 6.13.2
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtlwifi: fix memory leaks and invalid access at probe error path
Deinitialize at reverse order when probe fails.
When init_sw_vars fails, rtl_deinit_core should not be called, specially
now that it destroys the rtl_wq workqueue.
And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be
leaked.
Remove pci_set_drvdata call as it will already be cleaned up by the core
driver code and could lead to memory leaks too. cf. commit 8d450935ae7f
("wireless: rtlwifi: remove unnecessary pci_set_drvdata()") and
commit 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory"). |
["https://git.kernel.org/stable/c/32acebca0a51f5e372536bfdc0d7d332ab749013","https://git.kernel.org/stable/c/455e0f40b5352186a9095f2135d5c89255e7c39a","https://git.kernel.org/stable/c/624cea89a0865a2bc3e00182a6b0f954a94328b4","https://git.kernel.org/stable/c/6b76bab5c257463302c9e97f5d84d524457468eb","https://git.kernel.org/stable/c/85b67b4c4a0f8a6fb20cf4ef7684ff2b0cf559df","https://git.kernel.org/stable/c/b96371339fd9cac90f5ee4ac17ee5c4cbbdfa6f7","https://git.kernel.org/stable/c/e7ceefbfd8d447abc8aca8ab993a942803522c06","https://git.kernel.org/stable/c/ee0b0d7baa8a6d42c7988f6e50c8f164cdf3fa47"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21736
|
Medium |
fixed |
- 6.1.129
- 6.6.78
- 6.12.14
- 6.13.3
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix possible int overflows in nilfs_fiemap()
Since nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its result
by being prepared to go through potentially maxblocks == INT_MAX blocks,
the value in n may experience an overflow caused by left shift of blkbits.
While it is extremely unlikely to occur, play it safe and cast right hand
expression to wider type to mitigate the issue.
Found by Linux Verification Center (linuxtesting.org) with static analysis
tool SVACE. |
["https://git.kernel.org/stable/c/250423300b4b0335918be187ef3cade248c06e6a","https://git.kernel.org/stable/c/58b1c6881081f5ddfb9a14dc241a74732c0f855c","https://git.kernel.org/stable/c/6438ef381c183444f7f9d1de18f22661cba1e946","https://git.kernel.org/stable/c/7649937987fed51ed09985da4019d50189fc534e","https://git.kernel.org/stable/c/8f41df5fd4c11d26e929a85f7239799641f92da7","https://git.kernel.org/stable/c/b9495a9109abc31d3170f7aad7d48aa64610a1a2","https://git.kernel.org/stable/c/f2bd0f1ab47822fe5bd699c8458b896c4b2edea1","https://git.kernel.org/stable/c/f3d80f34f58445355fa27b9579a449fb186aa64e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21744
|
Medium |
fixed |
- 6.1.129
- 6.6.78
- 6.12.14
- 6.13.3
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()
On removal of the device or unloading of the kernel module a potential NULL
pointer dereference occurs.
The following sequence deletes the interface:
brcmf_detach()
brcmf_remove_interface()
brcmf_del_if()
Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated to
BRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.
After brcmf_remove_interface() call the brcmf_proto_detach() function is
called providing the following sequence:
brcmf_detach()
brcmf_proto_detach()
brcmf_proto_msgbuf_detach()
brcmf_flowring_detach()
brcmf_msgbuf_delete_flowring()
brcmf_msgbuf_remove_flowring()
brcmf_flowring_delete()
brcmf_get_ifp()
brcmf_txfinalize()
Since brcmf_get_ip() can and actually will return NULL in this case the
call to brcmf_txfinalize() will result in a NULL pointer dereference inside
brcmf_txfinalize() when trying to update ifp->ndev->stats.tx_errors.
This will only happen if a flowring still has an skb.
Although the NULL pointer dereference has only been seen when trying to
update the tx statistic, all other uses of the ifp pointer have been
guarded as well with an early return if ifp is NULL. |
["https://git.kernel.org/stable/c/2326e19190e176fd72bb542b837a9d2b7fcb8693","https://git.kernel.org/stable/c/3877fc67bd3d5566cc12763bce39710ceb74a97d","https://git.kernel.org/stable/c/4e51d6d093e763348916e69d06d87e0a5593661b","https://git.kernel.org/stable/c/59ff4fa653ff6db07c61152516ffba79c2a74bda","https://git.kernel.org/stable/c/61541d9b5a23df33934fcc620a3a81f246b1b240","https://git.kernel.org/stable/c/68abd0c4ebf24cd499841a488b97a6873d5efabb","https://git.kernel.org/stable/c/a2beefc4fa49ebc22e664dc6b39dbd054f8488f9","https://git.kernel.org/stable/c/fbbfef2a5b858eab55741a58b2ac9a0cc8d53c58"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21776
|
Medium |
fixed |
- 6.1.129
- 6.6.79
- 6.12.16
- 6.13.4
|
In the Linux kernel, the following vulnerability has been resolved:
USB: hub: Ignore non-compliant devices with too many configs or interfaces
Robert Morris created a test program which can cause
usb_hub_to_struct_hub() to dereference a NULL or inappropriate
pointer:
Oops: general protection fault, probably for non-canonical address
0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTI
CPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14
Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021
Workqueue: usb_hub_wq hub_event
RIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110
...
Call Trace:
<TASK>
? die_addr+0x31/0x80
? exc_general_protection+0x1b4/0x3c0
? asm_exc_general_protection+0x26/0x30
? usb_hub_adjust_deviceremovable+0x78/0x110
hub_probe+0x7c7/0xab0
usb_probe_interface+0x14b/0x350
really_probe+0xd0/0x2d0
? __pfx___device_attach_driver+0x10/0x10
__driver_probe_device+0x6e/0x110
driver_probe_device+0x1a/0x90
__device_attach_driver+0x7e/0xc0
bus_for_each_drv+0x7f/0xd0
__device_attach+0xaa/0x1a0
bus_probe_device+0x8b/0xa0
device_add+0x62e/0x810
usb_set_configuration+0x65d/0x990
usb_generic_driver_probe+0x4b/0x70
usb_probe_device+0x36/0xd0
The cause of this error is that the device has two interfaces, and the
hub driver binds to interface 1 instead of interface 0, which is where
usb_hub_to_struct_hub() looks.
We can prevent the problem from occurring by refusing to accept hub
devices that violate the USB spec by having more than one
configuration or interface. |
["https://git.kernel.org/stable/c/2240fed37afbcdb5e8b627bc7ad986891100e05d","https://git.kernel.org/stable/c/49f077106fa07919a6a6dda99bb490dd1d1a8218","https://git.kernel.org/stable/c/5b9778e1fe715700993ce436c152dc3b7df0b490","https://git.kernel.org/stable/c/62d8f4c5454dd39aded4f343720d1c5a1803cfef","https://git.kernel.org/stable/c/c3720b04df84b5459050ae4e03ec7d545652f897","https://git.kernel.org/stable/c/d343fe0fad5c1d689775f2dda24a85ce98e29566","https://git.kernel.org/stable/c/d3a67adb365cdfdac4620daf38a82e57ca45806c","https://git.kernel.org/stable/c/e905a0fca7bff0855d312c16f71e60e1773b393e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21787
|
Medium |
fixed |
- 6.1.129
- 6.6.79
- 6.12.16
- 6.13.4
|
In the Linux kernel, the following vulnerability has been resolved:
team: better TEAM_OPTION_TYPE_STRING validation
syzbot reported following splat [1]
Make sure user-provided data contains one nul byte.
[1]
BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:633 [inline]
BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714
string_nocheck lib/vsprintf.c:633 [inline]
string+0x3ec/0x5f0 lib/vsprintf.c:714
vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843
__request_module+0x252/0x9f0 kernel/module/kmod.c:149
team_mode_get drivers/net/team/team_core.c:480 [inline]
team_change_mode drivers/net/team/team_core.c:607 [inline]
team_mode_option_set+0x437/0x970 drivers/net/team/team_core.c:1401
team_option_set drivers/net/team/team_core.c:375 [inline]
team_nl_options_set_doit+0x1339/0x1f90 drivers/net/team/team_core.c:2662
genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]
genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]
genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210
netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2543
genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219
netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline]
netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1348
netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1892
sock_sendmsg_nosec net/socket.c:718 [inline]
__sock_sendmsg+0x30f/0x380 net/socket.c:733
____sys_sendmsg+0x877/0xb60 net/socket.c:2573
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2627
__sys_sendmsg net/socket.c:2659 [inline]
__do_sys_sendmsg net/socket.c:2664 [inline]
__se_sys_sendmsg net/socket.c:2662 [inline]
__x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2662
x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f |
["https://git.kernel.org/stable/c/4236bf4716589558cc0f3c3612642b2c2141b04e","https://git.kernel.org/stable/c/4512482e4805dd30bc77dec511f2a2edba5cb868","https://git.kernel.org/stable/c/5bef3ac184b5626ea62385d6b82a1992b89d7940","https://git.kernel.org/stable/c/7c30483d0f6bdb2230e10e3e4be5167927eac7a0","https://git.kernel.org/stable/c/7f5af50f3aa0af8cbef9fb76fffeed69e8143f59","https://git.kernel.org/stable/c/8401cade1918281177974b32c925afdce750d292","https://git.kernel.org/stable/c/d071a91fa614ecdf760c29f61f6a7bfb7df796d6","https://git.kernel.org/stable/c/f443687ad20c70320d1248f35f57bf46cac8df0a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21846
|
Medium |
fixed |
- 6.1.130
- 6.6.80
- 6.12.17
- 6.13.5
|
In the Linux kernel, the following vulnerability has been resolved:
acct: perform last write from workqueue
In [1] it was reported that the acct(2) system call can be used to
trigger NULL deref in cases where it is set to write to a file that
triggers an internal lookup. This can e.g., happen when pointing acc(2)
to /sys/power/resume. At the point the where the write to this file
happens the calling task has already exited and called exit_fs(). A
lookup will thus trigger a NULL-deref when accessing current->fs.
Reorganize the code so that the the final write happens from the
workqueue but with the caller's credentials. This preserves the
(strange) permission model and has almost no regression risk.
This api should stop to exist though. |
["https://git.kernel.org/stable/c/56d5f3eba3f5de0efdd556de4ef381e109b973a9","https://git.kernel.org/stable/c/5a59ced8ffc71973d42c82484a719c8f6ac8f7f7","https://git.kernel.org/stable/c/5c928e14a2ccd99462f2351ead627b58075bb736","https://git.kernel.org/stable/c/5d5b936cfa4b0d5670ca7420ef165a074bc008eb","https://git.kernel.org/stable/c/5ee8da9bea70dda492d61f075658939af33d8410","https://git.kernel.org/stable/c/8acbf4a88c6a98c8ed00afd1a7d1abcca9b4735e","https://git.kernel.org/stable/c/a8136afca090412a36429cb6c2543c714d9c0f84","https://git.kernel.org/stable/c/b03782ae707cc45e65242c7cddd8e28f1c22cde5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21866
|
Medium |
fixed |
- 6.1.130
- 6.6.80
- 6.12.17
- 6.13.5
|
In the Linux kernel, the following vulnerability has been resolved:
powerpc/code-patching: Fix KASAN hit by not flagging text patching area as VM_ALLOC
Erhard reported the following KASAN hit while booting his PowerMac G4
with a KASAN-enabled kernel 6.13-rc6:
BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8
Write of size 8 at addr f1000000 by task chronyd/1293
CPU: 0 UID: 123 PID: 1293 Comm: chronyd Tainted: G W 6.13.0-rc6-PMacG4 #2
Tainted: [W]=WARN
Hardware name: PowerMac3,6 7455 0x80010303 PowerMac
Call Trace:
[c2437590] [c1631a84] dump_stack_lvl+0x70/0x8c (unreliable)
[c24375b0] [c0504998] print_report+0xdc/0x504
[c2437610] [c050475c] kasan_report+0xf8/0x108
[c2437690] [c0505a3c] kasan_check_range+0x24/0x18c
[c24376a0] [c03fb5e4] copy_to_kernel_nofault+0xd8/0x1c8
[c24376c0] [c004c014] patch_instructions+0x15c/0x16c
[c2437710] [c00731a8] bpf_arch_text_copy+0x60/0x7c
[c2437730] [c0281168] bpf_jit_binary_pack_finalize+0x50/0xac
[c2437750] [c0073cf4] bpf_int_jit_compile+0xb30/0xdec
[c2437880] [c0280394] bpf_prog_select_runtime+0x15c/0x478
[c24378d0] [c1263428] bpf_prepare_filter+0xbf8/0xc14
[c2437990] [c12677ec] bpf_prog_create_from_user+0x258/0x2b4
[c24379d0] [c027111c] do_seccomp+0x3dc/0x1890
[c2437ac0] [c001d8e0] system_call_exception+0x2dc/0x420
[c2437f30] [c00281ac] ret_from_syscall+0x0/0x2c
--- interrupt: c00 at 0x5a1274
NIP: 005a1274 LR: 006a3b3c CTR: 005296c8
REGS: c2437f40 TRAP: 0c00 Tainted: G W (6.13.0-rc6-PMacG4)
MSR: 0200f932 <VEC,EE,PR,FP,ME,IR,DR,RI> CR: 24004422 XER: 00000000
GPR00: 00000166 af8f3fa0 a7ee3540 00000001 00000000 013b6500 005a5858 0200f932
GPR08: 00000000 00001fe9 013d5fc8 005296c8 2822244c 00b2fcd8 00000000 af8f4b57
GPR16: 00000000 00000001 00000000 00000000 00000000 00000001 00000000 00000002
GPR24: 00afdbb0 00000000 00000000 00000000 006e0004 013ce060 006e7c1c 00000001
NIP [005a1274] 0x5a1274
LR [006a3b3c] 0x6a3b3c
--- interrupt: c00
The buggy address belongs to the virtual mapping at
[f1000000, f1002000) created by:
text_area_cpu_up+0x20/0x190
The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x76e30
flags: 0x80000000(zone=2)
raw: 80000000 00000000 00000122 00000000 00000000 00000000 ffffffff 00000001
raw: 00000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
f0ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>f1000000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
^
f1000080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
f1000100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
==================================================================
f8 corresponds to KASAN_VMALLOC_INVALID which means the area is not
initialised hence not supposed to be used yet.
Powerpc text patching infrastructure allocates a virtual memory area
using get_vm_area() and flags it as VM_ALLOC. But that flag is meant
to be used for vmalloc() and vmalloc() allocated memory is not
supposed to be used before a call to __vmalloc_node_range() which is
never called for that area.
That went undetected until commit e4137f08816b ("mm, kasan, kmsan:
instrument copy_from/to_kernel_nofault")
The area allocated by text_area_cpu_up() is not vmalloc memory, it is
mapped directly on demand when needed by map_kernel_page(). There is
no VM flag corresponding to such usage, so just pass no flag. That way
the area will be unpoisonned and usable immediately. |
["https://git.kernel.org/stable/c/2d542f13d26344e3452eee77613026ce9b653065","https://git.kernel.org/stable/c/2e6c80423f201405fd65254e52decd21663896f3","https://git.kernel.org/stable/c/6847b3e40bb963e57b61d1cc6fe84cb37b9d3d4c","https://git.kernel.org/stable/c/8d06e9208184b2851fa79a3a39d6860320c8bdf8","https://git.kernel.org/stable/c/97de5852058a299ba447cd9782fe96488d30108b","https://git.kernel.org/stable/c/c905a3053518212a1017e50bd2be3bee59305bb0","https://git.kernel.org/stable/c/d262a192d38e527faa5984629aabda2e0d1c4f54","https://git.kernel.org/stable/c/f8d4c5b653c1bc0df56e15658bbf64fc359adc4e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26960
|
Medium |
fixed |
- 5.10.215
- 5.15.154
- 6.1.84
- 6.6.24
- 6.7.12
- 6.8.3
|
In the Linux kernel, the following vulnerability has been resolved:
mm: swap: fix race between free_swap_and_cache() and swapoff()
There was previously a theoretical window where swapoff() could run and
teardown a swap_info_struct while a call to free_swap_and_cache() was
running in another thread. This could cause, amongst other bad
possibilities, swap_page_trans_huge_swapped() (called by
free_swap_and_cache()) to access the freed memory for swap_map.
This is a theoretical problem and I haven't been able to provoke it from a
test case. But there has been agreement based on code review that this is
possible (see link below).
Fix it by using get_swap_device()/put_swap_device(), which will stall
swapoff(). There was an extra check in _swap_info_get() to confirm that
the swap entry was not free. This isn't present in get_swap_device()
because it doesn't make sense in general due to the race between getting
the reference and swapoff. So I've added an equivalent check directly in
free_swap_and_cache().
Details of how to provoke one possible issue (thanks to David Hildenbrand
for deriving this):
--8<-----
__swap_entry_free() might be the last user and result in
"count == SWAP_HAS_CACHE".
swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0.
So the question is: could someone reclaim the folio and turn
si->inuse_pages==0, before we completed swap_page_trans_huge_swapped().
Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are
still references by swap entries.
Process 1 still references subpage 0 via swap entry.
Process 2 still references subpage 1 via swap entry.
Process 1 quits. Calls free_swap_and_cache().
-> count == SWAP_HAS_CACHE
[then, preempted in the hypervisor etc.]
Process 2 quits. Calls free_swap_and_cache().
-> count == SWAP_HAS_CACHE
Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls
__try_to_reclaim_swap().
__try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()->
put_swap_folio()->free_swap_slot()->swapcache_free_entries()->
swap_entry_free()->swap_range_free()->
...
WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries);
What stops swapoff to succeed after process 2 reclaimed the swap cache
but before process1 finished its call to swap_page_trans_huge_swapped()?
--8<----- |
["https://git.kernel.org/stable/c/0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a","https://git.kernel.org/stable/c/1ede7f1d7eed1738d1b9333fd1e152ccb450b86a","https://git.kernel.org/stable/c/2da5568ee222ce0541bfe446a07998f92ed1643e","https://git.kernel.org/stable/c/363d17e7f7907c8e27a9e86968af0eaa2301787b","https://git.kernel.org/stable/c/3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39","https://git.kernel.org/stable/c/82b1c07a0af603e3c47b906c8e991dc96f01688e","https://git.kernel.org/stable/c/d85c11c97ecf92d47a4b29e3faca714dc1f18d0d","https://git.kernel.org/stable/c/0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a","https://git.kernel.org/stable/c/1ede7f1d7eed1738d1b9333fd1e152ccb450b86a","https://git.kernel.org/stable/c/2da5568ee222ce0541bfe446a07998f92ed1643e","https://git.kernel.org/stable/c/363d17e7f7907c8e27a9e86968af0eaa2301787b","https://git.kernel.org/stable/c/3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39","https://git.kernel.org/stable/c/82b1c07a0af603e3c47b906c8e991dc96f01688e","https://git.kernel.org/stable/c/d85c11c97ecf92d47a4b29e3faca714dc1f18d0d","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27072
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
media: usbtv: Remove useless locks in usbtv_video_free()
Remove locks calls in usbtv_video_free() because
are useless and may led to a deadlock as reported here:
https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000
Also remove usbtv_stop() call since it will be called when
unregistering the device.
Before 'c838530d230b' this issue would only be noticed if you
disconnect while streaming and now it is noticeable even when
disconnecting while not streaming.
[hverkuil: fix minor spelling mistake in log message] |
["https://git.kernel.org/stable/c/3e7d82ebb86e94643bdb30b0b5b077ed27dce1c2","https://git.kernel.org/stable/c/4ec4641df57cbdfdc51bb4959afcdbcf5003ddb9","https://git.kernel.org/stable/c/65e6a2773d655172143cc0b927cdc89549842895","https://git.kernel.org/stable/c/bdd82c47b22a8befd617b723098b2a41b77373c7","https://git.kernel.org/stable/c/d5ed208d04acf06781d63d30f9fa991e8d609ebd","https://git.kernel.org/stable/c/dea46e246ef0f98d89d59a4229157cd9ffb636bf","https://git.kernel.org/stable/c/3e7d82ebb86e94643bdb30b0b5b077ed27dce1c2","https://git.kernel.org/stable/c/65e6a2773d655172143cc0b927cdc89549842895"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35895
|
Medium |
fixed |
- 5.4.274
- 5.10.215
- 5.15.154
- 6.1.85
- 6.6.26
- 6.8.5
|
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Prevent lock inversion deadlock in map delete elem
syzkaller started using corpuses where a BPF tracing program deletes
elements from a sockmap/sockhash map. Because BPF tracing programs can be
invoked from any interrupt context, locks taken during a map_delete_elem
operation must be hardirq-safe. Otherwise a deadlock due to lock inversion
is possible, as reported by lockdep:
CPU0 CPU1
---- ----
lock(&htab->buckets[i].lock);
local_irq_disable();
lock(&host->lock);
lock(&htab->buckets[i].lock);
<Interrupt>
lock(&host->lock);
Locks in sockmap are hardirq-unsafe by design. We expects elements to be
deleted from sockmap/sockhash only in task (normal) context with interrupts
enabled, or in softirq context.
Detect when map_delete_elem operation is invoked from a context which is
_not_ hardirq-unsafe, that is interrupts are disabled, and bail out with an
error.
Note that map updates are not affected by this issue. BPF verifier does not
allow updating sockmap/sockhash from a BPF tracing program today. |
["https://git.kernel.org/stable/c/668b3074aa14829e2ac2759799537a93b60fef86","https://git.kernel.org/stable/c/6af057ccdd8e7619960aca1f0428339f213b31cd","https://git.kernel.org/stable/c/a44770fed86515eedb5a7c00b787f847ebb134a5","https://git.kernel.org/stable/c/d1e73fb19a4c872d7a399ad3c66e8ca30e0875ec","https://git.kernel.org/stable/c/dd54b48db0c822ae7b520bc80751f0a0a173ef75","https://git.kernel.org/stable/c/f7990498b05ac41f7d6a190dc0418ef1d21bf058","https://git.kernel.org/stable/c/ff91059932401894e6c86341915615c5eb0eca48","https://git.kernel.org/stable/c/668b3074aa14829e2ac2759799537a93b60fef86","https://git.kernel.org/stable/c/6af057ccdd8e7619960aca1f0428339f213b31cd","https://git.kernel.org/stable/c/a44770fed86515eedb5a7c00b787f847ebb134a5","https://git.kernel.org/stable/c/d1e73fb19a4c872d7a399ad3c66e8ca30e0875ec","https://git.kernel.org/stable/c/dd54b48db0c822ae7b520bc80751f0a0a173ef75","https://git.kernel.org/stable/c/f7990498b05ac41f7d6a190dc0418ef1d21bf058","https://git.kernel.org/stable/c/ff91059932401894e6c86341915615c5eb0eca48","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35990
|
Medium |
fixed |
- 5.10.216
- 5.15.158
- 6.1.90
- 6.6.30
- 6.8.9
|
In the Linux kernel, the following vulnerability has been resolved:
dma: xilinx_dpdma: Fix locking
There are several places where either chan->lock or chan->vchan.lock was
not held. Add appropriate locking. This fixes lockdep warnings like
[ 31.077578] ------------[ cut here ]------------
[ 31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0
[ 31.077953] Modules linked in:
[ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98
[ 31.078102] Hardware name: xlnx,zynqmp (DT)
[ 31.078169] Workqueue: events_unbound deferred_probe_work_func
[ 31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0
[ 31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0
[ 31.078550] sp : ffffffc083bb2e10
[ 31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168
[ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480
[ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000
[ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000
[ 31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001
[ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def
[ 31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516
[ 31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff
[ 31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000
[ 31.080307] Call trace:
[ 31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0
[ 31.080518] xilinx_dpdma_issue_pending+0x11c/0x120
[ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac
[ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c
[ 31.080825] drm_atomic_helper_commit_planes+0x20c/0x684
[ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0
[ 31.081139] commit_tail+0x234/0x294
[ 31.081246] drm_atomic_helper_commit+0x1f8/0x210
[ 31.081363] drm_atomic_commit+0x100/0x140
[ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384
[ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c
[ 31.081725] drm_client_modeset_commit+0x34/0x5c
[ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168
[ 31.081899] drm_fb_helper_set_par+0x50/0x70
[ 31.081971] fbcon_init+0x538/0xc48
[ 31.082047] visual_init+0x16c/0x23c
[ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634
[ 31.082320] do_take_over_console+0x24c/0x33c
[ 31.082429] do_fbcon_takeover+0xbc/0x1b0
[ 31.082503] fbcon_fb_registered+0x2d0/0x34c
[ 31.082663] register_framebuffer+0x27c/0x38c
[ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c
[ 31.082939] drm_fb_helper_initial_config+0x50/0x74
[ 31.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108
[ 31.083115] drm_client_register+0xa0/0xf4
[ 31.083195] drm_fbdev_dma_setup+0xb0/0x1cc
[ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0
[ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0
[ 31.083616] platform_probe+0x8c/0x13c
[ 31.083713] really_probe+0x258/0x59c
[ 31.083793] __driver_probe_device+0xc4/0x224
[ 31.083878] driver_probe_device+0x70/0x1c0
[ 31.083961] __device_attach_driver+0x108/0x1e0
[ 31.084052] bus_for_each_drv+0x9c/0x100
[ 31.084125] __device_attach+0x100/0x298
[ 31.084207] device_initial_probe+0x14/0x20
[ 31.084292] bus_probe_device+0xd8/0xdc
[ 31.084368] deferred_probe_work_func+0x11c/0x180
[ 31.084451] process_one_work+0x3ac/0x988
[ 31.084643] worker_thread+0x398/0x694
[ 31.084752] kthread+0x1bc/0x1c0
[ 31.084848] ret_from_fork+0x10/0x20
[ 31.084932] irq event stamp: 64549
[ 31.084970] hardirqs last enabled at (64548): [<ffffffc081adf35c>] _raw_spin_unlock_irqrestore+0x80/0x90
[ 31.085157]
---truncated--- |
["https://git.kernel.org/stable/c/0ccac964520a6f19e355652c8ca38af2a7f27076","https://git.kernel.org/stable/c/244296cc3a155199a8b080d19e645d7d49081a38","https://git.kernel.org/stable/c/8bf574183282d219cfa991f7df37aad491d74c11","https://git.kernel.org/stable/c/8e3c94767cad5150198e4337c8b91f3bb068e14b","https://git.kernel.org/stable/c/c660be571609e03e7d5972343536a736fcb31557","https://git.kernel.org/stable/c/fcdd5bb4a8c81c64c1334d7e0aba41a8829a24de","https://git.kernel.org/stable/c/0ccac964520a6f19e355652c8ca38af2a7f27076","https://git.kernel.org/stable/c/244296cc3a155199a8b080d19e645d7d49081a38","https://git.kernel.org/stable/c/8bf574183282d219cfa991f7df37aad491d74c11","https://git.kernel.org/stable/c/8e3c94767cad5150198e4337c8b91f3bb068e14b","https://git.kernel.org/stable/c/c660be571609e03e7d5972343536a736fcb31557","https://git.kernel.org/stable/c/fcdd5bb4a8c81c64c1334d7e0aba41a8829a24de","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38591
|
Medium |
fixed |
- 5.15.161
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix deadlock on SRQ async events.
xa_lock for SRQ table may be required in AEQ. Use xa_store_irq()/
xa_erase_irq() to avoid deadlock. |
["https://git.kernel.org/stable/c/22c915af31bd84ffaa46145e317f53333f94a868","https://git.kernel.org/stable/c/4a3be1a0ffe04c085dd7f79be97c91b0c786df3d","https://git.kernel.org/stable/c/605889754ee68aacf7c381938fcd5eb654e71822","https://git.kernel.org/stable/c/72dc542f0d8977e7d41d610db6bb65c47cad43e9","https://git.kernel.org/stable/c/756ddbe665ea7f9416951bd76731b174d136eea0","https://git.kernel.org/stable/c/b46494b6f9c19f141114a57729e198698f40af37","https://git.kernel.org/stable/c/d271e66abac5c7eb8de345b9b44d89f777437a4c","https://git.kernel.org/stable/c/22c915af31bd84ffaa46145e317f53333f94a868","https://git.kernel.org/stable/c/4a3be1a0ffe04c085dd7f79be97c91b0c786df3d","https://git.kernel.org/stable/c/72dc542f0d8977e7d41d610db6bb65c47cad43e9","https://git.kernel.org/stable/c/756ddbe665ea7f9416951bd76731b174d136eea0","https://git.kernel.org/stable/c/b46494b6f9c19f141114a57729e198698f40af37","https://git.kernel.org/stable/c/d271e66abac5c7eb8de345b9b44d89f777437a4c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42090
|
Medium |
fixed |
- 4.19.317
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.97
- 6.6.37
- 6.9.8
|
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER
In create_pinctrl(), pinctrl_maps_mutex is acquired before calling
add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()
calls pinctrl_free(). However, pinctrl_free() attempts to acquire
pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to
a potential deadlock.
This patch resolves the issue by releasing pinctrl_maps_mutex before
calling pinctrl_free(), preventing the deadlock.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc. |
["https://git.kernel.org/stable/c/01fe2f885f7813f8aed5d3704b384a97b1116a9e","https://git.kernel.org/stable/c/4038c57bf61631219b31f1bd6e92106ec7f084dc","https://git.kernel.org/stable/c/420ce1261907e5dbeda1e4daffd5b6c76f8188c0","https://git.kernel.org/stable/c/48a7a7c9571c3e62f17012dd7f2063e926179ddd","https://git.kernel.org/stable/c/adec57ff8e66aee632f3dd1f93787c13d112b7a1","https://git.kernel.org/stable/c/b36efd2e3e22a329444b6b24fa48df6d20ae66e6","https://git.kernel.org/stable/c/b813e3fd102a959c5b208ed68afe27e0137a561b","https://git.kernel.org/stable/c/e65a0dc2e85efb28e182aca50218e8a056d0ce04","https://git.kernel.org/stable/c/01fe2f885f7813f8aed5d3704b384a97b1116a9e","https://git.kernel.org/stable/c/4038c57bf61631219b31f1bd6e92106ec7f084dc","https://git.kernel.org/stable/c/420ce1261907e5dbeda1e4daffd5b6c76f8188c0","https://git.kernel.org/stable/c/48a7a7c9571c3e62f17012dd7f2063e926179ddd","https://git.kernel.org/stable/c/adec57ff8e66aee632f3dd1f93787c13d112b7a1","https://git.kernel.org/stable/c/b36efd2e3e22a329444b6b24fa48df6d20ae66e6","https://git.kernel.org/stable/c/b813e3fd102a959c5b208ed68afe27e0137a561b","https://git.kernel.org/stable/c/e65a0dc2e85efb28e182aca50218e8a056d0ce04"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52912
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fixed bug on error when unloading amdgpu
Fixed bug on error when unloading amdgpu.
The error message is as follows:
[ 377.706202] kernel BUG at drivers/gpu/drm/drm_buddy.c:278!
[ 377.706215] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[ 377.706222] CPU: 4 PID: 8610 Comm: modprobe Tainted: G IOE 6.0.0-thomas #1
[ 377.706231] Hardware name: ASUS System Product Name/PRIME Z390-A, BIOS 2004 11/02/2021
[ 377.706238] RIP: 0010:drm_buddy_free_block+0x26/0x30 [drm_buddy]
[ 377.706264] Code: 00 00 00 90 0f 1f 44 00 00 48 8b 0e 89 c8 25 00 0c 00 00 3d 00 04 00 00 75 10 48 8b 47 18 48 d3 e0 48 01 47 28 e9 fa fe ff ff <0f> 0b 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 55 48 89 f5 53
[ 377.706282] RSP: 0018:ffffad2dc4683cb8 EFLAGS: 00010287
[ 377.706289] RAX: 0000000000000000 RBX: ffff8b1743bd5138 RCX: 0000000000000000
[ 377.706297] RDX: ffff8b1743bd5160 RSI: ffff8b1743bd5c78 RDI: ffff8b16d1b25f70
[ 377.706304] RBP: ffff8b1743bd59e0 R08: 0000000000000001 R09: 0000000000000001
[ 377.706311] R10: ffff8b16c8572400 R11: ffffad2dc4683cf0 R12: ffff8b16d1b25f70
[ 377.706318] R13: ffff8b16d1b25fd0 R14: ffff8b1743bd59c0 R15: ffff8b16d1b25f70
[ 377.706325] FS: 00007fec56c72c40(0000) GS:ffff8b1836500000(0000) knlGS:0000000000000000
[ 377.706334] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 377.706340] CR2: 00007f9b88c1ba50 CR3: 0000000110450004 CR4: 00000000003706e0
[ 377.706347] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 377.706354] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 377.706361] Call Trace:
[ 377.706365] <TASK>
[ 377.706369] drm_buddy_free_list+0x2a/0x60 [drm_buddy]
[ 377.706376] amdgpu_vram_mgr_fini+0xea/0x180 [amdgpu]
[ 377.706572] amdgpu_ttm_fini+0x12e/0x1a0 [amdgpu]
[ 377.706650] amdgpu_bo_fini+0x22/0x90 [amdgpu]
[ 377.706727] gmc_v11_0_sw_fini+0x26/0x30 [amdgpu]
[ 377.706821] amdgpu_device_fini_sw+0xa1/0x3c0 [amdgpu]
[ 377.706897] amdgpu_driver_release_kms+0x12/0x30 [amdgpu]
[ 377.706975] drm_dev_release+0x20/0x40 [drm]
[ 377.707006] release_nodes+0x35/0xb0
[ 377.707014] devres_release_all+0x8b/0xc0
[ 377.707020] device_unbind_cleanup+0xe/0x70
[ 377.707027] device_release_driver_internal+0xee/0x160
[ 377.707033] driver_detach+0x44/0x90
[ 377.707039] bus_remove_driver+0x55/0xe0
[ 377.707045] pci_unregister_driver+0x3b/0x90
[ 377.707052] amdgpu_exit+0x11/0x6c [amdgpu]
[ 377.707194] __x64_sys_delete_module+0x142/0x2b0
[ 377.707201] ? fpregs_assert_state_consistent+0x22/0x50
[ 377.707208] ? exit_to_user_mode_prepare+0x3e/0x190
[ 377.707215] do_syscall_64+0x38/0x90
[ 377.707221] entry_SYSCALL_64_after_hwframe+0x63/0xcd |
["https://git.kernel.org/stable/c/9196eb7c52e55749a332974f0081f77d53d60199","https://git.kernel.org/stable/c/99f1a36c90a7524972be5a028424c57fa17753ee"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43886
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add null check in resource_log_pipe_topology_update
[WHY]
When switching from "Extend" to "Second Display Only" we sometimes
call resource_get_otg_master_for_stream on a stream for the eDP,
which is disconnected. This leads to a null pointer dereference.
[HOW]
Added a null check in dc_resource.c/resource_log_pipe_topology_update. |
["https://git.kernel.org/stable/c/899d92fd26fe780aad711322aa671f68058207a6","https://git.kernel.org/stable/c/c36e922a36bdf69765c340a0857ca74092003bee"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43899
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix null pointer deref in dcn20_resource.c
Fixes a hang thats triggered when MPV is run on a DCN401 dGPU:
mpv --hwdec=vaapi --vo=gpu --hwdec-codecs=all
and then enabling fullscreen playback (double click on the video)
The following calltrace will be seen:
[ 181.843989] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 181.843997] #PF: supervisor instruction fetch in kernel mode
[ 181.844003] #PF: error_code(0x0010) - not-present page
[ 181.844009] PGD 0 P4D 0
[ 181.844020] Oops: 0010 [#1] PREEMPT SMP NOPTI
[ 181.844028] CPU: 6 PID: 1892 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu
[ 181.844038] Hardware name: System manufacturer System Product Name/CROSSHAIR VI HERO, BIOS 6302 10/23/2018
[ 181.844044] RIP: 0010:0x0
[ 181.844079] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
[ 181.844084] RSP: 0018:ffffb593c2b8f7b0 EFLAGS: 00010246
[ 181.844093] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004
[ 181.844099] RDX: ffffb593c2b8f804 RSI: ffffb593c2b8f7e0 RDI: ffff9e3c8e758400
[ 181.844105] RBP: ffffb593c2b8f7b8 R08: ffffb593c2b8f9c8 R09: ffffb593c2b8f96c
[ 181.844110] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb593c2b8f9c8
[ 181.844115] R13: 0000000000000001 R14: ffff9e3c88000000 R15: 0000000000000005
[ 181.844121] FS: 00007c6e323bb5c0(0000) GS:ffff9e3f85f80000(0000) knlGS:0000000000000000
[ 181.844128] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 181.844134] CR2: ffffffffffffffd6 CR3: 0000000140fbe000 CR4: 00000000003506e0
[ 181.844141] Call Trace:
[ 181.844146] <TASK>
[ 181.844153] ? show_regs+0x6d/0x80
[ 181.844167] ? __die+0x24/0x80
[ 181.844179] ? page_fault_oops+0x99/0x1b0
[ 181.844192] ? do_user_addr_fault+0x31d/0x6b0
[ 181.844204] ? exc_page_fault+0x83/0x1b0
[ 181.844216] ? asm_exc_page_fault+0x27/0x30
[ 181.844237] dcn20_get_dcc_compression_cap+0x23/0x30 [amdgpu]
[ 181.845115] amdgpu_dm_plane_validate_dcc.constprop.0+0xe5/0x180 [amdgpu]
[ 181.845985] amdgpu_dm_plane_fill_plane_buffer_attributes+0x300/0x580 [amdgpu]
[ 181.846848] fill_dc_plane_info_and_addr+0x258/0x350 [amdgpu]
[ 181.847734] fill_dc_plane_attributes+0x162/0x350 [amdgpu]
[ 181.848748] dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu]
[ 181.849791] ? dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu]
[ 181.850840] amdgpu_dm_atomic_check+0xdfe/0x1760 [amdgpu] |
["https://git.kernel.org/stable/c/974fccd61758599a9716c4b909d9226749efe37e","https://git.kernel.org/stable/c/ecbf60782662f0a388493685b85a645a0ba1613c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43901
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix NULL pointer dereference for DTN log in DCN401
When users run the command:
cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log
The following NULL pointer dereference happens:
[ +0.000003] BUG: kernel NULL pointer dereference, address: NULL
[ +0.000005] #PF: supervisor instruction fetch in kernel mode
[ +0.000002] #PF: error_code(0x0010) - not-present page
[ +0.000002] PGD 0 P4D 0
[ +0.000004] Oops: 0010 [#1] PREEMPT SMP NOPTI
[ +0.000003] RIP: 0010:0x0
[ +0.000008] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
[...]
[ +0.000002] PKRU: 55555554
[ +0.000002] Call Trace:
[ +0.000002] <TASK>
[ +0.000003] ? show_regs+0x65/0x70
[ +0.000006] ? __die+0x24/0x70
[ +0.000004] ? page_fault_oops+0x160/0x470
[ +0.000006] ? do_user_addr_fault+0x2b5/0x690
[ +0.000003] ? prb_read_valid+0x1c/0x30
[ +0.000005] ? exc_page_fault+0x8c/0x1a0
[ +0.000005] ? asm_exc_page_fault+0x27/0x30
[ +0.000012] dcn10_log_color_state+0xf9/0x510 [amdgpu]
[ +0.000306] ? srso_alias_return_thunk+0x5/0xfbef5
[ +0.000003] ? vsnprintf+0x2fb/0x600
[ +0.000009] dcn10_log_hw_state+0xfd0/0xfe0 [amdgpu]
[ +0.000218] ? __mod_memcg_lruvec_state+0xe8/0x170
[ +0.000008] ? srso_alias_return_thunk+0x5/0xfbef5
[ +0.000002] ? debug_smp_processor_id+0x17/0x20
[ +0.000003] ? srso_alias_return_thunk+0x5/0xfbef5
[ +0.000002] ? srso_alias_return_thunk+0x5/0xfbef5
[ +0.000002] ? set_ptes.isra.0+0x2b/0x90
[ +0.000004] ? srso_alias_return_thunk+0x5/0xfbef5
[ +0.000002] ? _raw_spin_unlock+0x19/0x40
[ +0.000004] ? srso_alias_return_thunk+0x5/0xfbef5
[ +0.000002] ? do_anonymous_page+0x337/0x700
[ +0.000004] dtn_log_read+0x82/0x120 [amdgpu]
[ +0.000207] full_proxy_read+0x66/0x90
[ +0.000007] vfs_read+0xb0/0x340
[ +0.000005] ? __count_memcg_events+0x79/0xe0
[ +0.000002] ? srso_alias_return_thunk+0x5/0xfbef5
[ +0.000003] ? count_memcg_events.constprop.0+0x1e/0x40
[ +0.000003] ? handle_mm_fault+0xb2/0x370
[ +0.000003] ksys_read+0x6b/0xf0
[ +0.000004] __x64_sys_read+0x19/0x20
[ +0.000003] do_syscall_64+0x60/0x130
[ +0.000004] entry_SYSCALL_64_after_hwframe+0x6e/0x76
[ +0.000003] RIP: 0033:0x7fdf32f147e2
[...]
This error happens when the color log tries to read the gamut remap
information from DCN401 which is not initialized in the dcn401_dpp_funcs
which leads to a null pointer dereference. This commit addresses this
issue by adding a proper guard to access the gamut_remap callback in
case the specific ASIC did not implement this function. |
["https://git.kernel.org/stable/c/1e68b7ce6bc6073579fe8713ec6b85aa9cd2e351","https://git.kernel.org/stable/c/5af757124792817f8eb1bd0c80ad60fab519586b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52825
|
Medium |
fixed |
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Fix a race condition of vram buffer unref in svm code
prange->svm_bo unref can happen in both mmu callback and a callback after
migrate to system ram. Both are async call in different tasks. Sync svm_bo
unref operation to avoid random "use-after-free". |
["https://git.kernel.org/stable/c/50f35a907c4f9ed431fd3dbb8b871ef1cbb0718e","https://git.kernel.org/stable/c/709c348261618da7ed89d6c303e2ceb9e453ba74","https://git.kernel.org/stable/c/7d43cdd22cd81a2b079e864c4321b9aba4c6af34","https://git.kernel.org/stable/c/c772eacbd6d0845fc922af8716bb9d29ae27b8cf","https://git.kernel.org/stable/c/fc0210720127cc6302e6d6f3de48f49c3fcf5659","https://git.kernel.org/stable/c/50f35a907c4f9ed431fd3dbb8b871ef1cbb0718e","https://git.kernel.org/stable/c/709c348261618da7ed89d6c303e2ceb9e453ba74","https://git.kernel.org/stable/c/7d43cdd22cd81a2b079e864c4321b9aba4c6af34","https://git.kernel.org/stable/c/c772eacbd6d0845fc922af8716bb9d29ae27b8cf","https://git.kernel.org/stable/c/fc0210720127cc6302e6d6f3de48f49c3fcf5659"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52919
|
Medium |
fixed |
- 4.14.328
- 4.19.297
- 5.4.259
- 5.10.199
- 5.15.137
- 6.1.60
- 6.5.9
|
In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: fix possible NULL pointer dereference in send_acknowledge()
Handle memory allocation failure from nci_skb_alloc() (calling
alloc_skb()) to avoid possible NULL pointer dereference. |
["https://git.kernel.org/stable/c/2b2edf089df3a69f0072c6e71563394c5a94e62e","https://git.kernel.org/stable/c/5622592f8f74ae3e594379af02e64ea84772d0dd","https://git.kernel.org/stable/c/76050b0cc5a72e0c7493287b7e18e1cb9e3c4612","https://git.kernel.org/stable/c/7937609cd387246aed994e81aa4fa951358fba41","https://git.kernel.org/stable/c/bb6cacc439ddd2cd51227ab193f4f91cfc7f014f","https://git.kernel.org/stable/c/c95fa5b20fe03609e0894656fa43c18045b5097e","https://git.kernel.org/stable/c/d7dbdbe3800a908eecd4975c31be47dd45e2104a","https://git.kernel.org/stable/c/ffdc881f68073ff86bf21afb9bb954812e8278be"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47663
|
Medium |
fixed |
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
staging: iio: frequency: ad9834: Validate frequency parameter value
In ad9834_write_frequency() clk_get_rate() can return 0. In such case
ad9834_calc_freqreg() call will lead to division by zero. Checking
'if (fout > (clk_freq / 2))' doesn't protect in case of 'fout' is 0.
ad9834_write_frequency() is called from ad9834_write(), where fout is
taken from text buffer, which can contain any value.
Modify parameters checking.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/0e727707a239d5c519fc9abc2f0fd913516a7e47","https://git.kernel.org/stable/c/3ba9abfcaa9e16bb91ed7e0e2b42e94a157a953e","https://git.kernel.org/stable/c/41cc91e3138fe52f8da92a81bebcd0e6cf488c53","https://git.kernel.org/stable/c/5edc3a45ef428501000a7b23d0e1777a548907f6","https://git.kernel.org/stable/c/8961b245e8f92bccbaacfbbdf69eba60e3e7c227","https://git.kernel.org/stable/c/b48aa991758999d4e8f9296c5bbe388f293ef465","https://git.kernel.org/stable/c/d8b09a5edc4a634373158c1a405491de3c52e58a","https://git.kernel.org/stable/c/dc12e49f970b08d8b007b8981b97e2eb93c0e89d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47669
|
Medium |
fixed |
- 4.19.322
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix state management in error path of log writing function
After commit a694291a6211 ("nilfs2: separate wait function from
nilfs_segctor_write") was applied, the log writing function
nilfs_segctor_do_construct() was able to issue I/O requests continuously
even if user data blocks were split into multiple logs across segments,
but two potential flaws were introduced in its error handling.
First, if nilfs_segctor_begin_construction() fails while creating the
second or subsequent logs, the log writing function returns without
calling nilfs_segctor_abort_construction(), so the writeback flag set on
pages/folios will remain uncleared. This causes page cache operations to
hang waiting for the writeback flag. For example,
truncate_inode_pages_final(), which is called via nilfs_evict_inode() when
an inode is evicted from memory, will hang.
Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared.
As a result, if the next log write involves checkpoint creation, that's
fine, but if a partial log write is performed that does not, inodes with
NILFS_I_COLLECTED set are erroneously removed from the "sc_dirty_files"
list, and their data and b-tree blocks may not be written to the device,
corrupting the block mapping.
Fix these issues by uniformly calling nilfs_segctor_abort_construction()
on failure of each step in the loop in nilfs_segctor_do_construct(),
having it clean up logs and segment usages according to progress, and
correcting the conditions for calling nilfs_redirty_inodes() to ensure
that the NILFS_I_COLLECTED flag is cleared. |
["https://git.kernel.org/stable/c/036441e8438b29111fa75008f0ce305fb4e83c0a","https://git.kernel.org/stable/c/0a1a961bde4351dc047ffdeb2f1311ca16a700cc","https://git.kernel.org/stable/c/30562eff4a6dd35c4b5be9699ef61ad9f5f20a06","https://git.kernel.org/stable/c/3e349d7191f0688fc9808ef24fd4e4b4ef5ca876","https://git.kernel.org/stable/c/40a2757de2c376ef8a08d9ee9c81e77f3c750adf","https://git.kernel.org/stable/c/6576dd6695f2afca3f4954029ac4a64f82ba60ab","https://git.kernel.org/stable/c/74866c16ea2183f52925fa5d76061a1fe7f7737b","https://git.kernel.org/stable/c/efdde00d4a1ef10bb71e09ebc67823a3d3ad725b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47672
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: don't wait for tx queues if firmware is dead
There is a WARNING in iwl_trans_wait_tx_queues_empty() (that was
recently converted from just a message), that can be hit if we
wait for TX queues to become empty after firmware died. Clearly,
we can't expect anything from the firmware after it's declared dead.
Don't call iwl_trans_wait_tx_queues_empty() in this case. While it could
be a good idea to stop the flow earlier, the flush functions do some
maintenance work that is not related to the firmware, so keep that part
of the code running even when the firmware is not running.
[edit commit message] |
["https://git.kernel.org/stable/c/16c1e5d5228f26f120e12e6ca55c59c3a5e6dece","https://git.kernel.org/stable/c/1afed66cb271b3e65fe9df1c9fba2bf4b1f55669","https://git.kernel.org/stable/c/1b0cd832c9607f41f84053b818e0b7908510a3b9","https://git.kernel.org/stable/c/3a84454f5204718ca5b4ad2c1f0bf2031e2403d1","https://git.kernel.org/stable/c/4d0a900ec470d392476c428875dbf053f8a0ae5e","https://git.kernel.org/stable/c/7188b7a72320367554b76d8f298417b070b05dd3","https://git.kernel.org/stable/c/ad2fcc2daa203a6ad491f00e9ae3b7867e8fe0f3","https://git.kernel.org/stable/c/de46b1d24f5f752b3bd8b46673c2ea4239661244"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47690
|
Medium |
fixed |
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: get rid of online repaire on corrupted directory
syzbot reports a f2fs bug as below:
kernel BUG at fs/f2fs/inode.c:896!
RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896
Call Trace:
evict+0x532/0x950 fs/inode.c:704
dispose_list fs/inode.c:747 [inline]
evict_inodes+0x5f9/0x690 fs/inode.c:797
generic_shutdown_super+0x9d/0x2d0 fs/super.c:627
kill_block_super+0x44/0x90 fs/super.c:1696
kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898
deactivate_locked_super+0xc4/0x130 fs/super.c:473
cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373
task_work_run+0x24f/0x310 kernel/task_work.c:228
ptrace_notify+0x2d2/0x380 kernel/signal.c:2402
ptrace_report_syscall include/linux/ptrace.h:415 [inline]
ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline]
syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173
syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline]
__syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline]
syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218
do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896
Online repaire on corrupted directory in f2fs_lookup() can generate
dirty data/meta while racing w/ readonly remount, it may leave dirty
inode after filesystem becomes readonly, however, checkpoint() will
skips flushing dirty inode in a state of readonly mode, result in
above panic.
Let's get rid of online repaire in f2fs_lookup(), and leave the work
to fsck.f2fs. |
["https://git.kernel.org/stable/c/884ee6dc85b959bc152f15bca80c30f06069e6c4","https://git.kernel.org/stable/c/8be95cd607478d85fa4626e86f811e785905bcbf","https://git.kernel.org/stable/c/bcefd0b0611f35b560d0a7281d87529fbe7a1e32","https://git.kernel.org/stable/c/e8d64f598eeb079c42a52deaa3a91312c736a49d","https://git.kernel.org/stable/c/f4746f2d79507f65cfbde11d3c39ee8338aa50af","https://git.kernel.org/stable/c/f9ce2f550d53d044ecfb5ce996406cf42cd6b84d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47707
|
Medium |
fixed |
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()
Blamed commit accidentally removed a check for rt->rt6i_idev being NULL,
as spotted by syzbot:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]
RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914
Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06
RSP: 0018:ffffc900047374e0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000
RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0
RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c
R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18
R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930
FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856
addrconf_notify+0x3cb/0x1020
notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93
call_netdevice_notifiers_extack net/core/dev.c:2032 [inline]
call_netdevice_notifiers net/core/dev.c:2046 [inline]
unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352
unregister_netdevice_many net/core/dev.c:11414 [inline]
unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289
unregister_netdevice include/linux/netdevice.h:3129 [inline]
__tun_detach+0x6b9/0x1600 drivers/net/tun.c:685
tun_detach drivers/net/tun.c:701 [inline]
tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510
__fput+0x24a/0x8a0 fs/file_table.c:422
task_work_run+0x24f/0x310 kernel/task_work.c:228
exit_task_work include/linux/task_work.h:40 [inline]
do_exit+0xa2f/0x27f0 kernel/exit.c:882
do_group_exit+0x207/0x2c0 kernel/exit.c:1031
__do_sys_exit_group kernel/exit.c:1042 [inline]
__se_sys_exit_group kernel/exit.c:1040 [inline]
__x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040
x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f1acc77def9
Code: Unable to access opcode bytes at 0x7f1acc77decf.
RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043
RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]
RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914
Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06
RSP: 0018:ffffc900047374e0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000
RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0
R
---truncated--- |
["https://git.kernel.org/stable/c/04ccecfa959d3b9ae7348780d8e379c6486176ac","https://git.kernel.org/stable/c/08409e401622e2896b4313be9f781bde8a2a6a53","https://git.kernel.org/stable/c/0ceb2f2b5c813f932d6e60d3feec5e7e713da783","https://git.kernel.org/stable/c/8a8b83016f06805775db099c8377024b6fa5b975","https://git.kernel.org/stable/c/9a0ddc73be37d19dff1ba08290af34e707d18e50","https://git.kernel.org/stable/c/a61a174280dad99f25a7dee920310885daf2552b","https://git.kernel.org/stable/c/e43dd28405e6b9935279996725ee11e6306547a5","https://git.kernel.org/stable/c/f2bd9635543ca41533b870f420872819f8331823"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47710
|
Medium |
fixed |
- 5.5
- 5.8
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
sock_map: Add a cond_resched() in sock_hash_free()
Several syzbot soft lockup reports all have in common sock_hash_free()
If a map with a large number of buckets is destroyed, we need to yield
the cpu when needed. |
["https://git.kernel.org/stable/c/04f62c012e0e4683e572b30baf6004ca0a3f6772","https://git.kernel.org/stable/c/1a11a1a53255ddab8a903cdae01b9d3eb2c1a47b","https://git.kernel.org/stable/c/80bd490ac0a3b662a489e17d8eedeb1e905a3d40","https://git.kernel.org/stable/c/984648aac87a6a1c8fd61663bec3f7b61eafad5e","https://git.kernel.org/stable/c/ae8c1b3e7353ad240b829eabac7ba2584b2c6bdc","https://git.kernel.org/stable/c/b1339be951ad31947ae19bc25cb08769bf255100","https://git.kernel.org/stable/c/bc05f6855642cff3c0eeb63060b35d8c4f8a851d","https://git.kernel.org/stable/c/cd10abf41bae55c9d2b93f34a516dbf52626bcb7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47720
|
Medium |
fixed |
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func
This commit adds a null check for the set_output_gamma function pointer
in the dcn30_set_output_transfer_func function. Previously,
set_output_gamma was being checked for nullity at line 386, but then it
was being dereferenced without any nullity check at line 401. This
could potentially lead to a null pointer dereference error if
set_output_gamma is indeed null.
To fix this, we now ensure that set_output_gamma is not null before
dereferencing it. We do this by adding a nullity check for
set_output_gamma before the call to set_output_gamma at line 401. If
set_output_gamma is null, we log an error message and do not call the
function.
This fix prevents a potential null pointer dereference error.
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func()
error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386)
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c
373 bool dcn30_set_output_transfer_func(struct dc *dc,
374 struct pipe_ctx *pipe_ctx,
375 const struct dc_stream_state *stream)
376 {
377 int mpcc_id = pipe_ctx->plane_res.hubp->inst;
378 struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc;
379 const struct pwl_params *params = NULL;
380 bool ret = false;
381
382 /* program OGAM or 3DLUT only for the top pipe*/
383 if (pipe_ctx->top_pipe == NULL) {
384 /*program rmu shaper and 3dlut in MPC*/
385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream);
386 if (ret == false && mpc->funcs->set_output_gamma) {
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL
387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL)
388 params = &stream->out_transfer_func.pwl;
389 else if (pipe_ctx->stream->out_transfer_func.type ==
390 TF_TYPE_DISTRIBUTED_POINTS &&
391 cm3_helper_translate_curve_to_hw_format(
392 &stream->out_transfer_func,
393 &mpc->blender_params, false))
394 params = &mpc->blender_params;
395 /* there are no ROM LUTs in OUTGAM */
396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED)
397 BREAK_TO_DEBUGGER();
398 }
399 }
400
--> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash
402 return ret;
403 } |
["https://git.kernel.org/stable/c/08ae395ea22fb3d9b318c8bde28c0dfd2f5fa4d2","https://git.kernel.org/stable/c/44948d3cb943602ba4a0b5ed3c91ae0525838fb1","https://git.kernel.org/stable/c/64886a4e6f1dce843c0889505cf0673b5211e16a","https://git.kernel.org/stable/c/72ee32d0907364104fbcf4f68dd5ae63cd8eae9e","https://git.kernel.org/stable/c/84edd5a3f5fa6aafa4afcaf9f101f46426c620c9","https://git.kernel.org/stable/c/ddf9ff244d704e1903533f7be377615ed34b83e7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47739
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
padata: use integer wrap around to prevent deadlock on seq_nr overflow
When submitting more than 2^32 padata objects to padata_do_serial, the
current sorting implementation incorrectly sorts padata objects with
overflowed seq_nr, causing them to be placed before existing objects in
the reorder list. This leads to a deadlock in the serialization process
as padata_find_next cannot match padata->seq_nr and pd->processed
because the padata instance with overflowed seq_nr will be selected
next.
To fix this, we use an unsigned integer wrap around to correctly sort
padata objects in scenarios with integer overflow. |
["https://git.kernel.org/stable/c/1b8cf11b3ca593a8802a51802cd0c28c38501428","https://git.kernel.org/stable/c/1bd712de96ad7167fe0d608e706cd60587579f16","https://git.kernel.org/stable/c/46c4079460f4dcaf445860679558eedef4e1bc91","https://git.kernel.org/stable/c/72164d5b648951684b1a593996b37a6083c61d7d","https://git.kernel.org/stable/c/9a22b2812393d93d84358a760c347c21939029a6","https://git.kernel.org/stable/c/9e279e6c1f012b82628b89e1b9c65dbefa8ca25a","https://git.kernel.org/stable/c/ab205e1c3846326f162180e56825b4ba38ce9c30"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49851
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
tpm: Clean up TPM space after command failure
tpm_dev_transmit prepares the TPM space before attempting command
transmission. However if the command fails no rollback of this
preparation is done. This can result in transient handles being leaked
if the device is subsequently closed with no further commands performed.
Fix this by flushing the space in the event of command transmission
failure. |
["https://git.kernel.org/stable/c/2c9b228938e9266a1065a3f4fe5c99b7235dc439","https://git.kernel.org/stable/c/3f9f72d843c92fb6f4ff7460d774413cde7f254c","https://git.kernel.org/stable/c/82478cb8a23bd4f97935bbe60d64528c6d9918b4","https://git.kernel.org/stable/c/87e8134c18977b566f4ec248c8a147244da69402","https://git.kernel.org/stable/c/adf4ce162561222338cf2c9a2caa294527f7f721","https://git.kernel.org/stable/c/c84ceb546f30432fccea4891163f7050f5bee5dd","https://git.kernel.org/stable/c/e3aaebcbb7c6b403416f442d1de70d437ce313a7","https://git.kernel.org/stable/c/ebc4e1f4492d114f9693950621b3ea42b2f82bec"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49871
|
Medium |
fixed |
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
Input: adp5589-keys - fix NULL pointer dereference
We register a devm action to call adp5589_clear_config() and then pass
the i2c client as argument so that we can call i2c_get_clientdata() in
order to get our device object. However, i2c_set_clientdata() is only
being set at the end of the probe function which means that we'll get a
NULL pointer dereference in case the probe function fails early. |
["https://git.kernel.org/stable/c/122b160561f6429701a0559a0f39b0ae309488c6","https://git.kernel.org/stable/c/34e304cc53ae5d3c8e3f08b41dd11e0d4f3e01ed","https://git.kernel.org/stable/c/4449fedb8a710043fc0925409eba844c192d4337","https://git.kernel.org/stable/c/7c3f04223aaf82489472d614c6decee5a1ce8d7f","https://git.kernel.org/stable/c/9a38791ee79bd17d225c15a6d1479448be127a59","https://git.kernel.org/stable/c/fb5cc65f973661241e4a2b7390b429aa7b330c69"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49879
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm: omapdrm: Add missing check for alloc_ordered_workqueue
As it may return NULL pointer and cause NULL pointer dereference. Add check
for the return value of alloc_ordered_workqueue. |
["https://git.kernel.org/stable/c/0d71916694aceb207fefecf62dfa811ec1108bbd","https://git.kernel.org/stable/c/2bda89735199683b03f55b807bd1e31a3857520b","https://git.kernel.org/stable/c/334de68eda2b99892ba869c15cb59bc956fd9f42","https://git.kernel.org/stable/c/b57b53e8ffcdfda87d954fc4187426a54fe75a3d","https://git.kernel.org/stable/c/c17a4f52fa3c3dac2dd6a3c38f2de7342d97d74c","https://git.kernel.org/stable/c/e60b0d3b5aa2e8d934deca9e11215af84e632bc9","https://git.kernel.org/stable/c/e794b7b9b92977365c693760a259f8eef940c536","https://git.kernel.org/stable/c/f37a1d9e5e22d5489309c3cd2db476dcdcc6530c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49881
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: update orig_path in ext4_find_extent()
In ext4_find_extent(), if the path is not big enough, we free it and set
*orig_path to NULL. But after reallocating and successfully initializing
the path, we don't update *orig_path, in which case the caller gets a
valid path but a NULL ppath, and this may cause a NULL pointer dereference
or a path memory leak. For example:
ext4_split_extent
path = *ppath = 2000
ext4_find_extent
if (depth > path[0].p_maxdepth)
kfree(path = 2000);
*orig_path = path = NULL;
path = kcalloc() = 3000
ext4_split_extent_at(*ppath = NULL)
path = *ppath;
ex = path[depth].p_ext;
// NULL pointer dereference!
==================================================================
BUG: kernel NULL pointer dereference, address: 0000000000000010
CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847
RIP: 0010:ext4_split_extent_at+0x6d/0x560
Call Trace:
<TASK>
ext4_split_extent.isra.0+0xcb/0x1b0
ext4_ext_convert_to_initialized+0x168/0x6c0
ext4_ext_handle_unwritten_extents+0x325/0x4d0
ext4_ext_map_blocks+0x520/0xdb0
ext4_map_blocks+0x2b0/0x690
ext4_iomap_begin+0x20e/0x2c0
[...]
==================================================================
Therefore, *orig_path is updated when the extent lookup succeeds, so that
the caller can safely use path or *ppath. |
["https://git.kernel.org/stable/c/11b230100d6801c014fab2afabc8bdea304c1b96","https://git.kernel.org/stable/c/5b4b2dcace35f618fe361a87bae6f0d13af31bc1","https://git.kernel.org/stable/c/6766937d0327000ac1b87c97bbecdd28b0dd6599","https://git.kernel.org/stable/c/6801ed1298204d16a38571091e31178bfdc3c679","https://git.kernel.org/stable/c/a9fcb1717d75061d3653ed69365c8d45331815cd","https://git.kernel.org/stable/c/b63481b3a388ee2df9e295f97273226140422a42","https://git.kernel.org/stable/c/ec0c0beb9b777cdd1edd7df9b36e0f3e67e2bdff","https://git.kernel.org/stable/c/f55ecc58d07a6c1f6d6d5b5af125c25f8da0bda2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49946
|
Medium |
fixed |
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
ppp: do not assume bh is held in ppp_channel_bridge_input()
Networking receive path is usually handled from BH handler.
However, some protocols need to acquire the socket lock, and
packets might be stored in the socket backlog is the socket was
owned by a user process.
In this case, release_sock(), __release_sock(), and sk_backlog_rcv()
might call the sk->sk_backlog_rcv() handler in process context.
sybot caught ppp was not considering this case in
ppp_channel_bridge_input() :
WARNING: inconsistent lock state
6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted
--------------------------------
inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes:
ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline]
ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline]
ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304
{SOFTIRQ-ON-W} state was registered at:
lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759
__raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]
_raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154
spin_lock include/linux/spinlock.h:351 [inline]
ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline]
ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304
pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379
sk_backlog_rcv include/net/sock.h:1111 [inline]
__release_sock+0x1a8/0x3d8 net/core/sock.c:3004
release_sock+0x68/0x1b8 net/core/sock.c:3558
pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
__sys_sendto+0x374/0x4f4 net/socket.c:2204
__do_sys_sendto net/socket.c:2216 [inline]
__se_sys_sendto net/socket.c:2212 [inline]
__arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212
__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712
el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598
irq event stamp: 282914
hardirqs last enabled at (282914): [<ffff80008b42e30c>] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline]
hardirqs last enabled at (282914): [<ffff80008b42e30c>] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194
hardirqs last disabled at (282913): [<ffff80008b42e13c>] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]
hardirqs last disabled at (282913): [<ffff80008b42e13c>] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162
softirqs last enabled at (282904): [<ffff8000801f8e88>] softirq_handle_end kernel/softirq.c:400 [inline]
softirqs last enabled at (282904): [<ffff8000801f8e88>] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582
softirqs last disabled at (282909): [<ffff8000801fbdf8>] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&pch->downl);
<Interrupt>
lock(&pch->downl);
*** DEADLOCK ***
1 lock held by ksoftirqd/1/24:
#0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325
stack backtrace:
CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Call trace:
dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319
show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326
__dump_sta
---truncated--- |
["https://git.kernel.org/stable/c/176dd41e8c2bd997ed3d66568a3362e69ecce99b","https://git.kernel.org/stable/c/635deca1800a68624f185dc1e04a8495b48cf185","https://git.kernel.org/stable/c/aec7291003df78cb71fd461d7b672912bde55807","https://git.kernel.org/stable/c/c837f8583535f094a39386308c2ccfd92c8596cd","https://git.kernel.org/stable/c/efe9cc0f7c0279216a5522271ec675b8288602e4","https://git.kernel.org/stable/c/f9620e2a665aa642625bd2501282bbddff556bd7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49954
|
Medium |
fixed |
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
static_call: Replace pointless WARN_ON() in static_call_module_notify()
static_call_module_notify() triggers a WARN_ON(), when memory allocation
fails in __static_call_add_module().
That's not really justified, because the failure case must be correctly
handled by the well known call chain and the error code is passed
through to the initiating userspace application.
A memory allocation fail is not a fatal problem, but the WARN_ON() takes
the machine out when panic_on_warn is set.
Replace it with a pr_warn(). |
["https://git.kernel.org/stable/c/85a104aaef1f56623acc10ba4c42d5f046ba65b7","https://git.kernel.org/stable/c/b83bef74c121a3311240fc4002d23486b85355e4","https://git.kernel.org/stable/c/bc9356513d56b688775497b7ac6f2b967f46a80c","https://git.kernel.org/stable/c/e67534bd31d79952b50e791e92adf0b3e6c13b8c","https://git.kernel.org/stable/c/ea2cdf4da093d0482f0ef36ba971e2e0c7673425","https://git.kernel.org/stable/c/fe513c2ef0a172a58f158e2e70465c4317f0a9a2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49973
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
r8169: add tally counter fields added with RTL8125
RTL8125 added fields to the tally counter, what may result in the chip
dma'ing these new fields to unallocated memory. Therefore make sure
that the allocated memory area is big enough to hold all of the
tally counter values, even if we use only parts of it. |
["https://git.kernel.org/stable/c/1c723d785adb711496bc64c24240f952f4faaabf","https://git.kernel.org/stable/c/21950321ad33d7613b1453f4c503d7b1871deb61","https://git.kernel.org/stable/c/585c048d15ed559f20cb94c8fa2f30077efa4fbc","https://git.kernel.org/stable/c/64648ae8c97ec5a3165021627f5a1658ebe081ca","https://git.kernel.org/stable/c/92bc8647b4d65f4d4bf8afdb206321c1bc55a486","https://git.kernel.org/stable/c/991e8b0bab669b7d06927c3e442b3352532e8581","https://git.kernel.org/stable/c/ced8e8b8f40accfcce4a2bbd8b150aa76d5eff9a","https://git.kernel.org/stable/c/fe44b3bfbf0c74df5712f44458689d0eccccf47d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50000
|
Medium |
fixed |
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc()
In mlx5e_tir_builder_alloc() kvzalloc() may return NULL
which is dereferenced on the next line in a reference
to the modify field.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/0168ab6fbd9e50d20b97486168b604b2ab28a2ca","https://git.kernel.org/stable/c/1bcc86cc721bea68980098f51f102aa2c2b9d932","https://git.kernel.org/stable/c/4655456a64a0f936098c8432bac64e7176bd2aff","https://git.kernel.org/stable/c/4d80dde26d7bab1320210279483ac854dcb274b2","https://git.kernel.org/stable/c/b48ee5bb25c02ca2b81e0d16bf8af17ab6ed3f8b","https://git.kernel.org/stable/c/f25389e779500cf4a59ef9804534237841bce536"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50002
|
Medium |
fixed |
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
static_call: Handle module init failure correctly in static_call_del_module()
Module insertion invokes static_call_add_module() to initialize the static
calls in a module. static_call_add_module() invokes __static_call_init(),
which allocates a struct static_call_mod to either encapsulate the built-in
static call sites of the associated key into it so further modules can be
added or to append the module to the module chain.
If that allocation fails the function returns with an error code and the
module core invokes static_call_del_module() to clean up eventually added
static_call_mod entries.
This works correctly, when all keys used by the module were converted over
to a module chain before the failure. If not then static_call_del_module()
causes a #GP as it blindly assumes that key::mods points to a valid struct
static_call_mod.
The problem is that key::mods is not a individual struct member of struct
static_call_key, it's part of a union to save space:
union {
/* bit 0: 0 = mods, 1 = sites */
unsigned long type;
struct static_call_mod *mods;
struct static_call_site *sites;
};
key::sites is a pointer to the list of built-in usage sites of the static
call. The type of the pointer is differentiated by bit 0. A mods pointer
has the bit clear, the sites pointer has the bit set.
As static_call_del_module() blidly assumes that the pointer is a valid
static_call_mod type, it fails to check for this failure case and
dereferences the pointer to the list of built-in call sites, which is
obviously bogus.
Cure it by checking whether the key has a sites or a mods pointer.
If it's a sites pointer then the key is not to be touched. As the sites are
walked in the same order as in __static_call_init() the site walk can be
terminated because all subsequent sites have not been touched by the init
code due to the error exit.
If it was converted before the allocation fail, then the inner loop which
searches for a module match will find nothing.
A fail in the second allocation in __static_call_init() is harmless and
does not require special treatment. The first allocation succeeded and
converted the key to a module chain. That first entry has mod::mod == NULL
and mod::next == NULL, so the inner loop of static_call_del_module() will
neither find a module match nor a module chain. The next site in the walk
was either already converted, but can't match the module, or it will exit
the outer loop because it has a static_call_site pointer and not a
static_call_mod pointer. |
["https://git.kernel.org/stable/c/2b494471797bff3d257e99dc0a7abb0c5ff3b4cd","https://git.kernel.org/stable/c/4b30051c4864234ec57290c3d142db7c88f10d8a","https://git.kernel.org/stable/c/9c48c2b53191bf991361998f5bb97b8f2fc5a89c","https://git.kernel.org/stable/c/b566c7d8a2de403ccc9d8a06195e19bbb386d0e4","https://git.kernel.org/stable/c/c0abbbe8c98c077292221ec7e2baa667c9f0974c","https://git.kernel.org/stable/c/ed4c8ce0f307f2ab8778aeb40a8866d171e8f128"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50013
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
exfat: fix memory leak in exfat_load_bitmap()
If the first directory entry in the root directory is not a bitmap
directory entry, 'bh' will not be released and reassigned, which
will cause a memory leak. |
["https://git.kernel.org/stable/c/4e1813e52f86eb8db0c6c9570251f2fcbc571f5d","https://git.kernel.org/stable/c/89081e8407e637463db5880d168e3652fb9f4330","https://git.kernel.org/stable/c/bf0b3b35259475d1fe377bcaa565488e26684f7a","https://git.kernel.org/stable/c/d2b537b3e533f28e0d97293fe9293161fe8cd137","https://git.kernel.org/stable/c/dca359db1eb37f334267ebd7e3cab9a66d191d5b","https://git.kernel.org/stable/c/ddf704c2ce3b73f38d2dd8cf1bb0f7ec038bdf63","https://git.kernel.org/stable/c/f692160d3e1e5450605071b8df8f7d08d9b09a83"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50015
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: dax: fix overflowing extents beyond inode size when partially writing
The dax_iomap_rw() does two things in each iteration: map written blocks
and copy user data to blocks. If the process is killed by user(See signal
handling in dax_iomap_iter()), the copied data will be returned and added
on inode size, which means that the length of written extents may exceed
the inode size, then fsck will fail. An example is given as:
dd if=/dev/urandom of=file bs=4M count=1
dax_iomap_rw
iomap_iter // round 1
ext4_iomap_begin
ext4_iomap_alloc // allocate 0~2M extents(written flag)
dax_iomap_iter // copy 2M data
iomap_iter // round 2
iomap_iter_advance
iter->pos += iter->processed // iter->pos = 2M
ext4_iomap_begin
ext4_iomap_alloc // allocate 2~4M extents(written flag)
dax_iomap_iter
fatal_signal_pending
done = iter->pos - iocb->ki_pos // done = 2M
ext4_handle_inode_extension
ext4_update_inode_size // inode size = 2M
fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix?
Fix the problem by truncating extents if the written length is smaller
than expected. |
["https://git.kernel.org/stable/c/5efccdee4a7d507a483f20f880b809cc4eaef14d","https://git.kernel.org/stable/c/8c30a9a8610c314554997f86370140746aa35661","https://git.kernel.org/stable/c/a9f331f51515bdb3ebc8d0963131af367ef468f6","https://git.kernel.org/stable/c/abfaa876b948baaea4d14f21a1963789845c8b4c","https://git.kernel.org/stable/c/dda898d7ffe85931f9cca6d702a51f33717c501e","https://git.kernel.org/stable/c/ec0dd451e236c46e4858d53e9e82bae7797a7af5","https://git.kernel.org/stable/c/f8a7c342326f6ad1dfdb30a18dd013c70f5e9669"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50024
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
net: Fix an unsafe loop on the list
The kernel may crash when deleting a genetlink family if there are still
listeners for that family:
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0
LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0
Call Trace:
__netlink_clear_multicast_users+0x74/0xc0
genl_unregister_family+0xd4/0x2d0
Change the unsafe loop on the list to a safe one, because inside the
loop there is an element removal from this list. |
["https://git.kernel.org/stable/c/1cdec792b2450105b1314c5123a9a0452cb2c2f0","https://git.kernel.org/stable/c/1dae9f1187189bc09ff6d25ca97ead711f7e26f9","https://git.kernel.org/stable/c/3be342e0332a7c83eb26fbb22bf156fdca467a5d","https://git.kernel.org/stable/c/464801a0f6ccb52b21faa33bac6014fd74cc5e10","https://git.kernel.org/stable/c/49f9b726bf2bf3dd2caf0d27cadf4bc1ccf7a7dd","https://git.kernel.org/stable/c/5f03a7f601f33cda1f710611625235dc86fd8a9e","https://git.kernel.org/stable/c/68ad5da6ca630a276f0a5c924179e57724d00013","https://git.kernel.org/stable/c/8e0766fcf37ad8eed289dd3853628dd9b01b58b0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50039
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
net/sched: accept TCA_STAB only for root qdisc
Most qdiscs maintain their backlog using qdisc_pkt_len(skb)
on the assumption it is invariant between the enqueue()
and dequeue() handlers.
Unfortunately syzbot can crash a host rather easily using
a TBF + SFQ combination, with an STAB on SFQ [1]
We can't support TCA_STAB on arbitrary level, this would
require to maintain per-qdisc storage.
[1]
[ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 88.798611] #PF: supervisor read access in kernel mode
[ 88.799014] #PF: error_code(0x0000) - not-present page
[ 88.799506] PGD 0 P4D 0
[ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI
[ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117
[ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq
[ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00
All code
========
0: 0f b7 50 12 movzwl 0x12(%rax),%edx
4: 48 8d 04 d5 00 00 00 lea 0x0(,%rdx,8),%rax
b: 00
c: 48 89 d6 mov %rdx,%rsi
f: 48 29 d0 sub %rdx,%rax
12: 48 8b 91 c0 01 00 00 mov 0x1c0(%rcx),%rdx
19: 48 c1 e0 03 shl $0x3,%rax
1d: 48 01 c2 add %rax,%rdx
20: 66 83 7a 1a 00 cmpw $0x0,0x1a(%rdx)
25: 7e c0 jle 0xffffffffffffffe7
27: 48 8b 3a mov (%rdx),%rdi
2a:* 4c 8b 07 mov (%rdi),%r8 <-- trapping instruction
2d: 4c 89 02 mov %r8,(%rdx)
30: 49 89 50 08 mov %rdx,0x8(%r8)
34: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi)
3b: 00
3c: 48 rex.W
3d: c7 .byte 0xc7
3e: 07 (bad)
...
Code starting with the faulting instruction
===========================================
0: 4c 8b 07 mov (%rdi),%r8
3: 4c 89 02 mov %r8,(%rdx)
6: 49 89 50 08 mov %rdx,0x8(%r8)
a: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi)
11: 00
12: 48 rex.W
13: c7 .byte 0xc7
14: 07 (bad)
...
[ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206
[ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800
[ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000
[ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f
[ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140
[ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac
[ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000
[ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0
[ 88.808165] Call Trace:
[ 88.808459] <TASK>
[ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)
[ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715)
[ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539)
[ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)
[ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq
[ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq
[ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g
---truncated--- |
["https://git.kernel.org/stable/c/1edf039ee01788ffc25625fe58a903ae2efa213e","https://git.kernel.org/stable/c/2acbb9539bc2284e30d2aeb789c3d96287014264","https://git.kernel.org/stable/c/3cb7cf1540ddff5473d6baeb530228d19bc97b8a","https://git.kernel.org/stable/c/3dc6ee96473cc2962c6db4297d4631f261be150f","https://git.kernel.org/stable/c/76feedc74b90270390fbfdf74a2e944e96872363","https://git.kernel.org/stable/c/8fb6503592d39065316f45d267c5527b4e7cd995","https://git.kernel.org/stable/c/adbc3eef43fc94c7c8436da832691ae02333a972"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50045
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: br_netfilter: fix panic with metadata_dst skb
Fix a kernel panic in the br_netfilter module when sending untagged
traffic via a VxLAN device.
This happens during the check for fragmentation in br_nf_dev_queue_xmit.
It is dependent on:
1) the br_netfilter module being loaded;
2) net.bridge.bridge-nf-call-iptables set to 1;
3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port;
4) untagged frames with size higher than the VxLAN MTU forwarded/flooded
When forwarding the untagged packet to the VxLAN bridge port, before
the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and
changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type
of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL.
Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check
for frames that needs to be fragmented: frames with higher MTU than the
VxLAN device end up calling br_nf_ip_fragment, which in turns call
ip_skb_dst_mtu.
The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst
with valid dst->dev, thus the crash.
This case was never supported in the first place, so drop the packet
instead.
PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data.
[ 176.291791] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000110
[ 176.292101] Mem abort info:
[ 176.292184] ESR = 0x0000000096000004
[ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits
[ 176.292530] SET = 0, FnV = 0
[ 176.292709] EA = 0, S1PTW = 0
[ 176.292862] FSC = 0x04: level 0 translation fault
[ 176.293013] Data abort info:
[ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000
[ 176.294166] [0000000000000110] pgd=0000000000000000,
p4d=0000000000000000
[ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
[ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth
br_netfilter bridge stp llc ipv6 crct10dif_ce
[ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted
6.8.0-rc3-g5b3fbd61b9d1 #2
[ 176.296314] Hardware name: linux,dummy-virt (DT)
[ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS
BTYPE=--)
[ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter]
[ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter]
[ 176.297636] sp : ffff800080003630
[ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27:
ffff6828c49ad9f8
[ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24:
00000000000003e8
[ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21:
ffff6828c3b16d28
[ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18:
0000000000000014
[ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15:
0000000095744632
[ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12:
ffffb7e137926a70
[ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 :
0000000000000000
[ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 :
f20e0100bebafeca
[ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 :
0000000000000000
[ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 :
ffff6828c7f918f0
[ 176.300889] Call trace:
[ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter]
[ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter]
[ 176.301703] nf_hook_slow+0x48/0x124
[ 176.302060] br_forward_finish+0xc8/0xe8 [bridge]
[ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter]
[ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter]
[ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter]
[ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter]
[ 176.303359] nf_hook_slow+0x48/0x124
[ 176.303
---truncated--- |
["https://git.kernel.org/stable/c/3453f5839420bfbb85c86c61e49f49ffd0f041c4","https://git.kernel.org/stable/c/75dfcb758015c97e1accd6340691fca67d363bed","https://git.kernel.org/stable/c/78ed917133b118661e1fe62d4a85d5d428ee9568","https://git.kernel.org/stable/c/915717e0bb9837cc5c101bc545af487bd787239e","https://git.kernel.org/stable/c/95c0cff5a1a5d28bf623b92eb5d1a8f56ed30803","https://git.kernel.org/stable/c/cce8419b8168f6e7eb637103a47f916f3de8bc81","https://git.kernel.org/stable/c/f07131239a76cc10d5e82c19d91f53cb55727297","https://git.kernel.org/stable/c/f9ff7665cd128012868098bbd07e28993e314fdb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50046
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()
On the node of an NFS client, some files saved in the mountpoint of the
NFS server were copied to another location of the same NFS server.
Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference
crash with the following syslog:
[232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116
[232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116
[232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058
[232066.588586] Mem abort info:
[232066.588701] ESR = 0x0000000096000007
[232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits
[232066.589084] SET = 0, FnV = 0
[232066.589216] EA = 0, S1PTW = 0
[232066.589340] FSC = 0x07: level 3 translation fault
[232066.589559] Data abort info:
[232066.589683] ISV = 0, ISS = 0x00000007
[232066.589842] CM = 0, WnR = 0
[232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400
[232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000
[232066.590757] Internal error: Oops: 96000007 [#1] SMP
[232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2
[232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs
[232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1
[232066.597356] Hardware name: Great Wall .\x93\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06
[232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4]
[232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4]
[232066.598595] sp : ffff8000f568fc70
[232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000
[232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001
[232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050
[232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000
[232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000
[232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6
[232066.600498] x11: 00000000000000
---truncated--- |
["https://git.kernel.org/stable/c/584c019baedddec3fd634053e8fb2d8836108d38","https://git.kernel.org/stable/c/632344b9efa064ca737bfcdaaaced59fd5f18ae9","https://git.kernel.org/stable/c/a848c29e3486189aaabd5663bc11aea50c5bd144","https://git.kernel.org/stable/c/ef9189bb15dcbe7ed3f3515aaa6fc8bf7483960d","https://git.kernel.org/stable/c/f892165c564e3aab272948dbb556cc20e290c55a","https://git.kernel.org/stable/c/fca41e5fa4914d12b2136c25f9dad69520b52683"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50103
|
Medium |
fixed |
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()
A devm_kzalloc() in asoc_qcom_lpass_cpu_platform_probe() could
possibly return NULL pointer. NULL Pointer Dereference may be
triggerred without addtional check.
Add a NULL check for the returned pointer. |
["https://git.kernel.org/stable/c/03c9c2c2d2d0fe203dfe8f56bedbcf04e303d7c4","https://git.kernel.org/stable/c/1e235d02d803660777ec911a2c467ae41f8539f5","https://git.kernel.org/stable/c/49da1463c9e3d2082276c3e0e2a8b65a88711cd2","https://git.kernel.org/stable/c/73cc3f905ca9aa95694eea3dfa1acadc90686368","https://git.kernel.org/stable/c/a8e691fe1894c8bdf815a6171ee22ae7da8b18aa","https://git.kernel.org/stable/c/e19bf49e903337641fc230d430d49813e3199902"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50116
|
Medium |
fixed |
- 4.19.323
- 5.4.285
- 5.10.229
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix kernel bug due to missing clearing of buffer delay flag
Syzbot reported that after nilfs2 reads a corrupted file system image
and degrades to read-only, the BUG_ON check for the buffer delay flag
in submit_bh_wbc() may fail, causing a kernel bug.
This is because the buffer delay flag is not cleared when clearing the
buffer state flags to discard a page/folio or a buffer head. So, fix
this.
This became necessary when the use of nilfs2's own page clear routine
was expanded. This state inconsistency does not occur if the buffer
is written normally by log writing. |
["https://git.kernel.org/stable/c/033bc52f35868c2493a2d95c56ece7fc155d7cb3","https://git.kernel.org/stable/c/27524f65621f490184f2ace44cd8e5f3685af4a3","https://git.kernel.org/stable/c/412a30b1b28d6073ba29c46a2b0f324c5936293f","https://git.kernel.org/stable/c/6ed469df0bfbef3e4b44fca954a781919db9f7ab","https://git.kernel.org/stable/c/743c78d455e784097011ea958b27396001181567","https://git.kernel.org/stable/c/822203f6355f4b322d21e7115419f6b98284be25","https://git.kernel.org/stable/c/9f2ab98371c2f2488bf3bf3f9b2a73510545e9c1","https://git.kernel.org/stable/c/c6f58ff2d4c552927fe9a187774e668ebba6c7aa"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50117
|
Medium |
fixed |
- 4.19.323
- 5.4.285
- 5.10.229
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd: Guard against bad data for ATIF ACPI method
If a BIOS provides bad data in response to an ATIF method call
this causes a NULL pointer dereference in the caller.
```
? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1))
? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434)
? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2))
? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1))
? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642)
? exc_page_fault (arch/x86/mm/fault.c:1542)
? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)
? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu
? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu
```
It has been encountered on at least one system, so guard for it.
(cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee) |
["https://git.kernel.org/stable/c/1d7175f9c57b1abf9ecfbdfd53ea760761f52ffe","https://git.kernel.org/stable/c/234682910971732cd4da96fd95946e296e486b38","https://git.kernel.org/stable/c/43b4fa6e0e238c6e2662f4fb61d9f51c2785fb1d","https://git.kernel.org/stable/c/58556dcbd5606a5daccaee73b2130bc16b48e025","https://git.kernel.org/stable/c/6032287747f874b52dc8b9d7490e2799736e035f","https://git.kernel.org/stable/c/975ede2a7bec52b5da1428829b3439667c8a234b","https://git.kernel.org/stable/c/bf58f03931fdcf7b3c45cb76ac13244477a60f44","https://git.kernel.org/stable/c/cd67af3c1762de4c2483ae4dbdd98f9ea8fa56e3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21917
|
Medium |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.131
- 6.6.83
- 6.12.19
- 6.13.7
|
In the Linux kernel, the following vulnerability has been resolved:
usb: renesas_usbhs: Flush the notify_hotplug_work
When performing continuous unbind/bind operations on the USB drivers
available on the Renesas RZ/G2L SoC, a kernel crash with the message
"Unable to handle kernel NULL pointer dereference at virtual address"
may occur. This issue points to the usbhsc_notify_hotplug() function.
Flush the delayed work to avoid its execution when driver resources are
unavailable. |
["https://git.kernel.org/stable/c/3248c1f833f924246cb98ce7da4569133c1b2292","https://git.kernel.org/stable/c/394965f90454d6f00fe11879142b720c6c1a872e","https://git.kernel.org/stable/c/4ca078084cdd5f32d533311d6a0b63a60dcadd41","https://git.kernel.org/stable/c/4cd847a7b630a85493d0294ad9542c21aafaa246","https://git.kernel.org/stable/c/552ca6b87e3778f3dd5b87842f95138162e16c82","https://git.kernel.org/stable/c/830818c8e70c0364e377f0c243b28061ef7967eb","https://git.kernel.org/stable/c/d50f5c0cd949593eb9a3d822b34d7b50046a06b7","https://git.kernel.org/stable/c/e5aac1c9b2974636db7ce796ffa6de88fa08335e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48918
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
iwlwifi: mvm: check debugfs_dir ptr before use
When "debugfs=off" is used on the kernel command line, iwiwifi's
mvm module uses an invalid/unchecked debugfs_dir pointer and causes
a BUG:
BUG: kernel NULL pointer dereference, address: 000000000000004f
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP
CPU: 1 PID: 503 Comm: modprobe Tainted: G W 5.17.0-rc5 #7
Hardware name: Dell Inc. Inspiron 15 5510/076F7Y, BIOS 2.4.1 11/05/2021
RIP: 0010:iwl_mvm_dbgfs_register+0x692/0x700 [iwlmvm]
Code: 69 a0 be 80 01 00 00 48 c7 c7 50 73 6a a0 e8 95 cf ee e0 48 8b 83 b0 1e 00 00 48 c7 c2 54 73 6a a0 be 64 00 00 00 48 8d 7d 8c <48> 8b 48 50 e8 15 22 07 e1 48 8b 43 28 48 8d 55 8c 48 c7 c7 5f 73
RSP: 0018:ffffc90000a0ba68 EFLAGS: 00010246
RAX: ffffffffffffffff RBX: ffff88817d6e3328 RCX: ffff88817d6e3328
RDX: ffffffffa06a7354 RSI: 0000000000000064 RDI: ffffc90000a0ba6c
RBP: ffffc90000a0bae0 R08: ffffffff824e4880 R09: ffffffffa069d620
R10: ffffc90000a0ba00 R11: ffffffffffffffff R12: 0000000000000000
R13: ffffc90000a0bb28 R14: ffff88817d6e3328 R15: ffff88817d6e3320
FS: 00007f64dd92d740(0000) GS:ffff88847f640000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000004f CR3: 000000016fc79001 CR4: 0000000000770ee0
PKRU: 55555554
Call Trace:
<TASK>
? iwl_mvm_mac_setup_register+0xbdc/0xda0 [iwlmvm]
iwl_mvm_start_post_nvm+0x71/0x100 [iwlmvm]
iwl_op_mode_mvm_start+0xab8/0xb30 [iwlmvm]
_iwl_op_mode_start+0x6f/0xd0 [iwlwifi]
iwl_opmode_register+0x6a/0xe0 [iwlwifi]
? 0xffffffffa0231000
iwl_mvm_init+0x35/0x1000 [iwlmvm]
? 0xffffffffa0231000
do_one_initcall+0x5a/0x1b0
? kmem_cache_alloc+0x1e5/0x2f0
? do_init_module+0x1e/0x220
do_init_module+0x48/0x220
load_module+0x2602/0x2bc0
? __kernel_read+0x145/0x2e0
? kernel_read_file+0x229/0x290
__do_sys_finit_module+0xc5/0x130
? __do_sys_finit_module+0xc5/0x130
__x64_sys_finit_module+0x13/0x20
do_syscall_64+0x38/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f64dda564dd
Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1b 29 0f 00 f7 d8 64 89 01 48
RSP: 002b:00007ffdba393f88 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f64dda564dd
RDX: 0000000000000000 RSI: 00005575399e2ab2 RDI: 0000000000000001
RBP: 000055753a91c5e0 R08: 0000000000000000 R09: 0000000000000002
R10: 0000000000000001 R11: 0000000000000246 R12: 00005575399e2ab2
R13: 000055753a91ceb0 R14: 0000000000000000 R15: 000055753a923018
</TASK>
Modules linked in: btintel(+) btmtk bluetooth vfat snd_hda_codec_hdmi fat snd_hda_codec_realtek snd_hda_codec_generic iwlmvm(+) snd_sof_pci_intel_tgl mac80211 snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation soundwire_cadence soundwire_bus snd_sof_intel_hda snd_sof_pci snd_sof snd_sof_xtensa_dsp snd_soc_hdac_hda snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core btrfs snd_compress snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec raid6_pq iwlwifi snd_hda_core snd_pcm snd_timer snd soundcore cfg80211 intel_ish_ipc(+) thunderbolt rfkill intel_ishtp ucsi_acpi wmi i2c_hid_acpi i2c_hid evdev
CR2: 000000000000004f
---[ end trace 0000000000000000 ]---
Check the debugfs_dir pointer for an error before using it.
[change to make both conditional] |
["https://git.kernel.org/stable/c/5a6248c0a22352f09ea041665d3bd3e18f6f872c","https://git.kernel.org/stable/c/7de1ed755e1ace30d97a724bad32452ed86b653b","https://git.kernel.org/stable/c/fe51975ff13831e794e1bcd0039b305dcad3d7ba"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48929
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix crash due to out of bounds access into reg2btf_ids.
When commit e6ac2450d6de ("bpf: Support bpf program calling kernel function") added
kfunc support, it defined reg2btf_ids as a cheap way to translate the verifier
reg type to the appropriate btf_vmlinux BTF ID, however
commit c25b2ae13603 ("bpf: Replace PTR_TO_XXX_OR_NULL with PTR_TO_XXX | PTR_MAYBE_NULL")
moved the __BPF_REG_TYPE_MAX from the last member of bpf_reg_type enum to after
the base register types, and defined other variants using type flag
composition. However, now, the direct usage of reg->type to index into
reg2btf_ids may no longer fall into __BPF_REG_TYPE_MAX range, and hence lead to
out of bounds access and kernel crash on dereference of bad pointer. |
["https://git.kernel.org/stable/c/45ce4b4f9009102cd9f581196d480a59208690c1","https://git.kernel.org/stable/c/8c39925e98d498b9531343066ef82ae39e41adae","https://git.kernel.org/stable/c/f0ce1bc9e0235dd7412240be493d7ea65ed9eadc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47728
|
Medium |
fixed |
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error
For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input
arguments, zero the value for the case of an error as otherwise it could leak
memory. For tracing, it is not needed given CAP_PERFMON can already read all
kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped
in here.
Also, the MTU helpers mtu_len pointer value is being written but also read.
Technically, the MEM_UNINIT should not be there in order to always force init.
Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now
implies two things actually: i) write into memory, ii) memory does not have
to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory,
ii) memory must be initialized. This means that for bpf_*_check_mtu() we're
readding the issue we're trying to fix, that is, it would then be able to
write back into things like .rodata BPF maps. Follow-up work will rework the
MEM_UNINIT semantics such that the intent can be better expressed. For now
just clear the *mtu_len on error path which can be lifted later again. |
["https://git.kernel.org/stable/c/4b3786a6c5397dc220b1483d8e2f4867743e966f","https://git.kernel.org/stable/c/594a9f5a8d2de2573a856e506f77ba7dd2cefc6a","https://git.kernel.org/stable/c/599d15b6d03356a97bff7a76155c5604c42a2962","https://git.kernel.org/stable/c/8397bf78988f3ae9dbebb0200189a62a57264980","https://git.kernel.org/stable/c/a634fa8e480ac2423f86311a602f6295df2c8ed0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49978
|
Medium |
fixed |
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
gso: fix udp gso fraglist segmentation after pull from frag_list
Detect gso fraglist skbs with corrupted geometry (see below) and
pass these to skb_segment instead of skb_segment_list, as the first
can segment them correctly.
Valid SKB_GSO_FRAGLIST skbs
- consist of two or more segments
- the head_skb holds the protocol headers plus first gso_size
- one or more frag_list skbs hold exactly one segment
- all but the last must be gso_size
Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can
modify these skbs, breaking these invariants.
In extreme cases they pull all data into skb linear. For UDP, this
causes a NULL ptr deref in __udpv4_gso_segment_list_csum at
udp_hdr(seg->next)->dest.
Detect invalid geometry due to pull, by checking head_skb size.
Don't just drop, as this may blackhole a destination. Convert to be
able to pass to regular skb_segment. |
["https://git.kernel.org/stable/c/080e6c9a3908de193a48f646c5ce1bfb15676ffc","https://git.kernel.org/stable/c/33e28acf42ee863f332a958bfc2f1a284a3659df","https://git.kernel.org/stable/c/3cd00d2e3655fad3bda96dc1ebf17b6495f86fea","https://git.kernel.org/stable/c/a1e40ac5b5e9077fe1f7ae0eb88034db0f9ae1ab","https://git.kernel.org/stable/c/af3122f5fdc0d00581d6e598a668df6bf54c9daa"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50019
|
Medium |
fixed |
- 5.15.168
- 6.1.113
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
kthread: unpark only parked kthread
Calling into kthread unparking unconditionally is mostly harmless when
the kthread is already unparked. The wake up is then simply ignored
because the target is not in TASK_PARKED state.
However if the kthread is per CPU, the wake up is preceded by a call
to kthread_bind() which expects the task to be inactive and in
TASK_PARKED state, which obviously isn't the case if it is unparked.
As a result, calling kthread_stop() on an unparked per-cpu kthread
triggers such a warning:
WARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525
<TASK>
kthread_stop+0x17a/0x630 kernel/kthread.c:707
destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810
wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257
netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693
default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769
ops_exit_list net/core/net_namespace.c:178 [inline]
cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640
process_one_work kernel/workqueue.c:3231 [inline]
process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312
worker_thread+0x86d/0xd70 kernel/workqueue.c:3393
kthread+0x2f0/0x390 kernel/kthread.c:389
ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
</TASK>
Fix this with skipping unecessary unparking while stopping a kthread. |
["https://git.kernel.org/stable/c/19a5029981c87c2ad0845e713837faa88f5d8e2b","https://git.kernel.org/stable/c/214e01ad4ed7158cab66498810094fac5d09b218","https://git.kernel.org/stable/c/40a6e660d2a3a7a5cb99f0b8ff4fb41bad039f68","https://git.kernel.org/stable/c/8608196a155cb6cfae04d96b10a2652d0327e33f","https://git.kernel.org/stable/c/cda5423c1a1c906062ef235c940f249b97d9d135"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50031
|
Medium |
fixed |
- 5.15.168
- 6.1.113
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
drm/v3d: Stop the active perfmon before being destroyed
When running `kmscube` with one or more performance monitors enabled
via `GALLIUM_HUD`, the following kernel panic can occur:
[ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4
[ 55.008368] Mem abort info:
[ 55.008377] ESR = 0x0000000096000005
[ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits
[ 55.008402] SET = 0, FnV = 0
[ 55.008412] EA = 0, S1PTW = 0
[ 55.008421] FSC = 0x05: level 1 translation fault
[ 55.008434] Data abort info:
[ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
[ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000
[ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
[ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
[ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper
gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb
drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight
[ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1
[ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT)
[ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608
[ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608
[ 55.008895] sp : ffffffc080673cf0
[ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28
[ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148
[ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38
[ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000
[ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90
[ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0
[ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04
[ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857
[ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470
[ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470
[ 55.013292] Call trace:
[ 55.013959] __mutex_lock.constprop.0+0x90/0x608
[ 55.014646] __mutex_lock_slowpath+0x1c/0x30
[ 55.015317] mutex_lock+0x50/0x68
[ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d]
[ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d]
[ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched]
[ 55.017921] kthread+0x11c/0x128
[ 55.018554] ret_from_fork+0x10/0x20
[ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401)
[ 55.019776] ---[ end trace 0000000000000000 ]---
[ 55.020411] note: v3d_bin[166] exited with preempt_count 1
This issue arises because, upon closing the file descriptor (which happens
when we interrupt `kmscube`), the active performance monitor is not
stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`,
the active performance monitor's pointer (`v3d->active_perfmon`) is still
retained.
If `kmscube` is run again, the driver will attempt to stop the active
performance monitor using the stale pointer in `v3d->active_perfmon`.
However, this pointer is no longer valid because the previous process has
already terminated, and all performance monitors associated with it have
been destroyed and freed.
To fix this, when the active performance monitor belongs to a given
process, explicitly stop it before destroying and freeing it. |
["https://git.kernel.org/stable/c/07c51108d9e278831c16191d1223ee49986e7890","https://git.kernel.org/stable/c/0c9e9a3a4873705740b19300cadc6599170646ef","https://git.kernel.org/stable/c/24ab54a066d2ef671b03eb909ca2114c0c9ac1e7","https://git.kernel.org/stable/c/333767cbce6ac20ec794c76eec82ed0ef55022db","https://git.kernel.org/stable/c/7d1fd3638ee3a9f9bca4785fffb638ca19120718"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50038
|
Medium |
fixed |
- 5.15.168
- 6.1.113
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xtables: avoid NFPROTO_UNSPEC where needed
syzbot managed to call xt_cluster match via ebtables:
WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780
[..]
ebt_do_table+0x174b/0x2a40
Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet
processing. As this is only useful to restrict locally terminating
TCP/UDP traffic, register this for ipv4 and ipv6 family only.
Pablo points out that this is a general issue, direct users of the
set/getsockopt interface can call into targets/matches that were only
intended for use with ip(6)tables.
Check all UNSPEC matches and targets for similar issues:
- matches and targets are fine except if they assume skb_network_header()
is valid -- this is only true when called from inet layer: ip(6) stack
pulls the ip/ipv6 header into linear data area.
- targets that return XT_CONTINUE or other xtables verdicts must be
restricted too, they are incompatbile with the ebtables traverser, e.g.
EBT_CONTINUE is a completely different value than XT_CONTINUE.
Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as
they are provided for use by ip(6)tables.
The MARK target is also used by arptables, so register for NFPROTO_ARP too.
While at it, bail out if connbytes fails to enable the corresponding
conntrack family.
This change passes the selftests in iptables.git. |
["https://git.kernel.org/stable/c/0bfcb7b71e735560077a42847f69597ec7dcc326","https://git.kernel.org/stable/c/4cdc55ec6222bb195995cc58f7cb46e4d8907056","https://git.kernel.org/stable/c/85ff9a0f793ca52c527e75cd40a69c948627ebde","https://git.kernel.org/stable/c/8f482bb7e27b37f1f734bb9a8eeb28b23d59d189","https://git.kernel.org/stable/c/997f67d813ce0cf5eb3cdb8f124da68141e91b6c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36893
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: tcpm: Check for port partner validity before consuming it
typec_register_partner() does not guarantee partner registration
to always succeed. In the event of failure, port->partner is set
to the error value or NULL. Given that port->partner validity is
not checked, this results in the following crash:
Unable to handle kernel NULL pointer dereference at virtual address xx
pc : run_state_machine+0x1bc8/0x1c08
lr : run_state_machine+0x1b90/0x1c08
..
Call trace:
run_state_machine+0x1bc8/0x1c08
tcpm_state_machine_work+0x94/0xe4
kthread_worker_fn+0x118/0x328
kthread+0x1d0/0x23c
ret_from_fork+0x10/0x20
To prevent the crash, check for port->partner validity before
derefencing it in all the call sites. |
["https://git.kernel.org/stable/c/2a07e6f0ad8a6e504a3912cfe8dc859b7d0740a5","https://git.kernel.org/stable/c/789326cafbd1f67f424436b6bc8bdb887a364637","https://git.kernel.org/stable/c/ae11f04b452b5205536e1c02d31f8045eba249dd","https://git.kernel.org/stable/c/d56d2ca03cc22123fd7626967d096d8661324e57","https://git.kernel.org/stable/c/fc2b655cb6dd2b381f1f284989721002e39b6b77","https://git.kernel.org/stable/c/789326cafbd1f67f424436b6bc8bdb887a364637","https://git.kernel.org/stable/c/ae11f04b452b5205536e1c02d31f8045eba249dd","https://git.kernel.org/stable/c/d56d2ca03cc22123fd7626967d096d8661324e57","https://git.kernel.org/stable/c/fc2b655cb6dd2b381f1f284989721002e39b6b77"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50028
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
thermal: core: Reference count the zone in thermal_zone_get_by_id()
There are places in the thermal netlink code where nothing prevents
the thermal zone object from going away while being accessed after it
has been returned by thermal_zone_get_by_id().
To address this, make thermal_zone_get_by_id() get a reference on the
thermal zone device object to be returned with the help of get_device(),
under thermal_list_lock, and adjust all of its callers to this change
with the help of the cleanup.h infrastructure. |
["https://git.kernel.org/stable/c/a42a5839f400e929c489bb1b58f54596c4535167","https://git.kernel.org/stable/c/c95538b286efc6109c987e97a051bc7844ede802"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56716
|
Medium |
fixed |
- 5.10.233
- 5.15.176
- 6.1.122
- 6.6.68
- 6.12.7
|
In the Linux kernel, the following vulnerability has been resolved:
netdevsim: prevent bad user input in nsim_dev_health_break_write()
If either a zero count or a large one is provided, kernel can crash. |
["https://git.kernel.org/stable/c/470c5ecbac2f19b1cdee2a6ce8d5650c3295c94b","https://git.kernel.org/stable/c/81bdfcd6e6a998e219c9dd49ec7291c2e0594bbc","https://git.kernel.org/stable/c/8e9ef6bdf71bf25f4735e0230ce1919de8985835","https://git.kernel.org/stable/c/b3a6daaf7cfb2de37b89fd7a5a2ad4ea9aa3e181","https://git.kernel.org/stable/c/d10321be26ff9e9e912697e9e8448099654ff561","https://git.kernel.org/stable/c/ee76746387f6233bdfa93d7406990f923641568f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47705
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
block: fix potential invalid pointer dereference in blk_add_partition
The blk_add_partition() function initially used a single if-condition
(IS_ERR(part)) to check for errors when adding a partition. This was
modified to handle the specific case of -ENXIO separately, allowing the
function to proceed without logging the error in this case. However,
this change unintentionally left a path where md_autodetect_dev()
could be called without confirming that part is a valid pointer.
This commit separates the error handling logic by splitting the
initial if-condition, improving code readability and handling specific
error scenarios explicitly. The function now distinguishes the general
error case from -ENXIO without altering the existing behavior of
md_autodetect_dev() calls. |
["https://git.kernel.org/stable/c/26e197b7f9240a4ac301dd0ad520c0c697c2ea7d","https://git.kernel.org/stable/c/4bc4272e2506941c3f3d4fb8b0c659ee814dcf6f","https://git.kernel.org/stable/c/64cf2a39202ca2d9df5ee70eb310b6141ce2b8ed","https://git.kernel.org/stable/c/652039ba477c9a4ab43740cf2cb0d068d53508c2","https://git.kernel.org/stable/c/80f5bfbb80ea1615290dbc24f49d3d8c86db58fe","https://git.kernel.org/stable/c/afe53ea9b378c376101d99d216f13b6256f75189","https://git.kernel.org/stable/c/cc4d21d9492db4e534d3e01253cf885c90dd2a8b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44954
|
Medium |
fixed |
- 4.19.320
- 5.4.282
- 5.10.224
- 5.15.165
- 6.1.105
- 6.6.46
- 6.10.5
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: line6: Fix racy access to midibuf
There can be concurrent accesses to line6 midibuf from both the URB
completion callback and the rawmidi API access. This could be a cause
of KMSAN warning triggered by syzkaller below (so put as reported-by
here).
This patch protects the midibuf call of the former code path with a
spinlock for avoiding the possible races. |
["https://git.kernel.org/stable/c/15b7a03205b31bc5623378c190d22b7ff60026f1","https://git.kernel.org/stable/c/40f3d5cb0e0cbf7fa697913a27d5d361373bdcf5","https://git.kernel.org/stable/c/51d87f11dd199bbc6a85982b088ff27bde53b48a","https://git.kernel.org/stable/c/535df7f896a568a8a1564114eaea49d002cb1747","https://git.kernel.org/stable/c/643293b68fbb6c03f5e907736498da17d43f0d81","https://git.kernel.org/stable/c/a54da4b787dcac60b598da69c9c0072812b8282d","https://git.kernel.org/stable/c/c80f454a805443c274394b1db0d1ebf477abd94e","https://git.kernel.org/stable/c/e7e7d2b180d8f297cea6db43ea72402fd33e1a29"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26747
|
Medium |
fixed |
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
usb: roles: fix NULL pointer issue when put module's reference
In current design, usb role class driver will get usb_role_switch parent's
module reference after the user get usb_role_switch device and put the
reference after the user put the usb_role_switch device. However, the
parent device of usb_role_switch may be removed before the user put the
usb_role_switch. If so, then, NULL pointer issue will be met when the user
put the parent module's reference.
This will save the module pointer in structure of usb_role_switch. Then,
we don't need to find module by iterating long relations. |
["https://git.kernel.org/stable/c/0158216805ca7e498d07de38840d2732166ae5fa","https://git.kernel.org/stable/c/01f82de440f2ab07c259b7573371e1c42e5565db","https://git.kernel.org/stable/c/1c9be13846c0b2abc2480602f8ef421360e1ad9e","https://git.kernel.org/stable/c/4b45829440b1b208948b39cc71f77a37a2536734","https://git.kernel.org/stable/c/e279bf8e51893e1fe160b3d8126ef2dd00f661e1","https://git.kernel.org/stable/c/ef982fc41055fcebb361a92288d3225783d12913","https://git.kernel.org/stable/c/0158216805ca7e498d07de38840d2732166ae5fa","https://git.kernel.org/stable/c/01f82de440f2ab07c259b7573371e1c42e5565db","https://git.kernel.org/stable/c/1c9be13846c0b2abc2480602f8ef421360e1ad9e","https://git.kernel.org/stable/c/4b45829440b1b208948b39cc71f77a37a2536734","https://git.kernel.org/stable/c/e279bf8e51893e1fe160b3d8126ef2dd00f661e1","https://git.kernel.org/stable/c/ef982fc41055fcebb361a92288d3225783d12913","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-39197
|
High |
fixed |
- 5.4.251
- 5.10.188
- 5.15.121
- 6.1.39
- 6.3.13
- 6.4.4
|
An out-of-bounds read vulnerability was found in Netfilter Connection Tracking (conntrack) in the Linux kernel. This flaw allows a remote user to disclose sensitive information via the DCCP protocol. |
["https://access.redhat.com/security/cve/CVE-2023-39197","https://bugzilla.redhat.com/show_bug.cgi?id=2218342","https://access.redhat.com/security/cve/CVE-2023-39197","https://bugzilla.redhat.com/show_bug.cgi?id=2218342"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56704
|
High |
fixed |
- 4.19.325
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
9p/xen: fix release of IRQ
Kernel logs indicate an IRQ was double-freed.
Pass correct device ID during IRQ release.
[Dominique: remove confusing variable reset to 0] |
["https://git.kernel.org/stable/c/2bb3ee1bf237557daea1d58007d2e1d4a6502ccf","https://git.kernel.org/stable/c/4950408793b118cb8075bcee1f033b543fb719fa","https://git.kernel.org/stable/c/530bc9f03a102fac95b07cda513bfc16ff69e0ee","https://git.kernel.org/stable/c/692eb06703afc3e24d889d77e94a0e20229f6a4a","https://git.kernel.org/stable/c/7f5a2ed5c1810661e6b03f5a4ebf17682cdea850","https://git.kernel.org/stable/c/b9e26059664bd9ebc64a0e8f5216266fc9f84265","https://git.kernel.org/stable/c/d74b4b297097bd361b8a9abfde9b521ff464ea9c","https://git.kernel.org/stable/c/d888f5f5d76b2722c267e6bdf51d445d60647b7b","https://git.kernel.org/stable/c/e43c608f40c065b30964f0a806348062991b802d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52973
|
High |
fixed |
- 4.14.329
- 4.19.273
- 5.4.232
- 5.10.168
- 5.15.93
- 6.1.11
|
In the Linux kernel, the following vulnerability has been resolved:
vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF
After a call to console_unlock() in vcs_read() the vc_data struct can be
freed by vc_deallocate(). Because of that, the struct vc_data pointer
load must be done at the top of while loop in vcs_read() to avoid a UAF
when vcs_size() is called.
Syzkaller reported a UAF in vcs_size().
BUG: KASAN: use-after-free in vcs_size (drivers/tty/vt/vc_screen.c:215)
Read of size 4 at addr ffff8881137479a8 by task 4a005ed81e27e65/1537
CPU: 0 PID: 1537 Comm: 4a005ed81e27e65 Not tainted 6.2.0-rc5 #1
Hardware name: Red Hat KVM, BIOS 1.15.0-2.module
Call Trace:
<TASK>
__asan_report_load4_noabort (mm/kasan/report_generic.c:350)
vcs_size (drivers/tty/vt/vc_screen.c:215)
vcs_read (drivers/tty/vt/vc_screen.c:415)
vfs_read (fs/read_write.c:468 fs/read_write.c:450)
...
</TASK>
Allocated by task 1191:
...
kmalloc_trace (mm/slab_common.c:1069)
vc_allocate (./include/linux/slab.h:580 ./include/linux/slab.h:720
drivers/tty/vt/vt.c:1128 drivers/tty/vt/vt.c:1108)
con_install (drivers/tty/vt/vt.c:3383)
tty_init_dev (drivers/tty/tty_io.c:1301 drivers/tty/tty_io.c:1413
drivers/tty/tty_io.c:1390)
tty_open (drivers/tty/tty_io.c:2080 drivers/tty/tty_io.c:2126)
chrdev_open (fs/char_dev.c:415)
do_dentry_open (fs/open.c:883)
vfs_open (fs/open.c:1014)
...
Freed by task 1548:
...
kfree (mm/slab_common.c:1021)
vc_port_destruct (drivers/tty/vt/vt.c:1094)
tty_port_destructor (drivers/tty/tty_port.c:296)
tty_port_put (drivers/tty/tty_port.c:312)
vt_disallocate_all (drivers/tty/vt/vt_ioctl.c:662 (discriminator 2))
vt_ioctl (drivers/tty/vt/vt_ioctl.c:903)
tty_ioctl (drivers/tty/tty_io.c:2776)
...
The buggy address belongs to the object at ffff888113747800
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 424 bytes inside of
1024-byte region [ffff888113747800, ffff888113747c00)
The buggy address belongs to the physical page:
page:00000000b3fe6c7c refcount:1 mapcount:0 mapping:0000000000000000
index:0x0 pfn:0x113740
head:00000000b3fe6c7c order:3 compound_mapcount:0 subpages_mapcount:0
compound_pincount:0
anon flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)
raw: 0017ffffc0010200 ffff888100042dc0 0000000000000000 dead000000000001
raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888113747880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888113747900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff888113747980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff888113747a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888113747a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
Disabling lock debugging due to kernel taint |
["https://git.kernel.org/stable/c/226fae124b2dac217ea5436060d623ff3385bc34","https://git.kernel.org/stable/c/55515d7d8743b71b80bfe68e89eb9d92630626ab","https://git.kernel.org/stable/c/6332f52f44b9776568bf3c0b714ddfb0bb175e78","https://git.kernel.org/stable/c/8506f16aae9daf354e3732bcfd447e2a97f023df","https://git.kernel.org/stable/c/af79ea9a2443016f64d8fd8d72020cc874f0e066","https://git.kernel.org/stable/c/d0332cbf53dad06a22189cc341391237f4ea6d9f","https://git.kernel.org/stable/c/fc9e27f3ba083534b8bbf72ab0f5c810ffdc7d18"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52974
|
High |
fixed |
- 4.14.306
- 4.19.273
- 5.4.232
- 5.10.168
- 5.15.93
- 6.1.11
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: iscsi_tcp: Fix UAF during login when accessing the shost ipaddress
If during iscsi_sw_tcp_session_create() iscsi_tcp_r2tpool_alloc() fails,
userspace could be accessing the host's ipaddress attr. If we then free the
session via iscsi_session_teardown() while userspace is still accessing the
session we will hit a use after free bug.
Set the tcp_sw_host->session after we have completed session creation and
can no longer fail. |
["https://git.kernel.org/stable/c/0aaabdb900c7415caa2006ef580322f7eac5f6b6","https://git.kernel.org/stable/c/496af9d3682ed4c28fb734342a09e6cc0c056ea4","https://git.kernel.org/stable/c/61e43ebfd243bcbad11be26bd921723027b77441","https://git.kernel.org/stable/c/6abd4698f4c8a78e7bbfc421205c060c199554a0","https://git.kernel.org/stable/c/9758ffe1c07b86aefd7ca8e40d9a461293427ca0","https://git.kernel.org/stable/c/d4d765f4761f9e3a2d62992f825aeee593bcb6b9","https://git.kernel.org/stable/c/f484a794e4ee2a9ce61f52a78e810ac45f3fe3b3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52922
|
High |
fixed |
- 4.14.322
- 4.19.291
- 5.4.251
- 5.10.188
- 5.15.123
- 6.1.42
- 6.4.7
|
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: Fix UAF in bcm_proc_show()
BUG: KASAN: slab-use-after-free in bcm_proc_show+0x969/0xa80
Read of size 8 at addr ffff888155846230 by task cat/7862
CPU: 1 PID: 7862 Comm: cat Not tainted 6.5.0-rc1-00153-gc8746099c197 #230
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0xd5/0x150
print_report+0xc1/0x5e0
kasan_report+0xba/0xf0
bcm_proc_show+0x969/0xa80
seq_read_iter+0x4f6/0x1260
seq_read+0x165/0x210
proc_reg_read+0x227/0x300
vfs_read+0x1d5/0x8d0
ksys_read+0x11e/0x240
do_syscall_64+0x35/0xb0
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Allocated by task 7846:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
__kasan_kmalloc+0x9e/0xa0
bcm_sendmsg+0x264b/0x44e0
sock_sendmsg+0xda/0x180
____sys_sendmsg+0x735/0x920
___sys_sendmsg+0x11d/0x1b0
__sys_sendmsg+0xfa/0x1d0
do_syscall_64+0x35/0xb0
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Freed by task 7846:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
kasan_save_free_info+0x27/0x40
____kasan_slab_free+0x161/0x1c0
slab_free_freelist_hook+0x119/0x220
__kmem_cache_free+0xb4/0x2e0
rcu_core+0x809/0x1bd0
bcm_op is freed before procfs entry be removed in bcm_release(),
this lead to bcm_proc_show() may read the freed bcm_op. |
["https://git.kernel.org/stable/c/11b8e27ed448baa385d90154a141466bd5e92f18","https://git.kernel.org/stable/c/3c3941bb1eb53abe7d640ffee5c4d6b559829ab3","https://git.kernel.org/stable/c/55c3b96074f3f9b0aee19bf93cd71af7516582bb","https://git.kernel.org/stable/c/9533dbfac0ff7edd77a5fa2c24974b1d66c8b0a6","https://git.kernel.org/stable/c/995f47d76647708ec26c6e388663ad4f3f264787","https://git.kernel.org/stable/c/9b58d36d0c1ea29a9571e0222a9c29df0ccfb7ff","https://git.kernel.org/stable/c/cf254b4f68e480e73dab055014e002b77aed30ed","https://git.kernel.org/stable/c/dfd0aa26e9a07f2ce546ccf8304ead6a2914e8a7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46700
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/mes: fix mes ring buffer overflow
wait memory room until enough before writing mes packets
to avoid ring buffer overflow.
v2: squash in sched_hw_submission fix
(cherry picked from commit 34e087e8920e635c62e2ed6a758b0cd27f836d13) |
["https://git.kernel.org/stable/c/11752c013f562a1124088a35bd314aa0e9f0e88f","https://git.kernel.org/stable/c/ed37550d7c516017c3b0324bdf144e2fa563ffb0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48980
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: sja1105: avoid out of bounds access in sja1105_init_l2_policing()
The SJA1105 family has 45 L2 policing table entries
(SJA1105_MAX_L2_POLICING_COUNT) and SJA1110 has 110
(SJA1110_MAX_L2_POLICING_COUNT). Keeping the table structure but
accounting for the difference in port count (5 in SJA1105 vs 10 in
SJA1110) does not fully explain the difference. Rather, the SJA1110 also
has L2 ingress policers for multicast traffic. If a packet is classified
as multicast, it will be processed by the policer index 99 + SRCPORT.
The sja1105_init_l2_policing() function initializes all L2 policers such
that they don't interfere with normal packet reception by default. To have
a common code between SJA1105 and SJA1110, the index of the multicast
policer for the port is calculated because it's an index that is out of
bounds for SJA1105 but in bounds for SJA1110, and a bounds check is
performed.
The code fails to do the proper thing when determining what to do with the
multicast policer of port 0 on SJA1105 (ds->num_ports = 5). The "mcast"
index will be equal to 45, which is also equal to
table->ops->max_entry_count (SJA1105_MAX_L2_POLICING_COUNT). So it passes
through the check. But at the same time, SJA1105 doesn't have multicast
policers. So the code programs the SHARINDX field of an out-of-bounds
element in the L2 Policing table of the static config.
The comparison between index 45 and 45 entries should have determined the
code to not access this policer index on SJA1105, since its memory wasn't
even allocated.
With enough bad luck, the out-of-bounds write could even overwrite other
valid kernel data, but in this case, the issue was detected using KASAN.
Kernel log:
sja1105 spi5.0: Probed switch chip: SJA1105Q
==================================================================
BUG: KASAN: slab-out-of-bounds in sja1105_setup+0x1cbc/0x2340
Write of size 8 at addr ffffff880bd57708 by task kworker/u8:0/8
...
Workqueue: events_unbound deferred_probe_work_func
Call trace:
...
sja1105_setup+0x1cbc/0x2340
dsa_register_switch+0x1284/0x18d0
sja1105_probe+0x748/0x840
...
Allocated by task 8:
...
sja1105_setup+0x1bcc/0x2340
dsa_register_switch+0x1284/0x18d0
sja1105_probe+0x748/0x840
... |
["https://git.kernel.org/stable/c/147f3e3d84054117ae6b9bf317ec4fda9f991192","https://git.kernel.org/stable/c/5e88c6f4aaa70c542e59e5a9d2244bcc99cd245d","https://git.kernel.org/stable/c/f8bac7f9fdb0017b32157957ffffd490f95faa07"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53108
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Adjust VSDB parser for replay feature
At some point, the IEEE ID identification for the replay check in the
AMD EDID was added. However, this check causes the following
out-of-bounds issues when using KASAN:
[ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu]
[ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383
...
[ 27.821207] Memory state around the buggy address:
[ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 27.821243] ^
[ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 27.821268] ==================================================================
This is caused because the ID extraction happens outside of the range of
the edid lenght. This commit addresses this issue by considering the
amd_vsdb_block size.
(cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8) |
["https://git.kernel.org/stable/c/0a326fbc8f72a320051f27328d4d4e7abdfe68d7","https://git.kernel.org/stable/c/16dd2825c23530f2259fc671960a3a65d2af69bd","https://git.kernel.org/stable/c/8db867061f4c76505ad62422b65d666b45289217"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49928
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: avoid reading out of bounds when loading TX power FW elements
Because the loop-expression will do one more time before getting false from
cond-expression, the original code copied one more entry size beyond valid
region.
Fix it by moving the entry copy to loop-body. |
["https://git.kernel.org/stable/c/4007c3d2da31d0c755ea3fcf55e395118e5d5621","https://git.kernel.org/stable/c/83c84cdb75572048b67d6a3916283aeac865996e","https://git.kernel.org/stable/c/ed2e4bb17a4884cf29c3347353d8aabb7265b46c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49414
|
Medium |
fixed |
- 5.4.207
- 5.10.132
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix race condition between ext4_write and ext4_convert_inline_data
Hulk Robot reported a BUG_ON:
==================================================================
EXT4-fs error (device loop3): ext4_mb_generate_buddy:805: group 0,
block bitmap and bg descriptor inconsistent: 25 vs 31513 free clusters
kernel BUG at fs/ext4/ext4_jbd2.c:53!
invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 0 PID: 25371 Comm: syz-executor.3 Not tainted 5.10.0+ #1
RIP: 0010:ext4_put_nojournal fs/ext4/ext4_jbd2.c:53 [inline]
RIP: 0010:__ext4_journal_stop+0x10e/0x110 fs/ext4/ext4_jbd2.c:116
[...]
Call Trace:
ext4_write_inline_data_end+0x59a/0x730 fs/ext4/inline.c:795
generic_perform_write+0x279/0x3c0 mm/filemap.c:3344
ext4_buffered_write_iter+0x2e3/0x3d0 fs/ext4/file.c:270
ext4_file_write_iter+0x30a/0x11c0 fs/ext4/file.c:520
do_iter_readv_writev+0x339/0x3c0 fs/read_write.c:732
do_iter_write+0x107/0x430 fs/read_write.c:861
vfs_writev fs/read_write.c:934 [inline]
do_pwritev+0x1e5/0x380 fs/read_write.c:1031
[...]
==================================================================
Above issue may happen as follows:
cpu1 cpu2
__________________________|__________________________
do_pwritev
vfs_writev
do_iter_write
ext4_file_write_iter
ext4_buffered_write_iter
generic_perform_write
ext4_da_write_begin
vfs_fallocate
ext4_fallocate
ext4_convert_inline_data
ext4_convert_inline_data_nolock
ext4_destroy_inline_data_nolock
clear EXT4_STATE_MAY_INLINE_DATA
ext4_map_blocks
ext4_ext_map_blocks
ext4_mb_new_blocks
ext4_mb_regular_allocator
ext4_mb_good_group_nolock
ext4_mb_init_group
ext4_mb_init_cache
ext4_mb_generate_buddy --> error
ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)
ext4_restore_inline_data
set EXT4_STATE_MAY_INLINE_DATA
ext4_block_write_begin
ext4_da_write_end
ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)
ext4_write_inline_data_end
handle=NULL
ext4_journal_stop(handle)
__ext4_journal_stop
ext4_put_nojournal(handle)
ref_cnt = (unsigned long)handle
BUG_ON(ref_cnt == 0) ---> BUG_ON
The lock held by ext4_convert_inline_data is xattr_sem, but the lock
held by generic_perform_write is i_rwsem. Therefore, the two locks can
be concurrent.
To solve above issue, we add inode_lock() for ext4_convert_inline_data().
At the same time, move ext4_convert_inline_data() in front of
ext4_punch_hole(), remove similar handling from ext4_punch_hole(). |
["https://git.kernel.org/stable/c/14602353b350950b551eccc6b46411aa3b12ffe2","https://git.kernel.org/stable/c/18881d7e517169193d9ef6c89c7f322e3e164277","https://git.kernel.org/stable/c/725e00cb7039eae291890f1bb19bc867176745f6","https://git.kernel.org/stable/c/91f90b571f1a23f5b8a9c2b68a9aa5d6981a3c3d","https://git.kernel.org/stable/c/ccc6639f831bee91aa8b41c8a1cdd020ecfb9f32","https://git.kernel.org/stable/c/f87c7a4b084afc13190cbb263538e444cb2b392a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49572
|
Medium |
fixed |
- 4.19.254
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix data-races around sysctl_tcp_slow_start_after_idle.
While reading sysctl_tcp_slow_start_after_idle, it can be changed
concurrently. Thus, we need to add READ_ONCE() to its readers. |
["https://git.kernel.org/stable/c/0e3f82a03ec8c3808e87283e12946227415706c9","https://git.kernel.org/stable/c/369d99c2b89f54473adcf9acdf40ea562b5a6e0e","https://git.kernel.org/stable/c/3b26e11b07a09b31247688bec61e2925d4a571b6","https://git.kernel.org/stable/c/41aeba4506f6b70ec7500c6fe202731a4ba29fe5","https://git.kernel.org/stable/c/4845b5713ab18a1bb6e31d1fbb4d600240b8b691","https://git.kernel.org/stable/c/68b6f9506747d507c7bfa374d178929b4157e8c6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49589
|
Medium |
fixed |
- 4.19.255
- 5.4.209
- 5.10.135
- 5.15.59
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
igmp: Fix data-races around sysctl_igmp_qrv.
While reading sysctl_igmp_qrv, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its readers.
This test can be packed into a helper, so such changes will be in the
follow-up series after net is merged into net-next.
qrv ?: READ_ONCE(net->ipv4.sysctl_igmp_qrv); |
["https://git.kernel.org/stable/c/8ebcc62c738f68688ee7c6fec2efe5bc6d3d7e60","https://git.kernel.org/stable/c/9eeb3a7702998bdccbfcc37997b5dd9215b9a7f7","https://git.kernel.org/stable/c/b399ffafffba39f47b731b26a5da1dc0ffc4b3ad","https://git.kernel.org/stable/c/c2954671010cd1127d1ffa328c6e6f8e99930982","https://git.kernel.org/stable/c/c721324afc589f8ea54bae04756b150aeaae5fa4","https://git.kernel.org/stable/c/e20dd1b0e0ea15bee1e528536a0840dba972ca0e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48636
|
Medium |
fixed |
- 4.9.330
- 4.14.295
- 4.19.260
- 5.4.215
- 5.10.146
- 5.15.71
- 5.19.12
|
In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: fix Oops in dasd_alias_get_start_dev due to missing pavgroup
Fix Oops in dasd_alias_get_start_dev() function caused by the pavgroup
pointer being NULL.
The pavgroup pointer is checked on the entrance of the function but
without the lcu->lock being held. Therefore there is a race window
between dasd_alias_get_start_dev() and _lcu_update() which sets
pavgroup to NULL with the lcu->lock held.
Fix by checking the pavgroup pointer with lcu->lock held. |
["https://git.kernel.org/stable/c/2e473351400e3dd66f0b71eddcef82ee45a584c1","https://git.kernel.org/stable/c/49f401a98b318761ca2e15d4c7869a20043fbed4","https://git.kernel.org/stable/c/650a2e79d176db753654d3dde88e53a2033036ac","https://git.kernel.org/stable/c/aaba5ff2742043705bc4c02fd0b2b246e2e16da1","https://git.kernel.org/stable/c/d3a67c21b18f33c79382084af556557c442f12a6","https://git.kernel.org/stable/c/d86b4267834e6d4af62e3073e48166e349ab1b70","https://git.kernel.org/stable/c/db7ba07108a48c0f95b74fabbfd5d63e924f992d","https://git.kernel.org/stable/c/f5fcc9d6d71d9ff7fdbdd4b89074e6e24fffc20b","https://git.kernel.org/stable/c/2e473351400e3dd66f0b71eddcef82ee45a584c1","https://git.kernel.org/stable/c/49f401a98b318761ca2e15d4c7869a20043fbed4","https://git.kernel.org/stable/c/650a2e79d176db753654d3dde88e53a2033036ac","https://git.kernel.org/stable/c/aaba5ff2742043705bc4c02fd0b2b246e2e16da1","https://git.kernel.org/stable/c/d3a67c21b18f33c79382084af556557c442f12a6","https://git.kernel.org/stable/c/d86b4267834e6d4af62e3073e48166e349ab1b70","https://git.kernel.org/stable/c/db7ba07108a48c0f95b74fabbfd5d63e924f992d","https://git.kernel.org/stable/c/f5fcc9d6d71d9ff7fdbdd4b89074e6e24fffc20b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48949
|
Medium |
fixed |
- 4.14.303
- 4.19.270
- 5.4.229
- 5.10.161
- 5.15.85
- 6.0.15
|
In the Linux kernel, the following vulnerability has been resolved:
igb: Initialize mailbox message for VF reset
When a MAC address is not assigned to the VF, that portion of the message
sent to the VF is not set. The memory, however, is allocated from the
stack meaning that information may be leaked to the VM. Initialize the
message buffer to 0 so that no information is passed to the VM in this
case. |
["https://git.kernel.org/stable/c/367e1e3399dbc56fc669740c4ab60e35da632b0e","https://git.kernel.org/stable/c/51fd5ede7ed42f272682a0c33d6f0767b3484a3d","https://git.kernel.org/stable/c/a6629659af3f5c6a91e3914ea62554c975ab77f4","https://git.kernel.org/stable/c/c383c7c35c7bc15e07a04eefa060a8a80cbeae29","https://git.kernel.org/stable/c/c581439a977545d61849a72e8ed631cfc8a2a3c1","https://git.kernel.org/stable/c/de5dc44370fbd6b46bd7f1a1e00369be54a041c8","https://git.kernel.org/stable/c/ef1d739dd1f362aec081278ff92f943c31eb177a","https://git.kernel.org/stable/c/f2479c3daaabccbac6c343a737615d0c595c6dc4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-45828
|
Medium |
fixed |
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
i3c: mipi-i3c-hci: Mask ring interrupts before ring stop request
Bus cleanup path in DMA mode may trigger a RING_OP_STAT interrupt when
the ring is being stopped. Depending on timing between ring stop request
completion, interrupt handler removal and code execution this may lead
to a NULL pointer dereference in hci_dma_irq_handler() if it gets to run
after the io_data pointer is set to NULL in hci_dma_cleanup().
Prevent this my masking the ring interrupts before ring stop request. |
["https://git.kernel.org/stable/c/19cc5767334bfe980f52421627d0826c0da86721","https://git.kernel.org/stable/c/6ca2738174e4ee44edb2ab2d86ce74f015a0cc32","https://git.kernel.org/stable/c/9d745a56aea45e47f4755bc12e6429d6314dbb54","https://git.kernel.org/stable/c/a6cddf68b3405b272b5a3cad9657be0b02b34bf4","https://git.kernel.org/stable/c/a6dc4b4fda2e147e557050eaae51ff15edeb680b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27010
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Fix mirred deadlock on device recursion
When the mirred action is used on a classful egress qdisc and a packet is
mirrored or redirected to self we hit a qdisc lock deadlock.
See trace below.
[..... other info removed for brevity....]
[ 82.890906]
[ 82.890906] ============================================
[ 82.890906] WARNING: possible recursive locking detected
[ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W
[ 82.890906] --------------------------------------------
[ 82.890906] ping/418 is trying to acquire lock:
[ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:
__dev_queue_xmit+0x1778/0x3550
[ 82.890906]
[ 82.890906] but task is already holding lock:
[ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:
__dev_queue_xmit+0x1778/0x3550
[ 82.890906]
[ 82.890906] other info that might help us debug this:
[ 82.890906] Possible unsafe locking scenario:
[ 82.890906]
[ 82.890906] CPU0
[ 82.890906] ----
[ 82.890906] lock(&sch->q.lock);
[ 82.890906] lock(&sch->q.lock);
[ 82.890906]
[ 82.890906] *** DEADLOCK ***
[ 82.890906]
[..... other info removed for brevity....]
Example setup (eth0->eth0) to recreate
tc qdisc add dev eth0 root handle 1: htb default 30
tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \
action mirred egress redirect dev eth0
Another example(eth0->eth1->eth0) to recreate
tc qdisc add dev eth0 root handle 1: htb default 30
tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \
action mirred egress redirect dev eth1
tc qdisc add dev eth1 root handle 1: htb default 30
tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \
action mirred egress redirect dev eth0
We fix this by adding an owner field (CPU id) to struct Qdisc set after
root qdisc is entered. When the softirq enters it a second time, if the
qdisc owner is the same CPU, the packet is dropped to break the loop. |
["https://git.kernel.org/stable/c/0f022d32c3eca477fbf79a205243a6123ed0fe11","https://git.kernel.org/stable/c/e6b90468da4dae2281a6e381107f411efb48b0ef","https://git.kernel.org/stable/c/0f022d32c3eca477fbf79a205243a6123ed0fe11","https://git.kernel.org/stable/c/e6b90468da4dae2281a6e381107f411efb48b0ef"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50259
|
Medium |
fixed |
- 5.15.171
- 6.1.116
- 6.6.60
- 6.11.7
|
In the Linux kernel, the following vulnerability has been resolved:
netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write()
This was found by a static analyzer.
We should not forget the trailing zero after copy_from_user()
if we will further do some string operations, sscanf() in this
case. Adding a trailing zero will ensure that the function
performs properly. |
["https://git.kernel.org/stable/c/27bd7a742e171362c9eb52ad5d1d71d3321f949f","https://git.kernel.org/stable/c/4ce1f56a1eaced2523329bef800d004e30f2f76c","https://git.kernel.org/stable/c/6a604877160fe5ab2e1985d5ce1ba6a61abe0693","https://git.kernel.org/stable/c/bcba86e03b3aac361ea671672cf48eed11f9011c","https://git.kernel.org/stable/c/c2150f666c6fc301d5d1643ed0f92251f1a0ff0d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49945
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net/ncsi: Disable the ncsi work before freeing the associated structure
The work function can run after the ncsi device is freed, resulting
in use-after-free bugs or kernel panic. |
["https://git.kernel.org/stable/c/a0ffa68c70b367358b2672cdab6fa5bc4c40de2c","https://git.kernel.org/stable/c/dd41dab62f32d9e9e0669af8459d12a93834b238","https://git.kernel.org/stable/c/f6ca58696749268181f43150b3553f2bafd71e42"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43855
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
md: fix deadlock between mddev_suspend and flush bio
Deadlock occurs when mddev is being suspended while some flush bio is in
progress. It is a complex issue.
T1. the first flush is at the ending stage, it clears 'mddev->flush_bio'
and tries to submit data, but is blocked because mddev is suspended
by T4.
T2. the second flush sets 'mddev->flush_bio', and attempts to queue
md_submit_flush_data(), which is already running (T1) and won't
execute again if on the same CPU as T1.
T3. the third flush inc active_io and tries to flush, but is blocked because
'mddev->flush_bio' is not NULL (set by T2).
T4. mddev_suspend() is called and waits for active_io dec to 0 which is inc
by T3.
T1 T2 T3 T4
(flush 1) (flush 2) (third 3) (suspend)
md_submit_flush_data
mddev->flush_bio = NULL;
.
. md_flush_request
. mddev->flush_bio = bio
. queue submit_flushes
. .
. . md_handle_request
. . active_io + 1
. . md_flush_request
. . wait !mddev->flush_bio
. .
. . mddev_suspend
. . wait !active_io
. .
. submit_flushes
. queue_work md_submit_flush_data
. //md_submit_flush_data is already running (T1)
.
md_handle_request
wait resume
The root issue is non-atomic inc/dec of active_io during flush process.
active_io is dec before md_submit_flush_data is queued, and inc soon
after md_submit_flush_data() run.
md_flush_request
active_io + 1
submit_flushes
active_io - 1
md_submit_flush_data
md_handle_request
active_io + 1
make_request
active_io - 1
If active_io is dec after md_handle_request() instead of within
submit_flushes(), make_request() can be called directly intead of
md_handle_request() in md_submit_flush_data(), and active_io will
only inc and dec once in the whole flush process. Deadlock will be
fixed.
Additionally, the only difference between fixing the issue and before is
that there is no return error handling of make_request(). But after
previous patch cleaned md_write_start(), make_requst() only return error
in raid5_make_request() by dm-raid, see commit 41425f96d7aa ("dm-raid456,
md/raid456: fix a deadlock for dm-raid456 while io concurrent with
reshape)". Since dm always splits data and flush operation into two
separate io, io size of flush submitted by dm always is 0, make_request()
will not be called in md_submit_flush_data(). To prevent future
modifications from introducing issues, add WARN_ON to ensure
make_request() no error is returned in this context. |
["https://git.kernel.org/stable/c/2d0738a8322bf4e5bfe693d16b3111928a9ccfbf","https://git.kernel.org/stable/c/32226070813140234b6c507084738e8e8385c5c6","https://git.kernel.org/stable/c/611d5cbc0b35a752e657a83eebadf40d814d006b","https://git.kernel.org/stable/c/ca963eefbc3331222b6121baa696d49ba2008811"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43895
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Skip Recompute DSC Params if no Stream on Link
[why]
Encounter NULL pointer dereference uner mst + dsc setup.
BUG: kernel NULL pointer dereference, address: 0000000000000008
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2
Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022
RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper]
Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8>
RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224
RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280
RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850
R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000
R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224
FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0
Call Trace:
<TASK>
? __die+0x23/0x70
? page_fault_oops+0x171/0x4e0
? plist_add+0xbe/0x100
? exc_page_fault+0x7c/0x180
? asm_exc_page_fault+0x26/0x30
? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]
? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]
compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
drm_atomic_check_only+0x5c5/0xa40
drm_mode_atomic_ioctl+0x76e/0xbc0
[how]
dsc recompute should be skipped if no mode change detected on the new
request. If detected, keep checking whether the stream is already on
current state or not.
(cherry picked from commit 8151a6c13111b465dbabe07c19f572f7cbd16fef) |
["https://git.kernel.org/stable/c/282f0a482ee61d5e863512f3c4fcec90216c20d9","https://git.kernel.org/stable/c/50e376f1fe3bf571d0645ddf48ad37eb58323919","https://git.kernel.org/stable/c/70275bb960c71d313254473d38c14e7101cee5ad","https://git.kernel.org/stable/c/718d83f66fb07b2cab89a1fc984613a00e3db18f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43912
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: nl80211: disallow setting special AP channel widths
Setting the AP channel width is meant for use with the normal
20/40/... MHz channel width progression, and switching around
in S1G or narrow channels isn't supported. Disallow that. |
["https://git.kernel.org/stable/c/23daf1b4c91db9b26f8425cc7039cf96d22ccbfe","https://git.kernel.org/stable/c/3d42f2125f6c89e1e71c87b9f23412afddbba45e","https://git.kernel.org/stable/c/ac3bf6e47fd8da9bfe8027e1acfe0282a91584fc","https://git.kernel.org/stable/c/c6ea738e3feb407a3283197d9a25d0788f4f3cee"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44970
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: SHAMPO, Fix invalid WQ linked list unlink
When all the strides in a WQE have been consumed, the WQE is unlinked
from the WQ linked list (mlx5_wq_ll_pop()). For SHAMPO, it is possible
to receive CQEs with 0 consumed strides for the same WQE even after the
WQE is fully consumed and unlinked. This triggers an additional unlink
for the same wqe which corrupts the linked list.
Fix this scenario by accepting 0 sized consumed strides without
unlinking the WQE again. |
["https://git.kernel.org/stable/c/50d8009a0ac02c3311b23a0066511f8337bd88d9","https://git.kernel.org/stable/c/650e24748e1e0a7ff91d5c72b72a2f2a452b5b76","https://git.kernel.org/stable/c/7b379353e9144e1f7460ff15f39862012c9d0d78","https://git.kernel.org/stable/c/fba8334721e266f92079632598e46e5f89082f30"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39276
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find()
Syzbot reports a warning as follows:
============================================
WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290
Modules linked in:
CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7
RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419
Call Trace:
<TASK>
ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375
generic_shutdown_super+0x136/0x2d0 fs/super.c:641
kill_block_super+0x44/0x90 fs/super.c:1675
ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327
[...]
============================================
This is because when finding an entry in ext4_xattr_block_cache_find(), if
ext4_sb_bread() returns -ENOMEM, the ce's e_refcnt, which has already grown
in the __entry_find(), won't be put away, and eventually trigger the above
issue in mb_cache_destroy() due to reference count leakage.
So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix. |
["https://git.kernel.org/stable/c/0c0b4a49d3e7f49690a6827a41faeffad5df7e21","https://git.kernel.org/stable/c/681ff9a09accd8a4379f8bd30b7a1641ee19bb3e","https://git.kernel.org/stable/c/76dc776153a47372719d664e0fc50d6355791abb","https://git.kernel.org/stable/c/896a7e7d0d555ad8b2b46af0c2fa7de7467f9483","https://git.kernel.org/stable/c/9ad75e78747b5a50dc5a52f0f8e92e920a653f16","https://git.kernel.org/stable/c/a95df6f04f2c37291adf26a74205cde0314d4577","https://git.kernel.org/stable/c/b37c0edef4e66fb21a2fbc211471195a383e5ab8","https://git.kernel.org/stable/c/e941b712e758f615d311946bf98216e79145ccd9","https://git.kernel.org/stable/c/0c0b4a49d3e7f49690a6827a41faeffad5df7e21","https://git.kernel.org/stable/c/681ff9a09accd8a4379f8bd30b7a1641ee19bb3e","https://git.kernel.org/stable/c/76dc776153a47372719d664e0fc50d6355791abb","https://git.kernel.org/stable/c/896a7e7d0d555ad8b2b46af0c2fa7de7467f9483","https://git.kernel.org/stable/c/9ad75e78747b5a50dc5a52f0f8e92e920a653f16","https://git.kernel.org/stable/c/a95df6f04f2c37291adf26a74205cde0314d4577","https://git.kernel.org/stable/c/b37c0edef4e66fb21a2fbc211471195a383e5ab8","https://git.kernel.org/stable/c/e941b712e758f615d311946bf98216e79145ccd9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52806
|
Medium |
fixed |
- 4.14.331
- 4.19.300
- 5.4.262
- 5.10.202
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: hda: Fix possible null-ptr-deref when assigning a stream
While AudioDSP drivers assign streams exclusively of HOST or LINK type,
nothing blocks a user to attempt to assign a COUPLED stream. As
supplied substream instance may be a stub, what is the case when
code-loading, such scenario ends with null-ptr-deref. |
["https://git.kernel.org/stable/c/2527775616f3638f4fd54649eba8c7b84d5e4250","https://git.kernel.org/stable/c/25354bae4fc310c3928e8a42fda2d486f67745d7","https://git.kernel.org/stable/c/43b91df291c8802268ab3cfd8fccfdf135800ed4","https://git.kernel.org/stable/c/4a320da7f7cbdab2098b103c47f45d5061f42edd","https://git.kernel.org/stable/c/631a96e9eb4228ff75fce7e72d133ca81194797e","https://git.kernel.org/stable/c/758c7733cb821041f5fd403b7b97c0b95d319323","https://git.kernel.org/stable/c/7de25112de8222fd20564769e6c99dc9f9738a0b","https://git.kernel.org/stable/c/f93dc90c2e8ed664985e366aa6459ac83cdab236","https://git.kernel.org/stable/c/fe7c1a0c2b25c82807cb46fc3aadbf2664a682b0","https://git.kernel.org/stable/c/2527775616f3638f4fd54649eba8c7b84d5e4250","https://git.kernel.org/stable/c/25354bae4fc310c3928e8a42fda2d486f67745d7","https://git.kernel.org/stable/c/43b91df291c8802268ab3cfd8fccfdf135800ed4","https://git.kernel.org/stable/c/4a320da7f7cbdab2098b103c47f45d5061f42edd","https://git.kernel.org/stable/c/631a96e9eb4228ff75fce7e72d133ca81194797e","https://git.kernel.org/stable/c/758c7733cb821041f5fd403b7b97c0b95d319323","https://git.kernel.org/stable/c/7de25112de8222fd20564769e6c99dc9f9738a0b","https://git.kernel.org/stable/c/f93dc90c2e8ed664985e366aa6459ac83cdab236","https://git.kernel.org/stable/c/fe7c1a0c2b25c82807cb46fc3aadbf2664a682b0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52809
|
Medium |
fixed |
- 4.14.331
- 4.19.300
- 5.4.262
- 5.10.202
- 5.15.140
- 6.1.64
- 6.5.13
- 6.6.3
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()
fc_lport_ptp_setup() did not check the return value of fc_rport_create()
which can return NULL and would cause a NULL pointer dereference. Address
this issue by checking return value of fc_rport_create() and log error
message on fc_rport_create() failed. |
["https://git.kernel.org/stable/c/442fd24d7b6b29e4a9cd9225afba4142d5f522ba","https://git.kernel.org/stable/c/4df105f0ce9f6f30cda4e99f577150d23f0c9c5f","https://git.kernel.org/stable/c/56d78b5495ebecbb9395101f3be177cd0a52450b","https://git.kernel.org/stable/c/6b9ecf4e1032e645873933e5b43cbb84cac19106","https://git.kernel.org/stable/c/77072ec41d6ab3718c3fc639bc149b8037caedfa","https://git.kernel.org/stable/c/930f0aaba4820d6362de4e6ed569eaf444f1ea4e","https://git.kernel.org/stable/c/b549acf999824d4f751ca57965700372f2f3ad00","https://git.kernel.org/stable/c/bb83f79f90e92f46466adcfd4fd264a7ae0f0f01","https://git.kernel.org/stable/c/f6fe7261b92b21109678747f36df9fdab1e30c34","https://git.kernel.org/stable/c/442fd24d7b6b29e4a9cd9225afba4142d5f522ba","https://git.kernel.org/stable/c/4df105f0ce9f6f30cda4e99f577150d23f0c9c5f","https://git.kernel.org/stable/c/56d78b5495ebecbb9395101f3be177cd0a52450b","https://git.kernel.org/stable/c/6b9ecf4e1032e645873933e5b43cbb84cac19106","https://git.kernel.org/stable/c/77072ec41d6ab3718c3fc639bc149b8037caedfa","https://git.kernel.org/stable/c/930f0aaba4820d6362de4e6ed569eaf444f1ea4e","https://git.kernel.org/stable/c/b549acf999824d4f751ca57965700372f2f3ad00","https://git.kernel.org/stable/c/bb83f79f90e92f46466adcfd4fd264a7ae0f0f01","https://git.kernel.org/stable/c/f6fe7261b92b21109678747f36df9fdab1e30c34"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48877
|
Medium |
fixed |
- 4.14.304
- 4.19.271
- 5.4.230
- 5.10.165
- 5.15.90
- 6.1.8
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: let's avoid panic if extent_tree is not created
This patch avoids the below panic.
pc : __lookup_extent_tree+0xd8/0x760
lr : f2fs_do_write_data_page+0x104/0x87c
sp : ffffffc010cbb3c0
x29: ffffffc010cbb3e0 x28: 0000000000000000
x27: ffffff8803e7f020 x26: ffffff8803e7ed40
x25: ffffff8803e7f020 x24: ffffffc010cbb460
x23: ffffffc010cbb480 x22: 0000000000000000
x21: 0000000000000000 x20: ffffffff22e90900
x19: 0000000000000000 x18: ffffffc010c5d080
x17: 0000000000000000 x16: 0000000000000020
x15: ffffffdb1acdbb88 x14: ffffff888759e2b0
x13: 0000000000000000 x12: ffffff802da49000
x11: 000000000a001200 x10: ffffff8803e7ed40
x9 : ffffff8023195800 x8 : ffffff802da49078
x7 : 0000000000000001 x6 : 0000000000000000
x5 : 0000000000000006 x4 : ffffffc010cbba28
x3 : 0000000000000000 x2 : ffffffc010cbb480
x1 : 0000000000000000 x0 : ffffff8803e7ed40
Call trace:
__lookup_extent_tree+0xd8/0x760
f2fs_do_write_data_page+0x104/0x87c
f2fs_write_single_data_page+0x420/0xb60
f2fs_write_cache_pages+0x418/0xb1c
__f2fs_write_data_pages+0x428/0x58c
f2fs_write_data_pages+0x30/0x40
do_writepages+0x88/0x190
__writeback_single_inode+0x48/0x448
writeback_sb_inodes+0x468/0x9e8
__writeback_inodes_wb+0xb8/0x2a4
wb_writeback+0x33c/0x740
wb_do_writeback+0x2b4/0x400
wb_workfn+0xe4/0x34c
process_one_work+0x24c/0x5bc
worker_thread+0x3e8/0xa50
kthread+0x150/0x1b4 |
["https://git.kernel.org/stable/c/1c38cdc747f00daf7394535eae5afc4c503c59bb","https://git.kernel.org/stable/c/2c129e868992621a739bdd57a5bffa3985ef1b91","https://git.kernel.org/stable/c/557e85ff9afef6d45020b6f09357111d38033c31","https://git.kernel.org/stable/c/72009139a661ade5cb1da4239734ed02fa1cfff0","https://git.kernel.org/stable/c/dd83a9763e29ed7a21c8a43f7a62cd0a6bf74692","https://git.kernel.org/stable/c/df9d44b645b83fffccfb4e28c1f93376585fdec8","https://git.kernel.org/stable/c/ff85a1dbd90d29f73033177ff8d8de4a27d9721c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48891
|
Medium |
fixed |
- 4.14.303
- 4.19.270
- 5.4.229
- 5.10.164
- 5.15.89
- 6.1.7
|
In the Linux kernel, the following vulnerability has been resolved:
regulator: da9211: Use irq handler when ready
If the system does not come from reset (like when it is kexec()), the
regulator might have an IRQ waiting for us.
If we enable the IRQ handler before its structures are ready, we crash.
This patch fixes:
[ 1.141839] Unable to handle kernel read from unreadable memory at virtual address 0000000000000078
[ 1.316096] Call trace:
[ 1.316101] blocking_notifier_call_chain+0x20/0xa8
[ 1.322757] cpu cpu0: dummy supplies not allowed for exclusive requests
[ 1.327823] regulator_notifier_call_chain+0x1c/0x2c
[ 1.327825] da9211_irq_handler+0x68/0xf8
[ 1.327829] irq_thread+0x11c/0x234
[ 1.327833] kthread+0x13c/0x154 |
["https://git.kernel.org/stable/c/02228f6aa6a64d588bc31e3267d05ff184d772eb","https://git.kernel.org/stable/c/1c1afcb8839b91c09d211ea304faa269763b1f91","https://git.kernel.org/stable/c/470f6a9175f13a53810734658c35cc5bba33be01","https://git.kernel.org/stable/c/ad1336274f733a7cb1f87b5c5908165a2c14df53","https://git.kernel.org/stable/c/d443308edbfb6e9e757b478af908515110d1efd5","https://git.kernel.org/stable/c/d4aa749e046435f054e94ebf50cad143d6229fae","https://git.kernel.org/stable/c/f75cde714e0a67f73ef169aa50d4ed77d04f7236"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52894
|
Medium |
fixed |
- 4.14.304
- 4.19.271
- 5.4.230
- 5.10.165
- 5.15.90
- 6.1.8
|
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()
In Google internal bug 265639009 we've received an (as yet) unreproducible
crash report from an aarch64 GKI 5.10.149-android13 running device.
AFAICT the source code is at:
https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10
The call stack is:
ncm_close() -> ncm_notify() -> ncm_do_notify()
with the crash at:
ncm_do_notify+0x98/0x270
Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)
Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...):
// halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification)
0B 0D 00 79 strh w11, [x8, #6]
// word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request)
6C 0A 00 B9 str w12, [x19, #8]
// x10 (NULL) was read here from offset 0 of valid pointer x9
// IMHO we're reading 'cdev->gadget' and getting NULL
// gadget is indeed at offset 0 of struct usb_composite_dev
2A 01 40 F9 ldr x10, [x9]
// loading req->buf pointer, which is at offset 0 of struct usb_request
69 02 40 F9 ldr x9, [x19]
// x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed
4B 5D 40 B9 ldr w11, [x10, #0x5c]
which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment:
event->wLength = cpu_to_le16(8);
req->length = NCM_STATUS_BYTECOUNT;
/* SPEED_CHANGE data is up/down speeds in bits/sec */
data = req->buf + sizeof *event;
data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));
My analysis of registers and NULL ptr deref crash offset
(Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)
heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing:
data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));
which calls:
ncm_bitrate(NULL)
which then calls:
gadget_is_superspeed(NULL)
which reads
((struct usb_gadget *)NULL)->max_speed
and hits a panic.
AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.
(remember there's a GKI KABI reservation of 16 bytes in struct work_struct)
It's not at all clear to me how this is all supposed to work...
but returning 0 seems much better than panic-ing... |
["https://git.kernel.org/stable/c/09e4507ec8ef2d44da6ba4092b8ee2d81f216497","https://git.kernel.org/stable/c/63d161f29cd39c050e8873aa36e0c9fc013bb763","https://git.kernel.org/stable/c/a21da7f7aae618c785f7e4a275d43c06dc8412b6","https://git.kernel.org/stable/c/a69c8dfb85b44be9cc223be07d35cc3a9baefbea","https://git.kernel.org/stable/c/c6ec929595c7443250b2a4faea988c62019d5cd2","https://git.kernel.org/stable/c/e92c70059178da751e5af7de02384b7dfadb5ec7","https://git.kernel.org/stable/c/fef6b29671b66dfb71f17e337c1ad14b5a2cedae"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52899
|
Medium |
fixed |
- 4.19.271
- 5.4.230
- 5.10.165
- 5.15.90
- 6.1.8
|
In the Linux kernel, the following vulnerability has been resolved:
Add exception protection processing for vd in axi_chan_handle_err function
Since there is no protection for vd, a kernel panic will be
triggered here in exceptional cases.
You can refer to the processing of axi_chan_block_xfer_complete function
The triggered kernel panic is as follows:
[ 67.848444] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060
[ 67.848447] Mem abort info:
[ 67.848449] ESR = 0x96000004
[ 67.848451] EC = 0x25: DABT (current EL), IL = 32 bits
[ 67.848454] SET = 0, FnV = 0
[ 67.848456] EA = 0, S1PTW = 0
[ 67.848458] Data abort info:
[ 67.848460] ISV = 0, ISS = 0x00000004
[ 67.848462] CM = 0, WnR = 0
[ 67.848465] user pgtable: 4k pages, 48-bit VAs, pgdp=00000800c4c0b000
[ 67.848468] [0000000000000060] pgd=0000000000000000, p4d=0000000000000000
[ 67.848472] Internal error: Oops: 96000004 [#1] SMP
[ 67.848475] Modules linked in: dmatest
[ 67.848479] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.100-emu_x2rc+ #11
[ 67.848483] pstate: 62000085 (nZCv daIf -PAN -UAO +TCO BTYPE=--)
[ 67.848487] pc : axi_chan_handle_err+0xc4/0x230
[ 67.848491] lr : axi_chan_handle_err+0x30/0x230
[ 67.848493] sp : ffff0803fe55ae50
[ 67.848495] x29: ffff0803fe55ae50 x28: ffff800011212200
[ 67.848500] x27: ffff0800c42c0080 x26: ffff0800c097c080
[ 67.848504] x25: ffff800010d33880 x24: ffff80001139d850
[ 67.848508] x23: ffff0800c097c168 x22: 0000000000000000
[ 67.848512] x21: 0000000000000080 x20: 0000000000002000
[ 67.848517] x19: ffff0800c097c080 x18: 0000000000000000
[ 67.848521] x17: 0000000000000000 x16: 0000000000000000
[ 67.848525] x15: 0000000000000000 x14: 0000000000000000
[ 67.848529] x13: 0000000000000000 x12: 0000000000000040
[ 67.848533] x11: ffff0800c0400248 x10: ffff0800c040024a
[ 67.848538] x9 : ffff800010576cd4 x8 : ffff0800c0400270
[ 67.848542] x7 : 0000000000000000 x6 : ffff0800c04003e0
[ 67.848546] x5 : ffff0800c0400248 x4 : ffff0800c4294480
[ 67.848550] x3 : dead000000000100 x2 : dead000000000122
[ 67.848555] x1 : 0000000000000100 x0 : ffff0800c097c168
[ 67.848559] Call trace:
[ 67.848562] axi_chan_handle_err+0xc4/0x230
[ 67.848566] dw_axi_dma_interrupt+0xf4/0x590
[ 67.848569] __handle_irq_event_percpu+0x60/0x220
[ 67.848573] handle_irq_event+0x64/0x120
[ 67.848576] handle_fasteoi_irq+0xc4/0x220
[ 67.848580] __handle_domain_irq+0x80/0xe0
[ 67.848583] gic_handle_irq+0xc0/0x138
[ 67.848585] el1_irq+0xc8/0x180
[ 67.848588] arch_cpu_idle+0x14/0x2c
[ 67.848591] default_idle_call+0x40/0x16c
[ 67.848594] do_idle+0x1f0/0x250
[ 67.848597] cpu_startup_entry+0x2c/0x60
[ 67.848600] rest_init+0xc0/0xcc
[ 67.848603] arch_call_rest_init+0x14/0x1c
[ 67.848606] start_kernel+0x4cc/0x500
[ 67.848610] Code: eb0002ff 9a9f12d6 f2fbd5a2 f2fbd5a3 (a94602c1)
[ 67.848613] ---[ end trace 585a97036f88203a ]--- |
["https://git.kernel.org/stable/c/20d0a6d17e85a8a816a64fa7d7cae616f1617833","https://git.kernel.org/stable/c/5054d001ffaf76155637c5e5b922c11016cd6a5d","https://git.kernel.org/stable/c/51a7ad5b60efac65691729d10745c28fa1016b96","https://git.kernel.org/stable/c/53dd833fd0a2d8f0118d01ea063a70652689d31e","https://git.kernel.org/stable/c/57054fe516d59d03a7bcf1888e82479ccc244f87","https://git.kernel.org/stable/c/f534dc438828cc3f1f8c6895b8bdfbef079521fb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52900
|
Medium |
fixed |
- 4.14.304
- 4.19.271
- 5.4.230
- 5.10.165
- 5.15.90
- 6.1.8
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix general protection fault in nilfs_btree_insert()
If nilfs2 reads a corrupted disk image and tries to reads a b-tree node
block by calling __nilfs_btree_get_block() against an invalid virtual
block address, it returns -ENOENT because conversion of the virtual block
address to a disk block address fails. However, this return value is the
same as the internal code that b-tree lookup routines return to indicate
that the block being searched does not exist, so functions that operate on
that b-tree may misbehave.
When nilfs_btree_insert() receives this spurious 'not found' code from
nilfs_btree_do_lookup(), it misunderstands that the 'not found' check was
successful and continues the insert operation using incomplete lookup path
data, causing the following crash:
general protection fault, probably for non-canonical address
0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
...
RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline]
RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline]
RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238
Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89
ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 <42> 80 3c
28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02
...
Call Trace:
<TASK>
nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline]
nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147
nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101
__block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991
__block_write_begin fs/buffer.c:2041 [inline]
block_write_begin+0x93/0x1e0 fs/buffer.c:2102
nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261
generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772
__generic_file_write_iter+0x176/0x400 mm/filemap.c:3900
generic_file_write_iter+0xab/0x310 mm/filemap.c:3932
call_write_iter include/linux/fs.h:2186 [inline]
new_sync_write fs/read_write.c:491 [inline]
vfs_write+0x7dc/0xc50 fs/read_write.c:584
ksys_write+0x177/0x2a0 fs/read_write.c:637
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
...
</TASK>
This patch fixes the root cause of this problem by replacing the error
code that __nilfs_btree_get_block() returns on block address conversion
failure from -ENOENT to another internal code -EINVAL which means that the
b-tree metadata is corrupted.
By returning -EINVAL, it propagates without glitches, and for all relevant
b-tree operations, functions in the upper bmap layer output an error
message indicating corrupted b-tree metadata via
nilfs_bmap_convert_error(), and code -EIO will be eventually returned as
it should be. |
["https://git.kernel.org/stable/c/0bf463939c09e5b2c35c71ed74a5fd60a74d6a04","https://git.kernel.org/stable/c/3c2a2ff67d46106715c2132021b98bd057c27545","https://git.kernel.org/stable/c/45627a1a6450662e1e0f8174ef07b05710a20062","https://git.kernel.org/stable/c/712bd74eccb9d3626a0a236641962eca8e11a243","https://git.kernel.org/stable/c/7633355e5c7f29c049a9048e461427d1d8ed3051","https://git.kernel.org/stable/c/b0ba060d3287108eba17603bee3810e4cf2c272d","https://git.kernel.org/stable/c/d9fde9eab1766170ff2ade67d09178d2cfd78749"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52915
|
Medium |
fixed |
- 4.14.326
- 4.19.295
- 5.4.257
- 5.10.197
- 5.15.133
- 6.1.55
- 6.5.5
|
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035_i2c_master_xfer
In af9035_i2c_master_xfer, msg is controlled by user. When msg[i].buf
is null and msg[i].len is zero, former checks on msg[i].buf would be
passed. Malicious data finally reach af9035_i2c_master_xfer. If accessing
msg[i].buf[0] without sanity check, null ptr deref would happen.
We add check on msg[i].len to prevent crash.
Similar commit:
commit 0ed554fd769a
("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()") |
["https://git.kernel.org/stable/c/0143f282b15f7cedc0392ea10050fb6000fd16e6","https://git.kernel.org/stable/c/41b7181a40af84448a2b144fb02d8bf32b7e9a23","https://git.kernel.org/stable/c/6c01ef65de0b321b2db1ef9abf8f1d15862b937e","https://git.kernel.org/stable/c/7bf744f2de0a848fb1d717f5831b03db96feae89","https://git.kernel.org/stable/c/b2f54ed7739dfdf42c4df0a11131aad7c8635464","https://git.kernel.org/stable/c/b49c6e5dd236787f13a062ec528d724169f11152","https://git.kernel.org/stable/c/d9ef84a7c222497ecb5fdf93361c76931804825e","https://git.kernel.org/stable/c/fa58d9db5cad4bb7bb694b6837e3b96d87554f2b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-36879
|
Medium |
|
N/A
|
An issue was discovered in the Linux kernel through 5.18.14. xfrm_expand_policies in net/xfrm/xfrm_policy.c can cause a refcount to be dropped twice. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=f85daf0e725358be78dfd208dea5fd665d8cb901","https://github.com/torvalds/linux/commit/f85daf0e725358be78dfd208dea5fd665d8cb901","https://lists.debian.org/debian-lts-announce/2022/09/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://security.netapp.com/advisory/ntap-20220901-0007/","https://www.debian.org/security/2022/dsa-5207","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=f85daf0e725358be78dfd208dea5fd665d8cb901","https://github.com/torvalds/linux/commit/f85daf0e725358be78dfd208dea5fd665d8cb901","https://lists.debian.org/debian-lts-announce/2022/09/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://security.netapp.com/advisory/ntap-20220901-0007/","https://www.debian.org/security/2022/dsa-5207"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21748
|
Medium |
fixed |
- 6.1.129
- 6.6.78
- 6.12.14
- 6.13.3
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix integer overflows on 32 bit systems
On 32bit systems the addition operations in ipc_msg_alloc() can
potentially overflow leading to memory corruption.
Add bounds checking using KSMBD_IPC_MAX_PAYLOAD to avoid overflow. |
["https://git.kernel.org/stable/c/760568c1f62ea874e8fb492f9cfa4f47b4b8391e","https://git.kernel.org/stable/c/82f59d64e6297f270311b16b5dcf65be406d1ea3","https://git.kernel.org/stable/c/aab98e2dbd648510f8f51b83fbf4721206ccae45","https://git.kernel.org/stable/c/b4b902737746c490258de5cb55cab39e79927a67","https://git.kernel.org/stable/c/ecb9947fa7c99a77b04d43404c6988a0d326e4a0","https://git.kernel.org/stable/c/f3b9fb2764591d792d160f375851013665a9e820"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21667
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
iomap: avoid avoid truncating 64-bit offset to 32 bits
on 32-bit kernels, iomap_write_delalloc_scan() was inadvertently using a
32-bit position due to folio_next_index() returning an unsigned long.
This could lead to an infinite loop when writing to an xfs filesystem. |
["https://git.kernel.org/stable/c/402ce16421477e27f30b57d6d1a6dc248fa3a4e4","https://git.kernel.org/stable/c/7ca4bd6b754913910151acce00be093f03642725","https://git.kernel.org/stable/c/91371922704c8d82049ef7c2ad974d0a2cd1174d","https://git.kernel.org/stable/c/c13094b894de289514d84b8db56d1f2931a0bade"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26735
|
Medium |
fixed |
- 4.19.308
- 5.4.270
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: fix possible use-after-free and null-ptr-deref
The pernet operations structure for the subsystem must be registered
before registering the generic netlink family. |
["https://git.kernel.org/stable/c/02b08db594e8218cfbc0e4680d4331b457968a9b","https://git.kernel.org/stable/c/5559cea2d5aa3018a5f00dd2aca3427ba09b386b","https://git.kernel.org/stable/c/65c38f23d10ff79feea1e5d50b76dc7af383c1e6","https://git.kernel.org/stable/c/82831e3ff76ef09fb184eb93b79a3eb3fb284f1d","https://git.kernel.org/stable/c/8391b9b651cfdf80ab0f1dc4a489f9d67386e197","https://git.kernel.org/stable/c/91b020aaa1e59bfb669d34c968e3db3d5416bcee","https://git.kernel.org/stable/c/953f42934533c151f440cd32390044d2396b87aa","https://git.kernel.org/stable/c/9e02973dbc6a91e40aa4f5d87b8c47446fbfce44","https://git.kernel.org/stable/c/02b08db594e8218cfbc0e4680d4331b457968a9b","https://git.kernel.org/stable/c/5559cea2d5aa3018a5f00dd2aca3427ba09b386b","https://git.kernel.org/stable/c/65c38f23d10ff79feea1e5d50b76dc7af383c1e6","https://git.kernel.org/stable/c/82831e3ff76ef09fb184eb93b79a3eb3fb284f1d","https://git.kernel.org/stable/c/8391b9b651cfdf80ab0f1dc4a489f9d67386e197","https://git.kernel.org/stable/c/91b020aaa1e59bfb669d34c968e3db3d5416bcee","https://git.kernel.org/stable/c/953f42934533c151f440cd32390044d2396b87aa","https://git.kernel.org/stable/c/9e02973dbc6a91e40aa4f5d87b8c47446fbfce44","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://security.netapp.com/advisory/ntap-20241101-0012/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35997
|
Medium |
fixed |
- 4.19.313
- 5.4.275
- 5.10.216
- 5.15.158
- 6.1.90
- 6.6.30
- 6.8.9
|
In the Linux kernel, the following vulnerability has been resolved:
HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up
The flag I2C_HID_READ_PENDING is used to serialize I2C operations.
However, this is not necessary, because I2C core already has its own
locking for that.
More importantly, this flag can cause a lock-up: if the flag is set in
i2c_hid_xfer() and an interrupt happens, the interrupt handler
(i2c_hid_irq) will check this flag and return immediately without doing
anything, then the interrupt handler will be invoked again in an
infinite loop.
Since interrupt handler is an RT task, it takes over the CPU and the
flag-clearing task never gets scheduled, thus we have a lock-up.
Delete this unnecessary flag. |
["https://git.kernel.org/stable/c/0561b65fbd53d3e788c5b0222d9112ca016fd6a1","https://git.kernel.org/stable/c/21bfca822cfc1e71796124e93b46e0d9fa584401","https://git.kernel.org/stable/c/29e94f295bad5be59cf4271a93e22cdcf5536722","https://git.kernel.org/stable/c/418c5575d56410c6e186ab727bf32ae32447d497","https://git.kernel.org/stable/c/5095b93021b899f54c9355bebf36d78854c33a22","https://git.kernel.org/stable/c/9c0f59e47a90c54d0153f8ddc0f80d7a36207d0e","https://git.kernel.org/stable/c/b65fb50e04a95eec34a9d1bc138454a98a5578d8","https://git.kernel.org/stable/c/c448a9fd50f77e8fb9156ff64848aa4295eb3003","https://git.kernel.org/stable/c/0561b65fbd53d3e788c5b0222d9112ca016fd6a1","https://git.kernel.org/stable/c/21bfca822cfc1e71796124e93b46e0d9fa584401","https://git.kernel.org/stable/c/29e94f295bad5be59cf4271a93e22cdcf5536722","https://git.kernel.org/stable/c/418c5575d56410c6e186ab727bf32ae32447d497","https://git.kernel.org/stable/c/5095b93021b899f54c9355bebf36d78854c33a22","https://git.kernel.org/stable/c/9c0f59e47a90c54d0153f8ddc0f80d7a36207d0e","https://git.kernel.org/stable/c/b65fb50e04a95eec34a9d1bc138454a98a5578d8","https://git.kernel.org/stable/c/c448a9fd50f77e8fb9156ff64848aa4295eb3003","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35899
|
Medium |
fixed |
- 5.4.274
- 5.10.215
- 5.15.154
- 6.1.85
- 6.6.26
- 6.8.5
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: flush pending destroy work before exit_net release
Similar to 2c9f0293280e ("netfilter: nf_tables: flush pending destroy
work before netlink notifier") to address a race between exit_net and
the destroy workqueue.
The trace below shows an element to be released via destroy workqueue
while exit_net path (triggered via module removal) has already released
the set that is used in such transaction.
[ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]
[ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465
[ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359
[ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables]
[ 1360.547984] Call Trace:
[ 1360.547991] <TASK>
[ 1360.547998] dump_stack_lvl+0x53/0x70
[ 1360.548014] print_report+0xc4/0x610
[ 1360.548026] ? __virt_addr_valid+0xba/0x160
[ 1360.548040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 1360.548054] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]
[ 1360.548176] kasan_report+0xae/0xe0
[ 1360.548189] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]
[ 1360.548312] nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]
[ 1360.548447] ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables]
[ 1360.548577] ? _raw_spin_unlock_irq+0x18/0x30
[ 1360.548591] process_one_work+0x2f1/0x670
[ 1360.548610] worker_thread+0x4d3/0x760
[ 1360.548627] ? __pfx_worker_thread+0x10/0x10
[ 1360.548640] kthread+0x16b/0x1b0
[ 1360.548653] ? __pfx_kthread+0x10/0x10
[ 1360.548665] ret_from_fork+0x2f/0x50
[ 1360.548679] ? __pfx_kthread+0x10/0x10
[ 1360.548690] ret_from_fork_asm+0x1a/0x30
[ 1360.548707] </TASK>
[ 1360.548719] Allocated by task 192061:
[ 1360.548726] kasan_save_stack+0x20/0x40
[ 1360.548739] kasan_save_track+0x14/0x30
[ 1360.548750] __kasan_kmalloc+0x8f/0xa0
[ 1360.548760] __kmalloc_node+0x1f1/0x450
[ 1360.548771] nf_tables_newset+0x10c7/0x1b50 [nf_tables]
[ 1360.548883] nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink]
[ 1360.548909] nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink]
[ 1360.548927] netlink_unicast+0x367/0x4f0
[ 1360.548935] netlink_sendmsg+0x34b/0x610
[ 1360.548944] ____sys_sendmsg+0x4d4/0x510
[ 1360.548953] ___sys_sendmsg+0xc9/0x120
[ 1360.548961] __sys_sendmsg+0xbe/0x140
[ 1360.548971] do_syscall_64+0x55/0x120
[ 1360.548982] entry_SYSCALL_64_after_hwframe+0x55/0x5d
[ 1360.548994] Freed by task 192222:
[ 1360.548999] kasan_save_stack+0x20/0x40
[ 1360.549009] kasan_save_track+0x14/0x30
[ 1360.549019] kasan_save_free_info+0x3b/0x60
[ 1360.549028] poison_slab_object+0x100/0x180
[ 1360.549036] __kasan_slab_free+0x14/0x30
[ 1360.549042] kfree+0xb6/0x260
[ 1360.549049] __nft_release_table+0x473/0x6a0 [nf_tables]
[ 1360.549131] nf_tables_exit_net+0x170/0x240 [nf_tables]
[ 1360.549221] ops_exit_list+0x50/0xa0
[ 1360.549229] free_exit_list+0x101/0x140
[ 1360.549236] unregister_pernet_operations+0x107/0x160
[ 1360.549245] unregister_pernet_subsys+0x1c/0x30
[ 1360.549254] nf_tables_module_exit+0x43/0x80 [nf_tables]
[ 1360.549345] __do_sys_delete_module+0x253/0x370
[ 1360.549352] do_syscall_64+0x55/0x120
[ 1360.549360] entry_SYSCALL_64_after_hwframe+0x55/0x5d
(gdb) list *__nft_release_table+0x473
0x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354).
11349 list_for_each_entry_safe(flowtable, nf, &table->flowtables, list) {
11350 list_del(&flowtable->list);
11351 nft_use_dec(&table->use);
11352 nf_tables_flowtable_destroy(flowtable);
11353 }
11354 list_for_each_entry_safe(set, ns, &table->sets, list) {
11355 list_del(&set->list);
11356 nft_use_dec(&table->use);
11357 if (set->flags & (NFT_SET_MAP | NFT_SET_OBJECT))
11358 nft_map_deactivat
---truncated--- |
["https://git.kernel.org/stable/c/24cea9677025e0de419989ecb692acd4bb34cac2","https://git.kernel.org/stable/c/333b5085522cf1898d5a0d92616046b414f631a7","https://git.kernel.org/stable/c/46c4481938e2ca62343b16ea83ab28f4c1733d31","https://git.kernel.org/stable/c/4e8447a9a3d367b5065a0b7abe101da6e0037b6e","https://git.kernel.org/stable/c/d2c9eb19fc3b11caebafde4c30a76a49203d18a6","https://git.kernel.org/stable/c/f4e14695fe805eb0f0cb36e0ad6a560b9f985e86","https://git.kernel.org/stable/c/f7e3c88cc2a977c2b9a8aa52c1ce689e7b394e49","https://git.kernel.org/stable/c/24cea9677025e0de419989ecb692acd4bb34cac2","https://git.kernel.org/stable/c/333b5085522cf1898d5a0d92616046b414f631a7","https://git.kernel.org/stable/c/46c4481938e2ca62343b16ea83ab28f4c1733d31","https://git.kernel.org/stable/c/4e8447a9a3d367b5065a0b7abe101da6e0037b6e","https://git.kernel.org/stable/c/d2c9eb19fc3b11caebafde4c30a76a49203d18a6","https://git.kernel.org/stable/c/f4e14695fe805eb0f0cb36e0ad6a560b9f985e86","https://git.kernel.org/stable/c/f7e3c88cc2a977c2b9a8aa52c1ce689e7b394e49","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-45871
|
High |
fixed |
- 4.14.326
- 4.19.295
- 5.4.257
- 5.10.195
- 5.15.132
- 6.1.53
- 6.4.16
- 6.5.3
|
An issue was discovered in drivers/net/ethernet/intel/igb/igb_main.c in the IGB driver in the Linux kernel before 6.5.3. A buffer size may not be adequate for frames larger than the MTU. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.5.3","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bb5ed01cd2428cd25b1c88a3a9cba87055eb289f","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20231110-0001/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.5.3","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bb5ed01cd2428cd25b1c88a3a9cba87055eb289f","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20231110-0001/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1462
|
Medium |
fixed |
- 4.9.325
- 4.14.290
- 4.19.254
- 5.4.208
- 5.10.134
- 5.15.46
- 5.15.58
- 5.18.13
|
An out-of-bounds read flaw was found in the Linux kernel’s TeleTYpe subsystem. The issue occurs in how a user triggers a race condition using ioctls TIOCSPTLCK and TIOCGPTPEER and TIOCSTI and TCXONC with leakage of memory in the flush_to_ldisc function. This flaw allows a local user to crash the system or read unauthorized random data from memory. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2078466","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://seclists.org/oss-sec/2022/q2/155","https://bugzilla.redhat.com/show_bug.cgi?id=2078466","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://seclists.org/oss-sec/2022/q2/155"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-0382
|
Medium |
|
N/A
|
An information leak flaw was found due to uninitialized memory in the Linux kernel's TIPC protocol subsystem, in the way a user sends a TIPC datagram to one or more destinations. This flaw allows a local user to read some kernel memory. This issue is limited to no more than 7 bytes, and the user cannot control what is read. This flaw affects the Linux kernel versions prior to 5.17-rc1. |
["https://github.com/torvalds/linux/commit/d6d86830705f173fca6087a3e67ceaf68db80523","https://github.com/torvalds/linux/commit/d6d86830705f173fca6087a3e67ceaf68db80523"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53135
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN
Hide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support
for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are
myriad bugs in the implementation, some of which are fatal to the guest,
and others which put the stability and health of the host at risk.
For guest fatalities, the most glaring issue is that KVM fails to ensure
tracing is disabled, and *stays* disabled prior to VM-Enter, which is
necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing
is enabled (enforced via a VMX consistency check). Per the SDM:
If the logical processor is operating with Intel PT enabled (if
IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the "load
IA32_RTIT_CTL" VM-entry control must be 0.
On the host side, KVM doesn't validate the guest CPUID configuration
provided by userspace, and even worse, uses the guest configuration to
decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring
guest CPUID to enumerate more address ranges than are supported in hardware
will result in KVM trying to passthrough, save, and load non-existent MSRs,
which generates a variety of WARNs, ToPA ERRORs in the host, a potential
deadlock, etc. |
["https://git.kernel.org/stable/c/aa0d42cacf093a6fcca872edc954f6f812926a17","https://git.kernel.org/stable/c/b8a1d572478b6f239061ee9578b2451bf2f021c2","https://git.kernel.org/stable/c/b91bb0ce5cd7005b376eac690ec664c1b56372ec","https://git.kernel.org/stable/c/c3742319d021f5aa3a0a8c828485fee14753f6de","https://git.kernel.org/stable/c/d28b059ee4779b5102c5da6e929762520510e406","https://git.kernel.org/stable/c/d4b42f926adcce4e5ec193c714afd9d37bba8e5b","https://git.kernel.org/stable/c/e6716f4230a8784957273ddd27326264b27b9313"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50232
|
Medium |
fixed |
- 5.15.171
- 6.1.116
- 6.6.60
- 6.11.7
|
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr()
In the ad7124_write_raw() function, parameter val can potentially
be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST()
is called within ad7124_set_channel_odr(). The ad7124_write_raw()
function is invoked through the sequence: iio_write_channel_raw() ->
iio_write_channel_attribute() -> iio_channel_write(), with no checks
in place to ensure val is non-zero. |
["https://git.kernel.org/stable/c/0ac0beb4235a9a474f681280a3bd4e2a5bb66569","https://git.kernel.org/stable/c/3dc0eda2cd5c653b162852ae5f0631bfe4ca5e95","https://git.kernel.org/stable/c/4f588fffc307a4bc2761aee6ff275bb4b433e451","https://git.kernel.org/stable/c/efa353ae1b0541981bc96dbf2e586387d0392baa","https://git.kernel.org/stable/c/f51343f346e6abde094548a7fb34472b0d4cae91"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53058
|
Medium |
fixed |
- 5.15.171
- 6.1.116
- 6.6.60
- 6.11.7
|
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data
In case the non-paged data of a SKB carries protocol header and protocol
payload to be transmitted on a certain platform that the DMA AXI address
width is configured to 40-bit/48-bit, or the size of the non-paged data
is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI
address width is configured to 32-bit, then this SKB requires at least
two DMA transmit descriptors to serve it.
For example, three descriptors are allocated to split one DMA buffer
mapped from one piece of non-paged data:
dma_desc[N + 0],
dma_desc[N + 1],
dma_desc[N + 2].
Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold
extra information to be reused in stmmac_tx_clean():
tx_q->tx_skbuff_dma[N + 0],
tx_q->tx_skbuff_dma[N + 1],
tx_q->tx_skbuff_dma[N + 2].
Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer
address returned by DMA mapping call. stmmac_tx_clean() will try to
unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf
is a valid buffer address.
The expected behavior that saves DMA buffer address of this non-paged
data to tx_q->tx_skbuff_dma[entry].buf is:
tx_q->tx_skbuff_dma[N + 0].buf = NULL;
tx_q->tx_skbuff_dma[N + 1].buf = NULL;
tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single();
Unfortunately, the current code misbehaves like this:
tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single();
tx_q->tx_skbuff_dma[N + 1].buf = NULL;
tx_q->tx_skbuff_dma[N + 2].buf = NULL;
On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the
DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address
obviously, then the DMA buffer will be unmapped immediately.
There may be a rare case that the DMA engine does not finish the
pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go
horribly wrong, DMA is going to access a unmapped/unreferenced memory
region, corrupted data will be transmited or iommu fault will be
triggered :(
In contrast, the for-loop that maps SKB fragments behaves perfectly
as expected, and that is how the driver should do for both non-paged
data and paged frags actually.
This patch corrects DMA map/unmap sequences by fixing the array index
for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address.
Tested and verified on DWXGMAC CORE 3.20a |
["https://git.kernel.org/stable/c/07c9c26e37542486e34d767505e842f48f29c3f6","https://git.kernel.org/stable/c/58d23d835eb498336716cca55b5714191a309286","https://git.kernel.org/stable/c/66600fac7a984dea4ae095411f644770b2561ede","https://git.kernel.org/stable/c/a3ff23f7c3f0e13f718900803e090fd3997d6bc9","https://git.kernel.org/stable/c/ece593fc9c00741b682869d3f3dc584d37b7c9df"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47684
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: check skb is non-NULL in tcp_rto_delta_us()
We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic
kernel that are running ceph and recently hit a null ptr dereference in
tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also
saw it getting hit from the RACK case as well. Here are examples of the oops
messages we saw in each of those cases:
Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020
Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode
Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page
Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0
Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI
Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu
Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023
Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160
Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3
Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246
Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000
Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60
Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8
Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900
Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30
Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000
Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0
Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554
Jul 26 15:05:02 rx [11061395.916786] Call Trace:
Jul 26 15:05:02 rx [11061395.919488]
Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f
Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9
Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380
Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0
Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50
Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0
Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20
Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450
Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140
Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90
Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0
Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40
Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160
Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160
Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220
Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240
Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0
Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240
Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130
Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280
Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10
Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30
Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even
---truncated--- |
["https://git.kernel.org/stable/c/09aea49fbc7e755a915c405644f347137cdb62b0","https://git.kernel.org/stable/c/16e0387d87fc858e34449fdf2b14ed5837f761db","https://git.kernel.org/stable/c/570f7d8c9bf14f041152ba8353d4330ef7575915","https://git.kernel.org/stable/c/5c4c03288a4aea705e36aa44119c13d7ee4dce99","https://git.kernel.org/stable/c/81d18c152e3f82bacadf83bc0a471b2363b9cc18","https://git.kernel.org/stable/c/96c4983eab2a5da235f7fff90beaf17b008ba029","https://git.kernel.org/stable/c/ad4f0a14d6856e68f023fc4e5017cfd881a3dfbc","https://git.kernel.org/stable/c/c8770db2d54437a5f49417ae7b46f7de23d14db6","https://git.kernel.org/stable/c/ec31cf42fc4e35bb1248ce6eb1de6de9f851ac86"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47699
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential null-ptr-deref in nilfs_btree_insert()
Patch series "nilfs2: fix potential issues with empty b-tree nodes".
This series addresses three potential issues with empty b-tree nodes that
can occur with corrupted filesystem images, including one recently
discovered by syzbot.
This patch (of 3):
If a b-tree is broken on the device, and the b-tree height is greater than
2 (the level of the root node is greater than 1) even if the number of
child nodes of the b-tree root is 0, a NULL pointer dereference occurs in
nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert().
This is because, when the number of child nodes of the b-tree root is 0,
nilfs_btree_do_lookup() does not set the block buffer head in any of
path[x].bp_bh, leaving it as the initial value of NULL, but if the level
of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(),
which accesses the buffer memory of path[x].bp_bh, is called.
Fix this issue by adding a check to nilfs_btree_root_broken(), which
performs sanity checks when reading the root node from the device, to
detect this inconsistency.
Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause
early on. |
["https://git.kernel.org/stable/c/1d94dbdfbb64cc48d10dec65cc3c4fbf2497b343","https://git.kernel.org/stable/c/21839b6fbc3c41b3e374ecbdb0cabbbb2c53cf34","https://git.kernel.org/stable/c/24bf40740a3da6b4056721da34997ae6938f3da1","https://git.kernel.org/stable/c/2b78e9df10fb7f4e9d3d7a18417dd72fbbc1dfd0","https://git.kernel.org/stable/c/3644554d308ddf2669e459a1551a7edf60b2d62b","https://git.kernel.org/stable/c/73d23ecf234b7a6d47fb883f2dabe10e3230b31d","https://git.kernel.org/stable/c/9403001ad65ae4f4c5de368bdda3a0636b51d51a","https://git.kernel.org/stable/c/db73500d3f0e558eb642aae1d4782e7726b4a03f","https://git.kernel.org/stable/c/f68523e0f26faade18833fbef577a4295d8e2c94"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47706
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
block, bfq: fix possible UAF for bfqq->bic with merge chain
1) initial state, three tasks:
Process 1 Process 2 Process 3
(BIC1) (BIC2) (BIC3)
| Λ | Λ | Λ
| | | | | |
V | V | V |
bfqq1 bfqq2 bfqq3
process ref: 1 1 1
2) bfqq1 merged to bfqq2:
Process 1 Process 2 Process 3
(BIC1) (BIC2) (BIC3)
| | | Λ
\--------------\| | |
V V |
bfqq1--------->bfqq2 bfqq3
process ref: 0 2 1
3) bfqq2 merged to bfqq3:
Process 1 Process 2 Process 3
(BIC1) (BIC2) (BIC3)
here -> Λ | |
\--------------\ \-------------\|
V V
bfqq1--------->bfqq2---------->bfqq3
process ref: 0 1 3
In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then
get bfqq3 through merge chain, and finially handle IO by bfqq3.
Howerver, current code will think bfqq2 is owned by BIC1, like initial
state, and set bfqq2->bic to BIC1.
bfq_insert_request
-> by Process 1
bfqq = bfq_init_rq(rq)
bfqq = bfq_get_bfqq_handle_split
bfqq = bic_to_bfqq
-> get bfqq2 from BIC1
bfqq->ref++
rq->elv.priv[0] = bic
rq->elv.priv[1] = bfqq
if (bfqq_process_refs(bfqq) == 1)
bfqq->bic = bic
-> record BIC1 to bfqq2
__bfq_insert_request
new_bfqq = bfq_setup_cooperator
-> get bfqq3 from bfqq2->new_bfqq
bfqq_request_freed(bfqq)
new_bfqq->ref++
rq->elv.priv[1] = new_bfqq
-> handle IO by bfqq3
Fix the problem by checking bfqq is from merge chain fist. And this
might fix a following problem reported by our syzkaller(unreproducible):
==================================================================
BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline]
BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline]
BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889
Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595
CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
Workqueue: kblockd blk_mq_requeue_work
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:364 [inline]
print_report+0x10d/0x610 mm/kasan/report.c:475
kasan_report+0x8e/0xc0 mm/kasan/report.c:588
bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline]
bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline]
bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889
bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757
bfq_init_rq block/bfq-iosched.c:6876 [inline]
bfq_insert_request block/bfq-iosched.c:6254 [inline]
bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304
blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593
blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502
process_one_work kernel/workqueue.c:2627 [inline]
process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700
worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781
kthread+0x33c/0x440 kernel/kthread.c:388
ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305
</TASK>
Allocated by task 20776:
kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
kasan_set_track+0x25/0x30 mm/kasan/common.c:52
__kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328
kasan_slab_alloc include/linux/kasan.h:188 [inline]
slab_post_alloc_hook mm/slab.h:763 [inline]
slab_alloc_node mm/slub.c:3458 [inline]
kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503
ioc_create_icq block/blk-ioc.c:370 [inline]
---truncated--- |
["https://git.kernel.org/stable/c/18ad4df091dd5d067d2faa8fce1180b79f7041a7","https://git.kernel.org/stable/c/6d130db286ad0ea392c96ebb2551acf0d7308048","https://git.kernel.org/stable/c/7faed2896d78e48ec96229e73b30b0af6c00a9aa","https://git.kernel.org/stable/c/880692ee233ba63808182705b3333403413b58f5","https://git.kernel.org/stable/c/8aa9de02a4be2e7006e636816ce19b0d667ceaa3","https://git.kernel.org/stable/c/a9bdd5b36887d2bacb8bc777fd18317c99fc2587","https://git.kernel.org/stable/c/bc2140534b2aae752e4f7cb4489642dbb5ec4777","https://git.kernel.org/stable/c/ddbdaad123254fb53e32480cb74a486a6868b1e0","https://git.kernel.org/stable/c/e1277ae780cca4e69ef5468d4582dfd48f0b8320"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47713
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()
Since '__dev_queue_xmit()' should be called with interrupts enabled,
the following backtrace:
ieee80211_do_stop()
...
spin_lock_irqsave(&local->queue_stop_reason_lock, flags)
...
ieee80211_free_txskb()
ieee80211_report_used_skb()
ieee80211_report_ack_skb()
cfg80211_mgmt_tx_status_ext()
nl80211_frame_tx_status()
genlmsg_multicast_netns()
genlmsg_multicast_netns_filtered()
nlmsg_multicast_filtered()
netlink_broadcast_filtered()
do_one_broadcast()
netlink_broadcast_deliver()
__netlink_sendskb()
netlink_deliver_tap()
__netlink_deliver_tap_skb()
dev_queue_xmit()
__dev_queue_xmit() ; with IRQS disabled
...
spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags)
issues the warning (as reported by syzbot reproducer):
WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120
Fix this by implementing a two-phase skb reclamation in
'ieee80211_do_stop()', where actual work is performed
outside of a section with interrupts disabled. |
["https://git.kernel.org/stable/c/04f75f5bae33349283d6886901d9acd2f110c024","https://git.kernel.org/stable/c/058c9026ad79dc98572442fd4c7e9a36aba6f596","https://git.kernel.org/stable/c/07eb0bd7b0a8abed9d45e0f567c9af1dc83e5268","https://git.kernel.org/stable/c/9d301de12da6e1bb069a9835c38359b8e8135121","https://git.kernel.org/stable/c/acb53a716e492a02479345157c43f21edc8bc64b","https://git.kernel.org/stable/c/ad4b7068b101fbbb4a9ca4b99b25eb051a9482ec","https://git.kernel.org/stable/c/db5ca4b42ccfa42d2af7b335ff12578e57775c02","https://git.kernel.org/stable/c/eab272972cffff9cd973b8e4055a8e81c64f7e6a","https://git.kernel.org/stable/c/f232916fab67ca1c3425926df4a866e59ff26908"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47737
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
nfsd: call cache_put if xdr_reserve_space returns NULL
If not enough buffer space available, but idmap_lookup has triggered
lookup_fn which calls cache_get and returns successfully. Then we
missed to call cache_put here which pairs with cache_get.
Reviwed-by: Jeff Layton <jlayton@kernel.org> |
["https://git.kernel.org/stable/c/3e8081ebff12bec1347deaceb6bce0765cce54df","https://git.kernel.org/stable/c/81821617312988096f5deccf0f7da6f888e98056","https://git.kernel.org/stable/c/8d0765f86135e27f0bb5c950c136495719b4c834","https://git.kernel.org/stable/c/9803ab882d565a8fb2dde5999d98866d1c499dfd","https://git.kernel.org/stable/c/9f03f0016ff797932551881c7e06ae50e9c39134","https://git.kernel.org/stable/c/a1afbbb5276f943ad7173d0b4c626b8c75a260da","https://git.kernel.org/stable/c/c6b16e700cf4d959af524bd9d3978407ff7ce462","https://git.kernel.org/stable/c/d078cbf5c38de83bc31f83c47dcd2184c04a50c7","https://git.kernel.org/stable/c/e32ee6a61041925d1a05c14d10352dcfce9ef029"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47749
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cxgb4: Added NULL check for lookup_atid
The lookup_atid() function can return NULL if the ATID is
invalid or does not exist in the identifier table, which
could lead to dereferencing a null pointer without a
check in the `act_establish()` and `act_open_rpl()` functions.
Add a NULL check to prevent null pointer dereferencing.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/0d50ae281a1712b9b2ca72830a96b8f11882358d","https://git.kernel.org/stable/c/39cb9f39913566ec5865581135f3e8123ad1aee1","https://git.kernel.org/stable/c/4e1fe68d695af367506ea3c794c5969630f21697","https://git.kernel.org/stable/c/54aaa3ed40972511e423b604324b881425b9ff1e","https://git.kernel.org/stable/c/b11318dc8a1ec565300bb1a9073095af817cc508","https://git.kernel.org/stable/c/b12e25d91c7f97958341538c7dc63ee49d01548f","https://git.kernel.org/stable/c/b9c94c8ba5a713817cffd74c4bacc05187469624","https://git.kernel.org/stable/c/dd598ac57dcae796cb58551074660c39b43fb155","https://git.kernel.org/stable/c/e766e6a92410ca269161de059fff0843b8ddd65f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49877
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate
When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger
NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if
bh is NULL. |
["https://git.kernel.org/stable/c/01cb2e751cc61ade454c9bc1aaa2eac1f8197112","https://git.kernel.org/stable/c/190d98bcd61117a78fe185222d162180f061a6ca","https://git.kernel.org/stable/c/33b525cef4cff49e216e4133cc48452e11c0391e","https://git.kernel.org/stable/c/46b1edf0536a5291a8ad2337f88c926214b209d9","https://git.kernel.org/stable/c/4846e72ab5a0726e49ad4188b9d9df091ae78c64","https://git.kernel.org/stable/c/61b84013e560382cbe7dd56758be3154d43a3988","https://git.kernel.org/stable/c/d52c5652e7dcb7a0648bbb8642cc3e617070ab49","https://git.kernel.org/stable/c/df944dc46d06af65a75191183d52be017e6b9dbe","https://git.kernel.org/stable/c/e68c8323355e8cedfbe0bec7d5a39009f61640b6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49944
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start
In sctp_listen_start() invoked by sctp_inet_listen(), it should set the
sk_state back to CLOSED if sctp_autobind() fails due to whatever reason.
Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse
is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will
be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash
is NULL.
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617
Call Trace:
<TASK>
__sys_listen_socket net/socket.c:1883 [inline]
__sys_listen+0x1b7/0x230 net/socket.c:1894
__do_sys_listen net/socket.c:1902 [inline] |
["https://git.kernel.org/stable/c/0e4e2e60556c6ed00e8450b720f106a268d23062","https://git.kernel.org/stable/c/7f64cb5b4d8c872296eda0fdce3bcf099eec7aa7","https://git.kernel.org/stable/c/89bbead9d897c77d0b566349c8643030ff2abeba","https://git.kernel.org/stable/c/8beee4d8dee76b67c75dc91fd8185d91e845c160","https://git.kernel.org/stable/c/9230a59eda0878d7ecaa901d876aec76f57bd455","https://git.kernel.org/stable/c/dd70c8a89ef99c3d53127fe19e51ef47c3f860fa","https://git.kernel.org/stable/c/e7a8442195e8ebd97df467ce4742980ab57edcce","https://git.kernel.org/stable/c/e914bf68dab88815a7ae7b7a3a5e8913c8ff14a5","https://git.kernel.org/stable/c/f032e1dac30b3376c7d6026fb01a8c403c47a80d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49948
|
Medium |
fixed |
- 4.19.323
- 5.4.285
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
net: add more sanity checks to qdisc_pkt_len_init()
One path takes care of SKB_GSO_DODGY, assuming
skb->len is bigger than hdr_len.
virtio_net_hdr_to_skb() does not fully dissect TCP headers,
it only make sure it is at least 20 bytes.
It is possible for an user to provide a malicious 'GSO' packet,
total length of 80 bytes.
- 20 bytes of IPv4 header
- 60 bytes TCP header
- a small gso_size like 8
virtio_net_hdr_to_skb() would declare this packet as a normal
GSO packet, because it would see 40 bytes of payload,
bigger than gso_size.
We need to make detect this case to not underflow
qdisc_skb_cb(skb)->pkt_len. |
["https://git.kernel.org/stable/c/1eebe602a8d8264a12e35e39d0645fa88dbbacdd","https://git.kernel.org/stable/c/2415f465730e48b6e38da1c7c097317bf5dd2d20","https://git.kernel.org/stable/c/27a8fabc54d2f960d47bdfbebf2bdc6e8a92a4c4","https://git.kernel.org/stable/c/473426a1d53a68dd1e718e6cd00d57936993fa6c","https://git.kernel.org/stable/c/566a931a1436d0e0ad13708ea55479b95426213c","https://git.kernel.org/stable/c/9b0ee571d20a238a22722126abdfde61f1b2bdd0","https://git.kernel.org/stable/c/ab9a9a9e9647392a19e7a885b08000e89c86b535","https://git.kernel.org/stable/c/d7d1a28f5dd57b4d83def876f8d7b4403bd37df9","https://git.kernel.org/stable/c/ff1c3cadcf405ab37dd91418a62a7acecf3bc5e2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49952
|
Medium |
fixed |
- 4.19.323
- 5.4.285
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: prevent nf_skb_duplicated corruption
syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write
per-cpu variable nf_skb_duplicated in an unsafe way [1].
Disabling preemption as hinted by the splat is not enough,
we have to disable soft interrupts as well.
[1]
BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316
caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87
CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:93 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49
nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87
nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30
expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288
nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23
nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626
nf_hook+0x2c4/0x450 include/linux/netfilter.h:269
NF_HOOK_COND include/linux/netfilter.h:302 [inline]
ip_output+0x185/0x230 net/ipv4/ip_output.c:433
ip_local_out net/ipv4/ip_output.c:129 [inline]
ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495
udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981
udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x1a6/0x270 net/socket.c:745
____sys_sendmsg+0x525/0x7d0 net/socket.c:2597
___sys_sendmsg net/socket.c:2651 [inline]
__sys_sendmmsg+0x3b2/0x740 net/socket.c:2737
__do_sys_sendmmsg net/socket.c:2766 [inline]
__se_sys_sendmmsg net/socket.c:2763 [inline]
__x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f4ce4f7def9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9
RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006
RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68
</TASK> |
["https://git.kernel.org/stable/c/38e3fd0c4a2616052eb3c8f4e6f32d1ff47cd663","https://git.kernel.org/stable/c/4e3542f40f3a94efa59ea328e307c50601ed7065","https://git.kernel.org/stable/c/50067d8b3f48e4cd4c9e817d3e9a5b5ff3507ca7","https://git.kernel.org/stable/c/531754952f5dfc4b141523088147071d6e6112c4","https://git.kernel.org/stable/c/752e1924604254f1708f3e3700283a86ebdd325d","https://git.kernel.org/stable/c/92ceba94de6fb4cee2bf40b485979c342f44a492","https://git.kernel.org/stable/c/b40b027a0c0cc1cb9471a13f9730bb2fff12a15b","https://git.kernel.org/stable/c/c0add6ed2cf1c4733cd489efc61faeccd3433b41","https://git.kernel.org/stable/c/f839c5cd348201fec440d987cbca9b979bdb4fa7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49957
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix null-ptr-deref when journal load failed.
During the mounting process, if journal_reset() fails because of too short
journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer.
Subsequently, ocfs2_journal_shutdown() calls
jbd2_journal_flush()->jbd2_cleanup_journal_tail()->
__jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail()
->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer
dereference error.
To resolve this issue, we should check the JBD2_LOADED flag to ensure the
journal was properly loaded. Additionally, use journal instead of
osb->journal directly to simplify the code. |
["https://git.kernel.org/stable/c/387bf565cc03e2e8c720b8b4798efea4aacb6962","https://git.kernel.org/stable/c/5784d9fcfd43bd853654bb80c87ef293b9e8e80a","https://git.kernel.org/stable/c/703b2c7e0798d263154dc8593dc2345f75dc077f","https://git.kernel.org/stable/c/82dfdd1e31e774578f76ce6dc90c834f96403a0f","https://git.kernel.org/stable/c/86a89e75e9e4dfa768b97db466ad6bedf2e7ea5b","https://git.kernel.org/stable/c/bf605ae98dab5c15c5b631d4d7f88898cb41b649","https://git.kernel.org/stable/c/f60e94a83db799bde625ac8671a5b4a6354e7120","https://git.kernel.org/stable/c/fd89d92c1140cee8f59de336cb37fa65e359c123","https://git.kernel.org/stable/c/ff55291fb36779819211b596da703389135f5b05"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49958
|
Medium |
fixed |
- 3.2
- 3.4
- 3.9
- 3.10
- 3.11
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: reserve space for inline xattr before attaching reflink tree
One of our customers reported a crash and a corrupted ocfs2 filesystem.
The crash was due to the detection of corruption. Upon troubleshooting,
the fsck -fn output showed the below corruption
[EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record,
but fsck believes the largest valid value is 227. Clamp the next record value? n
The stat output from the debugfs.ocfs2 showed the following corruption
where the "Next Free Rec:" had overshot the "Count:" in the root metadata
block.
Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856)
FS Generation: 904309833 (0x35e6ac49)
CRC32: 00000000 ECC: 0000
Type: Regular Attr: 0x0 Flags: Valid
Dynamic Features: (0x16) HasXattr InlineXattr Refcounted
Extended Attributes Block: 0 Extended Attributes Inline Size: 256
User: 0 (root) Group: 0 (root) Size: 281320357888
Links: 1 Clusters: 141738
ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024
atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024
mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024
dtime: 0x0 -- Wed Dec 31 17:00:00 1969
Refcount Block: 2777346
Last Extblk: 2886943 Orphan Slot: 0
Sub Alloc Slot: 0 Sub Alloc Bit: 14
Tree Depth: 1 Count: 227 Next Free Rec: 230
## Offset Clusters Block#
0 0 2310 2776351
1 2310 2139 2777375
2 4449 1221 2778399
3 5670 731 2779423
4 6401 566 2780447
....... .... .......
....... .... .......
The issue was in the reflink workfow while reserving space for inline
xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the
time this function is called the reflink tree is already recreated at the
destination inode from the source inode. At this point, this function
reserves space for inline xattrs at the destination inode without even
checking if there is space at the root metadata block. It simply reduces
the l_count from 243 to 227 thereby making space of 256 bytes for inline
xattr whereas the inode already has extents beyond this index (in this
case up to 230), thereby causing corruption.
The fix for this is to reserve space for inline metadata at the destination
inode before the reflink tree gets recreated. The customer has verified the
fix. |
["https://git.kernel.org/stable/c/020f5c53c17f66c0a8f2d37dad27ace301b8d8a1","https://git.kernel.org/stable/c/5c2072f02c0d75802ec28ec703b7d43a0dd008b5","https://git.kernel.org/stable/c/5c9807c523b4fca81d3e8e864dabc8c806402121","https://git.kernel.org/stable/c/5ca60b86f57a4d9648f68418a725b3a7de2816b0","https://git.kernel.org/stable/c/637c00e06564a945e9d0edb3d78d362d64935f9f","https://git.kernel.org/stable/c/74364cb578dcc0b6c9109519d19cbe5a56afac9a","https://git.kernel.org/stable/c/96ce4c3537114d1698be635f5e36c62dc49df7a4","https://git.kernel.org/stable/c/9f9a8f3ac65b4147f1a7b6c05fad5192c0e3c3d9","https://git.kernel.org/stable/c/aac31d654a0a31cb0d2fa36ae694f4e164a52707"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49959
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error
In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail()
to recover some journal space. But if an error occurs while executing
jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free
space right away, we try other branches, and if j_committing_transaction
is NULL (i.e., the tid is 0), we will get the following complain:
============================================
JBD2: I/O error when updating journal superblock for sdd-8.
__jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available
__jbd2_log_wait_for_space: no way to get more journal space in sdd-8
------------[ cut here ]------------
WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0
Modules linked in:
CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1
RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0
Call Trace:
<TASK>
add_transaction_credits+0x5d1/0x5e0
start_this_handle+0x1ef/0x6a0
jbd2__journal_start+0x18b/0x340
ext4_dirty_inode+0x5d/0xb0
__mark_inode_dirty+0xe4/0x5d0
generic_update_time+0x60/0x70
[...]
============================================
So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to
clean up at the moment, continue to try to reclaim free space in other ways.
Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt
when updating journal superblock fails") to make jbd2_cleanup_journal_tail
return the correct error code. |
["https://git.kernel.org/stable/c/1c62dc0d82c62f0dc8fcdc4843208e522acccaf5","https://git.kernel.org/stable/c/3ced0fe6c0eff032733ea8b38778b34707270138","https://git.kernel.org/stable/c/481e8f18a290e39e04ddb7feb2bb2a2cc3b213ed","https://git.kernel.org/stable/c/70bae48377a2c4296fd3caf4caf8f11079111019","https://git.kernel.org/stable/c/801a35dfef6996f3d5eaa96a59caf00440d9165e","https://git.kernel.org/stable/c/c6bf043b210eac67d35a114e345c4e5585672913","https://git.kernel.org/stable/c/d5dc65370a746750dbb2f03eabcf86b18db65f32","https://git.kernel.org/stable/c/ec7f8337c98ad281020ad1f11ba492462d80737a","https://git.kernel.org/stable/c/f5cacdc6f2bb2a9bf214469dd7112b43dd2dd68a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49975
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
uprobes: fix kernel info leak via "[uprobes]" vma
xol_add_vma() maps the uninitialized page allocated by __create_xol_area()
into userspace. On some architectures (x86) this memory is readable even
without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ,
although this doesn't really matter, debugger can read this memory anyway. |
["https://git.kernel.org/stable/c/21cb47db1ec9765f91304763a24565ddc22d2492","https://git.kernel.org/stable/c/24141df5a8615790950deedd926a44ddf1dfd6d8","https://git.kernel.org/stable/c/2aa45f43709ba2082917bd2973d02687075b6eee","https://git.kernel.org/stable/c/34820304cc2cd1804ee1f8f3504ec77813d29c8e","https://git.kernel.org/stable/c/5b981d8335e18aef7908a068529a3287258ff6d8","https://git.kernel.org/stable/c/9634e8dc964a4adafa7e1535147abd7ec29441a6","https://git.kernel.org/stable/c/f31f92107e5a8ecc8902705122c594e979a351fe","https://git.kernel.org/stable/c/f561b48d633ac2e7d0d667020fc634a96ade33a0","https://git.kernel.org/stable/c/fe5e9182d3e227476642ae2b312e2356c4d326a3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43863
|
Medium |
fixed |
- 5.15.165
- 6.1.104
- 6.6.45
- 6.10.4
|
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix a deadlock in dma buf fence polling
Introduce a version of the fence ops that on release doesn't remove
the fence from the pending list, and thus doesn't require a lock to
fix poll->fence wait->fence unref deadlocks.
vmwgfx overwrites the wait callback to iterate over the list of all
fences and update their status, to do that it holds a lock to prevent
the list modifcations from other threads. The fence destroy callback
both deletes the fence and removes it from the list of pending
fences, for which it holds a lock.
dma buf polling cb unrefs a fence after it's been signaled: so the poll
calls the wait, which signals the fences, which are being destroyed.
The destruction tries to acquire the lock on the pending fences list
which it can never get because it's held by the wait from which it
was called.
Old bug, but not a lot of userspace apps were using dma-buf polling
interfaces. Fix those, in particular this fixes KDE stalls/deadlock. |
["https://git.kernel.org/stable/c/3b933b16c996af8adb6bc1b5748a63dfb41a82bc","https://git.kernel.org/stable/c/9e20d028d8d1deb1e7fed18f22ffc01669cf3237","https://git.kernel.org/stable/c/a8943969f9ead2fd3044fc826140a21622ef830e","https://git.kernel.org/stable/c/c98ab18b9f315ff977c2c65d7c71298ef98be8e3","https://git.kernel.org/stable/c/e58337100721f3cc0c7424a18730e4f39844934f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53131
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint
Patch series "nilfs2: fix null-ptr-deref bugs on block tracepoints".
This series fixes null pointer dereference bugs that occur when using
nilfs2 and two block-related tracepoints.
This patch (of 2):
It has been reported that when using "block:block_touch_buffer"
tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a
NULL pointer dereference, or a general protection fault when KASAN is
enabled.
This happens because since the tracepoint was added in touch_buffer(), it
references the dev_t member bh->b_bdev->bd_dev regardless of whether the
buffer head has a pointer to a block_device structure. In the current
implementation, the block_device structure is set after the function
returns to the caller.
Here, touch_buffer() is used to mark the folio/page that owns the buffer
head as accessed, but the common search helper for folio/page used by the
caller function was optimized to mark the folio/page as accessed when it
was reimplemented a long time ago, eliminating the need to call
touch_buffer() here in the first place.
So this solves the issue by eliminating the touch_buffer() call itself. |
["https://git.kernel.org/stable/c/085556bf8c70e2629e02e79268dac3016a08b8bf","https://git.kernel.org/stable/c/19c71cdd77973f99a9adc3190130bc3aa7ae5423","https://git.kernel.org/stable/c/3b2a4fd9bbee77afdd3ed5a05a0c02b6cde8d3b9","https://git.kernel.org/stable/c/59b49ca67cca7b007a5afd3de0283c8008157665","https://git.kernel.org/stable/c/6438f3f42cda825f6f59b4e45ac3a1da28a6f2c9","https://git.kernel.org/stable/c/77e47f89d32c2d72eb33d0becbce7abe14d061f4","https://git.kernel.org/stable/c/b017697a517f8779ada4e8ce1c2c75dbf60a2636","https://git.kernel.org/stable/c/cd45e963e44b0f10d90b9e6c0e8b4f47f3c92471"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48896
|
Medium |
fixed |
- 5.4.229
- 5.10.164
- 5.15.89
- 6.1.7
|
In the Linux kernel, the following vulnerability has been resolved:
ixgbe: fix pci device refcount leak
As the comment of pci_get_domain_bus_and_slot() says, it
returns a PCI device with refcount incremented, when finish
using it, the caller must decrement the reference count by
calling pci_dev_put().
In ixgbe_get_first_secondary_devfn() and ixgbe_x550em_a_has_mii(),
pci_dev_put() is called to avoid leak. |
["https://git.kernel.org/stable/c/112df4cd2b09acd64bcd18f5ef83ba5d07b34bf0","https://git.kernel.org/stable/c/4c93422a54cd6a349988f42e1c6bf082cf4ea9d8","https://git.kernel.org/stable/c/53cefa802f070d46c0c518f4865be2c749818a18","https://git.kernel.org/stable/c/b93fb4405fcb5112c5739c5349afb52ec7f15c07","https://git.kernel.org/stable/c/c49996c6aa03590e4ef5add8772cb6068d99fd59"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49906
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check null pointer before try to access it
[why & how]
Change the order of the pipe_ctx->plane_state check to ensure that
plane_state is not null before accessing it. |
["https://git.kernel.org/stable/c/1b686053c06ffb9f4524b288110cf2a831ff7a25","https://git.kernel.org/stable/c/2002ccb93004e76a471b180560accb2c1f850f35","https://git.kernel.org/stable/c/ebef6616219ff04abdeb39450625f85419787ee3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49914
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe
This commit addresses a null pointer dereference issue in the
`dcn20_program_pipe` function. The issue could occur when
`pipe_ctx->plane_state` is null.
The fix adds a check to ensure `pipe_ctx->plane_state` is not null
before accessing. This prevents a null pointer dereference.
Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877) |
["https://git.kernel.org/stable/c/65a6fee22d5cfa645cb05489892dc9cd3d142fc2","https://git.kernel.org/stable/c/68f75e6f08aad66069a629db8d7840919156c761","https://git.kernel.org/stable/c/8e4ed3cf1642df0c4456443d865cff61a9598aa8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50009
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value
cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it
and return in case of error.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/5493f9714e4cdaf0ee7cec15899a231400cb1a9f","https://git.kernel.org/stable/c/5f250d44b8191d612355dd97b89b37bbc1b5d2cb","https://git.kernel.org/stable/c/cd9f7bf6cad8b2d3876105ce3c9fc63460a046f6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46720
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix dereference after null check
check the pointer hive before use. |
["https://git.kernel.org/stable/c/00b9594d6310eb33e14d3f07b54866499efe0d50","https://git.kernel.org/stable/c/0aad97bf6d0bc7a34a19f266b0b9fb2861efe64c","https://git.kernel.org/stable/c/1b73ea3d97cc23f9b16d10021782b48397d2b517","https://git.kernel.org/stable/c/b1f7810b05d1950350ac2e06992982974343e441"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52920
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: support non-r10 register spill/fill to/from stack in precision tracking
Use instruction (jump) history to record instructions that performed
register spill/fill to/from stack, regardless if this was done through
read-only r10 register, or any other register after copying r10 into it
*and* potentially adjusting offset.
To make this work reliably, we push extra per-instruction flags into
instruction history, encoding stack slot index (spi) and stack frame
number in extra 10 bit flags we take away from prev_idx in instruction
history. We don't touch idx field for maximum performance, as it's
checked most frequently during backtracking.
This change removes basically the last remaining practical limitation of
precision backtracking logic in BPF verifier. It fixes known
deficiencies, but also opens up new opportunities to reduce number of
verified states, explored in the subsequent patches.
There are only three differences in selftests' BPF object files
according to veristat, all in the positive direction (less states).
File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)
-------------------------------------- ------------- --------- --------- ------------- ---------- ---------- -------------
test_cls_redirect_dynptr.bpf.linked3.o cls_redirect 2987 2864 -123 (-4.12%) 240 231 -9 (-3.75%)
xdp_synproxy_kern.bpf.linked3.o syncookie_tc 82848 82661 -187 (-0.23%) 5107 5073 -34 (-0.67%)
xdp_synproxy_kern.bpf.linked3.o syncookie_xdp 85116 84964 -152 (-0.18%) 5162 5130 -32 (-0.62%)
Note, I avoided renaming jmp_history to more generic insn_hist to
minimize number of lines changed and potential merge conflicts between
bpf and bpf-next trees.
Notice also cur_hist_entry pointer reset to NULL at the beginning of
instruction verification loop. This pointer avoids the problem of
relying on last jump history entry's insn_idx to determine whether we
already have entry for current instruction or not. It can happen that we
added jump history entry because current instruction is_jmp_point(), but
also we need to add instruction flags for stack access. In this case, we
don't want to entries, so we need to reuse last added entry, if it is
present.
Relying on insn_idx comparison has the same ambiguity problem as the one
that was fixed recently in [0], so we avoid that.
[0] https://patchwork.kernel.org/project/netdevbpf/patch/20231110002638.4168352-3-andrii@kernel.org/ |
["https://git.kernel.org/stable/c/199f0452873741fa4b8d4d88958e929030b2f92b","https://git.kernel.org/stable/c/41f6f64e6999a837048b1bd13a2f8742964eca6b","https://git.kernel.org/stable/c/ecc2aeeaa08a355d84d3ca9c3d2512399a194f29"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48914
|
Medium |
fixed |
- 4.19.233
- 5.4.183
- 5.10.104
- 5.15.27
- 5.16.13
|
In the Linux kernel, the following vulnerability has been resolved:
xen/netfront: destroy queues before real_num_tx_queues is zeroed
xennet_destroy_queues() relies on info->netdev->real_num_tx_queues to
delete queues. Since d7dac083414eb5bb99a6d2ed53dc2c1b405224e5
("net-sysfs: update the queue counts in the unregistration path"),
unregister_netdev() indirectly sets real_num_tx_queues to 0. Those two
facts together means, that xennet_destroy_queues() called from
xennet_remove() cannot do its job, because it's called after
unregister_netdev(). This results in kfree-ing queues that are still
linked in napi, which ultimately crashes:
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 1 PID: 52 Comm: xenwatch Tainted: G W 5.16.10-1.32.fc32.qubes.x86_64+ #226
RIP: 0010:free_netdev+0xa3/0x1a0
Code: ff 48 89 df e8 2e e9 00 00 48 8b 43 50 48 8b 08 48 8d b8 a0 fe ff ff 48 8d a9 a0 fe ff ff 49 39 c4 75 26 eb 47 e8 ed c1 66 ff <48> 8b 85 60 01 00 00 48 8d 95 60 01 00 00 48 89 ef 48 2d 60 01 00
RSP: 0000:ffffc90000bcfd00 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff88800edad000 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffffc90000bcfc30 RDI: 00000000ffffffff
RBP: fffffffffffffea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: ffff88800edad050
R13: ffff8880065f8f88 R14: 0000000000000000 R15: ffff8880066c6680
FS: 0000000000000000(0000) GS:ffff8880f3300000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000e998c006 CR4: 00000000003706e0
Call Trace:
<TASK>
xennet_remove+0x13d/0x300 [xen_netfront]
xenbus_dev_remove+0x6d/0xf0
__device_release_driver+0x17a/0x240
device_release_driver+0x24/0x30
bus_remove_device+0xd8/0x140
device_del+0x18b/0x410
? _raw_spin_unlock+0x16/0x30
? klist_iter_exit+0x14/0x20
? xenbus_dev_request_and_reply+0x80/0x80
device_unregister+0x13/0x60
xenbus_dev_changed+0x18e/0x1f0
xenwatch_thread+0xc0/0x1a0
? do_wait_intr_irq+0xa0/0xa0
kthread+0x16b/0x190
? set_kthread_struct+0x40/0x40
ret_from_fork+0x22/0x30
</TASK>
Fix this by calling xennet_destroy_queues() from xennet_uninit(),
when real_num_tx_queues is still available. This ensures that queues are
destroyed when real_num_tx_queues is set to 0, regardless of how
unregister_netdev() was called.
Originally reported at
https://github.com/QubesOS/qubes-issues/issues/7257 |
["https://git.kernel.org/stable/c/198cdc287769c717dafff5887c6125cb7a373bf3","https://git.kernel.org/stable/c/47e2f166ed9fe17f24561d6315be2228f6a90209","https://git.kernel.org/stable/c/a1753d5c29a6fb9a8966dcf04cb4f3b71e303ae8","https://git.kernel.org/stable/c/a63eb1e4a2e1a191a90217871e67fba42fd39255","https://git.kernel.org/stable/c/b40c912624775a21da32d1105e158db5f6d0554a","https://git.kernel.org/stable/c/dcf4ff7a48e7598e6b10126cc02177abb8ae4f3f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40965
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
i2c: lpi2c: Avoid calling clk_get_rate during transfer
Instead of repeatedly calling clk_get_rate for each transfer, lock
the clock rate and cache the value.
A deadlock has been observed while adding tlv320aic32x4 audio codec to
the system. When this clock provider adds its clock, the clk mutex is
locked already, it needs to access i2c, which in return needs the mutex
for clk_get_rate as well. |
["https://git.kernel.org/stable/c/2b42e9587a7a9c7b824e0feb92958f258263963e","https://git.kernel.org/stable/c/4268254a39484fc11ba991ae148bacbe75d9cc0a","https://git.kernel.org/stable/c/d038693e08adf9c162c6377800495e4f5a2df045","https://git.kernel.org/stable/c/2b42e9587a7a9c7b824e0feb92958f258263963e","https://git.kernel.org/stable/c/4268254a39484fc11ba991ae148bacbe75d9cc0a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48947
|
Medium |
fixed |
- 4.9.337
- 4.14.303
- 4.19.270
- 5.4.229
- 5.10.161
- 5.15.85
- 6.0.15
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix u8 overflow
By keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increases
multiple times and eventually it will wrap around the maximum number
(i.e., 255).
This patch prevents this by adding a boundary check with
L2CAP_MAX_CONF_RSP
Btmon log:
Bluetooth monitor ver 5.64
= Note: Linux version 6.1.0-rc2 (x86_64) 0.264594
= Note: Bluetooth subsystem version 2.22 0.264636
@ MGMT Open: btmon (privileged) version 1.22 {0x0001} 0.272191
= New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0) [hci0] 13.877604
@ RAW Open: 9496 (privileged) version 2.22 {0x0002} 13.890741
= Open Index: 00:00:00:00:00:00 [hci0] 13.900426
(...)
> ACL Data RX: Handle 200 flags 0x00 dlen 1033 #32 [hci0] 14.273106
invalid packet size (12 != 1033)
08 00 01 00 02 01 04 00 01 10 ff ff ............
> ACL Data RX: Handle 200 flags 0x00 dlen 1547 #33 [hci0] 14.273561
invalid packet size (14 != 1547)
0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@.....
> ACL Data RX: Handle 200 flags 0x00 dlen 2061 #34 [hci0] 14.274390
invalid packet size (16 != 2061)
0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@.......
> ACL Data RX: Handle 200 flags 0x00 dlen 2061 #35 [hci0] 14.274932
invalid packet size (16 != 2061)
0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@.......
= bluetoothd: Bluetooth daemon 5.43 14.401828
> ACL Data RX: Handle 200 flags 0x00 dlen 1033 #36 [hci0] 14.275753
invalid packet size (12 != 1033)
08 00 01 00 04 01 04 00 40 00 00 00 ........@... |
["https://git.kernel.org/stable/c/19a78143961a197de8502f4f29c453b913dc3c29","https://git.kernel.org/stable/c/49d5867819ab7c744852b45509e8469839c07e0e","https://git.kernel.org/stable/c/5550bbf709c323194881737fd290c4bada9e6ead","https://git.kernel.org/stable/c/95f1847a361c7b4bf7d74c06ecb6968455082c1a","https://git.kernel.org/stable/c/9fdc79b571434af7bc742da40a3405f038b637a7","https://git.kernel.org/stable/c/ad528fde0702903208d0a79d88d5a42ae3fc235b","https://git.kernel.org/stable/c/bcd70260ef56e0aee8a4fc6cd214a419900b0765","https://git.kernel.org/stable/c/f3fe6817156a2ad4b06f01afab04638a34d7c9a6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-47518
|
High |
fixed |
|
An issue was discovered in the Linux kernel before 6.0.11. Missing validation of the number of channels in drivers/net/wireless/microchip/wilc1000/cfg80211.c in the WILC1000 wireless driver can trigger a heap-based buffer overflow when copying the list of operating channels from Wi-Fi management frames. |
["https://github.com/torvalds/linux/commit/0cdfa9e6f0915e3d243e2393bfa8a22e12d553b0","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lore.kernel.org/r/20221123153543.8568-5-philipturnbull%40github.com","https://security.netapp.com/advisory/ntap-20230113-0007/","https://github.com/torvalds/linux/commit/0cdfa9e6f0915e3d243e2393bfa8a22e12d553b0","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lore.kernel.org/r/20221123153543.8568-5-philipturnbull%40github.com","https://security.netapp.com/advisory/ntap-20230113-0007/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4208
|
High |
fixed |
- 4.14.322
- 4.19.291
- 5.4.253
- 5.10.190
- 5.15.126
- 6.1.45
- 6.4.10
|
A use-after-free vulnerability in the Linux kernel's net/sched: cls_u32 component can be exploited to achieve local privilege escalation.
When u32_change() is called on an existing filter, the whole tcf_result struct is always copied into the new instance of the filter. This causes a problem when updating a filter bound to a class, as tcf_unbind_filter() is always called on the old instance in the success path, decreasing filter_cnt of the still referenced class and allowing it to be deleted, leading to a use-after-free.
We recommend upgrading past commit 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81","https://kernel.dance/3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.debian.org/security/2023/dsa-5492","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81","https://kernel.dance/3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.debian.org/security/2023/dsa-5492"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-0433
|
Medium |
|
N/A
|
A NULL pointer dereference flaw was found in the Linux kernel's BPF subsystem in the way a user triggers the map_get_next_key function of the BPF bloom filter. This flaw allows a local user to crash the system. This flaw affects Linux kernel versions prior to 5.17-rc1. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2048259","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=3ccdcee28415c4226de05438b4d89eb5514edf73","https://lore.kernel.org/bpf/1640776802-22421-1-git-send-email-tcs.kernel%40gmail.com/t/","https://bugzilla.redhat.com/show_bug.cgi?id=2048259","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=3ccdcee28415c4226de05438b4d89eb5514edf73","https://lore.kernel.org/bpf/1640776802-22421-1-git-send-email-tcs.kernel%40gmail.com/t/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2018-14625
|
High |
|
N/A
|
A flaw was found in the Linux Kernel where an attacker may be able to have an uncontrolled read to kernel-memory from within a vm guest. A race condition between connect() and close() function may allow an attacker using the AF_VSOCK protocol to gather a 4 byte information leak or possibly intercept or corrupt AF_VSOCK messages destined to other clients. |
["https://access.redhat.com/errata/RHSA-2019:2029","https://access.redhat.com/errata/RHSA-2019:2043","https://access.redhat.com/errata/RHSA-2019:4154","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-14625","https://lists.debian.org/debian-lts-announce/2019/05/msg00002.html","https://syzkaller.appspot.com/bug?extid=bd391451452fb0b93039","https://usn.ubuntu.com/3871-1/","https://usn.ubuntu.com/3871-3/","https://usn.ubuntu.com/3871-4/","https://usn.ubuntu.com/3871-5/","https://usn.ubuntu.com/3872-1/","https://usn.ubuntu.com/3878-1/","https://usn.ubuntu.com/3878-2/","https://access.redhat.com/errata/RHSA-2019:2029","https://access.redhat.com/errata/RHSA-2019:2043","https://access.redhat.com/errata/RHSA-2019:4154","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-14625","https://lists.debian.org/debian-lts-announce/2019/05/msg00002.html","https://syzkaller.appspot.com/bug?extid=bd391451452fb0b93039","https://usn.ubuntu.com/3871-1/","https://usn.ubuntu.com/3871-3/","https://usn.ubuntu.com/3871-4/","https://usn.ubuntu.com/3871-5/","https://usn.ubuntu.com/3872-1/","https://usn.ubuntu.com/3878-1/","https://usn.ubuntu.com/3878-2/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-6535
|
High |
|
N/A
|
A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver, causing kernel panic and a denial of service. |
["https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:0881","https://access.redhat.com/errata/RHSA-2024:0897","https://access.redhat.com/errata/RHSA-2024:1248","https://access.redhat.com/errata/RHSA-2024:2094","https://access.redhat.com/errata/RHSA-2024:3810","https://access.redhat.com/security/cve/CVE-2023-6535","https://bugzilla.redhat.com/show_bug.cgi?id=2254053","https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:0881","https://access.redhat.com/errata/RHSA-2024:0897","https://access.redhat.com/errata/RHSA-2024:1248","https://access.redhat.com/errata/RHSA-2024:2094","https://access.redhat.com/errata/RHSA-2024:3810","https://access.redhat.com/security/cve/CVE-2023-6535","https://bugzilla.redhat.com/show_bug.cgi?id=2254053","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://security.netapp.com/advisory/ntap-20240415-0003/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2008-2544
|
Medium |
|
N/A
|
Mounting /proc filesystem via chroot command silently mounts it in read-write mode. The user could bypass the chroot environment and gain write access to files, he would never have otherwise. |
["https://bugzilla.redhat.com/show_bug.cgi?id=213135"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53124
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: fix data-races around sk->sk_forward_alloc
Syzkaller reported this warning:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0
Modules linked in:
CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:inet_sock_destruct+0x1c5/0x1e0
Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00
RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206
RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007
RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00
RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007
R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00
R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78
FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
? __warn+0x88/0x130
? inet_sock_destruct+0x1c5/0x1e0
? report_bug+0x18e/0x1a0
? handle_bug+0x53/0x90
? exc_invalid_op+0x18/0x70
? asm_exc_invalid_op+0x1a/0x20
? inet_sock_destruct+0x1c5/0x1e0
__sk_destruct+0x2a/0x200
rcu_do_batch+0x1aa/0x530
? rcu_do_batch+0x13b/0x530
rcu_core+0x159/0x2f0
handle_softirqs+0xd3/0x2b0
? __pfx_smpboot_thread_fn+0x10/0x10
run_ksoftirqd+0x25/0x30
smpboot_thread_fn+0xdd/0x1d0
kthread+0xd3/0x100
? __pfx_kthread+0x10/0x10
ret_from_fork+0x34/0x50
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
---[ end trace 0000000000000000 ]---
Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add()
concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked,
which triggers a data-race around sk->sk_forward_alloc:
tcp_v6_rcv
tcp_v6_do_rcv
skb_clone_and_charge_r
sk_rmem_schedule
__sk_mem_schedule
sk_forward_alloc_add()
skb_set_owner_r
sk_mem_charge
sk_forward_alloc_add()
__kfree_skb
skb_release_all
skb_release_head_state
sock_rfree
sk_mem_uncharge
sk_forward_alloc_add()
sk_mem_reclaim
// set local var reclaimable
__sk_mem_reclaim
sk_forward_alloc_add()
In this syzkaller testcase, two threads call
tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like
this:
(cpu 1) | (cpu 2) | sk_forward_alloc
... | ... | 0
__sk_mem_schedule() | | +4096 = 4096
| __sk_mem_schedule() | +4096 = 8192
sk_mem_charge() | | -768 = 7424
| sk_mem_charge() | -768 = 6656
... | ... |
sk_mem_uncharge() | | +768 = 7424
reclaimable=7424 | |
| sk_mem_uncharge() | +768 = 8192
| reclaimable=8192 |
__sk_mem_reclaim() | | -4096 = 4096
| __sk_mem_reclaim() | -8192 = -4096 != 0
The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when
sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock().
Fix the same issue in dccp_v6_do_rcv(). |
["https://git.kernel.org/stable/c/073d89808c065ac4c672c0a613a71b27a80691cb","https://git.kernel.org/stable/c/3f51f8c9d28954cf380100883a02eed35a8277e9","https://git.kernel.org/stable/c/695fb0b9aecfd5dd5b2946ba8897ac2c1eef654d","https://git.kernel.org/stable/c/be7c61ea5f816168c38955eb4e898adc8b4b32fd","https://git.kernel.org/stable/c/c3d052cae566ec2285f5999958a5deb415a0f59e","https://git.kernel.org/stable/c/d285eb9d0641c8344f2836081b4ccb7b3c5cc1b6","https://git.kernel.org/stable/c/fe2c0bd6d1e29ccefdc978b9a290571c93c27473"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42123
|
Medium |
|
N/A
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix double free err_addr pointer warnings
In amdgpu_umc_bad_page_polling_timeout, the amdgpu_umc_handle_bad_pages
will be run many times so that double free err_addr in some special case.
So set the err_addr to NULL to avoid the warnings. |
["https://git.kernel.org/stable/c/506c245f3f1cd989cb89811a7f06e04ff8813a0d","https://git.kernel.org/stable/c/8e24beb3c2b08a4763f920399a9cc577ed440a1a","https://git.kernel.org/stable/c/506c245f3f1cd989cb89811a7f06e04ff8813a0d","https://git.kernel.org/stable/c/8e24beb3c2b08a4763f920399a9cc577ed440a1a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43872
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix soft lockup under heavy CEQE load
CEQEs are handled in interrupt handler currently. This may cause the
CPU core staying in interrupt context too long and lead to soft lockup
under heavy load.
Handle CEQEs in BH workqueue and set an upper limit for the number of
CEQE handled by a single call of work handler. |
["https://git.kernel.org/stable/c/06580b33c183c9f98e2a2ca96a86137179032c08","https://git.kernel.org/stable/c/2fdf34038369c0a27811e7b4680662a14ada1d6b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50245
|
Medium |
fixed |
- 5.15.171
- 6.1.116
- 6.6.60
- 6.11.7
|
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix possible deadlock in mi_read
Mutex lock with another subclass used in ni_lock_dir(). |
["https://git.kernel.org/stable/c/03b097099eef255fbf85ea6a786ae3c91b11f041","https://git.kernel.org/stable/c/34e3220efd666d49965a26840d39f27601ce70f4","https://git.kernel.org/stable/c/47e8a17491e37df53743bc2e72309f8f0d6224af","https://git.kernel.org/stable/c/c8e7d3b72ee57e43d58ba560fe7970dd840a4061","https://git.kernel.org/stable/c/f1bc362fe978952a9304bd0286788b0ae7724f14"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35806
|
Medium |
fixed |
- 4.10
- 4.15
- 4.19.312
- 5.4.274
- 5.10.215
- 5.15.154
- 6.1.84
- 6.6.24
- 6.7.12
- 6.8.3
|
In the Linux kernel, the following vulnerability has been resolved:
soc: fsl: qbman: Always disable interrupts when taking cgr_lock
smp_call_function_single disables IRQs when executing the callback. To
prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.
This is already done by qman_update_cgr and qman_delete_cgr; fix the
other lockers. |
["https://git.kernel.org/stable/c/0e6521b0f93ff350434ed4ae61a250907e65d397","https://git.kernel.org/stable/c/276af8efb05c8e47acf2738a5609dd72acfc703f","https://git.kernel.org/stable/c/584c2a9184a33a40fceee838f856de3cffa19be3","https://git.kernel.org/stable/c/62c3ecd2833cff0eff4a82af4082c44ca8d2518a","https://git.kernel.org/stable/c/a62168653774c36398d65846a98034436ee66d03","https://git.kernel.org/stable/c/af25c5180b2b1796342798f6c56fcfd12f5035bd","https://git.kernel.org/stable/c/b56a793f267679945d1fdb9a280013bd2d0ed7f9","https://git.kernel.org/stable/c/dd199e5b759ffe349622a4b8fbcafc51fc51b1ec","https://git.kernel.org/stable/c/e6378314bb920acb39013051fa65d8f9f8030430","https://git.kernel.org/stable/c/0e6521b0f93ff350434ed4ae61a250907e65d397","https://git.kernel.org/stable/c/276af8efb05c8e47acf2738a5609dd72acfc703f","https://git.kernel.org/stable/c/584c2a9184a33a40fceee838f856de3cffa19be3","https://git.kernel.org/stable/c/62c3ecd2833cff0eff4a82af4082c44ca8d2518a","https://git.kernel.org/stable/c/a62168653774c36398d65846a98034436ee66d03","https://git.kernel.org/stable/c/af25c5180b2b1796342798f6c56fcfd12f5035bd","https://git.kernel.org/stable/c/b56a793f267679945d1fdb9a280013bd2d0ed7f9","https://git.kernel.org/stable/c/dd199e5b759ffe349622a4b8fbcafc51fc51b1ec","https://git.kernel.org/stable/c/e6378314bb920acb39013051fa65d8f9f8030430","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56782
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ACPI: x86: Add adev NULL check to acpi_quirk_skip_serdev_enumeration()
acpi_dev_hid_match() does not check for adev == NULL, dereferencing
it unconditional.
Add a check for adev being NULL before calling acpi_dev_hid_match().
At the moment acpi_quirk_skip_serdev_enumeration() is never called with
a controller_parent without an ACPI companion, but better safe than sorry. |
["https://git.kernel.org/stable/c/4a49194f587a62d972b602e3e1a2c3cfe6567966","https://git.kernel.org/stable/c/e173bce05f7032a8b4964cfef82a4b7668f5f3af"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44972
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not clear page dirty inside extent_write_locked_range()
[BUG]
For subpage + zoned case, the following workload can lead to rsv data
leak at unmount time:
# mkfs.btrfs -f -s 4k $dev
# mount $dev $mnt
# fsstress -w -n 8 -d $mnt -s 1709539240
0/0: fiemap - no filename
0/1: copyrange read - no filename
0/2: write - no filename
0/3: rename - no source filename
0/4: creat f0 x:0 0 0
0/4: creat add id=0,parent=-1
0/5: writev f0[259 1 0 0 0 0] [778052,113,965] 0
0/6: ioctl(FIEMAP) f0[259 1 0 0 224 887097] [1294220,2291618343991484791,0x10000] -1
0/7: dwrite - xfsctl(XFS_IOC_DIOINFO) f0[259 1 0 0 224 887097] return 25, fallback to stat()
0/7: dwrite f0[259 1 0 0 224 887097] [696320,102400] 0
# umount $mnt
The dmesg includes the following rsv leak detection warning (all call
trace skipped):
------------[ cut here ]------------
WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8653 btrfs_destroy_inode+0x1e0/0x200 [btrfs]
---[ end trace 0000000000000000 ]---
------------[ cut here ]------------
WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8654 btrfs_destroy_inode+0x1a8/0x200 [btrfs]
---[ end trace 0000000000000000 ]---
------------[ cut here ]------------
WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8660 btrfs_destroy_inode+0x1a0/0x200 [btrfs]
---[ end trace 0000000000000000 ]---
BTRFS info (device sda): last unmount of filesystem 1b4abba9-de34-4f07-9e7f-157cf12a18d6
------------[ cut here ]------------
WARNING: CPU: 3 PID: 4528 at fs/btrfs/block-group.c:4434 btrfs_free_block_groups+0x338/0x500 [btrfs]
---[ end trace 0000000000000000 ]---
BTRFS info (device sda): space_info DATA has 268218368 free, is not full
BTRFS info (device sda): space_info total=268435456, used=204800, pinned=0, reserved=0, may_use=12288, readonly=0 zone_unusable=0
BTRFS info (device sda): global_block_rsv: size 0 reserved 0
BTRFS info (device sda): trans_block_rsv: size 0 reserved 0
BTRFS info (device sda): chunk_block_rsv: size 0 reserved 0
BTRFS info (device sda): delayed_block_rsv: size 0 reserved 0
BTRFS info (device sda): delayed_refs_rsv: size 0 reserved 0
------------[ cut here ]------------
WARNING: CPU: 3 PID: 4528 at fs/btrfs/block-group.c:4434 btrfs_free_block_groups+0x338/0x500 [btrfs]
---[ end trace 0000000000000000 ]---
BTRFS info (device sda): space_info METADATA has 267796480 free, is not full
BTRFS info (device sda): space_info total=268435456, used=131072, pinned=0, reserved=0, may_use=262144, readonly=0 zone_unusable=245760
BTRFS info (device sda): global_block_rsv: size 0 reserved 0
BTRFS info (device sda): trans_block_rsv: size 0 reserved 0
BTRFS info (device sda): chunk_block_rsv: size 0 reserved 0
BTRFS info (device sda): delayed_block_rsv: size 0 reserved 0
BTRFS info (device sda): delayed_refs_rsv: size 0 reserved 0
Above $dev is a tcmu-runner emulated zoned HDD, which has a max zone
append size of 64K, and the system has 64K page size.
[CAUSE]
I have added several trace_printk() to show the events (header skipped):
> btrfs_dirty_pages: r/i=5/259 dirty start=774144 len=114688
> btrfs_dirty_pages: r/i=5/259 dirty part of page=720896 off_in_page=53248 len_in_page=12288
> btrfs_dirty_pages: r/i=5/259 dirty part of page=786432 off_in_page=0 len_in_page=65536
> btrfs_dirty_pages: r/i=5/259 dirty part of page=851968 off_in_page=0 len_in_page=36864
The above lines show our buffered write has dirtied 3 pages of inode
259 of root 5:
704K 768K 832K 896K
I |////I/////////////////I///////////| I
756K 868K
|///| is the dirtied range using subpage bitmaps. and 'I' is the page
boundary.
Meanwhile all three pages (704K, 768K, 832K) have their PageDirty
flag set.
> btrfs_direct_write: r/i=5/259 start dio filepos=696320 len=102400
Then direct IO writ
---truncated--- |
["https://git.kernel.org/stable/c/97713b1a2ced1e4a2a6c40045903797ebd44d7e0","https://git.kernel.org/stable/c/ba4dedb71356638d8284e34724daca944be70368","https://git.kernel.org/stable/c/d3b403209f767e5857c1b9fda66726e6e6ffc99f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50099
|
Medium |
fixed |
- 4.19.323
- 5.4.285
- 5.10.228
- 5.15.169
- 6.1.114
- 6.6.58
- 6.11.5
|
In the Linux kernel, the following vulnerability has been resolved:
arm64: probes: Remove broken LDR (literal) uprobe support
The simulate_ldr_literal() and simulate_ldrsw_literal() functions are
unsafe to use for uprobes. Both functions were originally written for
use with kprobes, and access memory with plain C accesses. When uprobes
was added, these were reused unmodified even though they cannot safely
access user memory.
There are three key problems:
1) The plain C accesses do not have corresponding extable entries, and
thus if they encounter a fault the kernel will treat these as
unintentional accesses to user memory, resulting in a BUG() which
will kill the kernel thread, and likely lead to further issues (e.g.
lockup or panic()).
2) The plain C accesses are subject to HW PAN and SW PAN, and so when
either is in use, any attempt to simulate an access to user memory
will fault. Thus neither simulate_ldr_literal() nor
simulate_ldrsw_literal() can do anything useful when simulating a
user instruction on any system with HW PAN or SW PAN.
3) The plain C accesses are privileged, as they run in kernel context,
and in practice can access a small range of kernel virtual addresses.
The instructions they simulate have a range of +/-1MiB, and since the
simulated instructions must itself be a user instructions in the
TTBR0 address range, these can address the final 1MiB of the TTBR1
acddress range by wrapping downwards from an address in the first
1MiB of the TTBR0 address range.
In contemporary kernels the last 8MiB of TTBR1 address range is
reserved, and accesses to this will always fault, meaning this is no
worse than (1).
Historically, it was theoretically possible for the linear map or
vmemmap to spill into the final 8MiB of the TTBR1 address range, but
in practice this is extremely unlikely to occur as this would
require either:
* Having enough physical memory to fill the entire linear map all the
way to the final 1MiB of the TTBR1 address range.
* Getting unlucky with KASLR randomization of the linear map such
that the populated region happens to overlap with the last 1MiB of
the TTBR address range.
... and in either case if we were to spill into the final page there
would be larger problems as the final page would alias with error
pointers.
Practically speaking, (1) and (2) are the big issues. Given there have
been no reports of problems since the broken code was introduced, it
appears that no-one is relying on probing these instructions with
uprobes.
Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW
(literal), limiting the use of simulate_ldr_literal() and
simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR
(literal) and LDRSW (literal) will be rejected as
arm_probe_decode_insn() will return INSN_REJECTED. In future we can
consider introducing working uprobes support for these instructions, but
this will require more significant work. |
["https://git.kernel.org/stable/c/20cde998315a3d2df08e26079a3ea7501abce6db","https://git.kernel.org/stable/c/3728b4eb27910ffedd173018279a970705f2e03a","https://git.kernel.org/stable/c/9f1e7735474e7457a4d919a517900e46868ae5f6","https://git.kernel.org/stable/c/acc450aa07099d071b18174c22a1119c57da8227","https://git.kernel.org/stable/c/ad4bc35a6d22e9ff9b67d0d0c38bce654232f195","https://git.kernel.org/stable/c/ae743deca78d9e4b7f4f60ad2f95e20e8ea057f9","https://git.kernel.org/stable/c/bae792617a7e911477f67a3aff850ad4ddf51572","https://git.kernel.org/stable/c/cc86f2e9876c8b5300238cec6bf0bd8c842078ee"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46681
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
pktgen: use cpus_read_lock() in pg_net_init()
I have seen the WARN_ON(smp_processor_id() != cpu) firing
in pktgen_thread_worker() during tests.
We must use cpus_read_lock()/cpus_read_unlock()
around the for_each_online_cpu(cpu) loop.
While we are at it use WARN_ON_ONCE() to avoid a possible syslog flood. |
["https://git.kernel.org/stable/c/5f5f7366dda8ae870e8305d6e7b3c0c2686cd2cf","https://git.kernel.org/stable/c/979b581e4c69257acab1af415ddad6b2d78a2fa5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46705
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: reset mmio mappings with devm
Set our various mmio mappings to NULL. This should make it easier to
catch something rogue trying to mess with mmio after device removal. For
example, we might unmap everything and then start hitting some mmio
address which has already been unmamped by us and then remapped by
something else, causing all kinds of carnage. |
["https://git.kernel.org/stable/c/b1c9fbed3884d3883021d699c7cdf5253a65543a","https://git.kernel.org/stable/c/c7117419784f612d59ee565145f722e8b5541fe6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52584
|
Low |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
spmi: mediatek: Fix UAF on device remove
The pmif driver data that contains the clocks is allocated along with
spmi_controller.
On device remove, spmi_controller will be freed first, and then devres
, including the clocks, will be cleanup.
This leads to UAF because putting the clocks will access the clocks in
the pmif driver data, which is already freed along with spmi_controller.
This can be reproduced by enabling DEBUG_TEST_DRIVER_REMOVE and
building the kernel with KASAN.
Fix the UAF issue by using unmanaged clk_bulk_get() and putting the
clocks before freeing spmi_controller. |
["https://git.kernel.org/stable/c/521f28eedd6b14228c46e3b81e3bf9b90c2818d8","https://git.kernel.org/stable/c/9a3881b1f07db1bb55cb0108e6f05cfd027eaf2e","https://git.kernel.org/stable/c/e821d50ab5b956ed0effa49faaf29912fd4106d9","https://git.kernel.org/stable/c/f8dcafcb54632536684336161da8bdd52120f95e","https://git.kernel.org/stable/c/521f28eedd6b14228c46e3b81e3bf9b90c2818d8","https://git.kernel.org/stable/c/9a3881b1f07db1bb55cb0108e6f05cfd027eaf2e","https://git.kernel.org/stable/c/e821d50ab5b956ed0effa49faaf29912fd4106d9","https://git.kernel.org/stable/c/f8dcafcb54632536684336161da8bdd52120f95e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-27950
|
Medium |
fixed |
|
In drivers/hid/hid-elo.c in the Linux kernel before 5.16.11, a memory leak exists for a certain hid_parse error condition. |
["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.11","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=817b8b9c5396d2b2d92311b46719aad5d3339dbe","https://github.com/torvalds/linux/commit/817b8b9c5396d2b2d92311b46719aad5d3339dbe","https://www.openwall.com/lists/oss-security/2022/03/13/1","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.11","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=817b8b9c5396d2b2d92311b46719aad5d3339dbe","https://github.com/torvalds/linux/commit/817b8b9c5396d2b2d92311b46719aad5d3339dbe","https://www.openwall.com/lists/oss-security/2022/03/13/1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56581
|
High |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.12.4
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: ref-verify: fix use-after-free after invalid ref action
At btrfs_ref_tree_mod() after we successfully inserted the new ref entry
(local variable 'ref') into the respective block entry's rbtree (local
variable 'be'), if we find an unexpected action of BTRFS_DROP_DELAYED_REF,
we error out and free the ref entry without removing it from the block
entry's rbtree. Then in the error path of btrfs_ref_tree_mod() we call
btrfs_free_ref_cache(), which iterates over all block entries and then
calls free_block_entry() for each one, and there we will trigger a
use-after-free when we are called against the block entry to which we
added the freed ref entry to its rbtree, since the rbtree still points
to the block entry, as we didn't remove it from the rbtree before freeing
it in the error path at btrfs_ref_tree_mod(). Fix this by removing the
new ref entry from the rbtree before freeing it.
Syzbot report this with the following stack traces:
BTRFS error (device loop0 state EA): Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615
__btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523
update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512
btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594
btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754
btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116
btrfs_insert_empty_items+0x9c/0x1a0 fs/btrfs/ctree.c:4314
btrfs_insert_empty_item fs/btrfs/ctree.h:669 [inline]
btrfs_insert_orphan_item+0x1f1/0x320 fs/btrfs/orphan.c:23
btrfs_orphan_add+0x6d/0x1a0 fs/btrfs/inode.c:3482
btrfs_unlink+0x267/0x350 fs/btrfs/inode.c:4293
vfs_unlink+0x365/0x650 fs/namei.c:4469
do_unlinkat+0x4ae/0x830 fs/namei.c:4533
__do_sys_unlinkat fs/namei.c:4576 [inline]
__se_sys_unlinkat fs/namei.c:4569 [inline]
__x64_sys_unlinkat+0xcc/0xf0 fs/namei.c:4569
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
BTRFS error (device loop0 state EA): Ref action 1, root 5, ref_root 5, parent 0, owner 260, offset 0, num_refs 1
__btrfs_mod_ref+0x76b/0xac0 fs/btrfs/extent-tree.c:2521
update_ref_for_cow+0x96a/0x11f0
btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594
btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754
btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116
btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411
__btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030
btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline]
__btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137
__btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171
btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313
prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586
relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611
btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081
btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377
__btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161
btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538
BTRFS error (device loop0 state EA): Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615
__btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523
update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512
btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594
btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754
btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116
btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411
__btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030
btrfs_update_delayed_i
---truncated--- |
["https://git.kernel.org/stable/c/4275ac2741941c9c7c2293619fdbacb9f70ba85b","https://git.kernel.org/stable/c/6370db28af9a8ae3bbdfe97f8a48f8f995e144cf","https://git.kernel.org/stable/c/6fd018aa168e472ce35be32296d109db6adb87ea","https://git.kernel.org/stable/c/7c4e39f9d2af4abaf82ca0e315d1fd340456620f","https://git.kernel.org/stable/c/a6f9e7a0bf1185c9070c0de03bb85eafb9abd650","https://git.kernel.org/stable/c/d2b85ce0561fde894e28fa01bd5d32820d585006","https://git.kernel.org/stable/c/dfb9fe7de61f34cc241ab3900bdde93341096e0e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56595
|
High |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
jfs: add a check to prevent array-index-out-of-bounds in dbAdjTree
When the value of lp is 0 at the beginning of the for loop, it will
become negative in the next assignment and we should bail out. |
["https://git.kernel.org/stable/c/368a533152220b0a6f1142327d96c6b6361f3002","https://git.kernel.org/stable/c/3b5d21b56c3774bc84eab0a93aaac22a4475e2c4","https://git.kernel.org/stable/c/491487eeddccc4bb49f2e59d8c8f35bec89c15ca","https://git.kernel.org/stable/c/8a4311bbde702362fe7412045d06ab6767235dac","https://git.kernel.org/stable/c/a174706ba4dad895c40b1d2277bade16dfacdcd9","https://git.kernel.org/stable/c/a3d408870bc19b794646871bc4c3a5daa66f91c5","https://git.kernel.org/stable/c/b15000bcbecf27e0f7c0f149a409e5b865e28ca2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56596
|
High |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix array-index-out-of-bounds in jfs_readdir
The stbl might contain some invalid values. Added a check to
return error code in that case. |
["https://git.kernel.org/stable/c/839f102efb168f02dfdd46717b7c6dddb26b015e","https://git.kernel.org/stable/c/8ff7579554571d92e3deab168f5a7d7b146ed368","https://git.kernel.org/stable/c/97e693593162eef6851d232f0c8148169ed46a5c","https://git.kernel.org/stable/c/9efe72eefd4c4a7ce63b3e4d667d766d2b360cb4","https://git.kernel.org/stable/c/b62f41aeec9d250144c53875b507c1d45ae8c8fc","https://git.kernel.org/stable/c/e7d376f94f72b020f84e77278b150ec1cc27502c","https://git.kernel.org/stable/c/ff9fc48fab0e1ea0d423c23c99b91bba178f0b05"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56598
|
High |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
jfs: array-index-out-of-bounds fix in dtReadFirst
The value of stbl can be sometimes out of bounds due
to a bad filesystem. Added a check with appopriate return
of error code in that case. |
["https://git.kernel.org/stable/c/22dcbf7661c6ffc3247978c254dc40b833a0d429","https://git.kernel.org/stable/c/25f1e673ef61d6bf9a6022e27936785896d74948","https://git.kernel.org/stable/c/2eea5fda5556ef03defebf07b0a12fcd2c5210f4","https://git.kernel.org/stable/c/823d573f5450ca6be80b36f54d1902ac7cd23fb9","https://git.kernel.org/stable/c/8c97a4d5463a1c972ef576ac499ea9b05f956097","https://git.kernel.org/stable/c/ca84a2c9be482836b86d780244f0357e5a778c46","https://git.kernel.org/stable/c/fd993b2180b4c373af8b99aa28d4dcda5c2a8f10"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56600
|
High |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
net: inet6: do not leave a dangling sk pointer in inet6_create()
sock_init_data() attaches the allocated sk pointer to the provided sock
object. If inet6_create() fails later, the sk object is released, but the
sock object retains the dangling sk pointer, which may cause use-after-free
later.
Clear the sock sk pointer on error. |
["https://git.kernel.org/stable/c/276a473c956fb55a6f3affa9ff232e10fffa7b43","https://git.kernel.org/stable/c/35360255ca30776dee34d9fa764cffa24d0a5f65","https://git.kernel.org/stable/c/706b07b7b37f886423846cb38919132090bc40da","https://git.kernel.org/stable/c/79e16a0d339532ea832d85798eb036fc4f9e0cea","https://git.kernel.org/stable/c/9df99c395d0f55fb444ef39f4d6f194ca437d884","https://git.kernel.org/stable/c/f2709d1271cfdf55c670ab5c5982139ab627ddc7","https://git.kernel.org/stable/c/f44fceb71d72d29fb00e0ac84cdf9c081b03cd06"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56601
|
High |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
net: inet: do not leave a dangling sk pointer in inet_create()
sock_init_data() attaches the allocated sk object to the provided sock
object. If inet_create() fails later, the sk object is freed, but the
sock object retains the dangling pointer, which may create use-after-free
later.
Clear the sk pointer in the sock object on error. |
["https://git.kernel.org/stable/c/25447c6aaa7235f155292b0c58a067347e8ae891","https://git.kernel.org/stable/c/2bc34d8c8898ae9fddf4612501aabb22d76c2b2c","https://git.kernel.org/stable/c/3e8258070b0f2aba66b3ef18883de229674fb288","https://git.kernel.org/stable/c/691d6d816f93b2a1008c14178399061466e674ef","https://git.kernel.org/stable/c/9365fa510c6f82e3aa550a09d0c5c6b44dbc78ff","https://git.kernel.org/stable/c/b4513cfd3a10c03c660d5d3d26c2e322efbfdd9b","https://git.kernel.org/stable/c/f8a3f255f7509a209292871715cda03779640c8d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56602
|
High |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()
sock_init_data() attaches the allocated sk object to the provided sock
object. If ieee802154_create() fails later, the allocated sk object is
freed, but the dangling pointer remains in the provided sock object, which
may allow use-after-free.
Clear the sk pointer in the sock object on error. |
["https://git.kernel.org/stable/c/03caa9bfb9fde97fb53d33decd7364514e6825cb","https://git.kernel.org/stable/c/14959fd7538b3be6d7617d9e60e404d6a8d4fd1f","https://git.kernel.org/stable/c/1d5fe782c0ff068d80933f9cfd0fd39d5434bbc9","https://git.kernel.org/stable/c/2b46994a6e76c8cc5556772932b9b60d03a55cd8","https://git.kernel.org/stable/c/b4982fbf13042e3bb33e04eddfea8b1506b5ea65","https://git.kernel.org/stable/c/b4fcd63f6ef79c73cafae8cf4a114def5fc3d80d","https://git.kernel.org/stable/c/e8bd6c5f5dc2234b4ea714380aedeea12a781754"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56603
|
High |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
net: af_can: do not leave a dangling sk pointer in can_create()
On error can_create() frees the allocated sk object, but sock_init_data()
has already attached it to the provided sock object. This will leave a
dangling sk pointer in the sock object and may cause use-after-free later. |
["https://git.kernel.org/stable/c/1fe625f12d090d69f3f084990c7e4c1ff94bfe5f","https://git.kernel.org/stable/c/5947c9ac08f0771ea8ed64186b0d52e9029cb6c0","https://git.kernel.org/stable/c/811a7ca7320c062e15d0f5b171fe6ad8592d1434","https://git.kernel.org/stable/c/884ae8bcee749be43a071d6ed2d89058dbd2425c","https://git.kernel.org/stable/c/8df832e6b945e1ba61467d7f1c9305e314ae92fe","https://git.kernel.org/stable/c/ce39b5576785bb3e66591145aad03d66bc3e778d","https://git.kernel.org/stable/c/db207d19adbac96058685f6257720906ad41d215"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56605
|
High |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()
bt_sock_alloc() allocates the sk object and attaches it to the provided
sock object. On error l2cap_sock_alloc() frees the sk object, but the
dangling pointer is still attached to the sock object, which may create
use-after-free in other code. |
["https://git.kernel.org/stable/c/61686abc2f3c2c67822aa23ce6f160467ec83d35","https://git.kernel.org/stable/c/7c4f78cdb8e7501e9f92d291a7d956591bf73be9","https://git.kernel.org/stable/c/8ad09ddc63ace3950ac43db6fbfe25b40f589dd6","https://git.kernel.org/stable/c/a8677028dd5123e5e525b8195483994d87123de4","https://git.kernel.org/stable/c/bb2f2342a6ddf7c04f9aefbbfe86104cd138e629","https://git.kernel.org/stable/c/daa13175a6dea312a76099066cb4cbd4fc959a84","https://git.kernel.org/stable/c/f6ad641646b67f29c7578dcd6c25813c7dcbf51e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56606
|
High |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
af_packet: avoid erroring out after sock_init_data() in packet_create()
After sock_init_data() the allocated sk object is attached to the provided
sock object. On error, packet_create() frees the sk object leaving the
dangling pointer in the sock object on return. Some other code may try
to use this pointer and cause use-after-free. |
["https://git.kernel.org/stable/c/132e615bb1d7cdec2d3cfbdec2efa630e923fd21","https://git.kernel.org/stable/c/157f08db94123e2ba56877dd0ac88908b13a5dd0","https://git.kernel.org/stable/c/1dc1e1db927056cb323296e2294a855cd003dfe7","https://git.kernel.org/stable/c/46f2a11cb82b657fd15bab1c47821b635e03838b","https://git.kernel.org/stable/c/71b22837a5e55ac27d6a14b9cdf2326587405c4f","https://git.kernel.org/stable/c/a6cf750b737374454a4e03a5ed449a3eb0c96414","https://git.kernel.org/stable/c/fd09880b16d33aa5a7420578e01cd79148fa9829"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56642
|
High |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
tipc: Fix use-after-free of kernel socket in cleanup_bearer().
syzkaller reported a use-after-free of UDP kernel socket
in cleanup_bearer() without repro. [0][1]
When bearer_disable() calls tipc_udp_disable(), cleanup
of the UDP kernel socket is deferred by work calling
cleanup_bearer().
tipc_exit_net() waits for such works to finish by checking
tipc_net(net)->wq_count. However, the work decrements the
count too early before releasing the kernel socket,
unblocking cleanup_net() and resulting in use-after-free.
Let's move the decrement after releasing the socket in
cleanup_bearer().
[0]:
ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at
sk_alloc+0x438/0x608
inet_create+0x4c8/0xcb0
__sock_create+0x350/0x6b8
sock_create_kern+0x58/0x78
udp_sock_create4+0x68/0x398
udp_sock_create+0x88/0xc8
tipc_udp_enable+0x5e8/0x848
__tipc_nl_bearer_enable+0x84c/0xed8
tipc_nl_bearer_enable+0x38/0x60
genl_family_rcv_msg_doit+0x170/0x248
genl_rcv_msg+0x400/0x5b0
netlink_rcv_skb+0x1dc/0x398
genl_rcv+0x44/0x68
netlink_unicast+0x678/0x8b0
netlink_sendmsg+0x5e4/0x898
____sys_sendmsg+0x500/0x830
[1]:
BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline]
BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979
udp_hashslot include/net/udp.h:85 [inline]
udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979
sk_common_release+0xaf/0x3f0 net/core/sock.c:3820
inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437
inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489
__sock_release net/socket.c:658 [inline]
sock_release+0xa0/0x210 net/socket.c:686
cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819
process_one_work kernel/workqueue.c:3229 [inline]
process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310
worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391
kthread+0x531/0x6b0 kernel/kthread.c:389
ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244
Uninit was created at:
slab_free_hook mm/slub.c:2269 [inline]
slab_free mm/slub.c:4580 [inline]
kmem_cache_free+0x207/0xc40 mm/slub.c:4682
net_free net/core/net_namespace.c:454 [inline]
cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647
process_one_work kernel/workqueue.c:3229 [inline]
process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310
worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391
kthread+0x531/0x6b0 kernel/kthread.c:389
ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244
CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
Workqueue: events cleanup_bearer |
["https://git.kernel.org/stable/c/4e69457f9dfae67435f3ccf29008768eae860415","https://git.kernel.org/stable/c/650ee9a22d7a2de8999fac2d45983597a0c22359","https://git.kernel.org/stable/c/6a2fa13312e51a621f652d522d7e2df7066330b6","https://git.kernel.org/stable/c/d00d4470bf8c4282617a3a10e76b20a9c7e4cffa","https://git.kernel.org/stable/c/d2a4894f238551eae178904e7f45af87577074fd","https://git.kernel.org/stable/c/d62d5180c036eeac09f80660edc7a602b369125f","https://git.kernel.org/stable/c/e48b211c4c59062cb6dd6c2c37c51a7cc235a464"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56658
|
High |
fixed |
- 3.13
- 3.19
- 4.2
- 6.1.121
- 6.6.67
- 6.12.6
|
In the Linux kernel, the following vulnerability has been resolved:
net: defer final 'struct net' free in netns dismantle
Ilya reported a slab-use-after-free in dst_destroy [1]
Issue is in xfrm6_net_init() and xfrm4_net_init() :
They copy xfrm[46]_dst_ops_template into net->xfrm.xfrm[46]_dst_ops.
But net structure might be freed before all the dst callbacks are
called. So when dst_destroy() calls later :
if (dst->ops->destroy)
dst->ops->destroy(dst);
dst->ops points to the old net->xfrm.xfrm[46]_dst_ops, which has been freed.
See a relevant issue fixed in :
ac888d58869b ("net: do not delay dst_entries_add() in dst_release()")
A fix is to queue the 'struct net' to be freed after one
another cleanup_net() round (and existing rcu_barrier())
[1]
BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112)
Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0
Dec 03 05:46:18 kernel:
CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67
Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014
Call Trace:
<IRQ>
dump_stack_lvl (lib/dump_stack.c:124)
print_address_description.constprop.0 (mm/kasan/report.c:378)
? dst_destroy (net/core/dst.c:112)
print_report (mm/kasan/report.c:489)
? dst_destroy (net/core/dst.c:112)
? kasan_addr_to_slab (mm/kasan/common.c:37)
kasan_report (mm/kasan/report.c:603)
? dst_destroy (net/core/dst.c:112)
? rcu_do_batch (kernel/rcu/tree.c:2567)
dst_destroy (net/core/dst.c:112)
rcu_do_batch (kernel/rcu/tree.c:2567)
? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491)
? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4339 kernel/locking/lockdep.c:4406)
rcu_core (kernel/rcu/tree.c:2825)
handle_softirqs (kernel/softirq.c:554)
__irq_exit_rcu (kernel/softirq.c:589 kernel/softirq.c:428 kernel/softirq.c:637)
irq_exit_rcu (kernel/softirq.c:651)
sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049)
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702)
RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743)
Code: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90
RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246
RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123
RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed11c7e1835d
R10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000
R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000
? ct_kernel_exit.constprop.0 (kernel/context_tracking.c:148)
? cpuidle_idle_call (kernel/sched/idle.c:186)
default_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118)
cpuidle_idle_call (kernel/sched/idle.c:186)
? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168)
? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848)
? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406)
? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59)
do_idle (kernel/sched/idle.c:326)
cpu_startup_entry (kernel/sched/idle.c:423 (discriminator 1))
start_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282)
? __pfx_start_secondary (arch/x86/kernel/smpboot.c:232)
? soft_restart_cpu (arch/x86/kernel/head_64.S:452)
common_startup_64 (arch/x86/kernel/head_64.S:414)
</TASK>
Dec 03 05:46:18 kernel:
Allocated by task 12184:
kasan_save_stack (mm/kasan/common.c:48)
kasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69)
__kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345)
kmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141)
copy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480)
create_new_namespaces
---truncated--- |
["https://git.kernel.org/stable/c/0f6ede9fbc747e2553612271bce108f7517e7a45","https://git.kernel.org/stable/c/3267b254dc0a04dfa362a2be24573cfa6d2d78f5","https://git.kernel.org/stable/c/6610c7f8a8d47fd1123eed55ba8c11c2444d8842","https://git.kernel.org/stable/c/b7a79e51297f7b82adb687086f5cb2da446f1e40","https://git.kernel.org/stable/c/c261dcd61c9e88a8f1a66654354d32295a975230","https://git.kernel.org/stable/c/dac465986a4a38cd2f13e934f562b6ca344e5720"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56640
|
High |
fixed |
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix LGR and link use-after-free issue
We encountered a LGR/link use-after-free issue, which manifested as
the LGR/link refcnt reaching 0 early and entering the clear process,
making resource access unsafe.
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcount_warn_saturate+0x9c/0x140
Workqueue: events smc_lgr_terminate_work [smc]
Call trace:
refcount_warn_saturate+0x9c/0x140
__smc_lgr_terminate.part.45+0x2a8/0x370 [smc]
smc_lgr_terminate_work+0x28/0x30 [smc]
process_one_work+0x1b8/0x420
worker_thread+0x158/0x510
kthread+0x114/0x118
or
refcount_t: underflow; use-after-free.
WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcount_warn_saturate+0xf0/0x140
Workqueue: smc_hs_wq smc_listen_work [smc]
Call trace:
refcount_warn_saturate+0xf0/0x140
smcr_link_put+0x1cc/0x1d8 [smc]
smc_conn_free+0x110/0x1b0 [smc]
smc_conn_abort+0x50/0x60 [smc]
smc_listen_find_device+0x75c/0x790 [smc]
smc_listen_work+0x368/0x8a0 [smc]
process_one_work+0x1b8/0x420
worker_thread+0x158/0x510
kthread+0x114/0x118
It is caused by repeated release of LGR/link refcnt. One suspect is that
smc_conn_free() is called repeatedly because some smc_conn_free() from
server listening path are not protected by sock lock.
e.g.
Calls under socklock | smc_listen_work
-------------------------------------------------------
lock_sock(sk) | smc_conn_abort
smc_conn_free | \- smc_conn_free
\- smcr_link_put | \- smcr_link_put (duplicated)
release_sock(sk)
So here add sock lock protection in smc_listen_work() path, making it
exclusive with other connection operations. |
["https://git.kernel.org/stable/c/0cf598548a6c36d90681d53c6b77d52363f2f295","https://git.kernel.org/stable/c/2c7f14ed9c19ec0f149479d1c2842ec1f9bf76d7","https://git.kernel.org/stable/c/673d606683ac70bc074ca6676b938bff18635226","https://git.kernel.org/stable/c/6f0ae06a234a78ae137064f2c89135ac078a00eb","https://git.kernel.org/stable/c/f502a88fdd415647a1f2dc45fac71b9c522a052b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50151
|
High |
fixed |
- 5.4.285
- 5.10.229
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix OOBs when building SMB2_IOCTL request
When using encryption, either enforced by the server or when using
'seal' mount option, the client will squash all compound request buffers
down for encryption into a single iov in smb2_set_next_command().
SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold the
SMB2_IOCTL request in the first iov, and if the user passes an input
buffer that is greater than 328 bytes, smb2_set_next_command() will
end up writing off the end of @rqst->iov[0].iov_base as shown below:
mount.cifs //srv/share /mnt -o ...,seal
ln -s $(perl -e "print('a')for 1..1024") /mnt/link
BUG: KASAN: slab-out-of-bounds in
smb2_set_next_command.cold+0x1d6/0x24c [cifs]
Write of size 4116 at addr ffff8881148fcab8 by task ln/859
CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
1.16.3-2.fc40 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x5d/0x80
? smb2_set_next_command.cold+0x1d6/0x24c [cifs]
print_report+0x156/0x4d9
? smb2_set_next_command.cold+0x1d6/0x24c [cifs]
? __virt_addr_valid+0x145/0x310
? __phys_addr+0x46/0x90
? smb2_set_next_command.cold+0x1d6/0x24c [cifs]
kasan_report+0xda/0x110
? smb2_set_next_command.cold+0x1d6/0x24c [cifs]
kasan_check_range+0x10f/0x1f0
__asan_memcpy+0x3c/0x60
smb2_set_next_command.cold+0x1d6/0x24c [cifs]
smb2_compound_op+0x238c/0x3840 [cifs]
? kasan_save_track+0x14/0x30
? kasan_save_free_info+0x3b/0x70
? vfs_symlink+0x1a1/0x2c0
? do_symlinkat+0x108/0x1c0
? __pfx_smb2_compound_op+0x10/0x10 [cifs]
? kmem_cache_free+0x118/0x3e0
? cifs_get_writable_path+0xeb/0x1a0 [cifs]
smb2_get_reparse_inode+0x423/0x540 [cifs]
? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs]
? rcu_is_watching+0x20/0x50
? __kmalloc_noprof+0x37c/0x480
? smb2_create_reparse_symlink+0x257/0x490 [cifs]
? smb2_create_reparse_symlink+0x38f/0x490 [cifs]
smb2_create_reparse_symlink+0x38f/0x490 [cifs]
? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs]
? find_held_lock+0x8a/0xa0
? hlock_class+0x32/0xb0
? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs]
cifs_symlink+0x24f/0x960 [cifs]
? __pfx_make_vfsuid+0x10/0x10
? __pfx_cifs_symlink+0x10/0x10 [cifs]
? make_vfsgid+0x6b/0xc0
? generic_permission+0x96/0x2d0
vfs_symlink+0x1a1/0x2c0
do_symlinkat+0x108/0x1c0
? __pfx_do_symlinkat+0x10/0x10
? strncpy_from_user+0xaa/0x160
__x64_sys_symlinkat+0xb9/0xf0
do_syscall_64+0xbb/0x1d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f08d75c13bb |
["https://git.kernel.org/stable/c/1ab60323c5201bef25f2a3dc0ccc404d9aca77f1","https://git.kernel.org/stable/c/2ef632bfb888d1a14f81c1703817951e0bec5531","https://git.kernel.org/stable/c/6f0516ef1290da24b85461ed08a0938af7415e49","https://git.kernel.org/stable/c/b209c3a0bc3ac172265c7fa8309e5d00654f2510","https://git.kernel.org/stable/c/e07d05b7f5ad9a503d9cab0afde2ab867bb65470","https://git.kernel.org/stable/c/ed31aba8ce93472d9e16f5cff844ae7c94e9601d","https://git.kernel.org/stable/c/fe92ddc1c32d4474e605e3a31a4afcd0e7d765ec"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56538
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm: zynqmp_kms: Unplug DRM device before removal
Prevent userspace accesses to the DRM device from causing
use-after-frees by unplugging the device before we remove it. This
causes any further userspace accesses to result in an error without
further calls into this driver's internals. |
["https://git.kernel.org/stable/c/2e07c88914fc5289c21820b1aa94f058feb38197","https://git.kernel.org/stable/c/4fb97432e28a7e136b2d76135d50e988ada8e1af","https://git.kernel.org/stable/c/692f52aedccbf79b212a1e14e3735192b4c24a7d","https://git.kernel.org/stable/c/a17b9afe58c474657449cf87e238b1788200576b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56604
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc()
bt_sock_alloc() attaches allocated sk object to the provided sock object.
If rfcomm_dlc_alloc() fails, we release the sk object, but leave the
dangling pointer in the sock object, which may cause use-after-free.
Fix this by swapping calls to bt_sock_alloc() and rfcomm_dlc_alloc(). |
["https://git.kernel.org/stable/c/32df687e129ef0f9afcbcc914f7c32deb28fd481","https://git.kernel.org/stable/c/3945c799f12b8d1f49a3b48369ca494d981ac465","https://git.kernel.org/stable/c/6021ccc2471b7b95e29b7cfc7938e042bf56e281","https://git.kernel.org/stable/c/ac3eaac4cf142a15fe67be747a682b1416efeb6e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53203
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: fix potential array underflow in ucsi_ccg_sync_control()
The "command" variable can be controlled by the user via debugfs. The
worry is that if con_index is zero then "&uc->ucsi->connector[con_index
- 1]" would be an array underflow. |
["https://git.kernel.org/stable/c/0e66fd8e5a2e45c7dacfc9178ba702153f4a61a8","https://git.kernel.org/stable/c/56971710cd541f2f05160a84b3183477d34a1be9","https://git.kernel.org/stable/c/e15fd96c0b701c53f9006bcc836eaeb35a05a023","https://git.kernel.org/stable/c/e44189455c62469eb91d383ce9103d54c1f807a3","https://git.kernel.org/stable/c/e56aac6e5a25630645607b6856d4b2a17b2311a5","https://git.kernel.org/stable/c/ef92cd55289a282910575c5b9d87f646f2d39b38"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56631
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: sg: Fix slab-use-after-free read in sg_release()
Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN:
BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30
kernel/locking/lockdep.c:5838
__mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912
sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407
In sg_release(), the function kref_put(&sfp->f_ref, sg_remove_sfp) is
called before releasing the open_rel_lock mutex. The kref_put() call may
decrement the reference count of sfp to zero, triggering its cleanup
through sg_remove_sfp(). This cleanup includes scheduling deferred work
via sg_remove_sfp_usercontext(), which ultimately frees sfp.
After kref_put(), sg_release() continues to unlock open_rel_lock and may
reference sfp or sdp. If sfp has already been freed, this results in a
slab-use-after-free error.
Move the kref_put(&sfp->f_ref, sg_remove_sfp) call after unlocking the
open_rel_lock mutex. This ensures:
- No references to sfp or sdp occur after the reference count is
decremented.
- Cleanup functions such as sg_remove_sfp() and
sg_remove_sfp_usercontext() can safely execute without impacting the
mutex handling in sg_release().
The fix has been tested and validated by syzbot. This patch closes the
bug reported at the following syzkaller link and ensures proper
sequencing of resource cleanup and mutex operations, eliminating the
risk of use-after-free errors in sg_release(). |
["https://git.kernel.org/stable/c/198b89dd5a595ee3f96e5ce5c448b0484cd0e53c","https://git.kernel.org/stable/c/1f5e2f1ca5875728fcf62bc1a054707444ab4960","https://git.kernel.org/stable/c/275b8347e21ab8193e93223a8394a806e4ba8918","https://git.kernel.org/stable/c/285ce1f89f8d414e7eecab5ef5118cd512596318","https://git.kernel.org/stable/c/59b30afa578637169e2819536bb66459fdddc39d","https://git.kernel.org/stable/c/e19acb1926c4a1f30ee1ec84d8afba2d975bd534","https://git.kernel.org/stable/c/f10593ad9bc36921f623361c9e3dd96bd52d85ee"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-23559
|
High |
fixed |
- 4.14.305
- 4.19.272
- 5.4.231
- 5.10.166
- 5.15.91
- 6.1.9
|
In rndis_query_oid in drivers/net/wireless/rndis_wlan.c in the Linux kernel through 6.1.5, there is an integer overflow in an addition. |
["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b870e73a56c4cccbec33224233eaf295839f228c","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://patchwork.kernel.org/project/linux-wireless/patch/20230110173007.57110-1-szymon.heidrich%40gmail.com/","https://security.netapp.com/advisory/ntap-20230302-0003/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b870e73a56c4cccbec33224233eaf295839f228c","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://patchwork.kernel.org/project/linux-wireless/patch/20230110173007.57110-1-szymon.heidrich%40gmail.com/","https://security.netapp.com/advisory/ntap-20230302-0003/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50282
|
High |
fixed |
- 4.19.324
- 5.4.286
- 5.10.230
- 5.15.172
- 6.1.117
- 6.6.61
- 6.11.8
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read()
Avoid a possible buffer overflow if size is larger than 4K.
(cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434) |
["https://git.kernel.org/stable/c/2faaee36e6e30f9efc7fa6bcb0bdcbe05c23f51f","https://git.kernel.org/stable/c/4d75b9468021c73108b4439794d69e892b1d24e3","https://git.kernel.org/stable/c/673bdb4200c092692f83b5f7ba3df57021d52d29","https://git.kernel.org/stable/c/8906728f2fbd6504cb488f4afdd66af28f330a7a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56551
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix usage slab after free
[ +0.000021] BUG: KASAN: slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]
[ +0.000027] Read of size 8 at addr ffff8881b8605f88 by task amd_pci_unplug/2147
[ +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug Not tainted 6.10.0+ #1
[ +0.000016] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020
[ +0.000016] Call Trace:
[ +0.000008] <TASK>
[ +0.000009] dump_stack_lvl+0x76/0xa0
[ +0.000017] print_report+0xce/0x5f0
[ +0.000017] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]
[ +0.000019] ? srso_return_thunk+0x5/0x5f
[ +0.000015] ? kasan_complete_mode_report_info+0x72/0x200
[ +0.000016] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]
[ +0.000019] kasan_report+0xbe/0x110
[ +0.000015] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]
[ +0.000023] __asan_report_load8_noabort+0x14/0x30
[ +0.000014] drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]
[ +0.000020] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? __kasan_check_write+0x14/0x30
[ +0.000016] ? __pfx_drm_sched_entity_flush+0x10/0x10 [gpu_sched]
[ +0.000020] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? __kasan_check_write+0x14/0x30
[ +0.000013] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? enable_work+0x124/0x220
[ +0.000015] ? __pfx_enable_work+0x10/0x10
[ +0.000013] ? srso_return_thunk+0x5/0x5f
[ +0.000014] ? free_large_kmalloc+0x85/0xf0
[ +0.000016] drm_sched_entity_destroy+0x18/0x30 [gpu_sched]
[ +0.000020] amdgpu_vce_sw_fini+0x55/0x170 [amdgpu]
[ +0.000735] ? __kasan_check_read+0x11/0x20
[ +0.000016] vce_v4_0_sw_fini+0x80/0x110 [amdgpu]
[ +0.000726] amdgpu_device_fini_sw+0x331/0xfc0 [amdgpu]
[ +0.000679] ? mutex_unlock+0x80/0xe0
[ +0.000017] ? __pfx_amdgpu_device_fini_sw+0x10/0x10 [amdgpu]
[ +0.000662] ? srso_return_thunk+0x5/0x5f
[ +0.000014] ? __kasan_check_write+0x14/0x30
[ +0.000013] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? mutex_unlock+0x80/0xe0
[ +0.000016] amdgpu_driver_release_kms+0x16/0x80 [amdgpu]
[ +0.000663] drm_minor_release+0xc9/0x140 [drm]
[ +0.000081] drm_release+0x1fd/0x390 [drm]
[ +0.000082] __fput+0x36c/0xad0
[ +0.000018] __fput_sync+0x3c/0x50
[ +0.000014] __x64_sys_close+0x7d/0xe0
[ +0.000014] x64_sys_call+0x1bc6/0x2680
[ +0.000014] do_syscall_64+0x70/0x130
[ +0.000014] ? srso_return_thunk+0x5/0x5f
[ +0.000014] ? irqentry_exit_to_user_mode+0x60/0x190
[ +0.000015] ? srso_return_thunk+0x5/0x5f
[ +0.000014] ? irqentry_exit+0x43/0x50
[ +0.000012] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? exc_page_fault+0x7c/0x110
[ +0.000015] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ +0.000014] RIP: 0033:0x7ffff7b14f67
[ +0.000013] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff
[ +0.000026] RSP: 002b:00007fffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
[ +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67
[ +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003
[ +0.000014] RBP: 00007fffffffe3a0 R08: 0000555555569890 R09: 0000000000000000
[ +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffffffe5c8
[ +0.000013] R13: 00005555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040
[ +0.000020] </TASK>
[ +0.000016] Allocated by task 383 on cpu 7 at 26.880319s:
[ +0.000014] kasan_save_stack+0x28/0x60
[ +0.000008] kasan_save_track+0x18/0x70
[ +0.000007] kasan_save_alloc_info+0x38/0x60
[ +0.000007] __kasan_kmalloc+0xc1/0xd0
[ +0.000007] kmalloc_trace_noprof+0x180/0x380
[ +0.000007] drm_sched_init+0x411/0xec0 [gpu_sched]
[ +0.000012] amdgpu_device_init+0x695f/0xa610 [amdgpu]
[ +0.000658] amdgpu_driver_load_kms+0x1a/0x120 [amdgpu]
[ +0.000662] amdgpu_pci_p
---truncated--- |
["https://git.kernel.org/stable/c/05b1b33936b71e5f189a813a517f72e8a27fcb2f","https://git.kernel.org/stable/c/3990ef742c064e22189b954522930db04fc6b1a7","https://git.kernel.org/stable/c/3cc1116de10953f0265a05d9f351b02a9ec3b497","https://git.kernel.org/stable/c/6383199ada42d30562b4249c393592a2a9c38165","https://git.kernel.org/stable/c/b61badd20b443eabe132314669bb51a263982e5c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46815
|
High |
fixed |
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.109
- 6.6.50
- 6.10.9
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check num_valid_sets before accessing reader_wm_sets[]
[WHY & HOW]
num_valid_sets needs to be checked to avoid a negative index when
accessing reader_wm_sets[num_valid_sets - 1].
This fixes an OVERRUN issue reported by Coverity. |
["https://git.kernel.org/stable/c/21f9cb44f8c60bf6c26487d428b1a09ad3e8aebf","https://git.kernel.org/stable/c/6a4a08e45e614cfa7a56498cdfaeb7fae2f07fa0","https://git.kernel.org/stable/c/7c47dd2e92341f2989ab73dbed07f8894593ad7b","https://git.kernel.org/stable/c/a72d4996409569027b4609414a14a87679b12267","https://git.kernel.org/stable/c/b36e9b3104c4ba0f2f5dd083dcf6159cb316c996","https://git.kernel.org/stable/c/b38a4815f79b87efb196cd5121579fc51e29a7fb","https://git.kernel.org/stable/c/c4a7f7c0062fe2c73f70bb7e335199e25bd71492"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21791
|
High |
fixed |
- 6.1.129
- 6.6.79
- 6.12.16
- 6.13.4
|
In the Linux kernel, the following vulnerability has been resolved:
vrf: use RCU protection in l3mdev_l3_out()
l3mdev_l3_out() can be called without RCU being held:
raw_sendmsg()
ip_push_pending_frames()
ip_send_skb()
ip_local_out()
__ip_local_out()
l3mdev_ip_out()
Add rcu_read_lock() / rcu_read_unlock() pair to avoid
a potential UAF. |
["https://git.kernel.org/stable/c/022cac1c693add610ae76ede03adf4d9d5a2cf21","https://git.kernel.org/stable/c/20a3489b396764cc9376e32a9172bee26a89dc3b","https://git.kernel.org/stable/c/5bb4228c32261d06e4fbece37ec3828bcc005b6b","https://git.kernel.org/stable/c/6ccaa5797f5362a2aad6baa6ddaf4715ac2dd51e","https://git.kernel.org/stable/c/6d0ce46a93135d96b7fa075a94a88fe0da8e8773","https://git.kernel.org/stable/c/7b81425b517accefd46bee854d94954f5c57e019","https://git.kernel.org/stable/c/c40cb5c03e37552d6eff963187109e2c3f78ef6f","https://git.kernel.org/stable/c/c7574740be8ce68a57d0aece24987b9be2114c3c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53179
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free of signing key
Customers have reported use-after-free in @ses->auth_key.response with
SMB2.1 + sign mounts which occurs due to following race:
task A task B
cifs_mount()
dfs_mount_share()
get_session()
cifs_mount_get_session() cifs_send_recv()
cifs_get_smb_ses() compound_send_recv()
cifs_setup_session() smb2_setup_request()
kfree_sensitive() smb2_calc_signature()
crypto_shash_setkey() *UAF*
Fix this by ensuring that we have a valid @ses->auth_key.response by
checking whether @ses->ses_status is SES_GOOD or SES_EXITING with
@ses->ses_lock held. After commit 24a9799aa8ef ("smb: client: fix UAF
in smb2_reconnect_server()"), we made sure to call ->logoff() only
when @ses was known to be good (e.g. valid ->auth_key.response), so
it's safe to access signing key when @ses->ses_status == SES_EXITING. |
["https://git.kernel.org/stable/c/0e2b654a3848bf9da3b0d54c1ccf3f1b8c635591","https://git.kernel.org/stable/c/343d7fe6df9e247671440a932b6a73af4fa86d95","https://git.kernel.org/stable/c/39619c65ab4bbb3e78c818f537687653e112764d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21863
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
io_uring: prevent opcode speculation
sqe->opcode is used for different tables, make sure we santitise it
against speculations. |
["https://git.kernel.org/stable/c/1e988c3fe1264708f4f92109203ac5b1d65de50b","https://git.kernel.org/stable/c/506b9b5e8c2d2a411ea8fe361333f5081c56d23a","https://git.kernel.org/stable/c/b9826e3b26ec031e9063f64a7c735449c43955e4","https://git.kernel.org/stable/c/fdbfd52bd8b85ed6783365ff54c82ab7067bd61b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3777
|
High |
fixed |
- 5.10.188
- 5.15.123
- 6.1.42
- 6.4.7
|
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.
When nf_tables_delrule() is flushing table rules, it is not checked whether the chain is bound and the chain's owner rule can also release the objects in certain circumstances.
We recommend upgrading past commit 6eaf41e87a223ae6f8e7a28d6e78384ad7e407f8. |
["http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6eaf41e87a223ae6f8e7a28d6e78384ad7e407f8","https://kernel.dance/6eaf41e87a223ae6f8e7a28d6e78384ad7e407f8","https://www.debian.org/security/2023/dsa-5492","http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6eaf41e87a223ae6f8e7a28d6e78384ad7e407f8","https://kernel.dance/6eaf41e87a223ae6f8e7a28d6e78384ad7e407f8","https://www.debian.org/security/2023/dsa-5492"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-6817
|
High |
fixed |
- 5.10.204
- 5.15.143
- 6.1.68
- 6.6.7
|
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.
The function nft_pipapo_walk did not skip inactive elements during set walk which could lead double deactivations of PIPAPO (Pile Packet Policies) elements, leading to use-after-free.
We recommend upgrading past commit 317eb9685095678f2c9f5a8189de698c5354316a. |
["http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html","http://www.openwall.com/lists/oss-security/2023/12/22/13","http://www.openwall.com/lists/oss-security/2023/12/22/6","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=317eb9685095678f2c9f5a8189de698c5354316a","https://kernel.dance/317eb9685095678f2c9f5a8189de698c5354316a","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html","http://www.openwall.com/lists/oss-security/2023/12/22/13","http://www.openwall.com/lists/oss-security/2023/12/22/6","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=317eb9685095678f2c9f5a8189de698c5354316a","https://kernel.dance/317eb9685095678f2c9f5a8189de698c5354316a","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48951
|
High |
fixed |
- 4.9.337
- 4.14.303
- 4.19.270
- 5.4.228
- 5.10.160
- 5.15.84
- 6.0.14
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()
The bounds checks in snd_soc_put_volsw_sx() are only being applied to the
first channel, meaning it is possible to write out of bounds values to the
second channel in stereo controls. Add appropriate checks. |
["https://git.kernel.org/stable/c/1798b62d642e7b3d4ea3403914c3caf4e438465d","https://git.kernel.org/stable/c/18a168d85eadcfd45f015b5ecd2a97801b959e43","https://git.kernel.org/stable/c/50b5f6d4d9d2d69a7498c44fd8b26e13d73d3d98","https://git.kernel.org/stable/c/56288987843c3cb343e81e5fa51549cbaf541bd0","https://git.kernel.org/stable/c/9796d07c753164b7e6b0d7ef23fb4482840a9ef8","https://git.kernel.org/stable/c/97eea946b93961fffd29448dcda7398d0d51c4b2","https://git.kernel.org/stable/c/cf1c225f1927891ae388562b78ced7840c3723b9","https://git.kernel.org/stable/c/cf611d786796ec33da09d8c83d7d7f4e557b27de"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49029
|
High |
fixed |
- 4.9.335
- 4.14.301
- 4.19.268
- 5.4.226
- 5.10.158
- 5.15.82
- 6.0.12
|
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails
Smatch report warning as follows:
drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn:
'&data->list' not removed from list
If ibmpex_find_sensors() fails in ibmpex_register_bmc(), data will
be freed, but data->list will not be removed from driver_data.bmc_data,
then list traversal may cause UAF.
Fix by removeing it from driver_data.bmc_data before free(). |
["https://git.kernel.org/stable/c/24b9633f7db7f4809be7053df1d2e117e7c2de10","https://git.kernel.org/stable/c/45f6e81863747c0d7bc6a95ec51129900e71467a","https://git.kernel.org/stable/c/798198273bf86673b970b51acdb35e57f42b3fcb","https://git.kernel.org/stable/c/7b2b67fe1339389e0bf3c37c7a677a004ac0e4e3","https://git.kernel.org/stable/c/90907cd4d11351ff76c9a447bcb5db0e264c47cd","https://git.kernel.org/stable/c/e2a87785aab0dac190ac89be6a9ba955e2c634f2","https://git.kernel.org/stable/c/e65cfd1f9cd27d9c27ee5cb88128a9f79f25d863","https://git.kernel.org/stable/c/f2a13196ad41c6c2ab058279dffe6c97292e753a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21855
|
High |
fixed |
- 6.1.130
- 6.6.80
- 6.12.17
- 6.13.5
|
In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: Don't reference skb after sending to VIOS
Previously, after successfully flushing the xmit buffer to VIOS,
the tx_bytes stat was incremented by the length of the skb.
It is invalid to access the skb memory after sending the buffer to
the VIOS because, at any point after sending, the VIOS can trigger
an interrupt to free this memory. A race between reading skb->len
and freeing the skb is possible (especially during LPM) and will
result in use-after-free:
==================================================================
BUG: KASAN: slab-use-after-free in ibmvnic_xmit+0x75c/0x1808 [ibmvnic]
Read of size 4 at addr c00000024eb48a70 by task hxecom/14495
<...>
Call Trace:
[c000000118f66cf0] [c0000000018cba6c] dump_stack_lvl+0x84/0xe8 (unreliable)
[c000000118f66d20] [c0000000006f0080] print_report+0x1a8/0x7f0
[c000000118f66df0] [c0000000006f08f0] kasan_report+0x128/0x1f8
[c000000118f66f00] [c0000000006f2868] __asan_load4+0xac/0xe0
[c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic]
[c000000118f67340] [c0000000014be168] dev_hard_start_xmit+0x150/0x358
<...>
Freed by task 0:
kasan_save_stack+0x34/0x68
kasan_save_track+0x2c/0x50
kasan_save_free_info+0x64/0x108
__kasan_mempool_poison_object+0x148/0x2d4
napi_skb_cache_put+0x5c/0x194
net_tx_action+0x154/0x5b8
handle_softirqs+0x20c/0x60c
do_softirq_own_stack+0x6c/0x88
<...>
The buggy address belongs to the object at c00000024eb48a00 which
belongs to the cache skbuff_head_cache of size 224
================================================================== |
["https://git.kernel.org/stable/c/093b0e5c90592773863f300b908b741622eef597","https://git.kernel.org/stable/c/25dddd01dcc8ef3acff964dbb32eeb0d89f098e9","https://git.kernel.org/stable/c/501ac6a7e21b82e05207c6b4449812d82820f306","https://git.kernel.org/stable/c/abaff2717470e4b5b7c0c3a90e128b211a23da09","https://git.kernel.org/stable/c/bdf5d13aa05ec314d4385b31ac974d6c7e0997c9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53088
|
Medium |
fixed |
- 5.15.172
- 6.1.117
- 6.6.61
- 6.11.8
|
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix race condition by adding filter's intermediate sync state
Fix a race condition in the i40e driver that leads to MAC/VLAN filters
becoming corrupted and leaking. Address the issue that occurs under
heavy load when multiple threads are concurrently modifying MAC/VLAN
filters by setting mac and port VLAN.
1. Thread T0 allocates a filter in i40e_add_filter() within
i40e_ndo_set_vf_port_vlan().
2. Thread T1 concurrently frees the filter in __i40e_del_filter() within
i40e_ndo_set_vf_mac().
3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which
refers to the already freed filter memory, causing corruption.
Reproduction steps:
1. Spawn multiple VFs.
2. Apply a concurrent heavy load by running parallel operations to change
MAC addresses on the VFs and change port VLANs on the host.
3. Observe errors in dmesg:
"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX,
please set promiscuous on manually for VF XX".
Exact code for stable reproduction Intel can't open-source now.
The fix involves implementing a new intermediate filter state,
I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list.
These filters cannot be deleted from the hash list directly but
must be removed using the full process. |
["https://git.kernel.org/stable/c/262dc6ea5f1eb18c4d08ad83d51222d0dd0dd42a","https://git.kernel.org/stable/c/6e046f4937474bc1b9fa980c1ad8f3253fc638f6","https://git.kernel.org/stable/c/7ad3fb3bfd43feb4e15c81dffd23ac4e55742791","https://git.kernel.org/stable/c/bf5f837d9fd27d32fb76df0a108babcaf4446ff1","https://git.kernel.org/stable/c/f30490e9695ef7da3d0899c6a0293cc7cd373567"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26583
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
tls: fix race between async notify and socket close
The submitting thread (one which called recvmsg/sendmsg)
may exit as soon as the async crypto handler calls complete()
so any code past that point risks touching already freed data.
Try to avoid the locking and extra flags altogether.
Have the main thread hold an extra reference, this way
we can depend solely on the atomic ref counter for
synchronization.
Don't futz with reiniting the completion, either, we are now
tightly controlling when completion fires. |
["https://git.kernel.org/stable/c/6209319b2efdd8524691187ee99c40637558fa33","https://git.kernel.org/stable/c/7a3ca06d04d589deec81f56229a9a9d62352ce01","https://git.kernel.org/stable/c/86dc27ee36f558fe223dbdfbfcb6856247356f4a","https://git.kernel.org/stable/c/aec7961916f3f9e88766e2688992da6980f11b8d","https://git.kernel.org/stable/c/f17d21ea73918ace8afb9c2d8e734dbf71c2c9d7","https://git.kernel.org/stable/c/6209319b2efdd8524691187ee99c40637558fa33","https://git.kernel.org/stable/c/7a3ca06d04d589deec81f56229a9a9d62352ce01","https://git.kernel.org/stable/c/86dc27ee36f558fe223dbdfbfcb6856247356f4a","https://git.kernel.org/stable/c/aec7961916f3f9e88766e2688992da6980f11b8d","https://git.kernel.org/stable/c/f17d21ea73918ace8afb9c2d8e734dbf71c2c9d7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52898
|
Medium |
fixed |
- 4.19.271
- 5.4.230
- 5.10.165
- 5.15.90
- 6.1.8
|
In the Linux kernel, the following vulnerability has been resolved:
xhci: Fix null pointer dereference when host dies
Make sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race
and cause null pointer dereference when host suddenly dies.
Usb core may call xhci_free_dev() which frees the xhci->devs[slot_id]
virt device at the same time that xhci_kill_endpoint_urbs() tries to
loop through all the device's endpoints, checking if there are any
cancelled urbs left to give back.
hold the xhci spinlock while freeing the virt device |
["https://git.kernel.org/stable/c/081105213ff6f661c114781d469233c7d0e09c2e","https://git.kernel.org/stable/c/133b902378e4acbd824c29dd0d48570ad596e368","https://git.kernel.org/stable/c/6fac4b5cecb3928a0a81069aaa815a2edc8dd5a1","https://git.kernel.org/stable/c/a2bc47c43e70cf904b1af49f76d572326c08bca7","https://git.kernel.org/stable/c/c462ac871f49753eca86bb960f573b993976a5ea","https://git.kernel.org/stable/c/ea2ee5e9991caf74e0604f994c1831a5867055b2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43866
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Always drain health in shutdown callback
There is no point in recovery during device shutdown. if health
work started need to wait for it to avoid races and NULL pointer
access.
Hence, drain health WQ on shutdown callback. |
["https://git.kernel.org/stable/c/1b75da22ed1e6171e261bc9265370162553d5393","https://git.kernel.org/stable/c/5005e2e159b300c1b8c6820a1e13a62eb0127b9b","https://git.kernel.org/stable/c/6048dec754554a1303d632be6042d3feb3295285","https://git.kernel.org/stable/c/6b6c2ebd83f2bf97e8f221479372aaca97a4a9b2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-33742
|
High |
fixed |
- 4.9.322
- 4.14.287
- 4.19.251
- 5.4.204
- 5.10.129
- 5.15.53
- 5.18.10
|
Linux disk/nic frontends data leaks T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742). |
["http://www.openwall.com/lists/oss-security/2022/07/05/6","http://xenbits.xen.org/xsa/advisory-403.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-403.txt","http://www.openwall.com/lists/oss-security/2022/07/05/6","http://xenbits.xen.org/xsa/advisory-403.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-403.txt"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-45015
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dpu: move dpu_encoder's connector assignment to atomic_enable()
For cases where the crtc's connectors_changed was set without enable/active
getting toggled , there is an atomic_enable() call followed by an
atomic_disable() but without an atomic_mode_set().
This results in a NULL ptr access for the dpu_encoder_get_drm_fmt() call in
the atomic_enable() as the dpu_encoder's connector was cleared in the
atomic_disable() but not re-assigned as there was no atomic_mode_set() call.
Fix the NULL ptr access by moving the assignment for atomic_enable() and also
use drm_atomic_get_new_connector_for_encoder() to get the connector from
the atomic_state.
Patchwork: https://patchwork.freedesktop.org/patch/606729/ |
["https://git.kernel.org/stable/c/3bacf814b6a61cc683c68465f175ebd938f09c52","https://git.kernel.org/stable/c/3fb61718bcbe309279205d1cc275a6435611dc77","https://git.kernel.org/stable/c/aedf02e46eb549dac8db4821a6b9f0c6bf6e3990"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48844
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_core: Fix leaking sent_cmd skb
sent_cmd memory is not freed before freeing hci_dev causing it to leak
it contents. |
["https://git.kernel.org/stable/c/3679ccc09d8806686d579095ed504e045af7f7d6","https://git.kernel.org/stable/c/9473d06bd1c8da49eafb685aa95a290290c672dd","https://git.kernel.org/stable/c/dd3b1dc3dd050f1f47cd13e300732852414270f8","https://git.kernel.org/stable/c/3679ccc09d8806686d579095ed504e045af7f7d6","https://git.kernel.org/stable/c/9473d06bd1c8da49eafb685aa95a290290c672dd","https://git.kernel.org/stable/c/dd3b1dc3dd050f1f47cd13e300732852414270f8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26949
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/pm: Fix NULL pointer dereference when get power limit
Because powerplay_table initialization is skipped under
sriov case, We check and set default lower and upper OD
value if powerplay_table is NULL. |
["https://git.kernel.org/stable/c/08ae9ef829b8055c2fdc8cfee37510c1f4721a07","https://git.kernel.org/stable/c/99c2f1563b1400cc8331fc79d19ada1bb95bb388","https://git.kernel.org/stable/c/b8eaa8ef1f1157a9f330e36e66bdd7a693309948","https://git.kernel.org/stable/c/08ae9ef829b8055c2fdc8cfee37510c1f4721a07","https://git.kernel.org/stable/c/99c2f1563b1400cc8331fc79d19ada1bb95bb388","https://git.kernel.org/stable/c/b8eaa8ef1f1157a9f330e36e66bdd7a693309948"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36481
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
tracing/probes: fix error check in parse_btf_field()
btf_find_struct_member() might return NULL or an error via the
ERR_PTR() macro. However, its caller in parse_btf_field() only checks
for the NULL condition. Fix this by using IS_ERR() and returning the
error up the stack. |
["https://git.kernel.org/stable/c/4ed468edfeb54c7202e559eba74c25fac6a0dad0","https://git.kernel.org/stable/c/ad4b202da2c498fefb69e5d87f67b946e7fe1e6a","https://git.kernel.org/stable/c/e569eb34970281438e2b48a3ef11c87459fcfbcb","https://git.kernel.org/stable/c/4ed468edfeb54c7202e559eba74c25fac6a0dad0","https://git.kernel.org/stable/c/ad4b202da2c498fefb69e5d87f67b946e7fe1e6a","https://git.kernel.org/stable/c/e569eb34970281438e2b48a3ef11c87459fcfbcb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39473
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: ipc4-topology: Fix input format query of process modules without base extension
If a process module does not have base config extension then the same
format applies to all of it's inputs and the process->base_config_ext is
NULL, causing NULL dereference when specifically crafted topology and
sequences used. |
["https://git.kernel.org/stable/c/9e16f17a2a0e97b43538b272e7071537a3e03368","https://git.kernel.org/stable/c/e3ae00ee238bce6cfa5ad935c921181c14d18fd6","https://git.kernel.org/stable/c/ffa077b2f6ad124ec3d23fbddc5e4b0ff2647af8","https://git.kernel.org/stable/c/9e16f17a2a0e97b43538b272e7071537a3e03368","https://git.kernel.org/stable/c/e3ae00ee238bce6cfa5ad935c921181c14d18fd6","https://git.kernel.org/stable/c/ffa077b2f6ad124ec3d23fbddc5e4b0ff2647af8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39483
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked
When requesting an NMI window, WARN on vNMI support being enabled if and
only if NMIs are actually masked, i.e. if the vCPU is already handling an
NMI. KVM's ABI for NMIs that arrive simultanesouly (from KVM's point of
view) is to inject one NMI and pend the other. When using vNMI, KVM pends
the second NMI simply by setting V_NMI_PENDING, and lets the CPU do the
rest (hardware automatically sets V_NMI_BLOCKING when an NMI is injected).
However, if KVM can't immediately inject an NMI, e.g. because the vCPU is
in an STI shadow or is running with GIF=0, then KVM will request an NMI
window and trigger the WARN (but still function correctly).
Whether or not the GIF=0 case makes sense is debatable, as the intent of
KVM's behavior is to provide functionality that is as close to real
hardware as possible. E.g. if two NMIs are sent in quick succession, the
probability of both NMIs arriving in an STI shadow is infinitesimally low
on real hardware, but significantly larger in a virtual environment, e.g.
if the vCPU is preempted in the STI shadow. For GIF=0, the argument isn't
as clear cut, because the window where two NMIs can collide is much larger
in bare metal (though still small).
That said, KVM should not have divergent behavior for the GIF=0 case based
on whether or not vNMI support is enabled. And KVM has allowed
simultaneous NMIs with GIF=0 for over a decade, since commit 7460fb4a3400
("KVM: Fix simultaneous NMIs"). I.e. KVM's GIF=0 handling shouldn't be
modified without a *really* good reason to do so, and if KVM's behavior
were to be modified, it should be done irrespective of vNMI support. |
["https://git.kernel.org/stable/c/1d87cf2eba46deaff6142366127f2323de9f84d1","https://git.kernel.org/stable/c/b4bd556467477420ee3a91fbcba73c579669edc6","https://git.kernel.org/stable/c/f79edaf7370986d73d204b36c50cc563a4c0f356","https://git.kernel.org/stable/c/1d87cf2eba46deaff6142366127f2323de9f84d1","https://git.kernel.org/stable/c/b4bd556467477420ee3a91fbcba73c579669edc6","https://git.kernel.org/stable/c/f79edaf7370986d73d204b36c50cc563a4c0f356"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-39485
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
media: v4l: async: Properly re-initialise notifier entry in unregister
The notifier_entry of a notifier is not re-initialised after unregistering
the notifier. This leads to dangling pointers being left there so use
list_del_init() to return the notifier_entry an empty list. |
["https://git.kernel.org/stable/c/1aa6cd4adfc0380fa1ccc2f146848940ff882a66","https://git.kernel.org/stable/c/87100b09246202a91fce4a1562955c32229173bb","https://git.kernel.org/stable/c/9537a8425a7a0222999d5839a0b394b1e8834b4a","https://git.kernel.org/stable/c/1aa6cd4adfc0380fa1ccc2f146848940ff882a66","https://git.kernel.org/stable/c/87100b09246202a91fce4a1562955c32229173bb","https://git.kernel.org/stable/c/9537a8425a7a0222999d5839a0b394b1e8834b4a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40997
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: amd-pstate: fix memory leak on CPU EPP exit
The cpudata memory from kzalloc() in amd_pstate_epp_cpu_init() is
not freed in the analogous exit function, so fix that.
[ rjw: Subject and changelog edits ] |
["https://git.kernel.org/stable/c/448efb7ea0bfa2c4e27c5a2eb5684fd225cd12cd","https://git.kernel.org/stable/c/8015c17fe11a8608cc3eb83d0ab831e1845a9582","https://git.kernel.org/stable/c/cea04f3d9aeebda9d9c063c0dfa71e739c322c81","https://git.kernel.org/stable/c/448efb7ea0bfa2c4e27c5a2eb5684fd225cd12cd","https://git.kernel.org/stable/c/8015c17fe11a8608cc3eb83d0ab831e1845a9582","https://git.kernel.org/stable/c/cea04f3d9aeebda9d9c063c0dfa71e739c322c81"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42074
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: amd: acp: add a null check for chip_pdev structure
When acp platform device creation is skipped, chip->chip_pdev value will
remain NULL. Add NULL check for chip->chip_pdev structure in
snd_acp_resume() function to avoid null pointer dereference. |
["https://git.kernel.org/stable/c/98d919dfee1cc402ca29d45da642852d7c9a2301","https://git.kernel.org/stable/c/b0c39ae1cc86afe74aa2f6273ccb514f8d180cf6","https://git.kernel.org/stable/c/e158ed266fc1adfa456880fb6dabce2e5623843b","https://git.kernel.org/stable/c/98d919dfee1cc402ca29d45da642852d7c9a2301","https://git.kernel.org/stable/c/b0c39ae1cc86afe74aa2f6273ccb514f8d180cf6","https://git.kernel.org/stable/c/e158ed266fc1adfa456880fb6dabce2e5623843b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42135
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
vhost_task: Handle SIGKILL by flushing work and exiting
Instead of lingering until the device is closed, this has us handle
SIGKILL by:
1. marking the worker as killed so we no longer try to use it with
new virtqueues and new flush operations.
2. setting the virtqueue to worker mapping so no new works are queued.
3. running all the exiting works. |
["https://git.kernel.org/stable/c/abe067dc3a662eef7d5cddbbc41ed50a0b68b0af","https://git.kernel.org/stable/c/db5247d9bf5c6ade9fd70b4e4897441e0269b233","https://git.kernel.org/stable/c/dec987fe2df670827eb53b97c9552ed8dfc63ad4","https://git.kernel.org/stable/c/abe067dc3a662eef7d5cddbbc41ed50a0b68b0af","https://git.kernel.org/stable/c/db5247d9bf5c6ade9fd70b4e4897441e0269b233","https://git.kernel.org/stable/c/dec987fe2df670827eb53b97c9552ed8dfc63ad4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42144
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
thermal/drivers/mediatek/lvts_thermal: Check NULL ptr on lvts_data
Verify that lvts_data is not NULL before using it. |
["https://git.kernel.org/stable/c/79ef1a5593fdb8aa4dbccf6085c48f1739338bc9","https://git.kernel.org/stable/c/a1191a77351e25ddf091bb1a231cae12ee598b5d","https://git.kernel.org/stable/c/fd7ae1cabfedd727be5bee774c87acbc7b10b886","https://git.kernel.org/stable/c/79ef1a5593fdb8aa4dbccf6085c48f1739338bc9","https://git.kernel.org/stable/c/a1191a77351e25ddf091bb1a231cae12ee598b5d","https://git.kernel.org/stable/c/fd7ae1cabfedd727be5bee774c87acbc7b10b886"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-41009
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix overrunning reservations in ringbuf
The BPF ring buffer internally is implemented as a power-of-2 sized circular
buffer, with two logical and ever-increasing counters: consumer_pos is the
consumer counter to show which logical position the consumer consumed the
data, and producer_pos which is the producer counter denoting the amount of
data reserved by all producers.
Each time a record is reserved, the producer that "owns" the record will
successfully advance producer counter. In user space each time a record is
read, the consumer of the data advanced the consumer counter once it finished
processing. Both counters are stored in separate pages so that from user
space, the producer counter is read-only and the consumer counter is read-write.
One aspect that simplifies and thus speeds up the implementation of both
producers and consumers is how the data area is mapped twice contiguously
back-to-back in the virtual memory, allowing to not take any special measures
for samples that have to wrap around at the end of the circular buffer data
area, because the next page after the last data page would be first data page
again, and thus the sample will still appear completely contiguous in virtual
memory.
Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for
book-keeping the length and offset, and is inaccessible to the BPF program.
Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ`
for the BPF program to use. Bing-Jhong and Muhammad reported that it is however
possible to make a second allocated memory chunk overlapping with the first
chunk and as a result, the BPF program is now able to edit first chunk's
header.
For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size
of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to
bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in
[0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets
allocate a chunk B with size 0x3000. This will succeed because consumer_pos
was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask`
check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able
to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned
earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data
pages. This means that chunk B at [0x4000,0x4008] is chunk A's header.
bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then
locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk
B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong
page and could cause a crash.
Fix it by calculating the oldest pending_pos and check whether the range
from the oldest outstanding record to the newest would span beyond the ring
buffer size. If that is the case, then reject the request. We've tested with
the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh)
before/after the fix and while it seems a bit slower on some benchmarks, it
is still not significantly enough to matter. |
["https://git.kernel.org/stable/c/0f98f40eb1ed52af8b81f61901b6c0289ff59de4","https://git.kernel.org/stable/c/47416c852f2a04d348ea66ee451cbdcf8119f225","https://git.kernel.org/stable/c/511804ab701c0503b72eac08217eabfd366ba069","https://git.kernel.org/stable/c/be35504b959f2749bab280f4671e8df96dcf836f","https://git.kernel.org/stable/c/cfa1a2329a691ffd991fcf7248a57d752e712881","https://git.kernel.org/stable/c/d1b9df0435bc61e0b44f578846516df8ef476686","https://git.kernel.org/stable/c/0f98f40eb1ed52af8b81f61901b6c0289ff59de4","https://git.kernel.org/stable/c/47416c852f2a04d348ea66ee451cbdcf8119f225","https://git.kernel.org/stable/c/511804ab701c0503b72eac08217eabfd366ba069","https://git.kernel.org/stable/c/be35504b959f2749bab280f4671e8df96dcf836f","https://git.kernel.org/stable/c/cfa1a2329a691ffd991fcf7248a57d752e712881","https://git.kernel.org/stable/c/d1b9df0435bc61e0b44f578846516df8ef476686"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50110
|
Medium |
fixed |
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
xfrm: fix one more kernel-infoleak in algo dumping
During fuzz testing, the following issue was discovered:
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x598/0x2a30
_copy_to_iter+0x598/0x2a30
__skb_datagram_iter+0x168/0x1060
skb_copy_datagram_iter+0x5b/0x220
netlink_recvmsg+0x362/0x1700
sock_recvmsg+0x2dc/0x390
__sys_recvfrom+0x381/0x6d0
__x64_sys_recvfrom+0x130/0x200
x64_sys_call+0x32c8/0x3cc0
do_syscall_64+0xd8/0x1c0
entry_SYSCALL_64_after_hwframe+0x79/0x81
Uninit was stored to memory at:
copy_to_user_state_extra+0xcc1/0x1e00
dump_one_state+0x28c/0x5f0
xfrm_state_walk+0x548/0x11e0
xfrm_dump_sa+0x1e0/0x840
netlink_dump+0x943/0x1c40
__netlink_dump_start+0x746/0xdb0
xfrm_user_rcv_msg+0x429/0xc00
netlink_rcv_skb+0x613/0x780
xfrm_netlink_rcv+0x77/0xc0
netlink_unicast+0xe90/0x1280
netlink_sendmsg+0x126d/0x1490
__sock_sendmsg+0x332/0x3d0
____sys_sendmsg+0x863/0xc30
___sys_sendmsg+0x285/0x3e0
__x64_sys_sendmsg+0x2d6/0x560
x64_sys_call+0x1316/0x3cc0
do_syscall_64+0xd8/0x1c0
entry_SYSCALL_64_after_hwframe+0x79/0x81
Uninit was created at:
__kmalloc+0x571/0xd30
attach_auth+0x106/0x3e0
xfrm_add_sa+0x2aa0/0x4230
xfrm_user_rcv_msg+0x832/0xc00
netlink_rcv_skb+0x613/0x780
xfrm_netlink_rcv+0x77/0xc0
netlink_unicast+0xe90/0x1280
netlink_sendmsg+0x126d/0x1490
__sock_sendmsg+0x332/0x3d0
____sys_sendmsg+0x863/0xc30
___sys_sendmsg+0x285/0x3e0
__x64_sys_sendmsg+0x2d6/0x560
x64_sys_call+0x1316/0x3cc0
do_syscall_64+0xd8/0x1c0
entry_SYSCALL_64_after_hwframe+0x79/0x81
Bytes 328-379 of 732 are uninitialized
Memory access of size 732 starts at ffff88800e18e000
Data copied to user address 00007ff30f48aff0
CPU: 2 PID: 18167 Comm: syz-executor.0 Not tainted 6.8.11 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Fixes copying of xfrm algorithms where some random
data of the structure fields can end up in userspace.
Padding in structures may be filled with random (possibly sensitve)
data and should never be given directly to user-space.
A similar issue was resolved in the commit
8222d5910dae ("xfrm: Zero padding when dumping algos and encap")
Found by Linux Verification Center (linuxtesting.org) with Syzkaller. |
["https://git.kernel.org/stable/c/1e8fbd2441cb2ea28d6825f2985bf7d84af060bb","https://git.kernel.org/stable/c/610d4cea9b442b22b4820695fc3335e64849725e","https://git.kernel.org/stable/c/6889cd2a93e1e3606b3f6e958aa0924e836de4d2","https://git.kernel.org/stable/c/c73bca72b84b453c8d26a5e7673b20adb294bf54","https://git.kernel.org/stable/c/dc2ad8e8818e4bf1a93db78d81745b4877b32972"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50017
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
x86/mm/ident_map: Use gbpages only where full GB page should be mapped.
When ident_pud_init() uses only GB pages to create identity maps, large
ranges of addresses not actually requested can be included in the resulting
table; a 4K request will map a full GB. This can include a lot of extra
address space past that requested, including areas marked reserved by the
BIOS. That allows processor speculation into reserved regions, that on UV
systems can cause system halts.
Only use GB pages when map creation requests include the full GB page of
space. Fall back to using smaller 2M pages when only portions of a GB page
are included in the request.
No attempt is made to coalesce mapping requests. If a request requires a
map entry at the 2M (pmd) level, subsequent mapping requests within the
same 1G region will also be at the pmd level, even if adjacent or
overlapping such requests could have been combined to map a full GB page.
Existing usage starts with larger regions and then adds smaller regions, so
this should not have any great consequence. |
["https://git.kernel.org/stable/c/a23823098ab2c277c14fc110b97d8d5c83597195","https://git.kernel.org/stable/c/cc31744a294584a36bf764a0ffa3255a8e69f036","https://git.kernel.org/stable/c/d113f9723f2bfd9c6feeb899b8ddbee6b8a6e01f","https://git.kernel.org/stable/c/d80a99892f7a992d103138fa4636b2c33abd6740"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43841
|
Low |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: virt_wifi: avoid reporting connection success with wrong SSID
When user issues a connection with a different SSID than the one
virt_wifi has advertised, the __cfg80211_connect_result() will
trigger the warning: WARN_ON(bss_not_found).
The issue is because the connection code in virt_wifi does not
check the SSID from user space (it only checks the BSSID), and
virt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS
even if the SSID is different from the one virt_wifi has advertised.
Eventually cfg80211 won't be able to find the cfg80211_bss and generate
the warning.
Fixed it by checking the SSID (from user space) in the connection code. |
["https://git.kernel.org/stable/c/05c4488a0e446c6ccde9f22b573950665e1cd414","https://git.kernel.org/stable/c/36e92b5edc8e0daa18e9325674313802ce3fbc29","https://git.kernel.org/stable/c/416d3c1538df005195721a200b0371d39636e05d","https://git.kernel.org/stable/c/93e898a264b4e0a475552ba9f99a016eb43ef942","https://git.kernel.org/stable/c/994fc2164a03200c3bf42fb45b3d49d9d6d33a4d","https://git.kernel.org/stable/c/b5d14b0c6716fad7f0c94ac6e1d6f60a49f985c7","https://git.kernel.org/stable/c/d3cc85a10abc8eae48988336cdd3689ab92581b3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42157
|
Medium |
fixed |
- 4.19.318
- 5.4.280
- 5.10.222
- 5.15.163
- 6.1.98
- 6.6.39
- 6.9.9
|
In the Linux kernel, the following vulnerability has been resolved:
s390/pkey: Wipe sensitive data on failure
Wipe sensitive data from stack also if the copy_to_user() fails. |
["https://git.kernel.org/stable/c/1d8c270de5eb74245d72325d285894a577a945d9","https://git.kernel.org/stable/c/4889f117755b2f18c23045a0f57977f3ec130581","https://git.kernel.org/stable/c/6e2e374403bf73140d0efc9541cb1b3bea55ac02","https://git.kernel.org/stable/c/90a01aefb84b09ccb6024d75d85bb8f620bd3487","https://git.kernel.org/stable/c/93c034c4314bc4c4450a3869cd5da298502346ad","https://git.kernel.org/stable/c/b5eb9176ebd4697bc248bf8d145e66d782cf5250","https://git.kernel.org/stable/c/c44a2151e5d21c66b070a056c26471f30719b575","https://git.kernel.org/stable/c/c51795885c801b6b7e976717e0d6d45b1e5be0f0","https://git.kernel.org/stable/c/1d8c270de5eb74245d72325d285894a577a945d9","https://git.kernel.org/stable/c/4889f117755b2f18c23045a0f57977f3ec130581","https://git.kernel.org/stable/c/6e2e374403bf73140d0efc9541cb1b3bea55ac02","https://git.kernel.org/stable/c/90a01aefb84b09ccb6024d75d85bb8f620bd3487","https://git.kernel.org/stable/c/93c034c4314bc4c4450a3869cd5da298502346ad","https://git.kernel.org/stable/c/b5eb9176ebd4697bc248bf8d145e66d782cf5250","https://git.kernel.org/stable/c/c44a2151e5d21c66b070a056c26471f30719b575","https://git.kernel.org/stable/c/c51795885c801b6b7e976717e0d6d45b1e5be0f0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-0516
|
High |
fixed |
|
A vulnerability was found in kvm_s390_guest_sida_op in the arch/s390/kvm/kvm-s390.c function in KVM for s390 in the Linux kernel. This flaw allows a local attacker with a normal user privilege to obtain unauthorized memory write access. This flaw affects Linux kernel versions prior to 5.17-rc4. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2050237","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=09a93c1df3eafa43bcdfd7bf837c574911f12f55","https://security.netapp.com/advisory/ntap-20220331-0009/","https://www.debian.org/security/2022/dsa-5092","https://bugzilla.redhat.com/show_bug.cgi?id=2050237","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=09a93c1df3eafa43bcdfd7bf837c574911f12f55","https://security.netapp.com/advisory/ntap-20220331-0009/","https://www.debian.org/security/2022/dsa-5092"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49590
|
Medium |
fixed |
- 4.9.325
- 4.14.290
- 4.19.254
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
igmp: Fix data-races around sysctl_igmp_llm_reports.
While reading sysctl_igmp_llm_reports, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its readers.
This test can be packed into a helper, so such changes will be in the
follow-up series after net is merged into net-next.
if (ipv4_is_local_multicast(pmc->multiaddr) &&
!READ_ONCE(net->ipv4.sysctl_igmp_llm_reports)) |
["https://git.kernel.org/stable/c/1656ecaddf90e2a070ec2d2404cdae3edf80faca","https://git.kernel.org/stable/c/260446eb8e5541402b271343a4516f2b33dec1e4","https://git.kernel.org/stable/c/46307adceb67bdf2ec38408dd9cebc378a6b5c46","https://git.kernel.org/stable/c/473aad9ad57ff760005377e6f45a2ad4210e08ce","https://git.kernel.org/stable/c/a84b4afaca2573ed3aed1f8854aefe3ca5a82e72","https://git.kernel.org/stable/c/d77969e7d4ccc26bf1f414a39ef35050a83ba6d5","https://git.kernel.org/stable/c/ed876e99ccf417b8bd7fd8408ba5e8b008e46cc8","https://git.kernel.org/stable/c/f6da2267e71106474fbc0943dc24928b9cb79119"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49595
|
Medium |
fixed |
- 4.9.325
- 4.14.290
- 4.19.254
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix a data-race around sysctl_tcp_probe_threshold.
While reading sysctl_tcp_probe_threshold, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its reader. |
["https://git.kernel.org/stable/c/44768749980d53bc01980d9c060f736808d11af0","https://git.kernel.org/stable/c/92c0aa4175474483d6cf373314343d4e624e882a","https://git.kernel.org/stable/c/96900fa61777402eb5056269d8000aace33a8b6c","https://git.kernel.org/stable/c/9b5dc7ad6da1373d3c60d4b869d688f996e5d219","https://git.kernel.org/stable/c/b04817c94fbd285a967d9b830b274fe9998c9c0b","https://git.kernel.org/stable/c/d452ce36f2d4c402fa3f5275c9677f80166e7fc6","https://git.kernel.org/stable/c/f524c3e7f6cdad66b3b6a912cef47b656f8b0de3","https://git.kernel.org/stable/c/fa5fb2cf9393db898772db8cb897ed5fd265eb78"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48869
|
Medium |
fixed |
- 5.4.230
- 5.10.165
- 5.15.90
- 6.1.8
|
In the Linux kernel, the following vulnerability has been resolved:
USB: gadgetfs: Fix race between mounting and unmounting
The syzbot fuzzer and Gerald Lee have identified a use-after-free bug
in the gadgetfs driver, involving processes concurrently mounting and
unmounting the gadgetfs filesystem. In particular, gadgetfs_fill_super()
can race with gadgetfs_kill_sb(), causing the latter to deallocate
the_device while the former is using it. The output from KASAN says,
in part:
BUG: KASAN: use-after-free in instrument_atomic_read_write include/linux/instrumented.h:102 [inline]
BUG: KASAN: use-after-free in atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline]
BUG: KASAN: use-after-free in __refcount_sub_and_test include/linux/refcount.h:272 [inline]
BUG: KASAN: use-after-free in __refcount_dec_and_test include/linux/refcount.h:315 [inline]
BUG: KASAN: use-after-free in refcount_dec_and_test include/linux/refcount.h:333 [inline]
BUG: KASAN: use-after-free in put_dev drivers/usb/gadget/legacy/inode.c:159 [inline]
BUG: KASAN: use-after-free in gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086
Write of size 4 at addr ffff8880276d7840 by task syz-executor126/18689
CPU: 0 PID: 18689 Comm: syz-executor126 Not tainted 6.1.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
<TASK>
...
atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline]
__refcount_sub_and_test include/linux/refcount.h:272 [inline]
__refcount_dec_and_test include/linux/refcount.h:315 [inline]
refcount_dec_and_test include/linux/refcount.h:333 [inline]
put_dev drivers/usb/gadget/legacy/inode.c:159 [inline]
gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086
deactivate_locked_super+0xa7/0xf0 fs/super.c:332
vfs_get_super fs/super.c:1190 [inline]
get_tree_single+0xd0/0x160 fs/super.c:1207
vfs_get_tree+0x88/0x270 fs/super.c:1531
vfs_fsconfig_locked fs/fsopen.c:232 [inline]
The simplest solution is to ensure that gadgetfs_fill_super() and
gadgetfs_kill_sb() are serialized by making them both acquire a new
mutex. |
["https://git.kernel.org/stable/c/616fd34d017000ecf9097368b13d8a266f4920b3","https://git.kernel.org/stable/c/856e4b5e53f21edbd15d275dde62228dd94fb2b4","https://git.kernel.org/stable/c/9a39f4626b361ee7aa10fd990401c37ec3b466ae","https://git.kernel.org/stable/c/a2e075f40122d8daf587db126c562a67abd69cf9","https://git.kernel.org/stable/c/d18dcfe9860e842f394e37ba01ca9440ab2178f4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-41850
|
Medium |
|
N/A
|
roccat_report_event in drivers/hid/hid-roccat.c in the Linux kernel through 5.19.12 has a race condition and resultant use-after-free in certain situations where a report is received while copying a report->value is in progress. |
["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cacdb14b1c8d3804a3a7d31773bc7569837b71a4","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://lore.kernel.org/all/20220904193115.GA28134%40ubuntu/t/#u","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cacdb14b1c8d3804a3a7d31773bc7569837b71a4","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://lore.kernel.org/all/20220904193115.GA28134%40ubuntu/t/#u"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52884
|
Medium |
fixed |
- 5.15.161
- 6.1.93
- 6.6.33
- 6.9.4
|
In the Linux kernel, the following vulnerability has been resolved:
Input: cyapa - add missing input core locking to suspend/resume functions
Grab input->mutex during suspend/resume functions like it is done in
other input drivers. This fixes the following warning during system
suspend/resume cycle on Samsung Exynos5250-based Snow Chromebook:
------------[ cut here ]------------
WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c
Modules linked in: ...
CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109
Hardware name: Samsung Exynos (Flattened Device Tree)
Workqueue: events_unbound async_run_entry_fn
unwind_backtrace from show_stack+0x10/0x14
show_stack from dump_stack_lvl+0x58/0x70
dump_stack_lvl from __warn+0x1a8/0x1cc
__warn from warn_slowpath_fmt+0x18c/0x1b4
warn_slowpath_fmt from input_device_enabled+0x68/0x6c
input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc
cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c
cyapa_reinitialize from cyapa_resume+0x48/0x98
cyapa_resume from dpm_run_callback+0x90/0x298
dpm_run_callback from device_resume+0xb4/0x258
device_resume from async_resume+0x20/0x64
async_resume from async_run_entry_fn+0x40/0x15c
async_run_entry_fn from process_scheduled_works+0xbc/0x6a8
process_scheduled_works from worker_thread+0x188/0x454
worker_thread from kthread+0x108/0x140
kthread from ret_from_fork+0x14/0x28
Exception stack(0xf1625fb0 to 0xf1625ff8)
...
---[ end trace 0000000000000000 ]---
...
------------[ cut here ]------------
WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c
Modules linked in: ...
CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109
Hardware name: Samsung Exynos (Flattened Device Tree)
Workqueue: events_unbound async_run_entry_fn
unwind_backtrace from show_stack+0x10/0x14
show_stack from dump_stack_lvl+0x58/0x70
dump_stack_lvl from __warn+0x1a8/0x1cc
__warn from warn_slowpath_fmt+0x18c/0x1b4
warn_slowpath_fmt from input_device_enabled+0x68/0x6c
input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc
cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c
cyapa_reinitialize from cyapa_resume+0x48/0x98
cyapa_resume from dpm_run_callback+0x90/0x298
dpm_run_callback from device_resume+0xb4/0x258
device_resume from async_resume+0x20/0x64
async_resume from async_run_entry_fn+0x40/0x15c
async_run_entry_fn from process_scheduled_works+0xbc/0x6a8
process_scheduled_works from worker_thread+0x188/0x454
worker_thread from kthread+0x108/0x140
kthread from ret_from_fork+0x14/0x28
Exception stack(0xf1625fb0 to 0xf1625ff8)
...
---[ end trace 0000000000000000 ]--- |
["https://git.kernel.org/stable/c/7b4e0b39182cf5e677c1fc092a3ec40e621c25b6","https://git.kernel.org/stable/c/9400caf566f65c703e99d95f87b00c4b445627a7","https://git.kernel.org/stable/c/a4c638ab25786bd5aab5978fe51b2b9be16a4ebd","https://git.kernel.org/stable/c/a5fc298fa8f67cf1f0e1fc126eab70578cd40adc","https://git.kernel.org/stable/c/f99809fdeb50d65bcbc1661ef391af94eebb8a75","https://git.kernel.org/stable/c/7b4e0b39182cf5e677c1fc092a3ec40e621c25b6","https://git.kernel.org/stable/c/9400caf566f65c703e99d95f87b00c4b445627a7","https://git.kernel.org/stable/c/a4c638ab25786bd5aab5978fe51b2b9be16a4ebd","https://git.kernel.org/stable/c/a5fc298fa8f67cf1f0e1fc126eab70578cd40adc","https://git.kernel.org/stable/c/f99809fdeb50d65bcbc1661ef391af94eebb8a75"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35870
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix UAF in smb2_reconnect_server()
The UAF bug is due to smb2_reconnect_server() accessing a session that
is already being teared down by another thread that is executing
__cifs_put_smb_ses(). This can happen when (a) the client has
connection to the server but no session or (b) another thread ends up
setting @ses->ses_status again to something different than
SES_EXITING.
To fix this, we need to make sure to unconditionally set
@ses->ses_status to SES_EXITING and prevent any other threads from
setting a new status while we're still tearing it down.
The following can be reproduced by adding some delay to right after
the ipc is freed in __cifs_put_smb_ses() - which will give
smb2_reconnect_server() worker a chance to run and then accessing
@ses->ipc:
kinit ...
mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10
[disconnect srv]
ls /mnt/1 &>/dev/null
sleep 30
kdestroy
[reconnect srv]
sleep 10
umount /mnt/1
...
CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed
CIFS: VFS: \\srv Send error in SessSetup = -126
CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed
CIFS: VFS: \\srv Send error in SessSetup = -126
general protection fault, probably for non-canonical address
0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI
CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39
04/01/2014
Workqueue: cifsiod smb2_reconnect_server [cifs]
RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0
Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad
de 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 <48> 8b 01 48 39 f8 75
7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8
RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83
RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b
RDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800
RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000
R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000
FS: 0000000000000000(0000) GS:ffff888157c00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
<TASK>
? die_addr+0x36/0x90
? exc_general_protection+0x1c1/0x3f0
? asm_exc_general_protection+0x26/0x30
? __list_del_entry_valid_or_report+0x33/0xf0
__cifs_put_smb_ses+0x1ae/0x500 [cifs]
smb2_reconnect_server+0x4ed/0x710 [cifs]
process_one_work+0x205/0x6b0
worker_thread+0x191/0x360
? __pfx_worker_thread+0x10/0x10
kthread+0xe2/0x110
? __pfx_kthread+0x10/0x10
ret_from_fork+0x34/0x50
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK> |
["https://git.kernel.org/stable/c/24a9799aa8efecd0eb55a75e35f9d8e6400063aa","https://git.kernel.org/stable/c/45f2beda1f1bc3d962ec07db1ccc3197c25499a5","https://git.kernel.org/stable/c/6202996a1c1887e83d0b3b0fcd86d0e5e6910ea0","https://git.kernel.org/stable/c/755fe68cd4b59e1d2a2dd3286177fd4404f57fed","https://git.kernel.org/stable/c/24a9799aa8efecd0eb55a75e35f9d8e6400063aa","https://git.kernel.org/stable/c/45f2beda1f1bc3d962ec07db1ccc3197c25499a5","https://git.kernel.org/stable/c/6202996a1c1887e83d0b3b0fcd86d0e5e6910ea0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-47519
|
High |
fixed |
|
An issue was discovered in the Linux kernel before 6.0.11. Missing validation of IEEE80211_P2P_ATTR_OPER_CHANNEL in drivers/net/wireless/microchip/wilc1000/cfg80211.c in the WILC1000 wireless driver can trigger an out-of-bounds write when parsing the channel list attribute from Wi-Fi management frames. |
["https://github.com/torvalds/linux/commit/051ae669e4505abbe05165bebf6be7922de11f41","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lore.kernel.org/r/20221123153543.8568-3-philipturnbull%40github.com","https://security.netapp.com/advisory/ntap-20230113-0007/","https://github.com/torvalds/linux/commit/051ae669e4505abbe05165bebf6be7922de11f41","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lore.kernel.org/r/20221123153543.8568-3-philipturnbull%40github.com","https://security.netapp.com/advisory/ntap-20230113-0007/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47742
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
firmware_loader: Block path traversal
Most firmware names are hardcoded strings, or are constructed from fairly
constrained format strings where the dynamic parts are just some hex
numbers or such.
However, there are a couple codepaths in the kernel where firmware file
names contain string components that are passed through from a device or
semi-privileged userspace; the ones I could find (not counting interfaces
that require root privileges) are:
- lpfc_sli4_request_firmware_update() seems to construct the firmware
filename from "ModelName", a string that was previously parsed out of
some descriptor ("Vital Product Data") in lpfc_fill_vpd()
- nfp_net_fw_find() seems to construct a firmware filename from a model
name coming from nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), which I
think parses some descriptor that was read from the device.
(But this case likely isn't exploitable because the format string looks
like "netronome/nic_%s", and there shouldn't be any *folders* starting
with "netronome/nic_". The previous case was different because there,
the "%s" is *at the start* of the format string.)
- module_flash_fw_schedule() is reachable from the
ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as
GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is
enough to pass the privilege check), and takes a userspace-provided
firmware name.
(But I think to reach this case, you need to have CAP_NET_ADMIN over a
network namespace that a special kind of ethernet device is mapped into,
so I think this is not a viable attack path in practice.)
Fix it by rejecting any firmware names containing ".." path components.
For what it's worth, I went looking and haven't found any USB device
drivers that use the firmware loader dangerously. |
["https://git.kernel.org/stable/c/28f1cd94d3f1092728fb775a0fe26c5f1ac2ebeb","https://git.kernel.org/stable/c/3d2411f4edcb649eaf232160db459bb4770b5251","https://git.kernel.org/stable/c/6c4e13fdfcab34811c3143a0a03c05fec4e870ec","https://git.kernel.org/stable/c/7420c1bf7fc784e587b87329cc6dfa3dca537aa4","https://git.kernel.org/stable/c/9b1ca33ebd05b3acef5b976c04e5e791af93ce1b","https://git.kernel.org/stable/c/a77fc4acfd49fc6076e565445b2bc5fdc3244da4","https://git.kernel.org/stable/c/c30558e6c5c9ad6c86459d9acce1520ceeab9ea6","https://git.kernel.org/stable/c/d1768e5535d3ded59f888637016e6f821f4e069f","https://git.kernel.org/stable/c/f0e5311aa8022107d63c54e2f03684ec097d1394"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53156
|
High |
fixed |
- 4.19.325
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()
I found the following bug in my fuzzer:
UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51
index 255 is out of range for type 'htc_endpoint [22]'
CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: events request_firmware_work_func
Call Trace:
<TASK>
dump_stack_lvl+0x180/0x1b0
__ubsan_handle_out_of_bounds+0xd4/0x130
htc_issue_send.constprop.0+0x20c/0x230
? _raw_spin_unlock_irqrestore+0x3c/0x70
ath9k_wmi_cmd+0x41d/0x610
? mark_held_locks+0x9f/0xe0
...
Since this bug has been confirmed to be caused by insufficient verification
of conn_rsp_epid, I think it would be appropriate to add a range check for
conn_rsp_epid to htc_connect_service() to prevent the bug from occurring. |
["https://git.kernel.org/stable/c/3fe99b9690b99606d3743c9961ebee865cfa1ab8","https://git.kernel.org/stable/c/5f177fb9d01355ac183e65ad8909ea8ef734e0cf","https://git.kernel.org/stable/c/70eae50d2156cb6e078d0d78809b49bf2f4c7540","https://git.kernel.org/stable/c/8619593634cbdf5abf43f5714df49b04e4ef09ab","https://git.kernel.org/stable/c/8965db7fe2e913ee0802b05fc94c6d6aa74e0596","https://git.kernel.org/stable/c/b6551479daf2bfa80bfd5d9016b02a810e508bfb","https://git.kernel.org/stable/c/bc981179ab5d1a2715f35e3db4e4bb822bacc849","https://git.kernel.org/stable/c/c941af142200d975dd3be632aeb490f4cb91dae4","https://git.kernel.org/stable/c/cb480ae80fd4d0f1ac9e107ce799183beee5124b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53165
|
High |
fixed |
- 4.19.325
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
sh: intc: Fix use-after-free bug in register_intc_controller()
In the error handling for this function, d is freed without ever
removing it from intc_list which would lead to a use after free.
To fix this, let's only add it to the list after everything has
succeeded. |
["https://git.kernel.org/stable/c/3c7c806b3eafd94ae0f77305a174d63b69ec187c","https://git.kernel.org/stable/c/588bdec1ff8b81517dbae0ae51c9df52c0b952d3","https://git.kernel.org/stable/c/63e72e551942642c48456a4134975136cdcb9b3c","https://git.kernel.org/stable/c/6ba6e19912570b2ad68298be0be1dc779014a303","https://git.kernel.org/stable/c/971b4893457788e0e123ea552f0bb126a5300e61","https://git.kernel.org/stable/c/b8b84dcdf3ab1d414304819f824b10efba64132c","https://git.kernel.org/stable/c/c3f4f4547fb291982f5ef56c048277c4d5ccc4e4","https://git.kernel.org/stable/c/c43df7dae28fb9fce96ef088250c1e3c3a77c527","https://git.kernel.org/stable/c/d8de818df12d86a1a26a8efd7b4b3b9c6dc3c5cc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53173
|
High |
fixed |
- 4.19.325
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
NFSv4.0: Fix a use-after-free problem in the asynchronous open()
Yang Erkun reports that when two threads are opening files at the same
time, and are forced to abort before a reply is seen, then the call to
nfs_release_seqid() in nfs4_opendata_free() can result in a
use-after-free of the pointer to the defunct rpc task of the other
thread.
The fix is to ensure that if the RPC call is aborted before the call to
nfs_wait_on_sequence() is complete, then we must call nfs_release_seqid()
in nfs4_open_release() before the rpc_task is freed. |
["https://git.kernel.org/stable/c/1cfae9575296f5040cdc84b0730e79078c081d2d","https://git.kernel.org/stable/c/229a30ed42bb87bcb044c5523fabd9e4f0e75648","https://git.kernel.org/stable/c/2ab9639f16b05d948066a6c4cf19a0fdc61046ff","https://git.kernel.org/stable/c/2fdb05dc0931250574f0cb0ebeb5ed8e20f4a889","https://git.kernel.org/stable/c/5237a297ffd374a1c4157a53543b7a69d7bbbc03","https://git.kernel.org/stable/c/7bf6bf130af8ee7d93a99c28a7512df3017ec759","https://git.kernel.org/stable/c/b56ae8e715557b4fc227c9381d2e681ffafe7b15","https://git.kernel.org/stable/c/ba6e6c04f60fe52d91520ac4d749d372d4c74521","https://git.kernel.org/stable/c/e2277a1d9d5cd0d625a4fd7c04fce2b53e66df77"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53194
|
High |
fixed |
- 4.19.325
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
PCI: Fix use-after-free of slot->bus on hot remove
Dennis reports a boot crash on recent Lenovo laptops with a USB4 dock.
Since commit 0fc70886569c ("thunderbolt: Reset USB4 v2 host router") and
commit 59a54c5f3dbd ("thunderbolt: Reset topology created by the boot
firmware"), USB4 v2 and v1 Host Routers are reset on probe of the
thunderbolt driver.
The reset clears the Presence Detect State and Data Link Layer Link Active
bits at the USB4 Host Router's Root Port and thus causes hot removal of the
dock.
The crash occurs when pciehp is unbound from one of the dock's Downstream
Ports: pciehp creates a pci_slot on bind and destroys it on unbind. The
pci_slot contains a pointer to the pci_bus below the Downstream Port, but
a reference on that pci_bus is never acquired. The pci_bus is destroyed
before the pci_slot, so a use-after-free ensues when pci_slot_release()
accesses slot->bus.
In principle this should not happen because pci_stop_bus_device() unbinds
pciehp (and therefore destroys the pci_slot) before the pci_bus is
destroyed by pci_remove_bus_device().
However the stacktrace provided by Dennis shows that pciehp is unbound from
pci_remove_bus_device() instead of pci_stop_bus_device(). To understand
the significance of this, one needs to know that the PCI core uses a two
step process to remove a portion of the hierarchy: It first unbinds all
drivers in the sub-hierarchy in pci_stop_bus_device() and then actually
removes the devices in pci_remove_bus_device(). There is no precaution to
prevent driver binding in-between pci_stop_bus_device() and
pci_remove_bus_device().
In Dennis' case, it seems removal of the hierarchy by pciehp races with
driver binding by pci_bus_add_devices(). pciehp is bound to the
Downstream Port after pci_stop_bus_device() has run, so it is unbound by
pci_remove_bus_device() instead of pci_stop_bus_device(). Because the
pci_bus has already been destroyed at that point, accesses to it result in
a use-after-free.
One might conclude that driver binding needs to be prevented after
pci_stop_bus_device() has run. However it seems risky that pci_slot points
to pci_bus without holding a reference. Solely relying on correct ordering
of driver unbind versus pci_bus destruction is certainly not defensive
programming.
If pci_slot has a need to access data in pci_bus, it ought to acquire a
reference. Amend pci_create_slot() accordingly. Dennis reports that the
crash is not reproducible with this change.
Abridged stacktrace:
pcieport 0000:00:07.0: PME: Signaling with IRQ 156
pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+
pci_bus 0000:20: dev 00, created physical slot 12
pcieport 0000:00:07.0: pciehp: Slot(12): Card not present
...
pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 write cmd 0
Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI
CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1
RIP: 0010:dev_driver_string+0x12/0x40
pci_destroy_slot
pciehp_remove
pcie_port_remove_service
device_release_driver_internal
bus_remove_device
device_del
device_unregister
remove_iter
device_for_each_child
pcie_portdrv_remove
pci_device_remove
device_release_driver_internal
bus_remove_device
device_del
pci_remove_bus_device (recursive invocation)
pci_remove_bus_device
pciehp_unconfigure_device
pciehp_disable_slot
pciehp_handle_presence_or_link_change
pciehp_ist |
["https://git.kernel.org/stable/c/20502f0b3f3acd6bee300257556c27a867f80c8b","https://git.kernel.org/stable/c/41bbb1eb996be1435815aa1fbcc9ffc45b84cc12","https://git.kernel.org/stable/c/50473dd3b2a08601a078f852ea05572de9b1f86c","https://git.kernel.org/stable/c/69d2ceac11acf8579d58d55c9c5b65fb658f916e","https://git.kernel.org/stable/c/c7acef99642b763ba585f4a43af999fcdbcc3dc4","https://git.kernel.org/stable/c/c8266ab8e7ccd1d1f5a9c8b29eb2020175048134","https://git.kernel.org/stable/c/d0ddd2c92b75a19a37c887154223372b600fed37","https://git.kernel.org/stable/c/da6e6ff1f6c57f16e07af955e0e997fc90dd1e75","https://git.kernel.org/stable/c/e5d5c04aac71bf1476dc44b56f2206a4c2facca8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53227
|
High |
fixed |
- 4.19.325
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: bfa: Fix use-after-free in bfad_im_module_exit()
BUG: KASAN: slab-use-after-free in __lock_acquire+0x2aca/0x3a20
Read of size 8 at addr ffff8881082d80c8 by task modprobe/25303
Call Trace:
<TASK>
dump_stack_lvl+0x95/0xe0
print_report+0xcb/0x620
kasan_report+0xbd/0xf0
__lock_acquire+0x2aca/0x3a20
lock_acquire+0x19b/0x520
_raw_spin_lock+0x2b/0x40
attribute_container_unregister+0x30/0x160
fc_release_transport+0x19/0x90 [scsi_transport_fc]
bfad_im_module_exit+0x23/0x60 [bfa]
bfad_init+0xdb/0xff0 [bfa]
do_one_initcall+0xdc/0x550
do_init_module+0x22d/0x6b0
load_module+0x4e96/0x5ff0
init_module_from_file+0xcd/0x130
idempotent_init_module+0x330/0x620
__x64_sys_finit_module+0xb3/0x110
do_syscall_64+0xc1/0x1d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
Allocated by task 25303:
kasan_save_stack+0x24/0x50
kasan_save_track+0x14/0x30
__kasan_kmalloc+0x7f/0x90
fc_attach_transport+0x4f/0x4740 [scsi_transport_fc]
bfad_im_module_init+0x17/0x80 [bfa]
bfad_init+0x23/0xff0 [bfa]
do_one_initcall+0xdc/0x550
do_init_module+0x22d/0x6b0
load_module+0x4e96/0x5ff0
init_module_from_file+0xcd/0x130
idempotent_init_module+0x330/0x620
__x64_sys_finit_module+0xb3/0x110
do_syscall_64+0xc1/0x1d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 25303:
kasan_save_stack+0x24/0x50
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x38/0x50
kfree+0x212/0x480
bfad_im_module_init+0x7e/0x80 [bfa]
bfad_init+0x23/0xff0 [bfa]
do_one_initcall+0xdc/0x550
do_init_module+0x22d/0x6b0
load_module+0x4e96/0x5ff0
init_module_from_file+0xcd/0x130
idempotent_init_module+0x330/0x620
__x64_sys_finit_module+0xb3/0x110
do_syscall_64+0xc1/0x1d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Above issue happens as follows:
bfad_init
error = bfad_im_module_init()
fc_release_transport(bfad_im_scsi_transport_template);
if (error)
goto ext;
ext:
bfad_im_module_exit();
fc_release_transport(bfad_im_scsi_transport_template);
--> Trigger double release
Don't call bfad_im_module_exit() if bfad_im_module_init() failed. |
["https://git.kernel.org/stable/c/0ceac8012d3ddea3317f0d82934293d05feb8af1","https://git.kernel.org/stable/c/178b8f38932d635e90f5f0e9af1986c6f4a89271","https://git.kernel.org/stable/c/1ffdde30a90bf8efe8f270407f486706962b3292","https://git.kernel.org/stable/c/3932c753f805a02e9364a4c58b590f21901f8490","https://git.kernel.org/stable/c/8f5a97443b547b4c83f876f1d6a11df0f1fd4efb","https://git.kernel.org/stable/c/a2b5035ab0e368e8d8a371e27fbc72f133c0bd40","https://git.kernel.org/stable/c/c28409f851abd93b37969cac7498828ad533afd9","https://git.kernel.org/stable/c/e76181a5be90abcc3ed8a300bd13878aa214d022","https://git.kernel.org/stable/c/ef2c2580189ea88a0dcaf56eb3a565763a900edb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53239
|
High |
fixed |
- 4.19.325
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: 6fire: Release resources at card release
The current 6fire code tries to release the resources right after the
call of usb6fire_chip_abort(). But at this moment, the card object
might be still in use (as we're calling snd_card_free_when_closed()).
For avoid potential UAFs, move the release of resources to the card's
private_free instead of the manual call of usb6fire_chip_destroy() at
the USB disconnect callback. |
["https://git.kernel.org/stable/c/0df7f4b5cc10f5adf98be0845372e9eef7bb5b09","https://git.kernel.org/stable/c/273eec23467dfbfbd0e4c10302579ba441fb1e13","https://git.kernel.org/stable/c/57860a80f03f9dc69a34a5c37b0941ad032a0a8c","https://git.kernel.org/stable/c/74357d0b5cd3ef544752bc9f21cbeee4902fae6c","https://git.kernel.org/stable/c/a0810c3d6dd2d29a9b92604d682eacd2902ce947","https://git.kernel.org/stable/c/b754e831a94f82f2593af806741392903f359168","https://git.kernel.org/stable/c/b889a7d68d7e76b8795b754a75c91a2d561d5e8c","https://git.kernel.org/stable/c/ea8cc56db659cf0ae57073e32a4735ead7bd7ee3","https://git.kernel.org/stable/c/f2d06d4e129e2508e356136f99bb20a332ff1a00"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49895
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation
This commit addresses a potential index out of bounds issue in the
`cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30
color management module. The issue could occur when the index 'i'
exceeds the number of transfer function points (TRANSFER_FUNC_POINTS).
The fix adds a check to ensure 'i' is within bounds before accessing the
transfer function points. If 'i' is out of bounds, the function returns
false to indicate an error.
Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max |
["https://git.kernel.org/stable/c/0d38a0751143afc03faef02d55d31f70374ff843","https://git.kernel.org/stable/c/ad89f83343a501890cf082c8a584e96b59fe4015","https://git.kernel.org/stable/c/bc50b614d59990747dd5aeced9ec22f9258991ff","https://git.kernel.org/stable/c/c4fdc2d6fea129684b82bab90bb52fbace494a58","https://git.kernel.org/stable/c/de6ee4f9e6b1c36b4fdc7c345c1a6de9e246093e","https://git.kernel.org/stable/c/f3ccd855b4395ce65f10dd37847167f52e122b70","https://git.kernel.org/stable/c/f5c3d306de91a4b69cfe3eedb72b42d452593e42"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49969
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix index out of bounds in DCN30 color transformation
This commit addresses a potential index out of bounds issue in the
`cm3_helper_translate_curve_to_hw_format` function in the DCN30 color
management module. The issue could occur when the index 'i' exceeds the
number of transfer function points (TRANSFER_FUNC_POINTS).
The fix adds a check to ensure 'i' is within bounds before accessing the
transfer function points. If 'i' is out of bounds, the function returns
false to indicate an error.
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max |
["https://git.kernel.org/stable/c/0f1e222a4b41d77c442901d166fbdca967af0d86","https://git.kernel.org/stable/c/578422ddae3d13362b64e77ef9bab98780641631","https://git.kernel.org/stable/c/7ab69af56a23859b647dee69fa1052c689343621","https://git.kernel.org/stable/c/929506d5671419cffd8d01e9a7f5eae53682a838","https://git.kernel.org/stable/c/b9d8b94ec7e67f0cae228c054f77b73967c389a3","https://git.kernel.org/stable/c/c13f9c62015c56a938304cef6d507227ea3e0039","https://git.kernel.org/stable/c/d81873f9e715b72d4f8d391c8eb243946f784dfc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56548
|
High |
fixed |
- 4.19.325
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: don't query the device logical block size multiple times
Devices block sizes may change. One of these cases is a loop device by
using ioctl LOOP_SET_BLOCK_SIZE.
While this may cause other issues like IO being rejected, in the case of
hfsplus, it will allocate a block by using that size and potentially write
out-of-bounds when hfsplus_read_wrapper calls hfsplus_submit_bio and the
latter function reads a different io_size.
Using a new min_io_size initally set to sb_min_blocksize works for the
purposes of the original fix, since it will be set to the max between
HFSPLUS_SECTOR_SIZE and the first seen logical block size. We still use the
max between HFSPLUS_SECTOR_SIZE and min_io_size in case the latter is not
initialized.
Tested by mounting an hfsplus filesystem with loop block sizes 512, 1024
and 4096.
The produced KASAN report before the fix looks like this:
[ 419.944641] ==================================================================
[ 419.945655] BUG: KASAN: slab-use-after-free in hfsplus_read_wrapper+0x659/0xa0a
[ 419.946703] Read of size 2 at addr ffff88800721fc00 by task repro/10678
[ 419.947612]
[ 419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro Not tainted 6.12.0-rc5-00008-gdf56e0f2f3ca #84
[ 419.949007] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
[ 419.950035] Call Trace:
[ 419.950384] <TASK>
[ 419.950676] dump_stack_lvl+0x57/0x78
[ 419.951212] ? hfsplus_read_wrapper+0x659/0xa0a
[ 419.951830] print_report+0x14c/0x49e
[ 419.952361] ? __virt_addr_valid+0x267/0x278
[ 419.952979] ? kmem_cache_debug_flags+0xc/0x1d
[ 419.953561] ? hfsplus_read_wrapper+0x659/0xa0a
[ 419.954231] kasan_report+0x89/0xb0
[ 419.954748] ? hfsplus_read_wrapper+0x659/0xa0a
[ 419.955367] hfsplus_read_wrapper+0x659/0xa0a
[ 419.955948] ? __pfx_hfsplus_read_wrapper+0x10/0x10
[ 419.956618] ? do_raw_spin_unlock+0x59/0x1a9
[ 419.957214] ? _raw_spin_unlock+0x1a/0x2e
[ 419.957772] hfsplus_fill_super+0x348/0x1590
[ 419.958355] ? hlock_class+0x4c/0x109
[ 419.958867] ? __pfx_hfsplus_fill_super+0x10/0x10
[ 419.959499] ? __pfx_string+0x10/0x10
[ 419.960006] ? lock_acquire+0x3e2/0x454
[ 419.960532] ? bdev_name.constprop.0+0xce/0x243
[ 419.961129] ? __pfx_bdev_name.constprop.0+0x10/0x10
[ 419.961799] ? pointer+0x3f0/0x62f
[ 419.962277] ? __pfx_pointer+0x10/0x10
[ 419.962761] ? vsnprintf+0x6c4/0xfba
[ 419.963178] ? __pfx_vsnprintf+0x10/0x10
[ 419.963621] ? setup_bdev_super+0x376/0x3b3
[ 419.964029] ? snprintf+0x9d/0xd2
[ 419.964344] ? __pfx_snprintf+0x10/0x10
[ 419.964675] ? lock_acquired+0x45c/0x5e9
[ 419.965016] ? set_blocksize+0x139/0x1c1
[ 419.965381] ? sb_set_blocksize+0x6d/0xae
[ 419.965742] ? __pfx_hfsplus_fill_super+0x10/0x10
[ 419.966179] mount_bdev+0x12f/0x1bf
[ 419.966512] ? __pfx_mount_bdev+0x10/0x10
[ 419.966886] ? vfs_parse_fs_string+0xce/0x111
[ 419.967293] ? __pfx_vfs_parse_fs_string+0x10/0x10
[ 419.967702] ? __pfx_hfsplus_mount+0x10/0x10
[ 419.968073] legacy_get_tree+0x104/0x178
[ 419.968414] vfs_get_tree+0x86/0x296
[ 419.968751] path_mount+0xba3/0xd0b
[ 419.969157] ? __pfx_path_mount+0x10/0x10
[ 419.969594] ? kmem_cache_free+0x1e2/0x260
[ 419.970311] do_mount+0x99/0xe0
[ 419.970630] ? __pfx_do_mount+0x10/0x10
[ 419.971008] __do_sys_mount+0x199/0x1c9
[ 419.971397] do_syscall_64+0xd0/0x135
[ 419.971761] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 419.972233] RIP: 0033:0x7c3cb812972e
[ 419.972564] Code: 48 8b 0d f5 46 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48
[ 419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5
[ 419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e
[ 419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI:
---truncated--- |
["https://git.kernel.org/stable/c/06cbfbb13ac88f4154c2eb4bc4176f9d10139847","https://git.kernel.org/stable/c/1c82587cb57687de3f18ab4b98a8850c789bedcf","https://git.kernel.org/stable/c/21900e8478126ff6afe3b66679f676e74d1f8830","https://git.kernel.org/stable/c/2667c9b7b76efcbc7adbfea249892f20c313b0da","https://git.kernel.org/stable/c/3d7bda75e1a6239db053c73acde17ca146317824","https://git.kernel.org/stable/c/baccb5e12577b7a9eff54ffba301fdaa0f3ee5a8","https://git.kernel.org/stable/c/bfeecda050aa9376f642d5b2a71c4112cc6c8216","https://git.kernel.org/stable/c/e8a2b1c1c2ea85e9a5a2d0c5a5a7e7c639feb866","https://git.kernel.org/stable/c/f57725bcc5816425e25218fdf5fb6923bc578cdf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21700
|
High |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.129
- 6.6.76
- 6.12.13
- 6.13.2
|
In the Linux kernel, the following vulnerability has been resolved:
net: sched: Disallow replacing of child qdisc from one parent to another
Lion Ackermann was able to create a UAF which can be abused for privilege
escalation with the following script
Step 1. create root qdisc
tc qdisc add dev lo root handle 1:0 drr
step2. a class for packet aggregation do demonstrate uaf
tc class add dev lo classid 1:1 drr
step3. a class for nesting
tc class add dev lo classid 1:2 drr
step4. a class to graft qdisc to
tc class add dev lo classid 1:3 drr
step5.
tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024
step6.
tc qdisc add dev lo parent 1:2 handle 3:0 drr
step7.
tc class add dev lo classid 3:1 drr
step 8.
tc qdisc add dev lo parent 3:1 handle 4:0 pfifo
step 9. Display the class/qdisc layout
tc class ls dev lo
class drr 1:1 root leaf 2: quantum 64Kb
class drr 1:2 root leaf 3: quantum 64Kb
class drr 3:1 root leaf 4: quantum 64Kb
tc qdisc ls
qdisc drr 1: dev lo root refcnt 2
qdisc plug 2: dev lo parent 1:1
qdisc pfifo 4: dev lo parent 3:1 limit 1000p
qdisc drr 3: dev lo parent 1:2
step10. trigger the bug <=== prevented by this patch
tc qdisc replace dev lo parent 1:3 handle 4:0
step 11. Redisplay again the qdiscs/classes
tc class ls dev lo
class drr 1:1 root leaf 2: quantum 64Kb
class drr 1:2 root leaf 3: quantum 64Kb
class drr 1:3 root leaf 4: quantum 64Kb
class drr 3:1 root leaf 4: quantum 64Kb
tc qdisc ls
qdisc drr 1: dev lo root refcnt 2
qdisc plug 2: dev lo parent 1:1
qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p
qdisc drr 3: dev lo parent 1:2
Observe that a) parent for 4:0 does not change despite the replace request.
There can only be one parent. b) refcount has gone up by two for 4:0 and
c) both class 1:3 and 3:1 are pointing to it.
Step 12. send one packet to plug
echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001))
step13. send one packet to the grafted fifo
echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003))
step14. lets trigger the uaf
tc class delete dev lo classid 1:3
tc class delete dev lo classid 1:1
The semantics of "replace" is for a del/add _on the same node_ and not
a delete from one node(3:1) and add to another node (1:3) as in step10.
While we could "fix" with a more complex approach there could be
consequences to expectations so the patch takes the preventive approach of
"disallow such config".
Joint work with Lion Ackermann <nnamrec@gmail.com> |
["https://git.kernel.org/stable/c/38646749d6e12f9d80a08d21ca39f0beca20230d","https://git.kernel.org/stable/c/46c59ec33ec98aba20c15117630cae43a01404cc","https://git.kernel.org/stable/c/73c7e1d6898ccbeee126194dcc05f58b8a795e70","https://git.kernel.org/stable/c/7e2bd8c13b07e29a247c023c7444df23f9a79fd8","https://git.kernel.org/stable/c/bc50835e83f60f56e9bec2b392fb5544f250fb6f","https://git.kernel.org/stable/c/cd796e269123e1994bfc4e99dd76680ba0946a97","https://git.kernel.org/stable/c/deda09c0543a66fa51554abc5ffd723d99b191bf","https://git.kernel.org/stable/c/fe18c21d67dc7d1bcce1bba56515b1b0306db19b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21692
|
High |
fixed |
- 5.10.234
- 5.15.178
- 6.1.128
- 6.6.75
- 6.12.12
|
In the Linux kernel, the following vulnerability has been resolved:
net: sched: fix ets qdisc OOB Indexing
Haowei Yan <g1042620637@gmail.com> found that ets_class_from_arg() can
index an Out-Of-Bound class in ets_class_from_arg() when passed clid of
0. The overflow may cause local privilege escalation.
[ 18.852298] ------------[ cut here ]------------
[ 18.853271] UBSAN: array-index-out-of-bounds in net/sched/sch_ets.c:93:20
[ 18.853743] index 18446744073709551615 is out of range for type 'ets_class [16]'
[ 18.854254] CPU: 0 UID: 0 PID: 1275 Comm: poc Not tainted 6.12.6-dirty #17
[ 18.854821] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[ 18.856532] Call Trace:
[ 18.857441] <TASK>
[ 18.858227] dump_stack_lvl+0xc2/0xf0
[ 18.859607] dump_stack+0x10/0x20
[ 18.860908] __ubsan_handle_out_of_bounds+0xa7/0xf0
[ 18.864022] ets_class_change+0x3d6/0x3f0
[ 18.864322] tc_ctl_tclass+0x251/0x910
[ 18.864587] ? lock_acquire+0x5e/0x140
[ 18.865113] ? __mutex_lock+0x9c/0xe70
[ 18.866009] ? __mutex_lock+0xa34/0xe70
[ 18.866401] rtnetlink_rcv_msg+0x170/0x6f0
[ 18.866806] ? __lock_acquire+0x578/0xc10
[ 18.867184] ? __pfx_rtnetlink_rcv_msg+0x10/0x10
[ 18.867503] netlink_rcv_skb+0x59/0x110
[ 18.867776] rtnetlink_rcv+0x15/0x30
[ 18.868159] netlink_unicast+0x1c3/0x2b0
[ 18.868440] netlink_sendmsg+0x239/0x4b0
[ 18.868721] ____sys_sendmsg+0x3e2/0x410
[ 18.869012] ___sys_sendmsg+0x88/0xe0
[ 18.869276] ? rseq_ip_fixup+0x198/0x260
[ 18.869563] ? rseq_update_cpu_node_id+0x10a/0x190
[ 18.869900] ? trace_hardirqs_off+0x5a/0xd0
[ 18.870196] ? syscall_exit_to_user_mode+0xcc/0x220
[ 18.870547] ? do_syscall_64+0x93/0x150
[ 18.870821] ? __memcg_slab_free_hook+0x69/0x290
[ 18.871157] __sys_sendmsg+0x69/0xd0
[ 18.871416] __x64_sys_sendmsg+0x1d/0x30
[ 18.871699] x64_sys_call+0x9e2/0x2670
[ 18.871979] do_syscall_64+0x87/0x150
[ 18.873280] ? do_syscall_64+0x93/0x150
[ 18.874742] ? lock_release+0x7b/0x160
[ 18.876157] ? do_user_addr_fault+0x5ce/0x8f0
[ 18.877833] ? irqentry_exit_to_user_mode+0xc2/0x210
[ 18.879608] ? irqentry_exit+0x77/0xb0
[ 18.879808] ? clear_bhb_loop+0x15/0x70
[ 18.880023] ? clear_bhb_loop+0x15/0x70
[ 18.880223] ? clear_bhb_loop+0x15/0x70
[ 18.880426] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 18.880683] RIP: 0033:0x44a957
[ 18.880851] Code: ff ff e8 fc 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 8974 24 10
[ 18.881766] RSP: 002b:00007ffcdd00fad8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
[ 18.882149] RAX: ffffffffffffffda RBX: 00007ffcdd010db8 RCX: 000000000044a957
[ 18.882507] RDX: 0000000000000000 RSI: 00007ffcdd00fb70 RDI: 0000000000000003
[ 18.885037] RBP: 00007ffcdd010bc0 R08: 000000000703c770 R09: 000000000703c7c0
[ 18.887203] R10: 0000000000000080 R11: 0000000000000246 R12: 0000000000000001
[ 18.888026] R13: 00007ffcdd010da8 R14: 00000000004ca7d0 R15: 0000000000000001
[ 18.888395] </TASK>
[ 18.888610] ---[ end trace ]--- |
["https://git.kernel.org/stable/c/03c56665dab1f4ac844bc156652d50d639093fa5","https://git.kernel.org/stable/c/1332c6ed446be787f901ed1064ec6a3c694f028a","https://git.kernel.org/stable/c/997f6ec4208b23c87daf9f044689685f091826f7","https://git.kernel.org/stable/c/bcf0d815e728a3a304b50455b32a3170c16e1eaa","https://git.kernel.org/stable/c/d62b04fca4340a0d468d7853bd66e511935a18cb","https://git.kernel.org/stable/c/f4168299e553f17aa2ba4016e77a9c38da40eb1d","https://git.kernel.org/stable/c/f6b0f05fbfa4044f890e8a348288c0d9a20bd1d0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-36978
|
High |
fixed |
- 5.4.279
- 5.10.221
- 5.15.162
- 6.1.95
- 6.6.35
- 6.9.6
|
In the Linux kernel, the following vulnerability has been resolved:
net: sched: sch_multiq: fix possible OOB write in multiq_tune()
q->bands will be assigned to qopt->bands to execute subsequent code logic
after kmalloc. So the old q->bands should not be used in kmalloc.
Otherwise, an out-of-bounds write will occur. |
["https://git.kernel.org/stable/c/0f208fad86631e005754606c3ec80c0d44a11882","https://git.kernel.org/stable/c/52b1aa07cda6a199cd6754d3798c7759023bc70f","https://git.kernel.org/stable/c/54c2c171c11a798fe887b3ff72922aa9d1411c1e","https://git.kernel.org/stable/c/598572c64287aee0b75bbba4e2881496878860f3","https://git.kernel.org/stable/c/affc18fdc694190ca7575b9a86632a73b9fe043d","https://git.kernel.org/stable/c/d5d9d241786f49ae7cbc08e7fc95a115e9d80f3d","https://git.kernel.org/stable/c/d6fb5110e8722bc00748f22caeb650fe4672f129","https://git.kernel.org/stable/c/0f208fad86631e005754606c3ec80c0d44a11882","https://git.kernel.org/stable/c/52b1aa07cda6a199cd6754d3798c7759023bc70f","https://git.kernel.org/stable/c/54c2c171c11a798fe887b3ff72922aa9d1411c1e","https://git.kernel.org/stable/c/598572c64287aee0b75bbba4e2881496878860f3","https://git.kernel.org/stable/c/affc18fdc694190ca7575b9a86632a73b9fe043d","https://git.kernel.org/stable/c/d5d9d241786f49ae7cbc08e7fc95a115e9d80f3d","https://git.kernel.org/stable/c/d6fb5110e8722bc00748f22caeb650fe4672f129"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50048
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
fbcon: Fix a NULL pointer dereference issue in fbcon_putcs
syzbot has found a NULL pointer dereference bug in fbcon.
Here is the simplified C reproducer:
struct param {
uint8_t type;
struct tiocl_selection ts;
};
int main()
{
struct fb_con2fbmap con2fb;
struct param param;
int fd = open("/dev/fb1", 0, 0);
con2fb.console = 0x19;
con2fb.framebuffer = 0;
ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb);
param.type = 2;
param.ts.xs = 0; param.ts.ys = 0;
param.ts.xe = 0; param.ts.ye = 0;
param.ts.sel_mode = 0;
int fd1 = open("/dev/tty1", O_RDWR, 0);
ioctl(fd1, TIOCLINUX, ¶m);
con2fb.console = 1;
con2fb.framebuffer = 0;
ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb);
return 0;
}
After calling ioctl(fd1, TIOCLINUX, ¶m), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb)
causes the kernel to follow a different execution path:
set_con2fb_map
-> con2fb_init_display
-> fbcon_set_disp
-> redraw_screen
-> hide_cursor
-> clear_selection
-> highlight
-> invert_screen
-> do_update_region
-> fbcon_putcs
-> ops->putcs
Since ops->putcs is a NULL pointer, this leads to a kernel panic.
To prevent this, we need to call set_blitting_type() within set_con2fb_map()
to properly initialize ops->putcs. |
["https://git.kernel.org/stable/c/5b97eebcce1b4f3f07a71f635d6aa3af96c236e7","https://git.kernel.org/stable/c/8266ae6eafdcd5a3136592445ff4038bbc7ee80e","https://git.kernel.org/stable/c/e5c2dba62996a3a6eeb34bd248b90fc69c5a6a1b","https://git.kernel.org/stable/c/f7fb5dda555344529ce584ff7a28b109528d2f1b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50167
|
Medium |
fixed |
- 4.19.323
- 5.4.285
- 5.10.229
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
be2net: fix potential memory leak in be_xmit()
The be_xmit() returns NETDEV_TX_OK without freeing skb
in case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it. |
["https://git.kernel.org/stable/c/4c5f170ef4f85731a4d43ad9a6ac51106c0946be","https://git.kernel.org/stable/c/641c1beed52bf3c6deb0193fe4d38ec9ff75d2ae","https://git.kernel.org/stable/c/6b7ce8ee01c33c380aaa5077ff25215492e7eb0e","https://git.kernel.org/stable/c/77bc881d370e850b7f3cd2b5eae67d596b40efbc","https://git.kernel.org/stable/c/919ab6e2370289a2748780f44a43333cd3878aa7","https://git.kernel.org/stable/c/941026023c256939943a47d1c66671526befbb26","https://git.kernel.org/stable/c/e4dd8bfe0f6a23acd305f9b892c00899089bd621","https://git.kernel.org/stable/c/e86a79b804e26e3b7f1e415b22a085c0bb7ea3d3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50184
|
Medium |
fixed |
- 5.4.285
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
virtio_pmem: Check device status before requesting flush
If a pmem device is in a bad status, the driver side could wait for
host ack forever in virtio_pmem_flush(), causing the system to hang.
So add a status check in the beginning of virtio_pmem_flush() to return
early if the device is not activated. |
["https://git.kernel.org/stable/c/4ce662fe4be6fbc2595d9ef4888b2b6e778c99ed","https://git.kernel.org/stable/c/59ac565c6277d4be6661e81ea6a7f3ca2c5e4e36","https://git.kernel.org/stable/c/6a5ca0ab94e13a1474bf7ad8437a975c2193618f","https://git.kernel.org/stable/c/9a2bc9b6f929a2ce1ebe4d1a796ddab37568c5b4","https://git.kernel.org/stable/c/b01793cc63dd39c8f12b9a3d8dc115fbebb19e2a","https://git.kernel.org/stable/c/ce7a3a62cc533c922072f328fd2ea2fd7cb893d4","https://git.kernel.org/stable/c/e25fbcd97cf52c3c9824d44b5c56c19673c3dd50"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50185
|
Medium |
fixed |
- 5.10.228
- 5.15.169
- 6.1.113
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
mptcp: handle consistently DSS corruption
Bugged peer implementation can send corrupted DSS options, consistently
hitting a few warning in the data path. Use DEBUG_NET assertions, to
avoid the splat on some builds and handle consistently the error, dumping
related MIBs and performing fallback and/or reset according to the
subflow type. |
["https://git.kernel.org/stable/c/12c1676d598e3b8dd92a033b623b792cc2ea1ec5","https://git.kernel.org/stable/c/35668f8ec84f6c944676e48ecc6bbc5fc8e6fe25","https://git.kernel.org/stable/c/8bfd391bde685df7289b928ce8876a3583be4bfb","https://git.kernel.org/stable/c/b8be15d1ae7ea4eedd547c3b3141f592fbddcd30","https://git.kernel.org/stable/c/e32d262c89e2b22cb0640223f953b548617ed8a6","https://git.kernel.org/stable/c/fde99e972b8f88cebe619241d7aa43d288ef666a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50194
|
Medium |
fixed |
- 4.19.323
- 5.4.285
- 5.10.229
- 5.15.170
- 6.1.115
- 6.6.58
- 6.11.5
|
In the Linux kernel, the following vulnerability has been resolved:
arm64: probes: Fix uprobes for big-endian kernels
The arm64 uprobes code is broken for big-endian kernels as it doesn't
convert the in-memory instruction encoding (which is always
little-endian) into the kernel's native endianness before analyzing and
simulating instructions. This may result in a few distinct problems:
* The kernel may may erroneously reject probing an instruction which can
safely be probed.
* The kernel may erroneously erroneously permit stepping an
instruction out-of-line when that instruction cannot be stepped
out-of-line safely.
* The kernel may erroneously simulate instruction incorrectly dur to
interpretting the byte-swapped encoding.
The endianness mismatch isn't caught by the compiler or sparse because:
* The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so
the compiler and sparse have no idea these contain a little-endian
32-bit value. The core uprobes code populates these with a memcpy()
which similarly does not handle endianness.
* While the uprobe_opcode_t type is an alias for __le32, both
arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[]
to the similarly-named probe_opcode_t, which is an alias for u32.
Hence there is no endianness conversion warning.
Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and
adding the appropriate __le32_to_cpu() conversions prior to consuming
the instruction encoding. The core uprobes copies these fields as opaque
ranges of bytes, and so is unaffected by this change.
At the same time, remove MAX_UINSN_BYTES and consistently use
AARCH64_INSN_SIZE for clarity.
Tested with the following:
| #include <stdio.h>
| #include <stdbool.h>
|
| #define noinline __attribute__((noinline))
|
| static noinline void *adrp_self(void)
| {
| void *addr;
|
| asm volatile(
| " adrp %x0, adrp_self\n"
| " add %x0, %x0, :lo12:adrp_self\n"
| : "=r" (addr));
| }
|
|
| int main(int argc, char *argv)
| {
| void *ptr = adrp_self();
| bool equal = (ptr == adrp_self);
|
| printf("adrp_self => %p\n"
| "adrp_self() => %p\n"
| "%s\n",
| adrp_self, ptr, equal ? "EQUAL" : "NOT EQUAL");
|
| return 0;
| }
.... where the adrp_self() function was compiled to:
| 00000000004007e0 <adrp_self>:
| 4007e0: 90000000 adrp x0, 400000 <__ehdr_start>
| 4007e4: 911f8000 add x0, x0, #0x7e0
| 4007e8: d65f03c0 ret
Before this patch, the ADRP is not recognized, and is assumed to be
steppable, resulting in corruption of the result:
| # ./adrp-self
| adrp_self => 0x4007e0
| adrp_self() => 0x4007e0
| EQUAL
| # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events
| # echo 1 > /sys/kernel/tracing/events/uprobes/enable
| # ./adrp-self
| adrp_self => 0x4007e0
| adrp_self() => 0xffffffffff7e0
| NOT EQUAL
After this patch, the ADRP is correctly recognized and simulated:
| # ./adrp-self
| adrp_self => 0x4007e0
| adrp_self() => 0x4007e0
| EQUAL
| #
| # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events
| # echo 1 > /sys/kernel/tracing/events/uprobes/enable
| # ./adrp-self
| adrp_self => 0x4007e0
| adrp_self() => 0x4007e0
| EQUAL |
["https://git.kernel.org/stable/c/13f8f1e05f1dc36dbba6cba0ae03354c0dafcde7","https://git.kernel.org/stable/c/14841bb7a531b96e2dde37423a3b33e75147c60d","https://git.kernel.org/stable/c/3d2530c65be04e93720e30f191a7cf1a3aa8b51c","https://git.kernel.org/stable/c/8165bf83b8a64be801d59cd2532b0d1ffed74d00","https://git.kernel.org/stable/c/b6a638cb600e13f94b5464724eaa6ab7f3349ca2","https://git.kernel.org/stable/c/cf60d19d40184e43d9a624e55a0da73be09e938d","https://git.kernel.org/stable/c/cf9ddf9ed94c15564a05bbf6e9f18dffa0c7df80","https://git.kernel.org/stable/c/e6ab336213918575124d6db43dc5d3554526242e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50195
|
Medium |
fixed |
- 4.19.323
- 5.4.285
- 5.10.228
- 5.15.169
- 6.1.114
- 6.6.58
- 6.11.5
|
In the Linux kernel, the following vulnerability has been resolved:
posix-clock: Fix missing timespec64 check in pc_clock_settime()
As Andrew pointed out, it will make sense that the PTP core
checked timespec64 struct's tv_sec and tv_nsec range before calling
ptp->info->settime64().
As the man manual of clock_settime() said, if tp.tv_sec is negative or
tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL,
which include dynamic clocks which handles PTP clock, and the condition is
consistent with timespec64_valid(). As Thomas suggested, timespec64_valid()
only check the timespec is valid, but not ensure that the time is
in a valid range, so check it ahead using timespec64_valid_strict()
in pc_clock_settime() and return -EINVAL if not valid.
There are some drivers that use tp->tv_sec and tp->tv_nsec directly to
write registers without validity checks and assume that the higher layer
has checked it, which is dangerous and will benefit from this, such as
hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(),
and some drivers can remove the checks of itself. |
["https://git.kernel.org/stable/c/1ff7247101af723731ea42ed565d54fb8f341264","https://git.kernel.org/stable/c/27abbde44b6e71ee3891de13e1a228aa7ce95bfe","https://git.kernel.org/stable/c/29f085345cde24566efb751f39e5d367c381c584","https://git.kernel.org/stable/c/673a1c5a2998acbd429d6286e6cad10f17f4f073","https://git.kernel.org/stable/c/a3f169e398215e71361774d13bf91a0101283ac2","https://git.kernel.org/stable/c/c8789fbe2bbf75845e45302cba6ffa44e1884d01","https://git.kernel.org/stable/c/d8794ac20a299b647ba9958f6d657051fc51a540","https://git.kernel.org/stable/c/e0c966bd3e31911b57ef76cec4c5796ebd88e512"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50198
|
Medium |
fixed |
- 5.10.228
- 5.15.169
- 6.1.114
- 6.6.58
- 6.11.5
|
In the Linux kernel, the following vulnerability has been resolved:
iio: light: veml6030: fix IIO device retrieval from embedded device
The dev pointer that is received as an argument in the
in_illuminance_period_available_show function references the device
embedded in the IIO device, not in the i2c client.
dev_to_iio_dev() must be used to accessthe right data. The current
implementation leads to a segmentation fault on every attempt to read
the attribute because indio_dev gets a NULL assignment.
This bug has been present since the first appearance of the driver,
apparently since the last version (V6) before getting applied. A
constant attribute was used until then, and the last modifications might
have not been tested again. |
["https://git.kernel.org/stable/c/2cbb41abae65626736b8b52cf3b9339612c5a86a","https://git.kernel.org/stable/c/50039aec43a82ad2495f2d0fb0c289c8717b4bb2","https://git.kernel.org/stable/c/905166531831beb067fffe2bdfc98031ffe89087","https://git.kernel.org/stable/c/bcb90518ccd9e10bf6ab29e31994aab93e4a4361","https://git.kernel.org/stable/c/bf3ab8e1c28f10df0823d4ff312f83c952b06a15","https://git.kernel.org/stable/c/c7c44e57750c31de43906d97813273fdffcf7d02"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50201
|
Medium |
fixed |
- 5.10.228
- 5.15.169
- 6.1.114
- 6.6.58
- 6.11.5
|
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: Fix encoder->possible_clones
Include the encoder itself in its possible_clones bitmask.
In the past nothing validated that drivers were populating
possible_clones correctly, but that changed in commit
74d2aacbe840 ("drm: Validate encoder->possible_clones").
Looks like radeon never got the memo and is still not
following the rules 100% correctly.
This results in some warnings during driver initialization:
Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7)
WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c
...
(cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db) |
["https://git.kernel.org/stable/c/1a235af0216411a32ab4db54f7bd19020b46c86d","https://git.kernel.org/stable/c/28127dba64d8ae1a0b737b973d6d029908599611","https://git.kernel.org/stable/c/68801730ebb9393460b30cd3885e407f15da27a9","https://git.kernel.org/stable/c/c3cd27d85f0778f4ec07384d7516b33153759b8e","https://git.kernel.org/stable/c/df75c78bfeff99f9b4815c3e79e2b1b1e34fe264","https://git.kernel.org/stable/c/fda5dc80121b12871dc343ab37e0c3f0d138825d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50202
|
Medium |
fixed |
- 4.19.323
- 5.4.285
- 5.10.228
- 5.15.169
- 6.1.114
- 6.6.58
- 6.11.5
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: propagate directory read errors from nilfs_find_entry()
Syzbot reported that a task hang occurs in vcs_open() during a fuzzing
test for nilfs2.
The root cause of this problem is that in nilfs_find_entry(), which
searches for directory entries, ignores errors when loading a directory
page/folio via nilfs_get_folio() fails.
If the filesystem images is corrupted, and the i_size of the directory
inode is large, and the directory page/folio is successfully read but
fails the sanity check, for example when it is zero-filled,
nilfs_check_folio() may continue to spit out error messages in bursts.
Fix this issue by propagating the error to the callers when loading a
page/folio fails in nilfs_find_entry().
The current interface of nilfs_find_entry() and its callers is outdated
and cannot propagate error codes such as -EIO and -ENOMEM returned via
nilfs_find_entry(), so fix it together. |
["https://git.kernel.org/stable/c/08cfa12adf888db98879dbd735bc741360a34168","https://git.kernel.org/stable/c/270a6f9df35fa2aea01ec23770dc9b3fc9a12989","https://git.kernel.org/stable/c/9698088ac7704e260f492d9c254e29ed7dd8729a","https://git.kernel.org/stable/c/b4b3dc9e7e604be98a222e9f941f5e93798ca475","https://git.kernel.org/stable/c/bb857ae1efd3138c653239ed1e7aef14e1242c81","https://git.kernel.org/stable/c/c1d0476885d708a932980b0f28cd90d9bd71db39","https://git.kernel.org/stable/c/edf8146057264191d5bfe5b91773f13d936dadd3","https://git.kernel.org/stable/c/efa810b15a25531cbc2f527330947b9fe16916e7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50205
|
Medium |
fixed |
- 5.4.285
- 5.10.229
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size()
The step variable is initialized to zero. It is changed in the loop,
but if it's not changed it will remain zero. Add a variable check
before the division.
The observed behavior was introduced by commit 826b5de90c0b
("ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size"),
and it is difficult to show that any of the interval parameters will
satisfy the snd_interval_test() condition with data from the
amdtp_rate_table[] table.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/3452d39c4704aa12504e4190298c721fb01083c3","https://git.kernel.org/stable/c/4bdc21506f12b2d432b1f2667e5ff4c75eee58e3","https://git.kernel.org/stable/c/5e431f85c87bbffd93a9830d5a576586f9855291","https://git.kernel.org/stable/c/72cafe63b35d06b5cfbaf807e90ae657907858da","https://git.kernel.org/stable/c/7d4eb9e22131ec154e638cbd56629195c9bcbe9a","https://git.kernel.org/stable/c/d2826873db70a6719cdd9212a6739f3e6234cfc4","https://git.kernel.org/stable/c/d575414361630b8b0523912532fcd7c79e43468c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53112
|
Medium |
fixed |
- 4.19.325
- 6.1.119
- 6.6.63
- 6.11.10
|
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: uncache inode which has failed entering the group
Syzbot has reported the following BUG:
kernel BUG at fs/ocfs2/uptodate.c:509!
...
Call Trace:
<TASK>
? __die_body+0x5f/0xb0
? die+0x9e/0xc0
? do_trap+0x15a/0x3a0
? ocfs2_set_new_buffer_uptodate+0x145/0x160
? do_error_trap+0x1dc/0x2c0
? ocfs2_set_new_buffer_uptodate+0x145/0x160
? __pfx_do_error_trap+0x10/0x10
? handle_invalid_op+0x34/0x40
? ocfs2_set_new_buffer_uptodate+0x145/0x160
? exc_invalid_op+0x38/0x50
? asm_exc_invalid_op+0x1a/0x20
? ocfs2_set_new_buffer_uptodate+0x2e/0x160
? ocfs2_set_new_buffer_uptodate+0x144/0x160
? ocfs2_set_new_buffer_uptodate+0x145/0x160
ocfs2_group_add+0x39f/0x15a0
? __pfx_ocfs2_group_add+0x10/0x10
? __pfx_lock_acquire+0x10/0x10
? mnt_get_write_access+0x68/0x2b0
? __pfx_lock_release+0x10/0x10
? rcu_read_lock_any_held+0xb7/0x160
? __pfx_rcu_read_lock_any_held+0x10/0x10
? smack_log+0x123/0x540
? mnt_get_write_access+0x68/0x2b0
? mnt_get_write_access+0x68/0x2b0
? mnt_get_write_access+0x226/0x2b0
ocfs2_ioctl+0x65e/0x7d0
? __pfx_ocfs2_ioctl+0x10/0x10
? smack_file_ioctl+0x29e/0x3a0
? __pfx_smack_file_ioctl+0x10/0x10
? lockdep_hardirqs_on_prepare+0x43d/0x780
? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10
? __pfx_ocfs2_ioctl+0x10/0x10
__se_sys_ioctl+0xfb/0x170
do_syscall_64+0xf3/0x230
entry_SYSCALL_64_after_hwframe+0x77/0x7f
...
</TASK>
When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particular
inode in 'ocfs2_verify_group_and_input()', corresponding buffer head
remains cached and subsequent call to the same 'ioctl()' for the same
inode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (trying
to cache the same buffer head of that inode). Fix this by uncaching
the buffer head with 'ocfs2_remove_from_cache()' on error path in
'ocfs2_group_add()'. |
["https://git.kernel.org/stable/c/0e04746db2ec4aec04cef5763b9d9aa32829ae2f","https://git.kernel.org/stable/c/28d4ed71ae0b4baedca3e85ee6d8f227ec75ebf6","https://git.kernel.org/stable/c/5ae8cc0b0c027e9cab22596049bc4dd1cbc37ee4","https://git.kernel.org/stable/c/620d22598110b0d0cb97a3fcca65fc473ea86e73","https://git.kernel.org/stable/c/737f34137844d6572ab7d473c998c7f977ff30eb","https://git.kernel.org/stable/c/843dfc804af4b338ead42331dd58081b428ecdf8","https://git.kernel.org/stable/c/ac0cfe8ac35cf1be54131b90d114087b558777ca","https://git.kernel.org/stable/c/b751c50e19d66cfb7360c0b55cf17b0722252d12"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53119
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
virtio/vsock: Fix accept_queue memory leak
As the final stages of socket destruction may be delayed, it is possible
that virtio_transport_recv_listen() will be called after the accept_queue
has been flushed, but before the SOCK_DONE flag has been set. As a result,
sockets enqueued after the flush would remain unremoved, leading to a
memory leak.
vsock_release
__vsock_release
lock
virtio_transport_release
virtio_transport_close
schedule_delayed_work(close_work)
sk_shutdown = SHUTDOWN_MASK
(!) flush accept_queue
release
virtio_transport_recv_pkt
vsock_find_bound_socket
lock
if flag(SOCK_DONE) return
virtio_transport_recv_listen
child = vsock_create_connected
(!) vsock_enqueue_accept(child)
release
close_work
lock
virtio_transport_do_close
set_flag(SOCK_DONE)
virtio_transport_remove_sock
vsock_remove_sock
vsock_remove_bound
release
Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during
socket destruction.
unreferenced object 0xffff888109e3f800 (size 2040):
comm "kworker/5:2", pid 371, jiffies 4294940105
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............
backtrace (crc 9e5f4e84):
[<ffffffff81418ff1>] kmem_cache_alloc_noprof+0x2c1/0x360
[<ffffffff81d27aa0>] sk_prot_alloc+0x30/0x120
[<ffffffff81d2b54c>] sk_alloc+0x2c/0x4b0
[<ffffffff81fe049a>] __vsock_create.constprop.0+0x2a/0x310
[<ffffffff81fe6d6c>] virtio_transport_recv_pkt+0x4dc/0x9a0
[<ffffffff81fe745d>] vsock_loopback_work+0xfd/0x140
[<ffffffff810fc6ac>] process_one_work+0x20c/0x570
[<ffffffff810fce3f>] worker_thread+0x1bf/0x3a0
[<ffffffff811070dd>] kthread+0xdd/0x110
[<ffffffff81044fdd>] ret_from_fork+0x2d/0x50
[<ffffffff8100785a>] ret_from_fork_asm+0x1a/0x30 |
["https://git.kernel.org/stable/c/2415345042245de7601dcc6eafdbe3a3dcc9e379","https://git.kernel.org/stable/c/4310902c766e371359e6c6311056ae80b5beeac9","https://git.kernel.org/stable/c/897617a413e0bf1c6380e3b34b2f28f450508549","https://git.kernel.org/stable/c/946c7600fa2207cc8d3fbc86a518ec56f98a5813","https://git.kernel.org/stable/c/d7b0ff5a866724c3ad21f2628c22a63336deec3f","https://git.kernel.org/stable/c/e26fa236758e8baa61a82cfd9fd4388d2e8d6a4c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53130
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint
When using the "block:block_dirty_buffer" tracepoint, mark_buffer_dirty()
may cause a NULL pointer dereference, or a general protection fault when
KASAN is enabled.
This happens because, since the tracepoint was added in
mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev
regardless of whether the buffer head has a pointer to a block_device
structure.
In the current implementation, nilfs_grab_buffer(), which grabs a buffer
to read (or create) a block of metadata, including b-tree node blocks,
does not set the block device, but instead does so only if the buffer is
not in the "uptodate" state for each of its caller block reading
functions. However, if the uptodate flag is set on a folio/page, and the
buffer heads are detached from it by try_to_free_buffers(), and new buffer
heads are then attached by create_empty_buffers(), the uptodate flag may
be restored to each buffer without the block device being set to
bh->b_bdev, and mark_buffer_dirty() may be called later in that state,
resulting in the bug mentioned above.
Fix this issue by making nilfs_grab_buffer() always set the block device
of the super block structure to the buffer head, regardless of the state
of the buffer's uptodate flag. |
["https://git.kernel.org/stable/c/0a5014ad37c77ac6a2c525137c00a0e1724f6020","https://git.kernel.org/stable/c/0ce59fb1c73fdd5b6028226aeb46259a0cdc0957","https://git.kernel.org/stable/c/2026559a6c4ce34db117d2db8f710fe2a9420d5a","https://git.kernel.org/stable/c/7af3309c7a2ef26831a67125b11c34a7e01c1b2a","https://git.kernel.org/stable/c/86b19031dbc79abc378dfae357f6ea33ebeb0c95","https://git.kernel.org/stable/c/b0e4765740040c44039282057ecacd7435d1d2ba","https://git.kernel.org/stable/c/d904e4d845aafbcfd8a40c1df7d999f02f062be8","https://git.kernel.org/stable/c/ffc440a76a0f476a7e6ea838ec0dc8e9979944d1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53138
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: kTLS, Fix incorrect page refcounting
The kTLS tx handling code is using a mix of get_page() and
page_ref_inc() APIs to increment the page reference. But on the release
path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used.
This is an issue when using pages from large folios: the get_page()
references are stored on the folio page while the page_ref_inc()
references are stored directly in the given page. On release the folio
page will be dereferenced too many times.
This was found while doing kTLS testing with sendfile() + ZC when the
served file was read from NFS on a kernel with NFS large folios support
(commit 49b29a573da8 ("nfs: add support for large folios")). |
["https://git.kernel.org/stable/c/2723e8b2cbd486cb96e5a61b22473f7fd62e18df","https://git.kernel.org/stable/c/69fbd07f17b0fdaf8970bc705f5bf115c297839d","https://git.kernel.org/stable/c/93a14620b97c911489a5b008782f3d9b0c4aeff4","https://git.kernel.org/stable/c/a0ddb20a748b122ea86003485f7992fa5e84cc95","https://git.kernel.org/stable/c/c7b97f9e794d8e2bbaa50e1d6c230196fd214b5e","https://git.kernel.org/stable/c/dd6e972cc5890d91d6749bb48e3912721c4e4b25","https://git.kernel.org/stable/c/ffad2ac8c859c1c1a981fe9c4f7ff925db684a43"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53140
|
Medium |
fixed |
- 4.5
- 4.9
- 6.1.119
- 6.6.63
- 6.11.10
|
In the Linux kernel, the following vulnerability has been resolved:
netlink: terminate outstanding dump on socket close
Netlink supports iterative dumping of data. It provides the families
the following ops:
- start - (optional) kicks off the dumping process
- dump - actual dump helper, keeps getting called until it returns 0
- done - (optional) pairs with .start, can be used for cleanup
The whole process is asynchronous and the repeated calls to .dump
don't actually happen in a tight loop, but rather are triggered
in response to recvmsg() on the socket.
This gives the user full control over the dump, but also means that
the user can close the socket without getting to the end of the dump.
To make sure .start is always paired with .done we check if there
is an ongoing dump before freeing the socket, and if so call .done.
The complication is that sockets can get freed from BH and .done
is allowed to sleep. So we use a workqueue to defer the call, when
needed.
Unfortunately this does not work correctly. What we defer is not
the cleanup but rather releasing a reference on the socket.
We have no guarantee that we own the last reference, if someone
else holds the socket they may release it in BH and we're back
to square one.
The whole dance, however, appears to be unnecessary. Only the user
can interact with dumps, so we can clean up when socket is closed.
And close always happens in process context. Some async code may
still access the socket after close, queue notification skbs to it etc.
but no dumps can start, end or otherwise make progress.
Delete the workqueue and flush the dump state directly from the release
handler. Note that further cleanup is possible in -next, for instance
we now always call .done before releasing the main module reference,
so dump doesn't have to take a reference of its own. |
["https://git.kernel.org/stable/c/114a61d8d94ae3a43b82446cf737fd757021b834","https://git.kernel.org/stable/c/176c41b3ca9281a9736b67c6121b03dbf0c8c08f","https://git.kernel.org/stable/c/1904fb9ebf911441f90a68e96b22aa73e4410505","https://git.kernel.org/stable/c/4e87a52133284afbd40fb522dbf96e258af52a98","https://git.kernel.org/stable/c/598c956b62699c3753929602560d8df322e60559","https://git.kernel.org/stable/c/6e3f2c512d2b7dbd247485b1dd9e43e4210a18f4","https://git.kernel.org/stable/c/bbc769d2fa1b8b368c5fbe013b5b096afa3c05ca","https://git.kernel.org/stable/c/d2fab3d66cc16cfb9e3ea1772abe6b79b71fa603"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-58011
|
Medium |
fixed |
- 6.1.129
- 6.6.78
- 6.12.14
- 6.13.3
|
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: int3472: Check for adev == NULL
Not all devices have an ACPI companion fwnode, so adev might be NULL. This
can e.g. (theoretically) happen when a user manually binds one of
the int3472 drivers to another i2c/platform device through sysfs.
Add a check for adev not being set and return -ENODEV in that case to
avoid a possible NULL pointer deref in skl_int3472_get_acpi_buffer(). |
["https://git.kernel.org/stable/c/0a30353beca2693d30bde477024d755ffecea514","https://git.kernel.org/stable/c/4f8b210823cc2d1f9d967f089a6c00d025bb237f","https://git.kernel.org/stable/c/a808ecf878ad646ebc9c83d9fc4ce72fd9c49d3d","https://git.kernel.org/stable/c/cd2fd6eab480dfc247b737cf7a3d6b009c4d0f1c","https://git.kernel.org/stable/c/f9c7cc44758f4930b41285a6d54afa8cbd9762b4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46819
|
Medium |
fixed |
- 5.10.226
- 5.15.167
- 6.1.109
- 6.6.50
- 6.10.9
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: the warning dereferencing obj for nbio_v7_4
if ras_manager obj null, don't print NBIO err data |
["https://git.kernel.org/stable/c/130c2dc75c8c40acc3c96ededea6af80e03c14b8","https://git.kernel.org/stable/c/614564a5b28983de53b23a358ebe6c483a2aa21e","https://git.kernel.org/stable/c/70e8ec21fcb8c51446899d3bfe416b31adfa3661","https://git.kernel.org/stable/c/7d265772e44d403071a2b573eac0db60250b1c21","https://git.kernel.org/stable/c/d04ded1e73f1dcf19a71ec8b9cda3faa7acd8828","https://git.kernel.org/stable/c/d190b459b2a4304307c3468ed97477b808381011"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50141
|
Medium |
fixed |
- 5.15.171
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context
PRMT needs to find the correct type of block to translate the PA-VA
mapping for EFI runtime services.
The issue arises because the PRMT is finding a block of type
EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services
as described in Section 2.2.2 (Runtime Services) of the UEFI
Specification [1]. Since the PRM handler is a type of runtime service,
this causes an exception when the PRM handler is called.
[Firmware Bug]: Unable to handle paging request in EFI runtime service
WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341
__efi_queue_work+0x11c/0x170
Call trace:
Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM
context.
If no suitable block is found, a warning message will be printed, but
the procedure continues to manage the next PRM handler.
However, if the PRM handler is actually called without proper allocation,
it would result in a failure during error handling.
By using the correct memory types for runtime services, ensure that the
PRM handler and the context are properly mapped in the virtual address
space during runtime, preventing the paging request error.
The issue is really that only memory that has been remapped for runtime
by the firmware can be used by the PRM handler, and so the region needs
to have the EFI_MEMORY_RUNTIME attribute.
[ rjw: Subject and changelog edits ] |
["https://git.kernel.org/stable/c/088984c8d54c0053fc4ae606981291d741c5924b","https://git.kernel.org/stable/c/20e9fafb8bb6f545667d7916b0e81e68c0748810","https://git.kernel.org/stable/c/795b080d9aa127215a5baf088a22fa09341a0126","https://git.kernel.org/stable/c/8ce081ad842510f0e70fa6065a401660eac876d4","https://git.kernel.org/stable/c/8df52929530839e878e6912e33348b54101e3250"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50258
|
Medium |
|
N/A
|
In the Linux kernel, the following vulnerability has been resolved:
net: fix crash when config small gso_max_size/gso_ipv4_max_size
Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow
in sk_dst_gso_max_size(), which may trigger a BUG_ON crash,
because sk->sk_gso_max_size would be much bigger than device limits.
Call Trace:
tcp_write_xmit
tso_segs = tcp_init_tso_segs(skb, mss_now);
tcp_set_skb_tso_segs
tcp_skb_pcount_set
// skb->len = 524288, mss_now = 8
// u16 tso_segs = 524288/8 = 65535 -> 0
tso_segs = DIV_ROUND_UP(skb->len, mss_now)
BUG_ON(!tso_segs)
Add check for the minimum value of gso_max_size and gso_ipv4_max_size. |
["https://git.kernel.org/stable/c/90c8482a5d9791259ba77bfdc1849fc5128b4be7","https://git.kernel.org/stable/c/9ab5cf19fb0e4680f95e506d6c544259bf1111c4","https://git.kernel.org/stable/c/ac5977001eee7660c643f8e07a2de9001990b7b8","https://git.kernel.org/stable/c/e72fd1389a5364bc6aa6312ecf30bdb5891b9486","https://git.kernel.org/stable/c/e9365368b483328639c03fc730448dccd5a25b6b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53113
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mm: fix NULL pointer dereference in alloc_pages_bulk_noprof
We triggered a NULL pointer dereference for ac.preferred_zoneref->zone in
alloc_pages_bulk_noprof() when the task is migrated between cpusets.
When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be
¤t->mems_allowed. when first_zones_zonelist() is called to find
preferred_zoneref, the ac->nodemask may be modified concurrently if the
task is migrated between different cpusets. Assuming we have 2 NUMA Node,
when traversing Node1 in ac->zonelist, the nodemask is 2, and when
traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the
ac->preferred_zoneref points to NULL zone.
In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a
allowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading
to NULL pointer dereference.
__alloc_pages_noprof() fixes this issue by checking NULL pointer in commit
ea57485af8f4 ("mm, page_alloc: fix check for NULL preferred_zone") and
commit df76cee6bbeb ("mm, page_alloc: remove redundant checks from alloc
fastpath").
To fix it, check NULL pointer for preferred_zoneref->zone. |
["https://git.kernel.org/stable/c/31502374627ba9ec3e710dbd0bb00457cc6d2c19","https://git.kernel.org/stable/c/6addb2d9501ec866d7b3a3b4e665307c437e9be2","https://git.kernel.org/stable/c/8ce41b0f9d77cca074df25afd39b86e2ee3aa68e","https://git.kernel.org/stable/c/903d896448c2e50e8652aaba529a30d4d1eaa0e5","https://git.kernel.org/stable/c/d0f16cec79774c3132df006cf771eddd89d08f58"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53120
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: CT: Fix null-ptr-deref in add rule err flow
In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add()
callback returns error, zone_rule->attr is used uninitiated. Fix it to
use attr which has the needed pointer value.
Kernel log:
BUG: kernel NULL pointer dereference, address: 0000000000000110
RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core]
…
Call Trace:
<TASK>
? __die+0x20/0x70
? page_fault_oops+0x150/0x3e0
? exc_page_fault+0x74/0x140
? asm_exc_page_fault+0x22/0x30
? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core]
? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core]
mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core]
? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table]
nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table]
flow_offload_work_handler+0x142/0x320 [nf_flow_table]
? finish_task_switch.isra.0+0x15b/0x2b0
process_one_work+0x16c/0x320
worker_thread+0x28c/0x3a0
? __pfx_worker_thread+0x10/0x10
kthread+0xb8/0xf0
? __pfx_kthread+0x10/0x10
ret_from_fork+0x2d/0x50
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK> |
["https://git.kernel.org/stable/c/06dc488a593020bd2f006798557d2a32104d8359","https://git.kernel.org/stable/c/0c7c70ff8b696cfedba350411dca736361ef9a0f","https://git.kernel.org/stable/c/6030f8bd7902e9e276a0edc09bf11979e4e2bc2e","https://git.kernel.org/stable/c/882f392d9e3649557e71efd78ae20c86039ffb7c","https://git.kernel.org/stable/c/e99c6873229fe0482e7ceb7d5600e32d623ed9d9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35898
|
Medium |
fixed |
- 4.19.312
- 5.4.274
- 5.10.215
- 5.15.154
- 6.1.85
- 6.6.26
- 6.8.5
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()
nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can
concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable().
And thhere is not any protection when iterate over nf_tables_flowtables
list in __nft_flowtable_type_get(). Therefore, there is pertential
data-race of nf_tables_flowtables list entry.
Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list
in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller
nft_flowtable_type_get() to protect the entire type query process. |
["https://git.kernel.org/stable/c/24225011d81b471acc0e1e315b7d9905459a6304","https://git.kernel.org/stable/c/2485bcfe05ee3cf9ca8923a94fa2e456924c79c8","https://git.kernel.org/stable/c/69d1fe14a680042ec913f22196b58e2c8ff1b007","https://git.kernel.org/stable/c/8b891153b2e4dc0ca9d9dab8f619d49c740813df","https://git.kernel.org/stable/c/940d41caa71f0d3a52df2fde5fada524a993e331","https://git.kernel.org/stable/c/9b5b7708ec2be21dd7ef8ca0e3abe4ae9f3b083b","https://git.kernel.org/stable/c/a347bc8e6251eaee4b619da28020641eb5b0dd77","https://git.kernel.org/stable/c/e684b1674fd1ca4361812a491242ae871d6b2859","https://git.kernel.org/stable/c/24225011d81b471acc0e1e315b7d9905459a6304","https://git.kernel.org/stable/c/2485bcfe05ee3cf9ca8923a94fa2e456924c79c8","https://git.kernel.org/stable/c/69d1fe14a680042ec913f22196b58e2c8ff1b007","https://git.kernel.org/stable/c/8b891153b2e4dc0ca9d9dab8f619d49c740813df","https://git.kernel.org/stable/c/940d41caa71f0d3a52df2fde5fada524a993e331","https://git.kernel.org/stable/c/9b5b7708ec2be21dd7ef8ca0e3abe4ae9f3b083b","https://git.kernel.org/stable/c/a347bc8e6251eaee4b619da28020641eb5b0dd77","https://git.kernel.org/stable/c/e684b1674fd1ca4361812a491242ae871d6b2859","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49949
|
Medium |
fixed |
- 4.19
- 5.4
- 5.10
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
net: avoid potential underflow in qdisc_pkt_len_init() with UFO
After commit 7c6d2ecbda83 ("net: be more gentle about silly gso
requests coming from user") virtio_net_hdr_to_skb() had sanity check
to detect malicious attempts from user space to cook a bad GSO packet.
Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: count
transport header in UFO") while fixing one issue, allowed user space
to cook a GSO packet with the following characteristic :
IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28.
When this packet arrives in qdisc_pkt_len_init(), we end up
with hdr_len = 28 (IPv4 header + UDP header), matching skb->len
Then the following sets gso_segs to 0 :
gso_segs = DIV_ROUND_UP(skb->len - hdr_len,
shinfo->gso_size);
Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/
qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len;
This leads to the following crash in fq_codel [1]
qdisc_pkt_len_init() is best effort, we only want an estimation
of the bytes sent on the wire, not crashing the kernel.
This patch is fixing this particular issue, a following one
adds more sanity checks for another potential bug.
[1]
[ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 70.724561] #PF: supervisor read access in kernel mode
[ 70.724561] #PF: error_code(0x0000) - not-present page
[ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0
[ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI
[ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991
[ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel
[ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49
All code
========
0: 24 08 and $0x8,%al
2: 49 c1 e1 06 shl $0x6,%r9
6: 44 89 7c 24 18 mov %r15d,0x18(%rsp)
b: 45 31 ed xor %r13d,%r13d
e: 45 31 c0 xor %r8d,%r8d
11: 31 ff xor %edi,%edi
13: 89 44 24 14 mov %eax,0x14(%rsp)
17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9
1e: eb 04 jmp 0x24
20: 39 ca cmp %ecx,%edx
22: 73 37 jae 0x5b
24: 4d 8b 39 mov (%r9),%r15
27: 83 c7 01 add $0x1,%edi
2a:* 49 8b 17 mov (%r15),%rdx <-- trapping instruction
2d: 49 89 11 mov %rdx,(%r9)
30: 41 8b 57 28 mov 0x28(%r15),%edx
34: 45 8b 5f 34 mov 0x34(%r15),%r11d
38: 49 c7 07 00 00 00 00 movq $0x0,(%r15)
3f: 49 rex.WB
Code starting with the faulting instruction
===========================================
0: 49 8b 17 mov (%r15),%rdx
3: 49 89 11 mov %rdx,(%r9)
6: 41 8b 57 28 mov 0x28(%r15),%edx
a: 45 8b 5f 34 mov 0x34(%r15),%r11d
e: 49 c7 07 00 00 00 00 movq $0x0,(%r15)
15: 49 rex.WB
[ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202
[ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000
[ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
[ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000
[ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58
[ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000
[ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000
[ 70.724561] CS: 0010 DS: 0000 ES: 0000 C
---truncated--- |
["https://git.kernel.org/stable/c/1598d70ad9c7d0a4d9d54b82094e9f45908fda6d","https://git.kernel.org/stable/c/25ab0b87dbd89cecef8a9c60a02bb97832e471d1","https://git.kernel.org/stable/c/81fd007dcd47c34471766249853e4d4bce8eea4b","https://git.kernel.org/stable/c/939c88cbdc668dadd8cfa7a35d9066331239041c","https://git.kernel.org/stable/c/ba26060a29d3ca1bfc737aa79f7125128f35147c","https://git.kernel.org/stable/c/c20029db28399ecc50e556964eaba75c43b1e2f1","https://git.kernel.org/stable/c/d6114993e0a89fde84a60a60a8329a571580b174","https://git.kernel.org/stable/c/d70ca7598943572d5e384227bd268acb5109bf72","https://git.kernel.org/stable/c/f959cce8a2a04ce776aa8b78e83ce339e0d7fbac"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49856
|
Medium |
fixed |
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
x86/sgx: Fix deadlock in SGX NUMA node search
When the current node doesn't have an EPC section configured by firmware
and all other EPC sections are used up, CPU can get stuck inside the
while loop that looks for an available EPC page from remote nodes
indefinitely, leading to a soft lockup. Note how nid_of_current will
never be equal to nid in that while loop because nid_of_current is not
set in sgx_numa_mask.
Also worth mentioning is that it's perfectly fine for the firmware not
to setup an EPC section on a node. While setting up an EPC section on
each node can enhance performance, it is not a requirement for
functionality.
Rework the loop to start and end on *a* node that has SGX memory. This
avoids the deadlock looking for the current SGX-lacking node to show up
in the loop when it never will. |
["https://git.kernel.org/stable/c/0f89fb4042c08fd143bfc28af08bf6c8a0197eea","https://git.kernel.org/stable/c/20c96d0aaabfe361fc2a11c173968dc67feadbbf","https://git.kernel.org/stable/c/40fb64257dab507d86b5f1f2a62f3669ef0c91a8","https://git.kernel.org/stable/c/8132510c915815e6b537ab937d94ed66893bc7b8","https://git.kernel.org/stable/c/9c936844010466535bd46ea4ce4656ef17653644","https://git.kernel.org/stable/c/fb2d057539eda67ec7cfc369bf587e6518a9b99d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46829
|
Medium |
fixed |
- 3.3
- 3.5
- 3.11
- 3.13
- 3.15
- 3.16
- 4.19.322
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
rtmutex: Drop rt_mutex::wait_lock before scheduling
rt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held. In the
good case it returns with the lock held and in the deadlock case it emits a
warning and goes into an endless scheduling loop with the lock held, which
triggers the 'scheduling in atomic' warning.
Unlock rt_mutex::wait_lock in the dead lock case before issuing the warning
and dropping into the schedule for ever loop.
[ tglx: Moved unlock before the WARN(), removed the pointless comment,
massaged changelog, added Fixes tag ] |
["https://git.kernel.org/stable/c/1401da1486dc1cdbef6025fd74a3977df3a3e5d0","https://git.kernel.org/stable/c/432efdbe7da5ecfcbc0c2180cfdbab1441752a38","https://git.kernel.org/stable/c/6a976e9a47e8e5b326de671811561cab12e6fb1f","https://git.kernel.org/stable/c/85f03ca98e07cd0786738b56ae73740bce0ac27f","https://git.kernel.org/stable/c/93f44655472d9cd418293d328f9d141ca234ad83","https://git.kernel.org/stable/c/a92d81c9efec9280681c27a2c0a963fd0f1338e0","https://git.kernel.org/stable/c/d33d26036a0274b472299d7dcdaa5fb34329f91b","https://git.kernel.org/stable/c/f13b5afc5c4889569d84c3011ce449f61fccfb28"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46727
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add otg_master NULL check within resource_log_pipe_topology_update
[Why]
Coverity reports NULL_RETURN warning.
[How]
Add otg_master NULL check. |
["https://git.kernel.org/stable/c/871cd9d881fa791d3f82885000713de07041c0ae","https://git.kernel.org/stable/c/aad4d3d3d3b6a362bf5db11e1f28c4a60620900d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46730
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Ensure array index tg_inst won't be -1
[WHY & HOW]
tg_inst will be a negative if timing_generator_count equals 0, which
should be checked before used.
This fixes 2 OVERRUN issues reported by Coverity. |
["https://git.kernel.org/stable/c/687fe329f18ab0ab0496b20ed2cb003d4879d931","https://git.kernel.org/stable/c/a64284b9e1999ad5580debced4bc6d6adb28aad4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46775
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Validate function returns
[WHAT & HOW]
Function return values must be checked before data can be used
in subsequent functions.
This fixes 4 CHECKED_RETURN issues reported by Coverity. |
["https://git.kernel.org/stable/c/5639a3048c7079803256374204ad55ec52cd0b49","https://git.kernel.org/stable/c/673f816b9e1e92d1f70e1bf5f21b531e0ff9ad6c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46778
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check UnboundedRequestEnabled's value
CalculateSwathAndDETConfiguration_params_st's UnboundedRequestEnabled
is a pointer (i.e. dml_bool_t *UnboundedRequestEnabled), and thus
if (p->UnboundedRequestEnabled) checks its address, not bool value.
This fixes 1 REVERSE_INULL issue reported by Coverity. |
["https://git.kernel.org/stable/c/4e2b49a85e7974d21364798c5d4aa8070aa864d9","https://git.kernel.org/stable/c/a7b38c7852093385d0605aa3c8a2efd6edd1edfd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46834
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ethtool: fail closed if we can't get max channel used in indirection tables
Commit 0d1b7d6c9274 ("bnxt: fix crashes when reducing ring count with
active RSS contexts") proves that allowing indirection table to contain
channels with out of bounds IDs may lead to crashes. Currently the
max channel check in the core gets skipped if driver can't fetch
the indirection table or when we can't allocate memory.
Both of those conditions should be extremely rare but if they do
happen we should try to be safe and fail the channel change. |
["https://git.kernel.org/stable/c/101737d8b88dbd4be6010bac398fe810f1950036","https://git.kernel.org/stable/c/2899d58462ba868287d6ff3acad3675e7adf934f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46842
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Handle mailbox timeouts in lpfc_get_sfp_info
The MBX_TIMEOUT return code is not handled in lpfc_get_sfp_info and the
routine unconditionally frees submitted mailbox commands regardless of
return status. The issue is that for MBX_TIMEOUT cases, when firmware
returns SFP information at a later time, that same mailbox memory region
references previously freed memory in its cmpl routine.
Fix by adding checks for the MBX_TIMEOUT return code. During mailbox
resource cleanup, check the mbox flag to make sure that the wait did not
timeout. If the MBOX_WAKE flag is not set, then do not free the resources
because it will be freed when firmware completes the mailbox at a later
time in its cmpl routine.
Also, increase the timeout from 30 to 60 seconds to accommodate boot
scripts requiring longer timeouts. |
["https://git.kernel.org/stable/c/bba47fe3b038cca3d3ebd799665ce69d6d273b58","https://git.kernel.org/stable/c/ede596b1434b57c0b3fd5c02b326efe5c54f6e48"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46863
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: Intel: soc-acpi-intel-lnl-match: add missing empty item
There is no links_num in struct snd_soc_acpi_mach {}, and we test
!link->num_adr as a condition to end the loop in hda_sdw_machine_select().
So an empty item in struct snd_soc_acpi_link_adr array is required. |
["https://git.kernel.org/stable/c/8eb57389d8ad91c67bf844f5aae4caef74b9091b","https://git.kernel.org/stable/c/c4246f1fe9f24f8dcd97887ed67d8fcfd91f4796"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53089
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: KVM: Mark hrtimer to expire in hard interrupt context
Like commit 2c0d278f3293f ("KVM: LAPIC: Mark hrtimer to expire in hard
interrupt context") and commit 9090825fa9974 ("KVM: arm/arm64: Let the
timer expire in hardirq context on RT"), On PREEMPT_RT enabled kernels
unmarked hrtimers are moved into soft interrupt expiry mode by default.
Then the timers are canceled from an preempt-notifier which is invoked
with disabled preemption which is not allowed on PREEMPT_RT.
The timer callback is short so in could be invoked in hard-IRQ context.
So let the timer expire on hard-IRQ context even on -RT.
This fix a "scheduling while atomic" bug for PREEMPT_RT enabled kernels:
BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002
Modules linked in: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns
CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G W 6.12.0-rc2+ #1774
Tainted: [W]=WARN
Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022
Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000
90000001167475a0 0000000000000000 90000001167475a8 9000000005644830
90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001
0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140
00000000000003fe 0000000000000001 000000000000000d 0000000000000003
0000000000000030 00000000000003f3 000000000790c000 9000000116747830
90000000057ef000 0000000000000000 9000000005644830 0000000000000004
0000000000000000 90000000057f4b58 0000000000000001 9000000116747868
900000000451b600 9000000005644830 9000000003a13998 0000000010000020
00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d
...
Call Trace:
[<9000000003a13998>] show_stack+0x38/0x180
[<9000000004e3ea34>] dump_stack_lvl+0x84/0xc0
[<9000000003a71708>] __schedule_bug+0x48/0x60
[<9000000004e45734>] __schedule+0x1114/0x1660
[<9000000004e46040>] schedule_rtlock+0x20/0x60
[<9000000004e4e330>] rtlock_slowlock_locked+0x3f0/0x10a0
[<9000000004e4f038>] rt_spin_lock+0x58/0x80
[<9000000003b02d68>] hrtimer_cancel_wait_running+0x68/0xc0
[<9000000003b02e30>] hrtimer_cancel+0x70/0x80
[<ffff80000235eb70>] kvm_restore_timer+0x50/0x1a0 [kvm]
[<ffff8000023616c8>] kvm_arch_vcpu_load+0x68/0x2a0 [kvm]
[<ffff80000234c2d4>] kvm_sched_in+0x34/0x60 [kvm]
[<9000000003a749a0>] finish_task_switch.isra.0+0x140/0x2e0
[<9000000004e44a70>] __schedule+0x450/0x1660
[<9000000004e45cb0>] schedule+0x30/0x180
[<ffff800002354c70>] kvm_vcpu_block+0x70/0x120 [kvm]
[<ffff800002354d80>] kvm_vcpu_halt+0x60/0x3e0 [kvm]
[<ffff80000235b194>] kvm_handle_gspr+0x3f4/0x4e0 [kvm]
[<ffff80000235f548>] kvm_handle_exit+0x1c8/0x260 [kvm] |
["https://git.kernel.org/stable/c/1e4c384a4be9ed1e069e24f388ab2ee9951b77b5","https://git.kernel.org/stable/c/73adbd92f3223dc0c3506822b71c6b259d5d537b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56650
|
High |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: x_tables: fix LED ID check in led_tg_check()
Syzbot has reported the following BUG detected by KASAN:
BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70
Read of size 1 at addr ffff8881022da0c8 by task repro/5879
...
Call Trace:
<TASK>
dump_stack_lvl+0x241/0x360
? __pfx_dump_stack_lvl+0x10/0x10
? __pfx__printk+0x10/0x10
? _printk+0xd5/0x120
? __virt_addr_valid+0x183/0x530
? __virt_addr_valid+0x183/0x530
print_report+0x169/0x550
? __virt_addr_valid+0x183/0x530
? __virt_addr_valid+0x183/0x530
? __virt_addr_valid+0x45f/0x530
? __phys_addr+0xba/0x170
? strlen+0x58/0x70
kasan_report+0x143/0x180
? strlen+0x58/0x70
strlen+0x58/0x70
kstrdup+0x20/0x80
led_tg_check+0x18b/0x3c0
xt_check_target+0x3bb/0xa40
? __pfx_xt_check_target+0x10/0x10
? stack_depot_save_flags+0x6e4/0x830
? nft_target_init+0x174/0xc30
nft_target_init+0x82d/0xc30
? __pfx_nft_target_init+0x10/0x10
? nf_tables_newrule+0x1609/0x2980
? nf_tables_newrule+0x1609/0x2980
? rcu_is_watching+0x15/0xb0
? nf_tables_newrule+0x1609/0x2980
? nf_tables_newrule+0x1609/0x2980
? __kmalloc_noprof+0x21a/0x400
nf_tables_newrule+0x1860/0x2980
? __pfx_nf_tables_newrule+0x10/0x10
? __nla_parse+0x40/0x60
nfnetlink_rcv+0x14e5/0x2ab0
? __pfx_validate_chain+0x10/0x10
? __pfx_nfnetlink_rcv+0x10/0x10
? __lock_acquire+0x1384/0x2050
? netlink_deliver_tap+0x2e/0x1b0
? __pfx_lock_release+0x10/0x10
? netlink_deliver_tap+0x2e/0x1b0
netlink_unicast+0x7f8/0x990
? __pfx_netlink_unicast+0x10/0x10
? __virt_addr_valid+0x183/0x530
? __check_object_size+0x48e/0x900
netlink_sendmsg+0x8e4/0xcb0
? __pfx_netlink_sendmsg+0x10/0x10
? aa_sock_msg_perm+0x91/0x160
? __pfx_netlink_sendmsg+0x10/0x10
__sock_sendmsg+0x223/0x270
____sys_sendmsg+0x52a/0x7e0
? __pfx_____sys_sendmsg+0x10/0x10
__sys_sendmsg+0x292/0x380
? __pfx___sys_sendmsg+0x10/0x10
? lockdep_hardirqs_on_prepare+0x43d/0x780
? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10
? exc_page_fault+0x590/0x8c0
? do_syscall_64+0xb6/0x230
do_syscall_64+0xf3/0x230
entry_SYSCALL_64_after_hwframe+0x77/0x7f
...
</TASK>
Since an invalid (without '\0' byte at all) byte sequence may be passed
from userspace, add an extra check to ensure that such a sequence is
rejected as possible ID and so never passed to 'kstrdup()' and further. |
["https://git.kernel.org/stable/c/04317f4eb2aad312ad85c1a17ad81fe75f1f9bc7","https://git.kernel.org/stable/c/147a42bb02de8735cb08476be6d0917987d022c2","https://git.kernel.org/stable/c/36a9d94dac28beef6b8abba46ba8874320d3e800","https://git.kernel.org/stable/c/a9bcc0b70d9baf3ff005874489a0dc9d023b54c3","https://git.kernel.org/stable/c/ab9916321c95f5280b72b4c5055e269f98627efe","https://git.kernel.org/stable/c/ad28612ebae1fcc1104bd432e99e99d87f6bfe09","https://git.kernel.org/stable/c/c40c96d98e536fc1daaa125c2332b988615e30a4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1651
|
High |
fixed |
|
A memory leak flaw was found in the Linux kernel in acrn_dev_ioctl in the drivers/virt/acrn/hsm.c function in how the ACRN Device Model emulates virtual NICs in VM. This flaw allows a local privileged attacker to leak unauthorized kernel information, causing a denial of service. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ecd1735f14d6ac868ae5d8b7a2bf193fa11f388b","https://security.netapp.com/advisory/ntap-20220901-0008/","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ecd1735f14d6ac868ae5d8b7a2bf193fa11f388b","https://security.netapp.com/advisory/ntap-20220901-0008/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-6536
|
High |
fixed |
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver, causing kernel panic and a denial of service. |
["https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:0881","https://access.redhat.com/errata/RHSA-2024:0897","https://access.redhat.com/errata/RHSA-2024:1248","https://access.redhat.com/errata/RHSA-2024:2094","https://access.redhat.com/errata/RHSA-2024:3810","https://access.redhat.com/security/cve/CVE-2023-6536","https://bugzilla.redhat.com/show_bug.cgi?id=2254052","https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:0881","https://access.redhat.com/errata/RHSA-2024:0897","https://access.redhat.com/errata/RHSA-2024:1248","https://access.redhat.com/errata/RHSA-2024:2094","https://access.redhat.com/errata/RHSA-2024:3810","https://access.redhat.com/security/cve/CVE-2023-6536","https://bugzilla.redhat.com/show_bug.cgi?id=2254052","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://security.netapp.com/advisory/ntap-20240415-0001/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2019-3819
|
Medium |
|
N/A
|
A flaw was found in the Linux kernel in the function hid_debug_events_read() in drivers/hid/hid-debug.c file which may enter an infinite loop with certain parameters passed from a userspace. A local privileged user ("root") can cause a system lock up and a denial of service. Versions from v4.18 and newer are vulnerable. |
["http://lists.opensuse.org/opensuse-security-announce/2019-04/msg00052.html","http://www.securityfocus.com/bid/106730","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-3819","https://lists.debian.org/debian-lts-announce/2019/03/msg00034.html","https://lists.debian.org/debian-lts-announce/2019/04/msg00004.html","https://lists.debian.org/debian-lts-announce/2019/05/msg00002.html","https://usn.ubuntu.com/3932-1/","https://usn.ubuntu.com/3932-2/","https://usn.ubuntu.com/4115-1/","https://usn.ubuntu.com/4118-1/","http://lists.opensuse.org/opensuse-security-announce/2019-04/msg00052.html","http://www.securityfocus.com/bid/106730","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-3819","https://lists.debian.org/debian-lts-announce/2019/03/msg00034.html","https://lists.debian.org/debian-lts-announce/2019/04/msg00004.html","https://lists.debian.org/debian-lts-announce/2019/05/msg00002.html","https://usn.ubuntu.com/3932-1/","https://usn.ubuntu.com/3932-2/","https://usn.ubuntu.com/4115-1/","https://usn.ubuntu.com/4118-1/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-0500
|
High |
fixed |
|
A flaw was found in unrestricted eBPF usage by the BPF_BTF_LOAD, leading to a possible out-of-bounds memory write in the Linux kernel’s BPF subsystem due to the way a user loads BTF. This flaw allows a local user to crash or escalate their privileges on the system. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2044578","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=20b2aff4bc15bda809f994761d5719827d66c0b4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=216e3cd2f28dbbf1fe86848e0e29e6693b9f0a20","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34d3a78c681e8e7844b43d1a2f4671a04249c821","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c4807322660d4290ac9062c034aed6b87243861","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=48946bd6a5d695c50b34546864b79c1f910a33c1","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c25b2ae136039ffa820c26138ed4a5e5f3ab3841","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cf9f2f8d62eca810afbd1ee6cc0800202b000e57","https://security.netapp.com/advisory/ntap-20220519-0001/","https://bugzilla.redhat.com/show_bug.cgi?id=2044578","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=20b2aff4bc15bda809f994761d5719827d66c0b4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=216e3cd2f28dbbf1fe86848e0e29e6693b9f0a20","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34d3a78c681e8e7844b43d1a2f4671a04249c821","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c4807322660d4290ac9062c034aed6b87243861","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=48946bd6a5d695c50b34546864b79c1f910a33c1","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c25b2ae136039ffa820c26138ed4a5e5f3ab3841","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cf9f2f8d62eca810afbd1ee6cc0800202b000e57","https://security.netapp.com/advisory/ntap-20220519-0001/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52896
|
Medium |
fixed |
- 5.4.230
- 5.10.165
- 5.15.90
- 5.17
- 6.1.8
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix race between quota rescan and disable leading to NULL pointer deref
If we have one task trying to start the quota rescan worker while another
one is trying to disable quotas, we can end up hitting a race that results
in the quota rescan worker doing a NULL pointer dereference. The steps for
this are the following:
1) Quotas are enabled;
2) Task A calls the quota rescan ioctl and enters btrfs_qgroup_rescan().
It calls qgroup_rescan_init() which returns 0 (success) and then joins a
transaction and commits it;
3) Task B calls the quota disable ioctl and enters btrfs_quota_disable().
It clears the bit BTRFS_FS_QUOTA_ENABLED from fs_info->flags and calls
btrfs_qgroup_wait_for_completion(), which returns immediately since the
rescan worker is not yet running.
Then it starts a transaction and locks fs_info->qgroup_ioctl_lock;
4) Task A queues the rescan worker, by calling btrfs_queue_work();
5) The rescan worker starts, and calls rescan_should_stop() at the start
of its while loop, which results in 0 iterations of the loop, since
the flag BTRFS_FS_QUOTA_ENABLED was cleared from fs_info->flags by
task B at step 3);
6) Task B sets fs_info->quota_root to NULL;
7) The rescan worker tries to start a transaction and uses
fs_info->quota_root as the root argument for btrfs_start_transaction().
This results in a NULL pointer dereference down the call chain of
btrfs_start_transaction(). The stack trace is something like the one
reported in Link tag below:
general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f]
CPU: 1 PID: 34 Comm: kworker/u4:2 Not tainted 6.1.0-syzkaller-13872-gb6bb9676f216 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Workqueue: btrfs-qgroup-rescan btrfs_work_helper
RIP: 0010:start_transaction+0x48/0x10f0 fs/btrfs/transaction.c:564
Code: 48 89 fb 48 (...)
RSP: 0018:ffffc90000ab7ab0 EFLAGS: 00010206
RAX: 0000000000000041 RBX: 0000000000000208 RCX: ffff88801779ba80
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: dffffc0000000000 R08: 0000000000000001 R09: fffff52000156f5d
R10: fffff52000156f5d R11: 1ffff92000156f5c R12: 0000000000000000
R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000003
FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2bea75b718 CR3: 000000001d0cc000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
btrfs_qgroup_rescan_worker+0x3bb/0x6a0 fs/btrfs/qgroup.c:3402
btrfs_work_helper+0x312/0x850 fs/btrfs/async-thread.c:280
process_one_work+0x877/0xdb0 kernel/workqueue.c:2289
worker_thread+0xb14/0x1330 kernel/workqueue.c:2436
kthread+0x266/0x300 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
</TASK>
Modules linked in:
So fix this by having the rescan worker function not attempt to start a
transaction if it didn't do any rescan work. |
["https://git.kernel.org/stable/c/1004fc90f0d79a4b7d9e3d432729914f472f9ad1","https://git.kernel.org/stable/c/3bd43374857103ba3cac751d6d4afa8d83b5d92a","https://git.kernel.org/stable/c/64287cd456a22373053998c1fccf14b651e9cbbd","https://git.kernel.org/stable/c/89ac597e3e807b91e2ebd6a7c36fec7b97290233","https://git.kernel.org/stable/c/b7adbf9ada3513d2092362c8eac5cddc5b651f5c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50082
|
Medium |
fixed |
- 5.10.228
- 5.15.169
- 6.1.114
- 6.6.58
- 6.11.5
|
In the Linux kernel, the following vulnerability has been resolved:
blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race
We're seeing crashes from rq_qos_wake_function that look like this:
BUG: unable to handle page fault for address: ffffafe180a40084
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0
Oops: Oops: 0002 [#1] PREEMPT SMP PTI
CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40
Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00
RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011
RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084
RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011
R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002
R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003
FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<IRQ>
try_to_wake_up+0x5a/0x6a0
rq_qos_wake_function+0x71/0x80
__wake_up_common+0x75/0xa0
__wake_up+0x36/0x60
scale_up.part.0+0x50/0x110
wb_timer_fn+0x227/0x450
...
So rq_qos_wake_function() calls wake_up_process(data->task), which calls
try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock).
p comes from data->task, and data comes from the waitqueue entry, which
is stored on the waiter's stack in rq_qos_wait(). Analyzing the core
dump with drgn, I found that the waiter had already woken up and moved
on to a completely unrelated code path, clobbering what was previously
data->task. Meanwhile, the waker was passing the clobbered garbage in
data->task to wake_up_process(), leading to the crash.
What's happening is that in between rq_qos_wake_function() deleting the
waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding
that it already got a token and returning. The race looks like this:
rq_qos_wait() rq_qos_wake_function()
==============================================================
prepare_to_wait_exclusive()
data->got_token = true;
list_del_init(&curr->entry);
if (data.got_token)
break;
finish_wait(&rqw->wait, &data.wq);
^- returns immediately because
list_empty_careful(&wq_entry->entry)
is true
... return, go do something else ...
wake_up_process(data->task)
(NO LONGER VALID!)-^
Normally, finish_wait() is supposed to synchronize against the waker.
But, as noted above, it is returning immediately because the waitqueue
entry has already been removed from the waitqueue.
The bug is that rq_qos_wake_function() is accessing the waitqueue entry
AFTER deleting it. Note that autoremove_wake_function() wakes the waiter
and THEN deletes the waitqueue entry, which is the proper order.
Fix it by swapping the order. We also need to use
list_del_init_careful() to match the list_empty_careful() in
finish_wait(). |
["https://git.kernel.org/stable/c/04f283fc16c8d5db641b6bffd2d8310aa7eccebc","https://git.kernel.org/stable/c/3bc6d0f8b70a9101456cf02ab99acb75254e1852","https://git.kernel.org/stable/c/455a469758e57a6fe070e3e342db12e4a629e0eb","https://git.kernel.org/stable/c/4c5b123ab289767afe940389dbb963c5c05e594e","https://git.kernel.org/stable/c/b5e900a3612b69423a0e1b0ab67841a1fb4af80f","https://git.kernel.org/stable/c/d04b72c9ef2b0689bfc1057d21c4aeed087c329f","https://git.kernel.org/stable/c/e972b08b91ef48488bae9789f03cfedb148667fb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52434
|
High |
fixed |
- 5.4.277
- 5.10.211
- 5.15.150
- 6.6.8
|
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential OOBs in smb2_parse_contexts()
Validate offsets and lengths before dereferencing create contexts in
smb2_parse_contexts().
This fixes following oops when accessing invalid create contexts from
server:
BUG: unable to handle page fault for address: ffff8881178d8cc3
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 4a01067 P4D 4a01067 PUD 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
RIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs]
Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00
00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 <0f> b7
7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00
RSP: 0018:ffffc900007939e0 EFLAGS: 00010216
RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90
RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000
RBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000
R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000
R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22
FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
<TASK>
? __die+0x23/0x70
? page_fault_oops+0x181/0x480
? search_module_extables+0x19/0x60
? srso_alias_return_thunk+0x5/0xfbef5
? exc_page_fault+0x1b6/0x1c0
? asm_exc_page_fault+0x26/0x30
? smb2_parse_contexts+0xa0/0x3a0 [cifs]
SMB2_open+0x38d/0x5f0 [cifs]
? smb2_is_path_accessible+0x138/0x260 [cifs]
smb2_is_path_accessible+0x138/0x260 [cifs]
cifs_is_path_remote+0x8d/0x230 [cifs]
cifs_mount+0x7e/0x350 [cifs]
cifs_smb3_do_mount+0x128/0x780 [cifs]
smb3_get_tree+0xd9/0x290 [cifs]
vfs_get_tree+0x2c/0x100
? capable+0x37/0x70
path_mount+0x2d7/0xb80
? srso_alias_return_thunk+0x5/0xfbef5
? _raw_spin_unlock_irqrestore+0x44/0x60
__x64_sys_mount+0x11a/0x150
do_syscall_64+0x47/0xf0
entry_SYSCALL_64_after_hwframe+0x6f/0x77
RIP: 0033:0x7f8737657b1e |
["https://git.kernel.org/stable/c/13fb0fc4917621f3dfa285a27eaf7151d770b5e5","https://git.kernel.org/stable/c/17a0f64cc02d4972e21c733d9f21d1c512963afa","https://git.kernel.org/stable/c/1ae3c59355dc9882e09c020afe8ffbd895ad0f29","https://git.kernel.org/stable/c/6726429c18c62dbf5e96ebbd522f262e016553fb","https://git.kernel.org/stable/c/890bc4fac3c0973a49cac35f634579bebba7fe48","https://git.kernel.org/stable/c/af1689a9b7701d9907dfc84d2a4b57c4bc907144","https://git.kernel.org/stable/c/13fb0fc4917621f3dfa285a27eaf7151d770b5e5","https://git.kernel.org/stable/c/17a0f64cc02d4972e21c733d9f21d1c512963afa","https://git.kernel.org/stable/c/1ae3c59355dc9882e09c020afe8ffbd895ad0f29","https://git.kernel.org/stable/c/6726429c18c62dbf5e96ebbd522f262e016553fb","https://git.kernel.org/stable/c/890bc4fac3c0973a49cac35f634579bebba7fe48","https://git.kernel.org/stable/c/af1689a9b7701d9907dfc84d2a4b57c4bc907144","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://security.netapp.com/advisory/ntap-20250117-0009/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46765
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ice: protect XDP configuration with a mutex
The main threat to data consistency in ice_xdp() is a possible asynchronous
PF reset. It can be triggered by a user or by TX timeout handler.
XDP setup and PF reset code access the same resources in the following
sections:
* ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked
* ice_vsi_rebuild() for the PF VSI - not protected
* ice_vsi_open() - already rtnl-locked
With an unfortunate timing, such accesses can result in a crash such as the
one below:
[ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 14
[ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 18
[Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms
[ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001
[ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout recovery level 1, txqueue 14
[ +0.394718] ice 0000:b1:00.0: PTP reset successful
[ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098
[ +0.000045] #PF: supervisor read access in kernel mode
[ +0.000023] #PF: error_code(0x0000) - not-present page
[ +0.000023] PGD 0 P4D 0
[ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1
[ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021
[ +0.000036] Workqueue: ice ice_service_task [ice]
[ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [ice]
[...]
[ +0.000013] Call Trace:
[ +0.000016] <TASK>
[ +0.000014] ? __die+0x1f/0x70
[ +0.000029] ? page_fault_oops+0x171/0x4f0
[ +0.000029] ? schedule+0x3b/0xd0
[ +0.000027] ? exc_page_fault+0x7b/0x180
[ +0.000022] ? asm_exc_page_fault+0x22/0x30
[ +0.000031] ? ice_clean_tx_ring+0xa/0xd0 [ice]
[ +0.000194] ice_free_tx_ring+0xe/0x60 [ice]
[ +0.000186] ice_destroy_xdp_rings+0x157/0x310 [ice]
[ +0.000151] ice_vsi_decfg+0x53/0xe0 [ice]
[ +0.000180] ice_vsi_rebuild+0x239/0x540 [ice]
[ +0.000186] ice_vsi_rebuild_by_type+0x76/0x180 [ice]
[ +0.000145] ice_rebuild+0x18c/0x840 [ice]
[ +0.000145] ? delay_tsc+0x4a/0xc0
[ +0.000022] ? delay_tsc+0x92/0xc0
[ +0.000020] ice_do_reset+0x140/0x180 [ice]
[ +0.000886] ice_service_task+0x404/0x1030 [ice]
[ +0.000824] process_one_work+0x171/0x340
[ +0.000685] worker_thread+0x277/0x3a0
[ +0.000675] ? preempt_count_add+0x6a/0xa0
[ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50
[ +0.000679] ? __pfx_worker_thread+0x10/0x10
[ +0.000653] kthread+0xf0/0x120
[ +0.000635] ? __pfx_kthread+0x10/0x10
[ +0.000616] ret_from_fork+0x2d/0x50
[ +0.000612] ? __pfx_kthread+0x10/0x10
[ +0.000604] ret_from_fork_asm+0x1b/0x30
[ +0.000604] </TASK>
The previous way of handling this through returning -EBUSY is not viable,
particularly when destroying AF_XDP socket, because the kernel proceeds
with removal anyway.
There is plenty of code between those calls and there is no need to create
a large critical section that covers all of them, same as there is no need
to protect ice_vsi_rebuild() with rtnl_lock().
Add xdp_state_lock mutex to protect ice_vsi_rebuild() and ice_xdp().
Leaving unprotected sections in between would result in two states that
have to be considered:
1. when the VSI is closed, but not yet rebuild
2. when VSI is already rebuild, but not yet open
The latter case is actually already handled through !netif_running() case,
we just need to adjust flag checking a little. The former one is not as
trivial, because between ice_vsi_close() and ice_vsi_rebuild(), a lot of
hardware interaction happens, this can make adding/deleting rings exit
with an error. Luckily, VSI rebuild is pending and can apply new
configuration for us in a managed fashion.
Therefore, add an additional VSI state flag ICE_VSI_REBUILD_PENDING to
indicate that ice_x
---truncated--- |
["https://git.kernel.org/stable/c/2504b8405768a57a71e660dbfd5abd59f679a03f","https://git.kernel.org/stable/c/2f057db2fb29bc209c103050647562e60554d3d3","https://git.kernel.org/stable/c/391f7dae3d836891fc6cfbde38add2d0e10c6b7f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21853
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: avoid holding freeze_mutex during mmap operation
We use map->freeze_mutex to prevent races between map_freeze() and
memory mapping BPF map contents with writable permissions. The way we
naively do this means we'll hold freeze_mutex for entire duration of all
the mm and VMA manipulations, which is completely unnecessary. This can
potentially also lead to deadlocks, as reported by syzbot in [0].
So, instead, hold freeze_mutex only during writeability checks, bump
(proactively) "write active" count for the map, unlock the mutex and
proceed with mmap logic. And only if something went wrong during mmap
logic, then undo that "write active" counter increment.
[0] https://lore.kernel.org/bpf/678dcbc9.050a0220.303755.0066.GAE@google.com/ |
["https://git.kernel.org/stable/c/0d90d9e154144a3a80e9fc0eb9b21b7fc990f68f","https://git.kernel.org/stable/c/271e49f8a58edba65bc2b1250a0abaa98c4bfdbe","https://git.kernel.org/stable/c/29cfda62ab4d92ab94123813db49ab76c1e61b29","https://git.kernel.org/stable/c/2ce31c97c219b4fe797749f950274f246eb88c49","https://git.kernel.org/stable/c/4759acbd44d24a69b7b14848012ec4201d6c5501","https://git.kernel.org/stable/c/bc27c52eea189e8f7492d40739b7746d67b65beb","https://git.kernel.org/stable/c/d95607a5f2f9bb08194c9deaf4a5f3e8ba59a9d4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48901
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not start relocation until in progress drops are done
We hit a bug with a recovering relocation on mount for one of our file
systems in production. I reproduced this locally by injecting errors
into snapshot delete with balance running at the same time. This
presented as an error while looking up an extent item
WARNING: CPU: 5 PID: 1501 at fs/btrfs/extent-tree.c:866 lookup_inline_extent_backref+0x647/0x680
CPU: 5 PID: 1501 Comm: btrfs-balance Not tainted 5.16.0-rc8+ #8
RIP: 0010:lookup_inline_extent_backref+0x647/0x680
RSP: 0018:ffffae0a023ab960 EFLAGS: 00010202
RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000000000
RBP: ffff943fd2a39b60 R08: 0000000000000000 R09: 0000000000000001
R10: 0001434088152de0 R11: 0000000000000000 R12: 0000000001d05000
R13: ffff943fd2a39b60 R14: ffff943fdb96f2a0 R15: ffff9442fc923000
FS: 0000000000000000(0000) GS:ffff944e9eb40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1157b1fca8 CR3: 000000010f092000 CR4: 0000000000350ee0
Call Trace:
<TASK>
insert_inline_extent_backref+0x46/0xd0
__btrfs_inc_extent_ref.isra.0+0x5f/0x200
? btrfs_merge_delayed_refs+0x164/0x190
__btrfs_run_delayed_refs+0x561/0xfa0
? btrfs_search_slot+0x7b4/0xb30
? btrfs_update_root+0x1a9/0x2c0
btrfs_run_delayed_refs+0x73/0x1f0
? btrfs_update_root+0x1a9/0x2c0
btrfs_commit_transaction+0x50/0xa50
? btrfs_update_reloc_root+0x122/0x220
prepare_to_merge+0x29f/0x320
relocate_block_group+0x2b8/0x550
btrfs_relocate_block_group+0x1a6/0x350
btrfs_relocate_chunk+0x27/0xe0
btrfs_balance+0x777/0xe60
balance_kthread+0x35/0x50
? btrfs_balance+0xe60/0xe60
kthread+0x16b/0x190
? set_kthread_struct+0x40/0x40
ret_from_fork+0x22/0x30
</TASK>
Normally snapshot deletion and relocation are excluded from running at
the same time by the fs_info->cleaner_mutex. However if we had a
pending balance waiting to get the ->cleaner_mutex, and a snapshot
deletion was running, and then the box crashed, we would come up in a
state where we have a half deleted snapshot.
Again, in the normal case the snapshot deletion needs to complete before
relocation can start, but in this case relocation could very well start
before the snapshot deletion completes, as we simply add the root to the
dead roots list and wait for the next time the cleaner runs to clean up
the snapshot.
Fix this by setting a bit on the fs_info if we have any DEAD_ROOT's that
had a pending drop_progress key. If they do then we know we were in the
middle of the drop operation and set a flag on the fs_info. Then
balance can wait until this flag is cleared to start up again.
If there are DEAD_ROOT's that don't have a drop_progress set then we're
safe to start balance right away as we'll be properly protected by the
cleaner_mutex. |
["https://git.kernel.org/stable/c/5e70bc827b563caf22e1203428cc3719643de5aa","https://git.kernel.org/stable/c/6599d5e8bd758d897fd2ef4dc388ae50278b1f7e","https://git.kernel.org/stable/c/b4be6aefa73c9a6899ef3ba9c5faaa8a66e333ef"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48902
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not WARN_ON() if we have PageError set
Whenever we do any extent buffer operations we call
assert_eb_page_uptodate() to complain loudly if we're operating on an
non-uptodate page. Our overnight tests caught this warning earlier this
week
WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50
CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G W 5.17.0-rc3+ #564
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Workqueue: btrfs-cache btrfs_work_helper
RIP: 0010:assert_eb_page_uptodate+0x3f/0x50
RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246
RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000
RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0
RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000
R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1
R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000
FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ff31d3448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0
Call Trace:
extent_buffer_test_bit+0x3f/0x70
free_space_test_bit+0xa6/0xc0
load_free_space_tree+0x1f6/0x470
caching_thread+0x454/0x630
? rcu_read_lock_sched_held+0x12/0x60
? rcu_read_lock_sched_held+0x12/0x60
? rcu_read_lock_sched_held+0x12/0x60
? lock_release+0x1f0/0x2d0
btrfs_work_helper+0xf2/0x3e0
? lock_release+0x1f0/0x2d0
? finish_task_switch.isra.0+0xf9/0x3a0
process_one_work+0x26d/0x580
? process_one_work+0x580/0x580
worker_thread+0x55/0x3b0
? process_one_work+0x580/0x580
kthread+0xf0/0x120
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x1f/0x30
This was partially fixed by c2e39305299f01 ("btrfs: clear extent buffer
uptodate when we fail to write it"), however all that fix did was keep
us from finding extent buffers after a failed writeout. It didn't keep
us from continuing to use a buffer that we already had found.
In this case we're searching the commit root to cache the block group,
so we can start committing the transaction and switch the commit root
and then start writing. After the switch we can look up an extent
buffer that hasn't been written yet and start processing that block
group. Then we fail to write that block out and clear Uptodate on the
page, and then we start spewing these errors.
Normally we're protected by the tree lock to a certain degree here. If
we read a block we have that block read locked, and we block the writer
from locking the block before we submit it for the write. However this
isn't necessarily fool proof because the read could happen before we do
the submit_bio and after we locked and unlocked the extent buffer.
Also in this particular case we have path->skip_locking set, so that
won't save us here. We'll simply get a block that was valid when we
read it, but became invalid while we were using it.
What we really want is to catch the case where we've "read" a block but
it's not marked Uptodate. On read we ClearPageError(), so if we're
!Uptodate and !Error we know we didn't do the right thing for reading
the page.
Fix this by checking !Uptodate && !Error, this way we will not complain
if our buffer gets invalidated while we're using it, and we'll maintain
the spirit of the check which is to make sure we have a fully in-cache
block while we're messing with it. |
["https://git.kernel.org/stable/c/9efcc83b33b576302147634eca9bece8e3737e34","https://git.kernel.org/stable/c/a50e1fcbc9b85fd4e95b89a75c0884cb032a3e06","https://git.kernel.org/stable/c/e00077aa439f0e8f416699fa4e9600db6583db70"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43906
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/admgpu: fix dereferencing null pointer context
When user space sets an invalid ta type, the pointer context will be empty.
So it need to check the pointer context before using it |
["https://git.kernel.org/stable/c/030ffd4d43b433bc6671d9ec34fc12c59220b95d","https://git.kernel.org/stable/c/4fd52f7c2c11d330571c6bde06e5ea508ec25c9d","https://git.kernel.org/stable/c/641dac64178ccdb9e45c92b67120316896294d05"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44961
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Forward soft recovery errors to userspace
As we discussed before[1], soft recovery should be
forwarded to userspace, or we can get into a really
bad state where apps will keep submitting hanging
command buffers cascading us to a hard reset.
1: https://lore.kernel.org/all/bf23d5ed-9a6b-43e7-84ee-8cbfd0d60f18@froggi.es/
(cherry picked from commit 434967aadbbbe3ad9103cc29e9a327de20fdba01) |
["https://git.kernel.org/stable/c/0da0b06165d83a8ecbb6582d9d5a135f9d38a52a","https://git.kernel.org/stable/c/829798c789f567ef6ba4b084c15b7b5f3bd98d51","https://git.kernel.org/stable/c/c28d207edfc5679585f4e96acb67000076ce90be"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44962
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btnxpuart: Shutdown timer and prevent rearming when driver unloading
When unload the btnxpuart driver, its associated timer will be deleted.
If the timer happens to be modified at this moment, it leads to the
kernel call this timer even after the driver unloaded, resulting in
kernel panic.
Use timer_shutdown_sync() instead of del_timer_sync() to prevent rearming.
panic log:
Internal error: Oops: 0000000086000007 [#1] PREEMPT SMP
Modules linked in: algif_hash algif_skcipher af_alg moal(O) mlan(O) crct10dif_ce polyval_ce polyval_generic snd_soc_imx_card snd_soc_fsl_asoc_card snd_soc_imx_audmux mxc_jpeg_encdec v4l2_jpeg snd_soc_wm8962 snd_soc_fsl_micfil snd_soc_fsl_sai flexcan snd_soc_fsl_utils ap130x rpmsg_ctrl imx_pcm_dma can_dev rpmsg_char pwm_fan fuse [last unloaded: btnxpuart]
CPU: 5 PID: 723 Comm: memtester Tainted: G O 6.6.23-lts-next-06207-g4aef2658ac28 #1
Hardware name: NXP i.MX95 19X19 board (DT)
pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : 0xffff80007a2cf464
lr : call_timer_fn.isra.0+0x24/0x80
...
Call trace:
0xffff80007a2cf464
__run_timers+0x234/0x280
run_timer_softirq+0x20/0x40
__do_softirq+0x100/0x26c
____do_softirq+0x10/0x1c
call_on_irq_stack+0x24/0x4c
do_softirq_own_stack+0x1c/0x2c
irq_exit_rcu+0xc0/0xdc
el0_interrupt+0x54/0xd8
__el0_irq_handler_common+0x18/0x24
el0t_64_irq_handler+0x10/0x1c
el0t_64_irq+0x190/0x194
Code: ???????? ???????? ???????? ???????? (????????)
---[ end trace 0000000000000000 ]---
Kernel panic - not syncing: Oops: Fatal exception in interrupt
SMP: stopping secondary CPUs
Kernel Offset: disabled
CPU features: 0x0,c0000000,40028143,1000721b
Memory Limit: none
---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- |
["https://git.kernel.org/stable/c/0d0df1e750bac0fdaa77940e711c1625cff08d33","https://git.kernel.org/stable/c/28bbb5011a9723700006da67bdb57ab6a914452b","https://git.kernel.org/stable/c/4d9adcb94d55e9be8a3e464d9f2ff7d27e2ed016"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42237
|
Medium |
fixed |
- 5.16
- 6.1.100
- 6.6.41
- 6.9.10
|
In the Linux kernel, the following vulnerability has been resolved:
firmware: cs_dsp: Validate payload length before processing block
Move the payload length check in cs_dsp_load() and cs_dsp_coeff_load()
to be done before the block is processed.
The check that the length of a block payload does not exceed the number
of remaining bytes in the firwmware file buffer was being done near the
end of the loop iteration. However, some code before that check used the
length field without validating it. |
["https://git.kernel.org/stable/c/259955eca9b7acf1299b1ac077d8cfbe12df35d8","https://git.kernel.org/stable/c/3a9cd924aec1288d675df721f244da4dd7e16cff","https://git.kernel.org/stable/c/6598afa9320b6ab13041616950ca5f8f938c0cf1","https://git.kernel.org/stable/c/71d9e313d8f7e18c543a9c80506fe6b1eb1fe0c8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42252
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
closures: Change BUG_ON() to WARN_ON()
If a BUG_ON() can be hit in the wild, it shouldn't be a BUG_ON()
For reference, this has popped up once in the CI, and we'll need more
info to debug it:
03240 ------------[ cut here ]------------
03240 kernel BUG at lib/closure.c:21!
03240 kernel BUG at lib/closure.c:21!
03240 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
03240 Modules linked in:
03240 CPU: 15 PID: 40534 Comm: kworker/u80:1 Not tainted 6.10.0-rc4-ktest-ga56da69799bd #25570
03240 Hardware name: linux,dummy-virt (DT)
03240 Workqueue: btree_update btree_interior_update_work
03240 pstate: 00001005 (nzcv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--)
03240 pc : closure_put+0x224/0x2a0
03240 lr : closure_put+0x24/0x2a0
03240 sp : ffff0000d12071c0
03240 x29: ffff0000d12071c0 x28: dfff800000000000 x27: ffff0000d1207360
03240 x26: 0000000000000040 x25: 0000000000000040 x24: 0000000000000040
03240 x23: ffff0000c1f20180 x22: 0000000000000000 x21: ffff0000c1f20168
03240 x20: 0000000040000000 x19: ffff0000c1f20140 x18: 0000000000000001
03240 x17: 0000000000003aa0 x16: 0000000000003ad0 x15: 1fffe0001c326974
03240 x14: 0000000000000a1e x13: 0000000000000000 x12: 1fffe000183e402d
03240 x11: ffff6000183e402d x10: dfff800000000000 x9 : ffff6000183e402e
03240 x8 : 0000000000000001 x7 : 00009fffe7c1bfd3 x6 : ffff0000c1f2016b
03240 x5 : ffff0000c1f20168 x4 : ffff6000183e402e x3 : ffff800081391954
03240 x2 : 0000000000000001 x1 : 0000000000000000 x0 : 00000000a8000000
03240 Call trace:
03240 closure_put+0x224/0x2a0
03240 bch2_check_for_deadlock+0x910/0x1028
03240 bch2_six_check_for_deadlock+0x1c/0x30
03240 six_lock_slowpath.isra.0+0x29c/0xed0
03240 six_lock_ip_waiter+0xa8/0xf8
03240 __bch2_btree_node_lock_write+0x14c/0x298
03240 bch2_trans_lock_write+0x6d4/0xb10
03240 __bch2_trans_commit+0x135c/0x5520
03240 btree_interior_update_work+0x1248/0x1c10
03240 process_scheduled_works+0x53c/0xd90
03240 worker_thread+0x370/0x8c8
03240 kthread+0x258/0x2e8
03240 ret_from_fork+0x10/0x20
03240 Code: aa1303e0 d63f0020 a94363f7 17ffff8c (d4210000)
03240 ---[ end trace 0000000000000000 ]---
03240 Kernel panic - not syncing: Oops - BUG: Fatal exception
03240 SMP: stopping secondary CPUs
03241 SMP: failed to stop secondary CPUs 13,15
03241 Kernel Offset: disabled
03241 CPU features: 0x00,00000003,80000008,4240500b
03241 Memory Limit: none
03241 ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception ]---
03246 ========= FAILED TIMEOUT copygc_torture_no_checksum in 7200s |
["https://git.kernel.org/stable/c/339b84ab6b1d66900c27bd999271cb2ae40ce812","https://git.kernel.org/stable/c/5d85f2ab79d5918a66539ebf046c099f7448db8d","https://git.kernel.org/stable/c/c894a74756478bb7aec894bcc513add3d554c0cf","https://git.kernel.org/stable/c/ecb4aaa658da760fb83afd79cc5fd4360aa60635"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57977
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
memcg: fix soft lockup in the OOM process
A soft lockup issue was found in the product with about 56,000 tasks were
in the OOM cgroup, it was traversing them when the soft lockup was
triggered.
watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066]
CPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G
Hardware name: Huawei Cloud OpenStack Nova, BIOS
RIP: 0010:console_unlock+0x343/0x540
RSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIG_RAX: ffffffffffffff13
RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffff
RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247
RBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040
R10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0
R13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
vprintk_emit+0x193/0x280
printk+0x52/0x6e
dump_task+0x114/0x130
mem_cgroup_scan_tasks+0x76/0x100
dump_header+0x1fe/0x210
oom_kill_process+0xd1/0x100
out_of_memory+0x125/0x570
mem_cgroup_out_of_memory+0xb5/0xd0
try_charge+0x720/0x770
mem_cgroup_try_charge+0x86/0x180
mem_cgroup_try_charge_delay+0x1c/0x40
do_anonymous_page+0xb5/0x390
handle_mm_fault+0xc4/0x1f0
This is because thousands of processes are in the OOM cgroup, it takes a
long time to traverse all of them. As a result, this lead to soft lockup
in the OOM process.
To fix this issue, call 'cond_resched' in the 'mem_cgroup_scan_tasks'
function per 1000 iterations. For global OOM, call
'touch_softlockup_watchdog' per 1000 iterations to avoid this issue. |
["https://git.kernel.org/stable/c/0a09d56e1682c951046bf15542b3e9553046c9f6","https://git.kernel.org/stable/c/110399858194c71f11afefad6e7be9e3876b284f","https://git.kernel.org/stable/c/46576834291869457d4772bb7df72d7c2bb3d57f","https://git.kernel.org/stable/c/72f2c0b7c152c2983ed51d48c3272cab4f34d965","https://git.kernel.org/stable/c/972486d37169fe85035e81b8c5dff21f70df1173","https://git.kernel.org/stable/c/a9042dbc1ed4bf25a5f5c699d10c3d676abf8ca2","https://git.kernel.org/stable/c/ade81479c7dda1ce3eedb215c78bc615bbd04f06","https://git.kernel.org/stable/c/c3a3741db8c1202aa959c77df3a4c361612d1eb1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47661
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Avoid overflow from uint32_t to uint8_t
[WHAT & HOW]
dmub_rb_cmd's ramping_boundary has size of uint8_t and it is assigned
0xFFFF. Fix it by changing it to uint8_t with value of 0xFF.
This fixes 2 INTEGER_OVERFLOW issues reported by Coverity. |
["https://git.kernel.org/stable/c/30d1b783b6eeaf49d311a072c70d618d993d01ec","https://git.kernel.org/stable/c/d6b54900c564e35989cf6813e4071504fa0a90e0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47662
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Remove register from DCN35 DMCUB diagnostic collection
[Why]
These registers should not be read from driver and triggering the
security violation when DMCUB work times out and diagnostics are
collected blocks Z8 entry.
[How]
Remove the register read from DCN35. |
["https://git.kernel.org/stable/c/466423c6dd8af23ebb3a69d43434d01aed0db356","https://git.kernel.org/stable/c/eba4b2a38ccdf074a053834509545703d6df1d57"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47683
|
Medium |
fixed |
- 6.1.105
- 6.1.113
- 6.6.46
- 6.6.54
- 6.10.5
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Skip Recompute DSC Params if no Stream on Link
[why]
Encounter NULL pointer dereference uner mst + dsc setup.
BUG: kernel NULL pointer dereference, address: 0000000000000008
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2
Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022
RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper]
Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8>
RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224
RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280
RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850
R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000
R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224
FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0
Call Trace:
<TASK>
? __die+0x23/0x70
? page_fault_oops+0x171/0x4e0
? plist_add+0xbe/0x100
? exc_page_fault+0x7c/0x180
? asm_exc_page_fault+0x26/0x30
? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]
? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]
compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
drm_atomic_check_only+0x5c5/0xa40
drm_mode_atomic_ioctl+0x76e/0xbc0
[how]
dsc recompute should be skipped if no mode change detected on the new
request. If detected, keep checking whether the stream is already on
current state or not. |
["https://git.kernel.org/stable/c/7c887efda1201110211fed8921a92a713e0b6bcd","https://git.kernel.org/stable/c/8151a6c13111b465dbabe07c19f572f7cbd16fef"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49893
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check stream_status before it is used
[WHAT & HOW]
dc_state_get_stream_status can return null, and therefore null must be
checked before stream_status is used.
This fixes 1 NULL_RETURNS issue reported by Coverity. |
["https://git.kernel.org/stable/c/4914c8bfee1843fae046a12970b6f178e6642659","https://git.kernel.org/stable/c/58a8ee96f84d2c21abb85ad8c22d2bbdf59bd7a9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49908
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2)
This commit adds a null check for the 'afb' variable in the
amdgpu_dm_update_cursor function. Previously, 'afb' was assumed to be
null at line 8388, but was used later in the code without a null check.
This could potentially lead to a null pointer dereference.
Changes since v1:
- Moved the null check for 'afb' to the line where 'afb' is used. (Alex)
Fixes the below:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8433 amdgpu_dm_update_cursor()
error: we previously assumed 'afb' could be null (see line 8388) |
["https://git.kernel.org/stable/c/0fe20258b4989b9112b5e9470df33a0939403fd4","https://git.kernel.org/stable/c/a742168b6a39ead257da53bcbe472384d6e14a1b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49910
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add NULL check for function pointer in dcn401_set_output_transfer_func
This commit adds a null check for the set_output_gamma function pointer
in the dcn401_set_output_transfer_func function. Previously,
set_output_gamma was being checked for null, but then it was being
dereferenced without any null check. This could lead to a null pointer
dereference if set_output_gamma is null.
To fix this, we now ensure that set_output_gamma is not null before
dereferencing it. We do this by adding a null check for set_output_gamma
before the call to set_output_gamma. |
["https://git.kernel.org/stable/c/d8ee900b92b6526cf84275b49a473155ad75c70e","https://git.kernel.org/stable/c/dd340acd42c24a3f28dd22fae6bf38662334264c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49916
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn401_init_hw
This commit addresses a potential null pointer dereference issue in the
`dcn401_init_hw` function. The issue could occur when `dc->clk_mgr` or
`dc->clk_mgr->funcs` is null.
The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is
not null before accessing its functions. This prevents a potential null
pointer dereference.
Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn401/dcn401_hwseq.c:416 dcn401_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 225) |
["https://git.kernel.org/stable/c/4b6377f0e96085cbec96eb7f0b282430ccdd3d75","https://git.kernel.org/stable/c/ac1c41e318074d8a9ea925787e366be15d7645e8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49920
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check null pointers before multiple uses
[WHAT & HOW]
Poniters, such as stream_enc and dc->bw_vbios, are null checked previously
in the same function, so Coverity warns "implies that stream_enc and
dc->bw_vbios might be null". They are used multiple times in the
subsequent code and need to be checked.
This fixes 10 FORWARD_NULL issues reported by Coverity. |
["https://git.kernel.org/stable/c/26787fb6c2b2ee0d1a7e1574b36f4711ae40fe27","https://git.kernel.org/stable/c/fdd5ecbbff751c3b9061d8ebb08e5c96119915b4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49921
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check null pointers before used
[WHAT & HOW]
Poniters, such as dc->clk_mgr, are null checked previously in the same
function, so Coverity warns "implies that "dc->clk_mgr" might be null".
As a result, these pointers need to be checked when used again.
This fixes 10 FORWARD_NULL issues reported by Coverity. |
["https://git.kernel.org/stable/c/5b35bf1a82eb29841b67ff5643ba83762250fc24","https://git.kernel.org/stable/c/be1fb44389ca3038ad2430dac4234669bc177ee3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49940
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
l2tp: prevent possible tunnel refcount underflow
When a session is created, it sets a backpointer to its tunnel. When
the session refcount drops to 0, l2tp_session_free drops the tunnel
refcount if session->tunnel is non-NULL. However, session->tunnel is
set in l2tp_session_create, before the tunnel refcount is incremented
by l2tp_session_register, which leaves a small window where
session->tunnel is non-NULL when the tunnel refcount hasn't been
bumped.
Moving the assignment to l2tp_session_register is trivial but
l2tp_session_create calls l2tp_session_set_header_len which uses
session->tunnel to get the tunnel's encap. Add an encap arg to
l2tp_session_set_header_len to avoid using session->tunnel.
If l2tpv3 sessions have colliding IDs, it is possible for
l2tp_v3_session_get to race with l2tp_session_register and fetch a
session which doesn't yet have session->tunnel set. Add a check for
this case. |
["https://git.kernel.org/stable/c/24256415d18695b46da06c93135f5b51c548b950","https://git.kernel.org/stable/c/f7415e60c25a6108cd7955a20b2e66b6251ffe02"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49968
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: filesystems without casefold feature cannot be mounted with siphash
When mounting the ext4 filesystem, if the default hash version is set to
DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting. |
["https://git.kernel.org/stable/c/985b67cd86392310d9e9326de941c22fc9340eec","https://git.kernel.org/stable/c/e1373903db6c4ac994de0d18076280ad88e12dee"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49971
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Increase array size of dummy_boolean
[WHY]
dml2_core_shared_mode_support and dml_core_mode_support access the third
element of dummy_boolean, i.e. hw_debug5 = &s->dummy_boolean[2], when
dummy_boolean has size of 2. Any assignment to hw_debug5 causes an
OVERRUN.
[HOW]
Increase dummy_boolean's array size to 3.
This fixes 2 OVERRUN issues reported by Coverity. |
["https://git.kernel.org/stable/c/6d64d39486197083497a01b39e23f2f8474b35d3","https://git.kernel.org/stable/c/e9e48b7bb9cf3b78f0305ef0144aaf61da0a83d8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49972
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Deallocate DML memory if allocation fails
[Why]
When DC state create DML memory allocation fails, memory is not
deallocated subsequently, resulting in uninitialized structure
that is not NULL.
[How]
Deallocate memory if DML memory allocation fails. |
["https://git.kernel.org/stable/c/80345daa5746184195f2d383a2f1bad058f0f94c","https://git.kernel.org/stable/c/892abca6877a96c9123bb1c010cafccdf8ca1b75"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50090
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/oa: Fix overflow in oa batch buffer
By default xe_bb_create_job() appends a MI_BATCH_BUFFER_END to batch
buffer, this is not a problem if batch buffer is only used once but
oa reuses the batch buffer for the same metric and at each call
it appends a MI_BATCH_BUFFER_END, printing the warning below and then
overflowing.
[ 381.072016] ------------[ cut here ]------------
[ 381.072019] xe 0000:00:02.0: [drm] Assertion `bb->len * 4 + bb_prefetch(q->gt) <= size` failed!
platform: LUNARLAKE subplatform: 1
graphics: Xe2_LPG / Xe2_HPG 20.04 step B0
media: Xe2_LPM / Xe2_HPM 20.00 step B0
tile: 0 VRAM 0 B
GT: 0 type 1
So here checking if batch buffer already have MI_BATCH_BUFFER_END if
not append it.
v2:
- simply fix, suggestion from Ashutosh
(cherry picked from commit 9ba0e0f30ca42a98af3689460063edfb6315718a) |
["https://git.kernel.org/stable/c/6c10ba06bb1b48acce6d4d9c1e33beb9954f1788","https://git.kernel.org/stable/c/bcb5be3421705e682b0b32073ad627056d6bc2a2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50179
|
Medium |
fixed |
- 4.19.323
- 5.4.285
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
ceph: remove the incorrect Fw reference check when dirtying pages
When doing the direct-io reads it will also try to mark pages dirty,
but for the read path it won't hold the Fw caps and there is case
will it get the Fw reference. |
["https://git.kernel.org/stable/c/11ab19d48ab877430eed0c7d83810970bbcbc4f6","https://git.kernel.org/stable/c/126b567a2ef65fc38a71d832bf1216c56816f231","https://git.kernel.org/stable/c/74b302ebad5b43ac17460fa58092d892a3cba6eb","https://git.kernel.org/stable/c/9d4f619153bab7fa59736462967821d6521a38cb","https://git.kernel.org/stable/c/c08dfb1b49492c09cf13838c71897493ea3b424e","https://git.kernel.org/stable/c/c26c5ec832dd9e9dcd0a0a892a485c99889b68f0","https://git.kernel.org/stable/c/ea98284fc4fb05f276737d2043b02b62be5a8dfb","https://git.kernel.org/stable/c/f55e003d261baa7c57d51ae5c8ec1f5c26a35c89","https://git.kernel.org/stable/c/f863bfd0a2c6c99011c62ea71ac04f8e78707da9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49024
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
can: m_can: pci: add missing m_can_class_free_dev() in probe/remove methods
In m_can_pci_remove() and error handling path of m_can_pci_probe(),
m_can_class_free_dev() should be called to free resource allocated by
m_can_class_allocate_dev(), otherwise there will be memleak. |
["https://git.kernel.org/stable/c/0bbb88651ef6b7fbb1bf75ec7ba69add632e834b","https://git.kernel.org/stable/c/1eca1d4cc21b6d0fc5f9a390339804c0afce9439","https://git.kernel.org/stable/c/ea8dc27bb044e19868155e500ce397007be98656"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47703
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf, lsm: Add check for BPF LSM return value
A bpf prog returning a positive number attached to file_alloc_security
hook makes kernel panic.
This happens because file system can not filter out the positive number
returned by the LSM prog using IS_ERR, and misinterprets this positive
number as a file pointer.
Given that hook file_alloc_security never returned positive number
before the introduction of BPF LSM, and other BPF LSM hooks may
encounter similar issues, this patch adds LSM return value check
in verifier, to ensure no unexpected value is returned. |
["https://git.kernel.org/stable/c/1050727d83e70449991c29dd1cf29fe936a63da3","https://git.kernel.org/stable/c/27ca3e20fe80be85a92b10064dfeb56cb2564b1c","https://git.kernel.org/stable/c/5d99e198be279045e6ecefe220f5c52f8ce9bfd5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49955
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
ACPI: battery: Fix possible crash when unregistering a battery hook
When a battery hook returns an error when adding a new battery, then
the battery hook is automatically unregistered.
However the battery hook provider cannot know that, so it will later
call battery_hook_unregister() on the already unregistered battery
hook, resulting in a crash.
Fix this by using the list head to mark already unregistered battery
hooks as already being unregistered so that they can be ignored by
battery_hook_unregister(). |
["https://git.kernel.org/stable/c/07b98400cb0285a6348188aa8c5ec6a2ae0551f7","https://git.kernel.org/stable/c/76959aff14a0012ad6b984ec7686d163deccdc16","https://git.kernel.org/stable/c/76fb2cbf01571926da8ecf6876cc8cb07d3f5183","https://git.kernel.org/stable/c/9f469ef1c79dac7f9ac1518643a33703918f7e13","https://git.kernel.org/stable/c/c47843a831e0eae007ad7e848d208e675ba4c132","https://git.kernel.org/stable/c/ca1fb7942a287b40659cc79551a1de54a2c2e7d5","https://git.kernel.org/stable/c/ca26e8eed9c1c6651f51f7fa38fe444f8573cd1b","https://git.kernel.org/stable/c/ce31847f109c3a5b2abdd19d7bcaafaacfde53de","https://git.kernel.org/stable/c/da964de4c18199e14b961b5b2e5e6570552a313c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56634
|
Medium |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
gpio: grgpio: Add NULL check in grgpio_probe
devm_kasprintf() can return a NULL pointer on failure,but this
returned value in grgpio_probe is not checked.
Add NULL check in grgpio_probe, to handle kernel NULL
pointer dereference error. |
["https://git.kernel.org/stable/c/050b23d081da0f29474de043e9538c1f7a351b3b","https://git.kernel.org/stable/c/09adf8792b61c09ae543972a1ece1884ef773848","https://git.kernel.org/stable/c/4733f68e59bb7b9e3d395699abb18366954b9ba7","https://git.kernel.org/stable/c/53ff0caa6ad57372d426b4f48fc0f66df43a731f","https://git.kernel.org/stable/c/8d2ca6ac3711a4f4015d26b7cc84f325ac608edb","https://git.kernel.org/stable/c/ad4dfa7ea7f5f7e9a3c78627cfc749bc7005ca7a","https://git.kernel.org/stable/c/db2fc255fcf41f536ac8666409849e11659af88d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46773
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check denominator pbn_div before used
[WHAT & HOW]
A denominator cannot be 0, and is checked before used.
This fixes 1 DIVIDE_BY_ZERO issue reported by Coverity. |
["https://git.kernel.org/stable/c/116a678f3a9abc24f5c9d2525b7393d18d9eb58e","https://git.kernel.org/stable/c/11f997143c67680d6e40a13363618380cd57a414","https://git.kernel.org/stable/c/20e7164c52d9bfbb9d9862b833fa989624a61345","https://git.kernel.org/stable/c/dfafee0a7b51c7c9612edd2d991401294964d02f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46826
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ELF: fix kernel.randomize_va_space double read
ELF loader uses "randomize_va_space" twice. It is sysctl and can change
at any moment, so 2 loads could see 2 different values in theory with
unpredictable consequences.
Issue exactly one load for consistent value across one exec. |
["https://git.kernel.org/stable/c/1cf8cd80903073440b6ea055811d04edd24fe4f7","https://git.kernel.org/stable/c/1f81d51141a234ad0a3874b4d185dc27a521cd27","https://git.kernel.org/stable/c/2a97388a807b6ab5538aa8f8537b2463c6988bd2","https://git.kernel.org/stable/c/53f17409abf61f66b6f05aff795e938e5ba811d1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46835
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix smatch static checker warning
adev->gfx.imu.funcs could be NULL |
["https://git.kernel.org/stable/c/8bc7b3ce33e64c74211ed17aec823fc4e523426a","https://git.kernel.org/stable/c/bdbdc7cecd00305dc844a361f9883d3a21022027","https://git.kernel.org/stable/c/c2056c7a840f0dbf293bc3b0d91826d001668fb0","https://git.kernel.org/stable/c/d40c2c3dd0395fe7fdc19bd96551e87251426d66"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50248
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ntfs3: Add bounds checking to mi_enum_attr()
Added bounds checking to make sure that every attr don't stray beyond
valid memory region. |
["https://git.kernel.org/stable/c/22cdf3be7d34f61a91b9e2966fec3a29f3871398","https://git.kernel.org/stable/c/386613a44b858304a88529ade2ccc1e079a5fc56","https://git.kernel.org/stable/c/556bdf27c2dd5c74a9caacbe524b943a6cd42d99","https://git.kernel.org/stable/c/809f9b419c75f8042c58434d2bfe849140643e9d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3545
|
High |
fixed |
- 4.14.303
- 4.19.270
- 5.4.228
- 5.10.160
- 5.15.84
|
A vulnerability has been found in Linux Kernel and classified as critical. Affected by this vulnerability is the function area_cache_get of the file drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c of the component IPsec. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The identifier VDB-211045 was assigned to this vulnerability. |
["https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=02e1a114fdb71e59ee6770294166c30d437bf86a","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20221223-0003/","https://vuldb.com/?id.211045","https://www.debian.org/security/2023/dsa-5324","https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=02e1a114fdb71e59ee6770294166c30d437bf86a","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20221223-0003/","https://vuldb.com/?id.211045","https://www.debian.org/security/2023/dsa-5324"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2018-10876
|
Medium |
|
N/A
|
A flaw was found in Linux kernel in the ext4 filesystem code. A use-after-free is possible in ext4_ext_remove_space() function when mounting and operating a crafted ext4 image. |
["http://patchwork.ozlabs.org/patch/929239/","http://www.securityfocus.com/bid/104904","http://www.securityfocus.com/bid/106503","https://access.redhat.com/errata/RHSA-2019:0525","https://bugzilla.kernel.org/show_bug.cgi?id=199403","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10876","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8844618d8aa7a9973e7b527d038a2a589665002c","https://lists.debian.org/debian-lts-announce/2018/07/msg00020.html","https://usn.ubuntu.com/3753-1/","https://usn.ubuntu.com/3753-2/","https://usn.ubuntu.com/3871-1/","https://usn.ubuntu.com/3871-3/","https://usn.ubuntu.com/3871-4/","https://usn.ubuntu.com/3871-5/","http://patchwork.ozlabs.org/patch/929239/","http://www.securityfocus.com/bid/104904","http://www.securityfocus.com/bid/106503","https://access.redhat.com/errata/RHSA-2019:0525","https://bugzilla.kernel.org/show_bug.cgi?id=199403","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10876","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8844618d8aa7a9973e7b527d038a2a589665002c","https://lists.debian.org/debian-lts-announce/2018/07/msg00020.html","https://usn.ubuntu.com/3753-1/","https://usn.ubuntu.com/3753-2/","https://usn.ubuntu.com/3871-1/","https://usn.ubuntu.com/3871-3/","https://usn.ubuntu.com/3871-4/","https://usn.ubuntu.com/3871-5/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26901
|
Medium |
fixed |
- 4.19.311
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak
syzbot identified a kernel information leak vulnerability in
do_sys_name_to_handle() and issued the following report [1].
[1]
"BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
_copy_to_user+0xbc/0x100 lib/usercopy.c:40
copy_to_user include/linux/uaccess.h:191 [inline]
do_sys_name_to_handle fs/fhandle.c:73 [inline]
__do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
__se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94
__x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
...
Uninit was created at:
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
slab_alloc_node mm/slub.c:3478 [inline]
__kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
__do_kmalloc_node mm/slab_common.c:1006 [inline]
__kmalloc+0x121/0x3c0 mm/slab_common.c:1020
kmalloc include/linux/slab.h:604 [inline]
do_sys_name_to_handle fs/fhandle.c:39 [inline]
__do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
__se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94
__x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
...
Bytes 18-19 of 20 are uninitialized
Memory access of size 20 starts at ffff888128a46380
Data copied to user address 0000000020000240"
Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to
solve the problem. |
["https://git.kernel.org/stable/c/3948abaa4e2be938ccdfc289385a27342fb13d43","https://git.kernel.org/stable/c/423b6bdf19bbc5e1f7e7461045099917378f7e71","https://git.kernel.org/stable/c/4bac28f441e3cc9d3f1a84c8d023228a68d8a7c1","https://git.kernel.org/stable/c/772a7def9868091da3bcb0d6c6ff9f0c03d7fa8b","https://git.kernel.org/stable/c/bf9ec1b24ab4e94345aa1c60811dd329f069c38b","https://git.kernel.org/stable/c/c1362eae861db28b1608b9dc23e49634fe87b63b","https://git.kernel.org/stable/c/cba138f1ef37ec6f961baeab62f312dedc7cf730","https://git.kernel.org/stable/c/cde76b3af247f615447bcfecf610bb76c3529126","https://git.kernel.org/stable/c/e6450d5e46a737a008b4885aa223486113bf0ad6","https://git.kernel.org/stable/c/3948abaa4e2be938ccdfc289385a27342fb13d43","https://git.kernel.org/stable/c/423b6bdf19bbc5e1f7e7461045099917378f7e71","https://git.kernel.org/stable/c/4bac28f441e3cc9d3f1a84c8d023228a68d8a7c1","https://git.kernel.org/stable/c/772a7def9868091da3bcb0d6c6ff9f0c03d7fa8b","https://git.kernel.org/stable/c/bf9ec1b24ab4e94345aa1c60811dd329f069c38b","https://git.kernel.org/stable/c/c1362eae861db28b1608b9dc23e49634fe87b63b","https://git.kernel.org/stable/c/cba138f1ef37ec6f961baeab62f312dedc7cf730","https://git.kernel.org/stable/c/cde76b3af247f615447bcfecf610bb76c3529126","https://git.kernel.org/stable/c/e6450d5e46a737a008b4885aa223486113bf0ad6","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-47640
|
High |
fixed |
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
powerpc/kasan: Fix early region not updated correctly
The shadow's page table is not updated when PTE_RPN_SHIFT is 24
and PAGE_SHIFT is 12. It not only causes false positives but
also false negative as shown the following text.
Fix it by bringing the logic of kasan_early_shadow_page_entry here.
1. False Positive:
==================================================================
BUG: KASAN: vmalloc-out-of-bounds in pcpu_alloc+0x508/0xa50
Write of size 16 at addr f57f3be0 by task swapper/0/1
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.0-12267-gdebe436e77c7 #1
Call Trace:
[c80d1c20] [c07fe7b8] dump_stack_lvl+0x4c/0x6c (unreliable)
[c80d1c40] [c02ff668] print_address_description.constprop.0+0x88/0x300
[c80d1c70] [c02ff45c] kasan_report+0x1ec/0x200
[c80d1cb0] [c0300b20] kasan_check_range+0x160/0x2f0
[c80d1cc0] [c03018a4] memset+0x34/0x90
[c80d1ce0] [c0280108] pcpu_alloc+0x508/0xa50
[c80d1d40] [c02fd7bc] __kmem_cache_create+0xfc/0x570
[c80d1d70] [c0283d64] kmem_cache_create_usercopy+0x274/0x3e0
[c80d1db0] [c2036580] init_sd+0xc4/0x1d0
[c80d1de0] [c00044a0] do_one_initcall+0xc0/0x33c
[c80d1eb0] [c2001624] kernel_init_freeable+0x2c8/0x384
[c80d1ef0] [c0004b14] kernel_init+0x24/0x170
[c80d1f10] [c001b26c] ret_from_kernel_thread+0x5c/0x64
Memory state around the buggy address:
f57f3a80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
f57f3b00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>f57f3b80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
^
f57f3c00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
f57f3c80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
==================================================================
2. False Negative (with KASAN tests):
==================================================================
Before fix:
ok 45 - kmalloc_double_kzfree
# vmalloc_oob: EXPECTATION FAILED at lib/test_kasan.c:1039
KASAN failure expected in "((volatile char *)area)[3100]", but none occurred
not ok 46 - vmalloc_oob
not ok 1 - kasan
==================================================================
After fix:
ok 1 - kasan |
["https://git.kernel.org/stable/c/5a3d8f3192a409893c57808cc935e16484df1068","https://git.kernel.org/stable/c/7f19245c3647afea8c7c41f795506ef70f64b9f2","https://git.kernel.org/stable/c/dd75080aa8409ce10d50fb58981c6b59bf8707d3","https://git.kernel.org/stable/c/de56beace6648065d404cd9835aa7d30e3df519d","https://git.kernel.org/stable/c/e3d157a4b4f4e0268c98be5b7013bf4b31234bb6","https://git.kernel.org/stable/c/f39a3309393a4a484532f6ba745c6acbcfe06115"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49058
|
High |
fixed |
- 4.9.311
- 4.14.276
- 4.19.239
- 5.4.190
- 5.10.112
- 5.15.35
- 5.17.4
|
In the Linux kernel, the following vulnerability has been resolved:
cifs: potential buffer overflow in handling symlinks
Smatch printed a warning:
arch/x86/crypto/poly1305_glue.c:198 poly1305_update_arch() error:
__memcpy() 'dctx->buf' too small (16 vs u32max)
It's caused because Smatch marks 'link_len' as untrusted since it comes
from sscanf(). Add a check to ensure that 'link_len' is not larger than
the size of the 'link_str' buffer. |
["https://git.kernel.org/stable/c/1316c28569a80ab3596eeab05bf5e01991e7e739","https://git.kernel.org/stable/c/22d658c6c5affed10c8907e67160cef0b6c92186","https://git.kernel.org/stable/c/3e582749e742e662a8e9bb37cffac62dccaaa1e2","https://git.kernel.org/stable/c/4e166a41180be2f1e66bbb6d46448e80a9a5ec05","https://git.kernel.org/stable/c/515e7ba11ef043d6febe69389949c8ef5f25e9d0","https://git.kernel.org/stable/c/64c4a37ac04eeb43c42d272f6e6c8c12bfcf4304","https://git.kernel.org/stable/c/9901b07ba42b39266b34a888e48d7306fd707bee","https://git.kernel.org/stable/c/eb5f51756944735ac70cd8bb38637cc202e29c91"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49087
|
High |
fixed |
- 4.19.238
- 5.4.189
- 5.10.111
- 5.15.34
- 5.16.20
- 5.17.3
|
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: fix a race in rxrpc_exit_net()
Current code can lead to the following race:
CPU0 CPU1
rxrpc_exit_net()
rxrpc_peer_keepalive_worker()
if (rxnet->live)
rxnet->live = false;
del_timer_sync(&rxnet->peer_keepalive_timer);
timer_reduce(&rxnet->peer_keepalive_timer, jiffies + delay);
cancel_work_sync(&rxnet->peer_keepalive_work);
rxrpc_exit_net() exits while peer_keepalive_timer is still armed,
leading to use-after-free.
syzbot report was:
ODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0
WARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505
Modules linked in:
CPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: netns cleanup_net
RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505
Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 <0f> 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3
RSP: 0018:ffffc9000353fb00 EFLAGS: 00010082
RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000
RDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0
R13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000
FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
__debug_check_no_obj_freed lib/debugobjects.c:992 [inline]
debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1023
kfree+0xd6/0x310 mm/slab.c:3809
ops_free_list.part.0+0x119/0x370 net/core/net_namespace.c:176
ops_free_list net/core/net_namespace.c:174 [inline]
cleanup_net+0x591/0xb00 net/core/net_namespace.c:598
process_one_work+0x996/0x1610 kernel/workqueue.c:2289
worker_thread+0x665/0x1080 kernel/workqueue.c:2436
kthread+0x2e9/0x3a0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298
</TASK> |
["https://git.kernel.org/stable/c/08ff0e74fab517dbc44e11b8bc683dd4ecc65950","https://git.kernel.org/stable/c/1946014ca3b19be9e485e780e862c375c6f98bad","https://git.kernel.org/stable/c/41024a40f6c793abbb916a857f18fb009f07464c","https://git.kernel.org/stable/c/571d8e1d154ca18f08dcb72b69318d36e10010a0","https://git.kernel.org/stable/c/7ee84d29f22de6f6c63fad6c54690517659862f1","https://git.kernel.org/stable/c/864297ee30727ae6233f80296b7fc91442620b05","https://git.kernel.org/stable/c/cd8aef1f30d1215648e4e6686cfb422004851429"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49176
|
High |
fixed |
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
bfq: fix use-after-free in bfq_dispatch_request
KASAN reports a use-after-free report when doing normal scsi-mq test
[69832.239032] ==================================================================
[69832.241810] BUG: KASAN: use-after-free in bfq_dispatch_request+0x1045/0x44b0
[69832.243267] Read of size 8 at addr ffff88802622ba88 by task kworker/3:1H/155
[69832.244656]
[69832.245007] CPU: 3 PID: 155 Comm: kworker/3:1H Not tainted 5.10.0-10295-g576c6382529e #8
[69832.246626] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[69832.249069] Workqueue: kblockd blk_mq_run_work_fn
[69832.250022] Call Trace:
[69832.250541] dump_stack+0x9b/0xce
[69832.251232] ? bfq_dispatch_request+0x1045/0x44b0
[69832.252243] print_address_description.constprop.6+0x3e/0x60
[69832.253381] ? __cpuidle_text_end+0x5/0x5
[69832.254211] ? vprintk_func+0x6b/0x120
[69832.254994] ? bfq_dispatch_request+0x1045/0x44b0
[69832.255952] ? bfq_dispatch_request+0x1045/0x44b0
[69832.256914] kasan_report.cold.9+0x22/0x3a
[69832.257753] ? bfq_dispatch_request+0x1045/0x44b0
[69832.258755] check_memory_region+0x1c1/0x1e0
[69832.260248] bfq_dispatch_request+0x1045/0x44b0
[69832.261181] ? bfq_bfqq_expire+0x2440/0x2440
[69832.262032] ? blk_mq_delay_run_hw_queues+0xf9/0x170
[69832.263022] __blk_mq_do_dispatch_sched+0x52f/0x830
[69832.264011] ? blk_mq_sched_request_inserted+0x100/0x100
[69832.265101] __blk_mq_sched_dispatch_requests+0x398/0x4f0
[69832.266206] ? blk_mq_do_dispatch_ctx+0x570/0x570
[69832.267147] ? __switch_to+0x5f4/0xee0
[69832.267898] blk_mq_sched_dispatch_requests+0xdf/0x140
[69832.268946] __blk_mq_run_hw_queue+0xc0/0x270
[69832.269840] blk_mq_run_work_fn+0x51/0x60
[69832.278170] process_one_work+0x6d4/0xfe0
[69832.278984] worker_thread+0x91/0xc80
[69832.279726] ? __kthread_parkme+0xb0/0x110
[69832.280554] ? process_one_work+0xfe0/0xfe0
[69832.281414] kthread+0x32d/0x3f0
[69832.282082] ? kthread_park+0x170/0x170
[69832.282849] ret_from_fork+0x1f/0x30
[69832.283573]
[69832.283886] Allocated by task 7725:
[69832.284599] kasan_save_stack+0x19/0x40
[69832.285385] __kasan_kmalloc.constprop.2+0xc1/0xd0
[69832.286350] kmem_cache_alloc_node+0x13f/0x460
[69832.287237] bfq_get_queue+0x3d4/0x1140
[69832.287993] bfq_get_bfqq_handle_split+0x103/0x510
[69832.289015] bfq_init_rq+0x337/0x2d50
[69832.289749] bfq_insert_requests+0x304/0x4e10
[69832.290634] blk_mq_sched_insert_requests+0x13e/0x390
[69832.291629] blk_mq_flush_plug_list+0x4b4/0x760
[69832.292538] blk_flush_plug_list+0x2c5/0x480
[69832.293392] io_schedule_prepare+0xb2/0xd0
[69832.294209] io_schedule_timeout+0x13/0x80
[69832.295014] wait_for_common_io.constprop.1+0x13c/0x270
[69832.296137] submit_bio_wait+0x103/0x1a0
[69832.296932] blkdev_issue_discard+0xe6/0x160
[69832.297794] blk_ioctl_discard+0x219/0x290
[69832.298614] blkdev_common_ioctl+0x50a/0x1750
[69832.304715] blkdev_ioctl+0x470/0x600
[69832.305474] block_ioctl+0xde/0x120
[69832.306232] vfs_ioctl+0x6c/0xc0
[69832.306877] __se_sys_ioctl+0x90/0xa0
[69832.307629] do_syscall_64+0x2d/0x40
[69832.308362] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[69832.309382]
[69832.309701] Freed by task 155:
[69832.310328] kasan_save_stack+0x19/0x40
[69832.311121] kasan_set_track+0x1c/0x30
[69832.311868] kasan_set_free_info+0x1b/0x30
[69832.312699] __kasan_slab_free+0x111/0x160
[69832.313524] kmem_cache_free+0x94/0x460
[69832.314367] bfq_put_queue+0x582/0x940
[69832.315112] __bfq_bfqd_reset_in_service+0x166/0x1d0
[69832.317275] bfq_bfqq_expire+0xb27/0x2440
[69832.318084] bfq_dispatch_request+0x697/0x44b0
[69832.318991] __blk_mq_do_dispatch_sched+0x52f/0x830
[69832.319984] __blk_mq_sched_dispatch_requests+0x398/0x4f0
[69832.321087] blk_mq_sched_dispatch_requests+0xdf/0x140
[69832.322225] __blk_mq_run_hw_queue+0xc0/0x270
[69832.323114] blk_mq_run_work_fn+0x51/0x6
---truncated--- |
["https://git.kernel.org/stable/c/080665e2c3cbfc68359b9a348a3546ed9b908e7a","https://git.kernel.org/stable/c/40b4ba0030e0b02cbacd424ebb9f4c8b0976c786","https://git.kernel.org/stable/c/5117c9ff4c2ebae0f5c2c262d42a25a8fbc086e6","https://git.kernel.org/stable/c/5687958bf18f84384d809f521210d0f5deed03b0","https://git.kernel.org/stable/c/74e610b5ee0d95e751280567100509eb11517efa","https://git.kernel.org/stable/c/ab552fcb17cc9e4afe0e4ac4df95fc7b30e8490a","https://git.kernel.org/stable/c/df6e00b1a53c57dca82c63b5ecbcad5452231bc7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49179
|
High |
fixed |
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
block, bfq: don't move oom_bfqq
Our test report a UAF:
[ 2073.019181] ==================================================================
[ 2073.019188] BUG: KASAN: use-after-free in __bfq_put_async_bfqq+0xa0/0x168
[ 2073.019191] Write of size 8 at addr ffff8000ccf64128 by task rmmod/72584
[ 2073.019192]
[ 2073.019196] CPU: 0 PID: 72584 Comm: rmmod Kdump: loaded Not tainted 4.19.90-yk #5
[ 2073.019198] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 2073.019200] Call trace:
[ 2073.019203] dump_backtrace+0x0/0x310
[ 2073.019206] show_stack+0x28/0x38
[ 2073.019210] dump_stack+0xec/0x15c
[ 2073.019216] print_address_description+0x68/0x2d0
[ 2073.019220] kasan_report+0x238/0x2f0
[ 2073.019224] __asan_store8+0x88/0xb0
[ 2073.019229] __bfq_put_async_bfqq+0xa0/0x168
[ 2073.019233] bfq_put_async_queues+0xbc/0x208
[ 2073.019236] bfq_pd_offline+0x178/0x238
[ 2073.019240] blkcg_deactivate_policy+0x1f0/0x420
[ 2073.019244] bfq_exit_queue+0x128/0x178
[ 2073.019249] blk_mq_exit_sched+0x12c/0x160
[ 2073.019252] elevator_exit+0xc8/0xd0
[ 2073.019256] blk_exit_queue+0x50/0x88
[ 2073.019259] blk_cleanup_queue+0x228/0x3d8
[ 2073.019267] null_del_dev+0xfc/0x1e0 [null_blk]
[ 2073.019274] null_exit+0x90/0x114 [null_blk]
[ 2073.019278] __arm64_sys_delete_module+0x358/0x5a0
[ 2073.019282] el0_svc_common+0xc8/0x320
[ 2073.019287] el0_svc_handler+0xf8/0x160
[ 2073.019290] el0_svc+0x10/0x218
[ 2073.019291]
[ 2073.019294] Allocated by task 14163:
[ 2073.019301] kasan_kmalloc+0xe0/0x190
[ 2073.019305] kmem_cache_alloc_node_trace+0x1cc/0x418
[ 2073.019308] bfq_pd_alloc+0x54/0x118
[ 2073.019313] blkcg_activate_policy+0x250/0x460
[ 2073.019317] bfq_create_group_hierarchy+0x38/0x110
[ 2073.019321] bfq_init_queue+0x6d0/0x948
[ 2073.019325] blk_mq_init_sched+0x1d8/0x390
[ 2073.019330] elevator_switch_mq+0x88/0x170
[ 2073.019334] elevator_switch+0x140/0x270
[ 2073.019338] elv_iosched_store+0x1a4/0x2a0
[ 2073.019342] queue_attr_store+0x90/0xe0
[ 2073.019348] sysfs_kf_write+0xa8/0xe8
[ 2073.019351] kernfs_fop_write+0x1f8/0x378
[ 2073.019359] __vfs_write+0xe0/0x360
[ 2073.019363] vfs_write+0xf0/0x270
[ 2073.019367] ksys_write+0xdc/0x1b8
[ 2073.019371] __arm64_sys_write+0x50/0x60
[ 2073.019375] el0_svc_common+0xc8/0x320
[ 2073.019380] el0_svc_handler+0xf8/0x160
[ 2073.019383] el0_svc+0x10/0x218
[ 2073.019385]
[ 2073.019387] Freed by task 72584:
[ 2073.019391] __kasan_slab_free+0x120/0x228
[ 2073.019394] kasan_slab_free+0x10/0x18
[ 2073.019397] kfree+0x94/0x368
[ 2073.019400] bfqg_put+0x64/0xb0
[ 2073.019404] bfqg_and_blkg_put+0x90/0xb0
[ 2073.019408] bfq_put_queue+0x220/0x228
[ 2073.019413] __bfq_put_async_bfqq+0x98/0x168
[ 2073.019416] bfq_put_async_queues+0xbc/0x208
[ 2073.019420] bfq_pd_offline+0x178/0x238
[ 2073.019424] blkcg_deactivate_policy+0x1f0/0x420
[ 2073.019429] bfq_exit_queue+0x128/0x178
[ 2073.019433] blk_mq_exit_sched+0x12c/0x160
[ 2073.019437] elevator_exit+0xc8/0xd0
[ 2073.019440] blk_exit_queue+0x50/0x88
[ 2073.019443] blk_cleanup_queue+0x228/0x3d8
[ 2073.019451] null_del_dev+0xfc/0x1e0 [null_blk]
[ 2073.019459] null_exit+0x90/0x114 [null_blk]
[ 2073.019462] __arm64_sys_delete_module+0x358/0x5a0
[ 2073.019467] el0_svc_common+0xc8/0x320
[ 2073.019471] el0_svc_handler+0xf8/0x160
[ 2073.019474] el0_svc+0x10/0x218
[ 2073.019475]
[ 2073.019479] The buggy address belongs to the object at ffff8000ccf63f00
which belongs to the cache kmalloc-1024 of size 1024
[ 2073.019484] The buggy address is located 552 bytes inside of
1024-byte region [ffff8000ccf63f00, ffff8000ccf64300)
[ 2073.019486] The buggy address belongs to the page:
[ 2073.019492] page:ffff7e000333d800 count:1 mapcount:0 mapping:ffff8000c0003a00 index:0x0 compound_mapcount: 0
[ 2073.020123] flags: 0x7ffff0000008100(slab|head)
[ 2073.020403] raw: 07ffff0000008100 ffff7e0003334c08 ffff7e00001f5a08 ffff8000c0003a00
[ 2073.020409] ra
---truncated--- |
["https://git.kernel.org/stable/c/7507ead1e9d42957c2340f2c4a0e9d00034e3366","https://git.kernel.org/stable/c/8410f70977734f21b8ed45c37e925d311dfda2e7","https://git.kernel.org/stable/c/87fdfe8589d43e471dffb4c60f75eeb6f37afc4c","https://git.kernel.org/stable/c/8f34dea99cd7761156a146a5258a67d045d862f7","https://git.kernel.org/stable/c/c01fced8d38fbccc82787065229578006f28e020","https://git.kernel.org/stable/c/c4f5a678add58a8a0e7ee5e038496b376ea6d205"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49288
|
High |
fixed |
- 4.14.279
- 4.19.243
- 5.4.193
- 5.10.109
- 5.15.32
- 5.16.18
- 5.17.1
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: Fix races among concurrent prealloc proc writes
We have no protection against concurrent PCM buffer preallocation
changes via proc files, and it may potentially lead to UAF or some
weird problem. This patch applies the PCM open_mutex to the proc
write operation for avoiding the racy proc writes and the PCM stream
open (and further operations). |
["https://git.kernel.org/stable/c/37b12c16beb6f6c1c3c678c1aacbc46525c250f7","https://git.kernel.org/stable/c/51fce708ab8986a9879ee5da946a2cc120f1036d","https://git.kernel.org/stable/c/5ed8f8e3c4e59d0396b9ccf2e639711e24295bb6","https://git.kernel.org/stable/c/69534c48ba8ce552ce383b3dfdb271ffe51820c3","https://git.kernel.org/stable/c/a21d2f323b5a978dedf9ff1d50f101f85e39b3f2","https://git.kernel.org/stable/c/b560d670c87d7d40b3cf6949246fa4c7aa65a00a","https://git.kernel.org/stable/c/e14dca613e0a6ddc2bf6e360f16936a9f865205b","https://git.kernel.org/stable/c/e7786c445bb67a9a6e64f66ebd6b7215b153ff7d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49410
|
High |
fixed |
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix potential double free in create_var_ref()
In create_var_ref(), init_var_ref() is called to initialize the fields
of variable ref_field, which is allocated in the previous function call
to create_hist_field(). Function init_var_ref() allocates the
corresponding fields such as ref_field->system, but frees these fields
when the function encounters an error. The caller later calls
destroy_hist_field() to conduct error handling, which frees the fields
and the variable itself. This results in double free of the fields which
are already freed in the previous function.
Fix this by storing NULL to the corresponding fields when they are freed
in init_var_ref(). |
["https://git.kernel.org/stable/c/058cb6d86b9789377216c936506b346aaa1eb581","https://git.kernel.org/stable/c/37443b3508b8cce6832f8d25cb4550b2f7801f50","https://git.kernel.org/stable/c/4fdfb15e08598711dbf50daf56a33965232daf0e","https://git.kernel.org/stable/c/99696a2592bca641eb88cc9a80c90e591afebd0f","https://git.kernel.org/stable/c/bd83ff3bbfb003832481c9bff999d12385f396ae","https://git.kernel.org/stable/c/c27f744ceefadc7bbeb14233b6abc150ced617d2","https://git.kernel.org/stable/c/f8b383f83cb573152c577eca1ef101e89995b72a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49455
|
High |
fixed |
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
misc: ocxl: fix possible double free in ocxl_file_register_afu
info_release() will be called in device_unregister() when info->dev's
reference count is 0. So there is no need to call ocxl_afu_put() and
kfree() again.
Fix this by adding free_minor() and return to err_unregister error path. |
["https://git.kernel.org/stable/c/252768d32e92c1214aeebb5fec0844ca479bcf5c","https://git.kernel.org/stable/c/8fb674216835e1f0c143762696d645facebb4685","https://git.kernel.org/stable/c/950cf957fe34d40d63dfa3bf3968210430b6491e","https://git.kernel.org/stable/c/9e9087cf34ee69f4e95d146ac29385d6e367a97b","https://git.kernel.org/stable/c/de65c32ace9aa70d51facc61ba986607075e3a25","https://git.kernel.org/stable/c/ee89d8dee55ab4b3b8ad8b70866b2841ba334767"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49489
|
High |
fixed |
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm runtime resume
BUG: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6be3
Call trace:
dpu_vbif_init_memtypes+0x40/0xb8
dpu_runtime_resume+0xcc/0x1c0
pm_generic_runtime_resume+0x30/0x44
__genpd_runtime_resume+0x68/0x7c
genpd_runtime_resume+0x134/0x258
__rpm_callback+0x98/0x138
rpm_callback+0x30/0x88
rpm_resume+0x36c/0x49c
__pm_runtime_resume+0x80/0xb0
dpu_core_irq_uninstall+0x30/0xb0
dpu_irq_uninstall+0x18/0x24
msm_drm_uninit+0xd8/0x16c
Patchwork: https://patchwork.freedesktop.org/patch/483255/
[DB: fixed Fixes tag] |
["https://git.kernel.org/stable/c/134760263f6441741db0b2970e7face6b34b6d1c","https://git.kernel.org/stable/c/5b0adf5cbf3b74721e4e4c4e0cadc91b8df8bcc2","https://git.kernel.org/stable/c/97ac682b6f7d36be5d934f86c9911066540a68f1","https://git.kernel.org/stable/c/aa4cb188988dc6f1b3f4917d4dbc452150a5d871","https://git.kernel.org/stable/c/ef10d0c68e8608848cd58fca2589685718426607","https://git.kernel.org/stable/c/ef4bdaac7cb5416f236613ed9337ff0ea8ee329b","https://git.kernel.org/stable/c/fa5186b279ecf44b14fb435540d2065be91cb1ed"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49524
|
High |
fixed |
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
media: pci: cx23885: Fix the error handling in cx23885_initdev()
When the driver fails to call the dma_set_mask(), the driver will get
the following splat:
[ 55.853884] BUG: KASAN: use-after-free in __process_removed_driver+0x3c/0x240
[ 55.854486] Read of size 8 at addr ffff88810de60408 by task modprobe/590
[ 55.856822] Call Trace:
[ 55.860327] __process_removed_driver+0x3c/0x240
[ 55.861347] bus_for_each_dev+0x102/0x160
[ 55.861681] i2c_del_driver+0x2f/0x50
This is because the driver has initialized the i2c related resources
in cx23885_dev_setup() but not released them in error handling, fix this
bug by modifying the error path that jumps after failing to call the
dma_set_mask(). |
["https://git.kernel.org/stable/c/453514a874c78df1e7804e6e3aaa60c8d8deb6a8","https://git.kernel.org/stable/c/6041d1a0365baa729b6adfb6ed5386d9388018db","https://git.kernel.org/stable/c/7b9978e1c94e569d65a0e7e719abb9340f5db4a0","https://git.kernel.org/stable/c/86bd6a579c6c60547706cabf299cd2c9feab3332","https://git.kernel.org/stable/c/98106f100f50c487469903b9cf6d966785fc9cc3","https://git.kernel.org/stable/c/ca17e7a532d1a55466cc007b3f4d319541a27493","https://git.kernel.org/stable/c/e8123311cf06d7dae71e8c5fe78e0510d20cd30b","https://git.kernel.org/stable/c/fa636e9ee4442215cd9a2e079cd5a8e1fe0cb8ba"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49626
|
High |
fixed |
- 4.9.324
- 4.14.289
- 4.19.253
- 5.4.207
- 5.10.132
- 5.15.56
- 5.18.13
|
In the Linux kernel, the following vulnerability has been resolved:
sfc: fix use after free when disabling sriov
Use after free is detected by kfence when disabling sriov. What was read
after being freed was vf->pci_dev: it was freed from pci_disable_sriov
and later read in efx_ef10_sriov_free_vf_vports, called from
efx_ef10_sriov_free_vf_vswitching.
Set the pointer to NULL at release time to not trying to read it later.
Reproducer and dmesg log (note that kfence doesn't detect it every time):
$ echo 1 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs
$ echo 0 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs
BUG: KFENCE: use-after-free read in efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc]
Use-after-free read at 0x00000000ff3c1ba5 (in kfence-#224):
efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc]
efx_ef10_pci_sriov_disable+0x38/0x70 [sfc]
efx_pci_sriov_configure+0x24/0x40 [sfc]
sriov_numvfs_store+0xfe/0x140
kernfs_fop_write_iter+0x11c/0x1b0
new_sync_write+0x11f/0x1b0
vfs_write+0x1eb/0x280
ksys_write+0x5f/0xe0
do_syscall_64+0x5c/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
kfence-#224: 0x00000000edb8ef95-0x00000000671f5ce1, size=2792, cache=kmalloc-4k
allocated by task 6771 on cpu 10 at 3137.860196s:
pci_alloc_dev+0x21/0x60
pci_iov_add_virtfn+0x2a2/0x320
sriov_enable+0x212/0x3e0
efx_ef10_sriov_configure+0x67/0x80 [sfc]
efx_pci_sriov_configure+0x24/0x40 [sfc]
sriov_numvfs_store+0xba/0x140
kernfs_fop_write_iter+0x11c/0x1b0
new_sync_write+0x11f/0x1b0
vfs_write+0x1eb/0x280
ksys_write+0x5f/0xe0
do_syscall_64+0x5c/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
freed by task 6771 on cpu 12 at 3170.991309s:
device_release+0x34/0x90
kobject_cleanup+0x3a/0x130
pci_iov_remove_virtfn+0xd9/0x120
sriov_disable+0x30/0xe0
efx_ef10_pci_sriov_disable+0x57/0x70 [sfc]
efx_pci_sriov_configure+0x24/0x40 [sfc]
sriov_numvfs_store+0xfe/0x140
kernfs_fop_write_iter+0x11c/0x1b0
new_sync_write+0x11f/0x1b0
vfs_write+0x1eb/0x280
ksys_write+0x5f/0xe0
do_syscall_64+0x5c/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae |
["https://git.kernel.org/stable/c/3199e34912d84cdfb8a93a984c5ae5c73fb13e84","https://git.kernel.org/stable/c/58d93e9d160c0de6d867c7eb4c2206671a351eb1","https://git.kernel.org/stable/c/9c854ae512b89229aeee93849e9bd4c115b37909","https://git.kernel.org/stable/c/bcad880865bfb421885364b1f0c7351280fe2b97","https://git.kernel.org/stable/c/c2240500817b3b4b996cdf2a461a3a5679f49b94","https://git.kernel.org/stable/c/c9e75bb22a26e391f189f5a5133dd63dcb57fdaa","https://git.kernel.org/stable/c/e435c4aeeaa073091f7f3b7735af2ef5c97d63f2","https://git.kernel.org/stable/c/ebe41da5d47ac0fff877e57bd14c54dccf168827"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49685
|
High |
fixed |
- 4.9.321
- 4.14.286
- 4.19.250
- 5.4.202
- 5.10.127
- 5.15.51
- 5.18.8
|
In the Linux kernel, the following vulnerability has been resolved:
iio: trigger: sysfs: fix use-after-free on remove
Ensure that the irq_work has completed before the trigger is freed.
==================================================================
BUG: KASAN: use-after-free in irq_work_run_list
Read of size 8 at addr 0000000064702248 by task python3/25
Call Trace:
irq_work_run_list
irq_work_tick
update_process_times
tick_sched_handle
tick_sched_timer
__hrtimer_run_queues
hrtimer_interrupt
Allocated by task 25:
kmem_cache_alloc_trace
iio_sysfs_trig_add
dev_attr_store
sysfs_kf_write
kernfs_fop_write_iter
new_sync_write
vfs_write
ksys_write
sys_write
Freed by task 25:
kfree
iio_sysfs_trig_remove
dev_attr_store
sysfs_kf_write
kernfs_fop_write_iter
new_sync_write
vfs_write
ksys_write
sys_write
================================================================== |
["https://git.kernel.org/stable/c/31ff3309b47d98313c61b8301bf595820cc3cc33","https://git.kernel.org/stable/c/4687c3f955240ca2a576bdc3f742d4d915b6272d","https://git.kernel.org/stable/c/4ef1e521be610b720daeb7cf899fedc7db0274c4","https://git.kernel.org/stable/c/5e39397d60dacc7f5d81d442c1c958eaaaf31128","https://git.kernel.org/stable/c/78601726d4a59a291acc5a52da1d3a0a6831e4e8","https://git.kernel.org/stable/c/b07a30a774b3c3e584a68dc91779c68ea2da4813","https://git.kernel.org/stable/c/d6111e7bdb8ec27eb43d01c4cd4ff1620a75f7f2","https://git.kernel.org/stable/c/fd5d8fb298a2866c337da635c79d63c3afabcaf7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21796
|
High |
fixed |
- 5.10.235
- 5.15.179
- 6.1.129
- 6.6.79
- 6.12.16
- 6.13.4
|
In the Linux kernel, the following vulnerability has been resolved:
nfsd: clear acl_access/acl_default after releasing them
If getting acl_default fails, acl_access and acl_default will be released
simultaneously. However, acl_access will still retain a pointer pointing
to the released posix_acl, which will trigger a WARNING in
nfs3svc_release_getacl like this:
------------[ cut here ]------------
refcount_t: underflow; use-after-free.
WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28
refcount_warn_saturate+0xb5/0x170
Modules linked in:
CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted
6.12.0-rc6-00079-g04ae226af01f-dirty #8
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.1-2.fc37 04/01/2014
RIP: 0010:refcount_warn_saturate+0xb5/0x170
Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75
e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b eb
cd 0f b6 1d 8a3
RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde
RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380
RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56
R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001
R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0
FS: 0000000000000000(0000) GS:ffff88871ed00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
? refcount_warn_saturate+0xb5/0x170
? __warn+0xa5/0x140
? refcount_warn_saturate+0xb5/0x170
? report_bug+0x1b1/0x1e0
? handle_bug+0x53/0xa0
? exc_invalid_op+0x17/0x40
? asm_exc_invalid_op+0x1a/0x20
? tick_nohz_tick_stopped+0x1e/0x40
? refcount_warn_saturate+0xb5/0x170
? refcount_warn_saturate+0xb5/0x170
nfs3svc_release_getacl+0xc9/0xe0
svc_process_common+0x5db/0xb60
? __pfx_svc_process_common+0x10/0x10
? __rcu_read_unlock+0x69/0xa0
? __pfx_nfsd_dispatch+0x10/0x10
? svc_xprt_received+0xa1/0x120
? xdr_init_decode+0x11d/0x190
svc_process+0x2a7/0x330
svc_handle_xprt+0x69d/0x940
svc_recv+0x180/0x2d0
nfsd+0x168/0x200
? __pfx_nfsd+0x10/0x10
kthread+0x1a2/0x1e0
? kthread+0xf4/0x1e0
? __pfx_kthread+0x10/0x10
ret_from_fork+0x34/0x60
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
Kernel panic - not syncing: kernel: panic_on_warn set ...
Clear acl_access/acl_default after posix_acl_release is called to prevent
UAF from being triggered. |
["https://git.kernel.org/stable/c/1fd94884174bd20beb1773990fd3b1aa877688d9","https://git.kernel.org/stable/c/2e59b2b68782519560b3d6a41dd66a3d01a01cd3","https://git.kernel.org/stable/c/55d947315fb5f67a35e4e1d3e01bb886b9c6decf","https://git.kernel.org/stable/c/6f7cfee1a316891890c505563aa54f3476db52fd","https://git.kernel.org/stable/c/7faf14a7b0366f153284db0ad3347c457ea70136","https://git.kernel.org/stable/c/8a1737ae42c928384ab6447f6ee1a882510e85fa","https://git.kernel.org/stable/c/f8d871523142f7895f250a856f8c4a4181614510"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21811
|
High |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.129
- 6.6.76
- 6.12.13
- 6.13.2
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: protect access to buffers with no active references
nilfs_lookup_dirty_data_buffers(), which iterates through the buffers
attached to dirty data folios/pages, accesses the attached buffers without
locking the folios/pages.
For data cache, nilfs_clear_folio_dirty() may be called asynchronously
when the file system degenerates to read only, so
nilfs_lookup_dirty_data_buffers() still has the potential to cause use
after free issues when buffers lose the protection of their dirty state
midway due to this asynchronous clearing and are unintentionally freed by
try_to_free_buffers().
Eliminate this race issue by adjusting the lock section in this function. |
["https://git.kernel.org/stable/c/367a9bffabe08c04f6d725032cce3d891b2b9e1a","https://git.kernel.org/stable/c/4b08d23d7d1917bef4fbee8ad81372f49b006656","https://git.kernel.org/stable/c/58c27fa7a610b6e8d44e6220e7dbddfbaccaf439","https://git.kernel.org/stable/c/72cf688d0ce7e642b12ddc9b2a42524737ec1b4a","https://git.kernel.org/stable/c/8e1b9201c9a24638cf09c6e1c9f224157328010b","https://git.kernel.org/stable/c/c437dfac9f7a5a46ac2a5e6d6acd3059e9f68188","https://git.kernel.org/stable/c/d8ff250e085a4c4cdda4ad1cdd234ed110393143","https://git.kernel.org/stable/c/e1fc4a90a90ea8514246c45435662531975937d9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-47639
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU
Zap both valid and invalid roots when zapping/unmapping a gfn range, as
KVM must ensure it holds no references to the freed page after returning
from the unmap operation. Most notably, the TDP MMU doesn't zap invalid
roots in mmu_notifier callbacks. This leads to use-after-free and other
issues if the mmu_notifier runs to completion while an invalid root
zapper yields as KVM fails to honor the requirement that there must be
_no_ references to the page after the mmu_notifier returns.
The bug is most easily reproduced by hacking KVM to cause a collision
between set_nx_huge_pages() and kvm_mmu_notifier_release(), but the bug
exists between kvm_mmu_notifier_invalidate_range_start() and memslot
updates as well. Invalidating a root ensures pages aren't accessible by
the guest, and KVM won't read or write page data itself, but KVM will
trigger e.g. kvm_set_pfn_dirty() when zapping SPTEs, and thus completing
a zap of an invalid root _after_ the mmu_notifier returns is fatal.
WARNING: CPU: 24 PID: 1496 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:173 [kvm]
RIP: 0010:kvm_is_zone_device_pfn+0x96/0xa0 [kvm]
Call Trace:
<TASK>
kvm_set_pfn_dirty+0xa8/0xe0 [kvm]
__handle_changed_spte+0x2ab/0x5e0 [kvm]
__handle_changed_spte+0x2ab/0x5e0 [kvm]
__handle_changed_spte+0x2ab/0x5e0 [kvm]
zap_gfn_range+0x1f3/0x310 [kvm]
kvm_tdp_mmu_zap_invalidated_roots+0x50/0x90 [kvm]
kvm_mmu_zap_all_fast+0x177/0x1a0 [kvm]
set_nx_huge_pages+0xb4/0x190 [kvm]
param_attr_store+0x70/0x100
module_attr_store+0x19/0x30
kernfs_fop_write_iter+0x119/0x1b0
new_sync_write+0x11c/0x1b0
vfs_write+0x1cc/0x270
ksys_write+0x5f/0xe0
do_syscall_64+0x38/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
</TASK> |
["https://git.kernel.org/stable/c/0c8a8da182d4333d9bbb9131d765145568c847b2","https://git.kernel.org/stable/c/8cf6f98ab1d16d5e607635a0c21c4231eb15367e","https://git.kernel.org/stable/c/af47248407c0c5ae52a752af1ab5ce5b0db91502","https://git.kernel.org/stable/c/d62007edf01f5c11f75d0f4b1e538fc52a5b1982"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-47653
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
media: davinci: vpif: fix use-after-free on driver unbind
The driver allocates and registers two platform device structures during
probe, but the devices were never deregistered on driver unbind.
This results in a use-after-free on driver unbind as the device
structures were allocated using devres and would be freed by driver
core when remove() returns.
Fix this by adding the missing deregistration calls to the remove()
callback and failing probe on registration errors.
Note that the platform device structures must be freed using a proper
release callback to avoid leaking associated resources like device
names. |
["https://git.kernel.org/stable/c/43acb728bbc40169d2e2425e84a80068270974be","https://git.kernel.org/stable/c/6512c3c39cb6b573b791ce45365818a38b76afbe","https://git.kernel.org/stable/c/9ffc602e14d7b9f7e7cb2f67e18dfef9ef8af676","https://git.kernel.org/stable/c/b5a3bb7f6f164eb6ee74ef4898dcd019b2063448"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49076
|
High |
fixed |
- 5.10.111
- 5.15.34
- 5.16.20
- 5.17.3
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hfi1: Fix use-after-free bug for mm struct
Under certain conditions, such as MPI_Abort, the hfi1 cleanup code may
represent the last reference held on the task mm.
hfi1_mmu_rb_unregister() then drops the last reference and the mm is freed
before the final use in hfi1_release_user_pages(). A new task may
allocate the mm structure while it is still being used, resulting in
problems. One manifestation is corruption of the mmap_sem counter leading
to a hang in down_write(). Another is corruption of an mm struct that is
in use by another task. |
["https://git.kernel.org/stable/c/0b7186d657ee55e2cdefae498f07d5c1961e8023","https://git.kernel.org/stable/c/2bbac98d0930e8161b1957dc0ec99de39ade1b3c","https://git.kernel.org/stable/c/5a9a1b24ddb510715f8f621263938186579a965c","https://git.kernel.org/stable/c/5f54364ff6cfcd14cddf5441c4a490bb28dd69f7","https://git.kernel.org/stable/c/9ca11bd8222a612de0d2f54d050bfcf61ae2883f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49082
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Fix use after free in _scsih_expander_node_remove()
The function mpt3sas_transport_port_remove() called in
_scsih_expander_node_remove() frees the port field of the sas_expander
structure, leading to the following use-after-free splat from KASAN when
the ioc_info() call following that function is executed (e.g. when doing
rmmod of the driver module):
[ 3479.371167] ==================================================================
[ 3479.378496] BUG: KASAN: use-after-free in _scsih_expander_node_remove+0x710/0x750 [mpt3sas]
[ 3479.386936] Read of size 1 at addr ffff8881c037691c by task rmmod/1531
[ 3479.393524]
[ 3479.395035] CPU: 18 PID: 1531 Comm: rmmod Not tainted 5.17.0-rc8+ #1436
[ 3479.401712] Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.1 06/02/2021
[ 3479.409263] Call Trace:
[ 3479.411743] <TASK>
[ 3479.413875] dump_stack_lvl+0x45/0x59
[ 3479.417582] print_address_description.constprop.0+0x1f/0x120
[ 3479.423389] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas]
[ 3479.429469] kasan_report.cold+0x83/0xdf
[ 3479.433438] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas]
[ 3479.439514] _scsih_expander_node_remove+0x710/0x750 [mpt3sas]
[ 3479.445411] ? _raw_spin_unlock_irqrestore+0x2d/0x40
[ 3479.452032] scsih_remove+0x525/0xc90 [mpt3sas]
[ 3479.458212] ? mpt3sas_expander_remove+0x1d0/0x1d0 [mpt3sas]
[ 3479.465529] ? down_write+0xde/0x150
[ 3479.470746] ? up_write+0x14d/0x460
[ 3479.475840] ? kernfs_find_ns+0x137/0x310
[ 3479.481438] pci_device_remove+0x65/0x110
[ 3479.487013] __device_release_driver+0x316/0x680
[ 3479.493180] driver_detach+0x1ec/0x2d0
[ 3479.498499] bus_remove_driver+0xe7/0x2d0
[ 3479.504081] pci_unregister_driver+0x26/0x250
[ 3479.510033] _mpt3sas_exit+0x2b/0x6cf [mpt3sas]
[ 3479.516144] __x64_sys_delete_module+0x2fd/0x510
[ 3479.522315] ? free_module+0xaa0/0xaa0
[ 3479.527593] ? __cond_resched+0x1c/0x90
[ 3479.532951] ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[ 3479.539607] ? syscall_enter_from_user_mode+0x21/0x70
[ 3479.546161] ? trace_hardirqs_on+0x1c/0x110
[ 3479.551828] do_syscall_64+0x35/0x80
[ 3479.556884] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3479.563402] RIP: 0033:0x7f1fc482483b
...
[ 3479.943087] ==================================================================
Fix this by introducing the local variable port_id to store the port ID
value before executing mpt3sas_transport_port_remove(). This local variable
is then used in the call to ioc_info() instead of dereferencing the freed
port structure. |
["https://git.kernel.org/stable/c/17d66b1c92bcb41e72271ec60069d3684aaa1c9c","https://git.kernel.org/stable/c/1bb8a7fc64d63ec818e367e1b37676ea2ef2d20c","https://git.kernel.org/stable/c/25c1353dca74ad7cf3fd7ce258fe7c957a147d5e","https://git.kernel.org/stable/c/87d663d40801dffc99a5ad3b0188ad3e2b4d1557"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49093
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
skbuff: fix coalescing for page_pool fragment recycling
Fix a use-after-free when using page_pool with page fragments. We
encountered this problem during normal RX in the hns3 driver:
(1) Initially we have three descriptors in the RX queue. The first one
allocates PAGE1 through page_pool, and the other two allocate one
half of PAGE2 each. Page references look like this:
RX_BD1 _______ PAGE1
RX_BD2 _______ PAGE2
RX_BD3 _________/
(2) Handle RX on the first descriptor. Allocate SKB1, eventually added
to the receive queue by tcp_queue_rcv().
(3) Handle RX on the second descriptor. Allocate SKB2 and pass it to
netif_receive_skb():
netif_receive_skb(SKB2)
ip_rcv(SKB2)
SKB3 = skb_clone(SKB2)
SKB2 and SKB3 share a reference to PAGE2 through
skb_shinfo()->dataref. The other ref to PAGE2 is still held by
RX_BD3:
SKB2 ---+- PAGE2
SKB3 __/ /
RX_BD3 _________/
(3b) Now while handling TCP, coalesce SKB3 with SKB1:
tcp_v4_rcv(SKB3)
tcp_try_coalesce(to=SKB1, from=SKB3) // succeeds
kfree_skb_partial(SKB3)
skb_release_data(SKB3) // drops one dataref
SKB1 _____ PAGE1
\____
SKB2 _____ PAGE2
/
RX_BD3 _________/
In skb_try_coalesce(), __skb_frag_ref() takes a page reference to
PAGE2, where it should instead have increased the page_pool frag
reference, pp_frag_count. Without coalescing, when releasing both
SKB2 and SKB3, a single reference to PAGE2 would be dropped. Now
when releasing SKB1 and SKB2, two references to PAGE2 will be
dropped, resulting in underflow.
(3c) Drop SKB2:
af_packet_rcv(SKB2)
consume_skb(SKB2)
skb_release_data(SKB2) // drops second dataref
page_pool_return_skb_page(PAGE2) // drops one pp_frag_count
SKB1 _____ PAGE1
\____
PAGE2
/
RX_BD3 _________/
(4) Userspace calls recvmsg()
Copies SKB1 and releases it. Since SKB3 was coalesced with SKB1, we
release the SKB3 page as well:
tcp_eat_recv_skb(SKB1)
skb_release_data(SKB1)
page_pool_return_skb_page(PAGE1)
page_pool_return_skb_page(PAGE2) // drops second pp_frag_count
(5) PAGE2 is freed, but the third RX descriptor was still using it!
In our case this causes IOMMU faults, but it would silently corrupt
memory if the IOMMU was disabled.
Change the logic that checks whether pp_recycle SKBs can be coalesced.
We still reject differing pp_recycle between 'from' and 'to' SKBs, but
in order to avoid the situation described above, we also reject
coalescing when both 'from' and 'to' are pp_recycled and 'from' is
cloned.
The new logic allows coalescing a cloned pp_recycle SKB into a page
refcounted one, because in this case the release (4) will drop the right
reference, the one taken by skb_try_coalesce(). |
["https://git.kernel.org/stable/c/1effe8ca4e34c34cdd9318436a4232dcb582ebf4","https://git.kernel.org/stable/c/72bb856d16e883437023ff2ff77d0c498018728a","https://git.kernel.org/stable/c/ba965e8605aee5387cecaa28fcf7ee9f61779a49","https://git.kernel.org/stable/c/c4fa19615806a9a7e518c295b39175aa47a685ac"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49129
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7921: fix crash when startup fails.
If the nic fails to start, it is possible that the
reset_work has already been scheduled. Ensure the
work item is canceled so we do not have use-after-free
crash in case cleanup is called before the work item
is executed.
This fixes crash on my x86_64 apu2 when mt7921k radio
fails to work. Radio still fails, but OS does not
crash. |
["https://git.kernel.org/stable/c/38fbe806645090c07aa97171f20fc62c3d7d3a98","https://git.kernel.org/stable/c/827e7799c61b978fbc2cc9dac66cb62401b2b3f0","https://git.kernel.org/stable/c/ac1260b661c2ef0d0a56680cdb5672b931b7be8f","https://git.kernel.org/stable/c/c1a5e6002ec441a3b9fb4d048b4b49ae93409a46"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49182
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: add vlan list lock to protect vlan list
When adding port base VLAN, vf VLAN need to remove from HW and modify
the vlan state in vf VLAN list as false. If the periodicity task is
freeing the same node, it may cause "use after free" error.
This patch adds a vlan list lock to protect the vlan list. |
["https://git.kernel.org/stable/c/09e383ca97e798f9954189b741af54b5c51e7a97","https://git.kernel.org/stable/c/1932a624ab88ff407d1a1d567fe581faa15dc725","https://git.kernel.org/stable/c/30f0ff7176efe8ac6c55f85bce26ed58bb608758","https://git.kernel.org/stable/c/f58af41deeab0f45c9c80adf5f2de489ebbac3dd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49196
|
High |
fixed |
- 3.17
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Fix use after free in remove_phb_dynamic()
In remove_phb_dynamic() we use &phb->io_resource, after we've called
device_unregister(&host_bridge->dev). But the unregister may have freed
phb, because pcibios_free_controller_deferred() is the release function
for the host_bridge.
If there are no outstanding references when we call device_unregister()
then phb will be freed out from under us.
This has gone mainly unnoticed, but with slub_debug and page_poison
enabled it can lead to a crash:
PID: 7574 TASK: c0000000d492cb80 CPU: 13 COMMAND: "drmgr"
#0 [c0000000e4f075a0] crash_kexec at c00000000027d7dc
#1 [c0000000e4f075d0] oops_end at c000000000029608
#2 [c0000000e4f07650] __bad_page_fault at c0000000000904b4
#3 [c0000000e4f076c0] do_bad_slb_fault at c00000000009a5a8
#4 [c0000000e4f076f0] data_access_slb_common_virt at c000000000008b30
Data SLB Access [380] exception frame:
R0: c000000000167250 R1: c0000000e4f07a00 R2: c000000002a46100
R3: c000000002b39ce8 R4: 00000000000000c0 R5: 00000000000000a9
R6: 3894674d000000c0 R7: 0000000000000000 R8: 00000000000000ff
R9: 0000000000000100 R10: 6b6b6b6b6b6b6b6b R11: 0000000000008000
R12: c00000000023da80 R13: c0000009ffd38b00 R14: 0000000000000000
R15: 000000011c87f0f0 R16: 0000000000000006 R17: 0000000000000003
R18: 0000000000000002 R19: 0000000000000004 R20: 0000000000000005
R21: 000000011c87ede8 R22: 000000011c87c5a8 R23: 000000011c87d3a0
R24: 0000000000000000 R25: 0000000000000001 R26: c0000000e4f07cc8
R27: c00000004d1cc400 R28: c0080000031d00e8 R29: c00000004d23d800
R30: c00000004d1d2400 R31: c00000004d1d2540
NIP: c000000000167258 MSR: 8000000000009033 OR3: c000000000e9f474
CTR: 0000000000000000 LR: c000000000167250 XER: 0000000020040003
CCR: 0000000024088420 MQ: 0000000000000000 DAR: 6b6b6b6b6b6b6ba3
DSISR: c0000000e4f07920 Syscall Result: fffffffffffffff2
[NIP : release_resource+56]
[LR : release_resource+48]
#5 [c0000000e4f07a00] release_resource at c000000000167258 (unreliable)
#6 [c0000000e4f07a30] remove_phb_dynamic at c000000000105648
#7 [c0000000e4f07ab0] dlpar_remove_slot at c0080000031a09e8 [rpadlpar_io]
#8 [c0000000e4f07b50] remove_slot_store at c0080000031a0b9c [rpadlpar_io]
#9 [c0000000e4f07be0] kobj_attr_store at c000000000817d8c
#10 [c0000000e4f07c00] sysfs_kf_write at c00000000063e504
#11 [c0000000e4f07c20] kernfs_fop_write_iter at c00000000063d868
#12 [c0000000e4f07c70] new_sync_write at c00000000054339c
#13 [c0000000e4f07d10] vfs_write at c000000000546624
#14 [c0000000e4f07d60] ksys_write at c0000000005469f4
#15 [c0000000e4f07db0] system_call_exception at c000000000030840
#16 [c0000000e4f07e10] system_call_vectored_common at c00000000000c168
To avoid it, we can take a reference to the host_bridge->dev until we're
done using phb. Then when we drop the reference the phb will be freed. |
["https://git.kernel.org/stable/c/33d39efb61a84e055ca2386157d39ebbdf6b7d31","https://git.kernel.org/stable/c/403f9e0bc5535a0a5184d1352fa3a70e6ffacb6f","https://git.kernel.org/stable/c/895ca4ae1f72e0a0160ab162723e59c9f265ec93","https://git.kernel.org/stable/c/fe2640bd7a62f1f7c3f55fbda31084085075bc30"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49223
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
cxl/port: Hold port reference until decoder release
KASAN + DEBUG_KOBJECT_RELEASE reports a potential use-after-free in
cxl_decoder_release() where it goes to reference its parent, a cxl_port,
to free its id back to port->decoder_ida.
BUG: KASAN: use-after-free in to_cxl_port+0x18/0x90 [cxl_core]
Read of size 8 at addr ffff888119270908 by task kworker/35:2/379
CPU: 35 PID: 379 Comm: kworker/35:2 Tainted: G OE 5.17.0-rc2+ #198
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
Workqueue: events kobject_delayed_cleanup
Call Trace:
<TASK>
dump_stack_lvl+0x59/0x73
print_address_description.constprop.0+0x1f/0x150
? to_cxl_port+0x18/0x90 [cxl_core]
kasan_report.cold+0x83/0xdf
? to_cxl_port+0x18/0x90 [cxl_core]
to_cxl_port+0x18/0x90 [cxl_core]
cxl_decoder_release+0x2a/0x60 [cxl_core]
device_release+0x5f/0x100
kobject_cleanup+0x80/0x1c0
The device core only guarantees parent lifetime until all children are
unregistered. If a child needs a parent to complete its ->release()
callback that child needs to hold a reference to extend the lifetime of
the parent. |
["https://git.kernel.org/stable/c/49f2dab77a5e1354f5da6ccdc9346a8212697be2","https://git.kernel.org/stable/c/518bb96367123062b48b0a9842f2864249b565f6","https://git.kernel.org/stable/c/74be98774dfbc5b8b795db726bd772e735d2edd4","https://git.kernel.org/stable/c/b0022ca445d5fc4d0c89d15dcd0f855977b22c1d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49236
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix UAF due to race between btf_try_get_module and load_module
While working on code to populate kfunc BTF ID sets for module BTF from
its initcall, I noticed that by the time the initcall is invoked, the
module BTF can already be seen by userspace (and the BPF verifier). The
existing btf_try_get_module calls try_module_get which only fails if
mod->state == MODULE_STATE_GOING, i.e. it can increment module reference
when module initcall is happening in parallel.
Currently, BTF parsing happens from MODULE_STATE_COMING notifier
callback. At this point, the module initcalls have not been invoked.
The notifier callback parses and prepares the module BTF, allocates an
ID, which publishes it to userspace, and then adds it to the btf_modules
list allowing the kernel to invoke btf_try_get_module for the BTF.
However, at this point, the module has not been fully initialized (i.e.
its initcalls have not finished). The code in module.c can still fail
and free the module, without caring for other users. However, nothing
stops btf_try_get_module from succeeding between the state transition
from MODULE_STATE_COMING to MODULE_STATE_LIVE.
This leads to a use-after-free issue when BPF program loads
successfully in the state transition, load_module's do_init_module call
fails and frees the module, and BPF program fd on close calls module_put
for the freed module. Future patch has test case to verify we don't
regress in this area in future.
There are multiple points after prepare_coming_module (in load_module)
where failure can occur and module loading can return error. We
illustrate and test for the race using the last point where it can
practically occur (in module __init function).
An illustration of the race:
CPU 0 CPU 1
load_module
notifier_call(MODULE_STATE_COMING)
btf_parse_module
btf_alloc_id // Published to userspace
list_add(&btf_mod->list, btf_modules)
mod->init(...)
... ^
bpf_check |
check_pseudo_btf_id |
btf_try_get_module |
returns true | ...
... | module __init in progress
return prog_fd | ...
... V
if (ret < 0)
free_module(mod)
...
close(prog_fd)
...
bpf_prog_free_deferred
module_put(used_btf.mod) // use-after-free
We fix this issue by setting a flag BTF_MODULE_F_LIVE, from the notifier
callback when MODULE_STATE_LIVE state is reached for the module, so that
we return NULL from btf_try_get_module for modules that are not fully
formed. Since try_module_get already checks that module is not in
MODULE_STATE_GOING state, and that is the only transition a live module
can make before being removed from btf_modules list, this is enough to
close the race and prevent the bug.
A later selftest patch crafts the race condition artifically to verify
that it has been fixed, and that verifier fails to load program (with
ENXIO).
Lastly, a couple of comments:
1. Even if this race didn't exist, it seems more appropriate to only
access resources (ksyms and kfuncs) of a fully formed module which
has been initialized completely.
2. This patch was born out of need for synchronization against module
initcall for the next patch, so it is needed for correctness even
without the aforementioned race condition. The BTF resources
initialized by module initcall are set up once and then only looked
up, so just waiting until the initcall has finished ensures correct
behavior. |
["https://git.kernel.org/stable/c/0481baa2318cb1ab13277715da6cdbb657807b3f","https://git.kernel.org/stable/c/18688de203b47e5d8d9d0953385bf30b5949324f","https://git.kernel.org/stable/c/51b82141fffa454abf937a8ff0b8af89e4fd0c8f","https://git.kernel.org/stable/c/d7fccf264b1a785525b366a5b7f8113c756187ad"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49258
|
High |
fixed |
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
crypto: ccree - Fix use after free in cc_cipher_exit()
kfree_sensitive(ctx_p->user.key) will free the ctx_p->user.key. But
ctx_p->user.key is still used in the next line, which will lead to a
use after free.
We can call kfree_sensitive() after dev_dbg() to avoid the uaf. |
["https://git.kernel.org/stable/c/25c358efee5153dfd240d4e0d3169d5bebe9cacd","https://git.kernel.org/stable/c/335bf1fc74f775a8255257aa3e33763f2257b676","https://git.kernel.org/stable/c/3d950c34074ed74d2713c3856ba01264523289e6","https://git.kernel.org/stable/c/c93017c8d5ebf55a4e453ac7c84cc84cf92ab570","https://git.kernel.org/stable/c/cffb5382bd8d3cf21b874ab5b84bf7618932286b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49270
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
dm: fix use-after-free in dm_cleanup_zoned_dev()
dm_cleanup_zoned_dev() uses queue, so it must be called
before blk_cleanup_disk() starts its killing:
blk_cleanup_disk->blk_cleanup_queue()->kobject_put()->blk_release_queue()->
->...RCU...->blk_free_queue_rcu()->kmem_cache_free()
Otherwise, RCU callback may be executed first and
dm_cleanup_zoned_dev() will touch free'd memory:
BUG: KASAN: use-after-free in dm_cleanup_zoned_dev+0x33/0xd0
Read of size 8 at addr ffff88805ac6e430 by task dmsetup/681
CPU: 4 PID: 681 Comm: dmsetup Not tainted 5.17.0-rc2+ #6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x57/0x7d
print_address_description.constprop.0+0x1f/0x150
? dm_cleanup_zoned_dev+0x33/0xd0
kasan_report.cold+0x7f/0x11b
? dm_cleanup_zoned_dev+0x33/0xd0
dm_cleanup_zoned_dev+0x33/0xd0
__dm_destroy+0x26a/0x400
? dm_blk_ioctl+0x230/0x230
? up_write+0xd8/0x270
dev_remove+0x156/0x1d0
ctl_ioctl+0x269/0x530
? table_clear+0x140/0x140
? lock_release+0xb2/0x750
? remove_all+0x40/0x40
? rcu_read_lock_sched_held+0x12/0x70
? lock_downgrade+0x3c0/0x3c0
? rcu_read_lock_sched_held+0x12/0x70
dm_ctl_ioctl+0xa/0x10
__x64_sys_ioctl+0xb9/0xf0
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7fb6dfa95c27 |
["https://git.kernel.org/stable/c/0987f00a76a17aa7213da492c00ed9e5a6210c73","https://git.kernel.org/stable/c/43a043aed964659bc69ef81f266912b73c80d837","https://git.kernel.org/stable/c/588b7f5df0cb64f281290c7672470c006abe7160","https://git.kernel.org/stable/c/fdfe414ca28ddfd562c233fb27385cf820de03e8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49384
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
md: fix double free of io_acct_set bioset
Now io_acct_set is alloc and free in personality. Remove the codes that
free io_acct_set in md_free and md_stop. |
["https://git.kernel.org/stable/c/36a2fc44c574a59ee3b5e2cb327182f227b2b07e","https://git.kernel.org/stable/c/42b805af102471f53e3c7867b8c2b502ea4eef7e","https://git.kernel.org/stable/c/ea7d7bd90079d96f9c86bdaf0b106e0cd2a70661","https://git.kernel.org/stable/c/f99d5b5dc8a42c807b5f1176b925aa45d61962ab"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49470
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btmtksdio: fix use-after-free at btmtksdio_recv_event
We should not access skb buffer data anymore after hci_recv_frame was
called.
[ 39.634809] BUG: KASAN: use-after-free in btmtksdio_recv_event+0x1b0
[ 39.634855] Read of size 1 at addr ffffff80cf28a60d by task kworker
[ 39.634962] Call trace:
[ 39.634974] dump_backtrace+0x0/0x3b8
[ 39.634999] show_stack+0x20/0x2c
[ 39.635016] dump_stack_lvl+0x60/0x78
[ 39.635040] print_address_description+0x70/0x2f0
[ 39.635062] kasan_report+0x154/0x194
[ 39.635079] __asan_report_load1_noabort+0x44/0x50
[ 39.635099] btmtksdio_recv_event+0x1b0/0x1c4
[ 39.635129] btmtksdio_txrx_work+0x6cc/0xac4
[ 39.635157] process_one_work+0x560/0xc5c
[ 39.635177] worker_thread+0x7ec/0xcc0
[ 39.635195] kthread+0x2d0/0x3d0
[ 39.635215] ret_from_fork+0x10/0x20
[ 39.635247] Allocated by task 0:
[ 39.635260] (stack is not available)
[ 39.635281] Freed by task 2392:
[ 39.635295] kasan_save_stack+0x38/0x68
[ 39.635319] kasan_set_track+0x28/0x3c
[ 39.635338] kasan_set_free_info+0x28/0x4c
[ 39.635357] ____kasan_slab_free+0x104/0x150
[ 39.635374] __kasan_slab_free+0x18/0x28
[ 39.635391] slab_free_freelist_hook+0x114/0x248
[ 39.635410] kfree+0xf8/0x2b4
[ 39.635427] skb_free_head+0x58/0x98
[ 39.635447] skb_release_data+0x2f4/0x410
[ 39.635464] skb_release_all+0x50/0x60
[ 39.635481] kfree_skb+0xc8/0x25c
[ 39.635498] hci_event_packet+0x894/0xca4 [bluetooth]
[ 39.635721] hci_rx_work+0x1c8/0x68c [bluetooth]
[ 39.635925] process_one_work+0x560/0xc5c
[ 39.635951] worker_thread+0x7ec/0xcc0
[ 39.635970] kthread+0x2d0/0x3d0
[ 39.635990] ret_from_fork+0x10/0x20
[ 39.636021] The buggy address belongs to the object at ffffff80cf28a600
which belongs to the cache kmalloc-512 of size 512
[ 39.636039] The buggy address is located 13 bytes inside of
512-byte region [ffffff80cf28a600, ffffff80cf28a800) |
["https://git.kernel.org/stable/c/01c6a899fa6be4f4cbf60c4f44f0f6691155415f","https://git.kernel.org/stable/c/02ba31e09a26e8cd4582ac8e6163d80284997727","https://git.kernel.org/stable/c/0fab6361c4ba17d1b43a991bef4238a3c1754d35","https://git.kernel.org/stable/c/b3cec8a42fcd11d05313c724f27e01b1db77522c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49501
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
usbnet: Run unregister_netdev() before unbind() again
Commit 2c9d6c2b871d ("usbnet: run unbind() before unregister_netdev()")
sought to fix a use-after-free on disconnect of USB Ethernet adapters.
It turns out that a different fix is necessary to address the issue:
https://lore.kernel.org/netdev/18b3541e5372bc9b9fc733d422f4e698c089077c.1650177997.git.lukas@wunner.de/
So the commit was not necessary.
The commit made binding and unbinding of USB Ethernet asymmetrical:
Before, usbnet_probe() first invoked the ->bind() callback and then
register_netdev(). usbnet_disconnect() mirrored that by first invoking
unregister_netdev() and then ->unbind().
Since the commit, the order in usbnet_disconnect() is reversed and no
longer mirrors usbnet_probe().
One consequence is that a PHY disconnected (and stopped) in ->unbind()
is afterwards stopped once more by unregister_netdev() as it closes the
netdev before unregistering. That necessitates a contortion in ->stop()
because the PHY may only be stopped if it hasn't already been
disconnected.
Reverting the commit allows making the call to phy_stop() unconditional
in ->stop(). |
["https://git.kernel.org/stable/c/6d5deb242874d924beccf7eb3cef04c1c3b0da79","https://git.kernel.org/stable/c/969a1b3ea3cb7d58a16fe12fd1b04bfc0ea40509","https://git.kernel.org/stable/c/d1408f6b4dd78fb1b9e26bcf64477984e5f85409","https://git.kernel.org/stable/c/fbda837107f9bd4ec658d2aa88c6856dba606f06"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57984
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
i3c: dw: Fix use-after-free in dw_i3c_master driver due to race condition
In dw_i3c_common_probe, &master->hj_work is bound with
dw_i3c_hj_work. And dw_i3c_master_irq_handler can call
dw_i3c_master_irq_handle_ibis function to start the work.
If we remove the module which will call dw_i3c_common_remove to
make cleanup, it will free master->base through i3c_master_unregister
while the work mentioned above will be used. The sequence of operations
that may lead to a UAF bug is as follows:
CPU0 CPU1
| dw_i3c_hj_work
dw_i3c_common_remove |
i3c_master_unregister(&master->base) |
device_unregister(&master->dev) |
device_release |
//free master->base |
| i3c_master_do_daa(&master->base)
| //use master->base
Fix it by ensuring that the work is canceled before proceeding with
the cleanup in dw_i3c_common_remove. |
["https://git.kernel.org/stable/c/60d2fb033a999bb644f8e8606ff4a1b82de36c6f","https://git.kernel.org/stable/c/9b0063098fcde17cd2894f2c96459b23388507ca","https://git.kernel.org/stable/c/b75439c945b94dd8a2b645355bdb56f948052601","https://git.kernel.org/stable/c/fc84dd3c909a372c0d130f5f84c404717c17eed8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21759
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ipv6: mcast: extend RCU protection in igmp6_send()
igmp6_send() can be called without RTNL or RCU being held.
Extend RCU protection so that we can safely fetch the net pointer
and avoid a potential UAF.
Note that we no longer can use sock_alloc_send_skb() because
ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.
Instead use alloc_skb() and charge the net->ipv6.igmp_sk
socket under RCU protection. |
["https://git.kernel.org/stable/c/087c1faa594fa07a66933d750c0b2610aa1a2946","https://git.kernel.org/stable/c/0bf8e2f3768629d437a32cb824149e6e98254381","https://git.kernel.org/stable/c/81b25a07ebf53f9ef4ca8f3d96a8ddb94561dd5a","https://git.kernel.org/stable/c/8e92d6a413feaf968a33f0b439ecf27404407458"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21812
|
High |
fixed |
- 3.19
- 4.5
- 4.10
- 4.15
- 4.20
- 6.1.129
- 6.6.76
- 6.12.13
- 6.13.2
|
In the Linux kernel, the following vulnerability has been resolved:
ax25: rcu protect dev->ax25_ptr
syzbot found a lockdep issue [1].
We should remove ax25 RTNL dependency in ax25_setsockopt()
This should also fix a variety of possible UAF in ax25.
[1]
WARNING: possible circular locking dependency detected
6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted
------------------------------------------------------
syz.5.1818/12806 is trying to acquire lock:
ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680
but task is already holding lock:
ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline]
ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (sk_lock-AF_AX25){+.+.}-{0:0}:
lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849
lock_sock_nested+0x48/0x100 net/core/sock.c:3642
lock_sock include/net/sock.h:1618 [inline]
ax25_kill_by_device net/ax25/af_ax25.c:101 [inline]
ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146
notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85
__dev_notify_flags+0x207/0x400
dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026
dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563
dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820
sock_do_ioctl+0x240/0x460 net/socket.c:1234
sock_ioctl+0x626/0x8e0 net/socket.c:1339
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:906 [inline]
__se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (rtnl_mutex){+.+.}-{4:4}:
check_prev_add kernel/locking/lockdep.c:3161 [inline]
check_prevs_add kernel/locking/lockdep.c:3280 [inline]
validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904
__lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226
lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849
__mutex_lock_common kernel/locking/mutex.c:585 [inline]
__mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735
ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680
do_sock_setsockopt+0x3af/0x720 net/socket.c:2324
__sys_setsockopt net/socket.c:2349 [inline]
__do_sys_setsockopt net/socket.c:2355 [inline]
__se_sys_setsockopt net/socket.c:2352 [inline]
__x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(sk_lock-AF_AX25);
lock(rtnl_mutex);
lock(sk_lock-AF_AX25);
lock(rtnl_mutex);
*** DEADLOCK ***
1 lock held by syz.5.1818/12806:
#0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline]
#0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574
stack backtrace:
CPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074
check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206
check_prev_add kernel/locking/lockdep.c:3161 [inline]
check_prevs_add kernel/lockin
---truncated--- |
["https://git.kernel.org/stable/c/2802ed4ced27ebd474828fc67ffd7d66f11e3605","https://git.kernel.org/stable/c/7705d8a7f2c26c80973c81093db07c6022b2b30e","https://git.kernel.org/stable/c/8937f5e38a218531dce2a89fae60e3adcc2311e1","https://git.kernel.org/stable/c/95fc45d1dea8e1253f8ec58abc5befb71553d666","https://git.kernel.org/stable/c/c2531db6de3c95551be58878f859c6a053b7eb2e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-54458
|
High |
fixed |
- 6.1.129
- 6.6.79
- 6.12.16
- 6.13.4
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: bsg: Set bsg_queue to NULL after removal
Currently, this does not cause any issues, but I believe it is necessary to
set bsg_queue to NULL after removing it to prevent potential use-after-free
(UAF) access. |
["https://git.kernel.org/stable/c/1e95c798d8a7f70965f0f88d4657b682ff0ec75f","https://git.kernel.org/stable/c/22018622e1e9e371198dbd983af946a844d5924c","https://git.kernel.org/stable/c/5e7b6e44468c3242c21c2a8656d009fb3eb50a73","https://git.kernel.org/stable/c/5f782d4741bf558def60df192b858b0efc6a5f0a","https://git.kernel.org/stable/c/88a01e9c9ad40c075756ba93b47984461d4ff15d","https://git.kernel.org/stable/c/9193bdc170cc23fe98aca71d1a63c0bf6e1e853b","https://git.kernel.org/stable/c/bb4783c670180b922267222408e1c48d22dfbb46"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-58034
|
High |
fixed |
- 5.15.179
- 6.1.129
- 6.6.76
- 6.12.13
- 6.13.2
|
In the Linux kernel, the following vulnerability has been resolved:
memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()
As of_find_node_by_name() release the reference of the argument device
node, tegra_emc_find_node_by_ram_code() releases some device nodes while
still in use, resulting in possible UAFs. According to the bindings and
the in-tree DTS files, the "emc-tables" node is always device's child
node with the property "nvidia,use-ram-code", and the "lpddr2" node is a
child of the "emc-tables" node. Thus utilize the
for_each_child_of_node() macro and of_get_child_by_name() instead of
of_find_node_by_name() to simplify the code.
This bug was found by an experimental verification tool that I am
developing.
[krzysztof: applied v1, adjust the commit msg to incorporate v2 parts] |
["https://git.kernel.org/stable/c/3b02273446e23961d910b50cc12528faec649fb2","https://git.kernel.org/stable/c/755e44538c190c31de9090d8e8821d228fcfd416","https://git.kernel.org/stable/c/b9784e5cde1f9fb83661a70e580e381ae1264d12","https://git.kernel.org/stable/c/c144423cb07e4e227a8572d5742ca2b36ada770d","https://git.kernel.org/stable/c/c3def10c610ae046aaa61d00528e7bd15e4ad8d3","https://git.kernel.org/stable/c/e9d07e91de140679eeaf275f47ad154467cb9e05"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21722
|
High |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.129
- 6.12.13
- 6.13.2
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: do not force clear folio if buffer is referenced
Patch series "nilfs2: protect busy buffer heads from being force-cleared".
This series fixes the buffer head state inconsistency issues reported by
syzbot that occurs when the filesystem is corrupted and falls back to
read-only, and the associated buffer head use-after-free issue.
This patch (of 2):
Syzbot has reported that after nilfs2 detects filesystem corruption and
falls back to read-only, inconsistencies in the buffer state may occur.
One of the inconsistencies is that when nilfs2 calls mark_buffer_dirty()
to set a data or metadata buffer as dirty, but it detects that the buffer
is not in the uptodate state:
WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520
fs/buffer.c:1177
...
Call Trace:
<TASK>
nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598
nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73
nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344
nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218
vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257
do_mkdirat+0x264/0x3a0 fs/namei.c:4280
__do_sys_mkdirat fs/namei.c:4295 [inline]
__se_sys_mkdirat fs/namei.c:4293 [inline]
__x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The other is when nilfs_btree_propagate(), which propagates the dirty
state to the ancestor nodes of a b-tree that point to a dirty buffer,
detects that the origin buffer is not dirty, even though it should be:
WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089
nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089
...
Call Trace:
<TASK>
nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345
nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587
nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006
nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045
nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline]
nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline]
nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115
nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479
nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline]
nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701
kthread+0x2f0/0x390 kernel/kthread.c:389
ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
</TASK>
Both of these issues are caused by the callbacks that handle the
page/folio write requests, forcibly clear various states, including the
working state of the buffers they hold, at unexpected times when they
detect read-only fallback.
Fix these issues by checking if the buffer is referenced before clearing
the page/folio state, and skipping the clear if it is. |
["https://git.kernel.org/stable/c/1098bb8d52419d262a3358d099a1598a920b730f","https://git.kernel.org/stable/c/19296737024cd220a1d6590bf4c092bca8c99497","https://git.kernel.org/stable/c/4d042811c72f71be7c14726db2c72b67025a7cb5","https://git.kernel.org/stable/c/557ccf5e49f1fb848a29698585bcab2e50a597ef","https://git.kernel.org/stable/c/7d0544bacc11d6aa26ecd7debf9353193c7a3328","https://git.kernel.org/stable/c/ca76bb226bf47ff04c782cacbd299f12ddee1ec1","https://git.kernel.org/stable/c/f51ff43c4c5a6c8e72d0aca89e4d5e688938412f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21726
|
High |
fixed |
- 5.5
- 5.10.235
- 5.15.79
- 6.1.129
- 6.6.76
- 6.12.13
- 6.13.2
|
In the Linux kernel, the following vulnerability has been resolved:
padata: avoid UAF for reorder_work
Although the previous patch can avoid ps and ps UAF for _do_serial, it
can not avoid potential UAF issue for reorder_work. This issue can
happen just as below:
crypto_request crypto_request crypto_del_alg
padata_do_serial
...
padata_reorder
// processes all remaining
// requests then breaks
while (1) {
if (!padata)
break;
...
}
padata_do_serial
// new request added
list_add
// sees the new request
queue_work(reorder_work)
padata_reorder
queue_work_on(squeue->work)
...
<kworker context>
padata_serial_worker
// completes new request,
// no more outstanding
// requests
crypto_del_alg
// free pd
<kworker context>
invoke_padata_reorder
// UAF of pd
To avoid UAF for 'reorder_work', get 'pd' ref before put 'reorder_work'
into the 'serial_wq' and put 'pd' ref until the 'serial_wq' finish. |
["https://git.kernel.org/stable/c/4c6209efea2208597dbd3e52dc87a0d1a8f2dbe1","https://git.kernel.org/stable/c/6f45ef616775b0ce7889b0f6077fc8d681ab30bc","https://git.kernel.org/stable/c/7000507bb0d2ceb545c0a690e0c707c897d102c2","https://git.kernel.org/stable/c/8ca38d0ca8c3d30dd18d311f1a7ec5cb56972cac","https://git.kernel.org/stable/c/a54091c24220a4cd847d5b4f36d678edacddbaf0","https://git.kernel.org/stable/c/dd7d37ccf6b11f3d95e797ebe4e9e886d0332600","https://git.kernel.org/stable/c/f4f1b1169fc3694f9bc3e28c6c68dbbf4cc744c0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21727
|
High |
fixed |
- 5.10.235
- 5.15.179
- 6.1.129
- 6.6.76
- 6.12.13
- 6.13.2
|
In the Linux kernel, the following vulnerability has been resolved:
padata: fix UAF in padata_reorder
A bug was found when run ltp test:
BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0
Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206
CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+
Workqueue: pdecrypt_parallel padata_parallel_worker
Call Trace:
<TASK>
dump_stack_lvl+0x32/0x50
print_address_description.constprop.0+0x6b/0x3d0
print_report+0xdd/0x2c0
kasan_report+0xa5/0xd0
padata_find_next+0x29/0x1a0
padata_reorder+0x131/0x220
padata_parallel_worker+0x3d/0xc0
process_one_work+0x2ec/0x5a0
If 'mdelay(10)' is added before calling 'padata_find_next' in the
'padata_reorder' function, this issue could be reproduced easily with
ltp test (pcrypt_aead01).
This can be explained as bellow:
pcrypt_aead_encrypt
...
padata_do_parallel
refcount_inc(&pd->refcnt); // add refcnt
...
padata_do_serial
padata_reorder // pd
while (1) {
padata_find_next(pd, true); // using pd
queue_work_on
...
padata_serial_worker crypto_del_alg
padata_put_pd_cnt // sub refcnt
padata_free_shell
padata_put_pd(ps->pd);
// pd is freed
// loop again, but pd is freed
// call padata_find_next, UAF
}
In the padata_reorder function, when it loops in 'while', if the alg is
deleted, the refcnt may be decreased to 0 before entering
'padata_find_next', which leads to UAF.
As mentioned in [1], do_serial is supposed to be called with BHs disabled
and always happen under RCU protection, to address this issue, add
synchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls
to finish.
[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/
[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/ |
["https://git.kernel.org/stable/c/0ae2f332cfd2d74cf3ce344ec9938cf3e29c3ccd","https://git.kernel.org/stable/c/573ac9c70bf7885dc85d82fa44550581bfc3b738","https://git.kernel.org/stable/c/80231f069240d52e98b6a317456c67b2eafd0781","https://git.kernel.org/stable/c/bbccae982e9fa1d7abcb23a5ec81cb0ec883f7de","https://git.kernel.org/stable/c/e01780ea4661172734118d2a5f41bc9720765668","https://git.kernel.org/stable/c/f3e0b9f790f8e8065d59e67b565a83154d9f3079","https://git.kernel.org/stable/c/f78170bee51469734b1a306a74fc5f777bb22ba6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49753
|
High |
fixed |
- 4.14.305
- 4.19.272
- 5.4.231
- 5.10.166
- 5.15.91
- 6.1.9
|
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: Fix double increment of client_count in dma_chan_get()
The first time dma_chan_get() is called for a channel the channel
client_count is incorrectly incremented twice for public channels,
first in balance_ref_count(), and again prior to returning. This
results in an incorrect client count which will lead to the
channel resources not being freed when they should be. A simple
test of repeated module load and unload of async_tx on a Dell
Power Edge R7425 also shows this resulting in a kref underflow
warning.
[ 124.329662] async_tx: api initialized (async)
[ 129.000627] async_tx: api initialized (async)
[ 130.047839] ------------[ cut here ]------------
[ 130.052472] refcount_t: underflow; use-after-free.
[ 130.057279] WARNING: CPU: 3 PID: 19364 at lib/refcount.c:28
refcount_warn_saturate+0xba/0x110
[ 130.065811] Modules linked in: async_tx(-) rfkill intel_rapl_msr
intel_rapl_common amd64_edac edac_mce_amd ipmi_ssif kvm_amd dcdbas kvm
mgag200 drm_shmem_helper acpi_ipmi irqbypass drm_kms_helper ipmi_si
syscopyarea sysfillrect rapl pcspkr ipmi_devintf sysimgblt fb_sys_fops
k10temp i2c_piix4 ipmi_msghandler acpi_power_meter acpi_cpufreq vfat
fat drm fuse xfs libcrc32c sd_mod t10_pi sg ahci crct10dif_pclmul
libahci crc32_pclmul crc32c_intel ghash_clmulni_intel igb megaraid_sas
i40e libata i2c_algo_bit ccp sp5100_tco dca dm_mirror dm_region_hash
dm_log dm_mod [last unloaded: async_tx]
[ 130.117361] CPU: 3 PID: 19364 Comm: modprobe Kdump: loaded Not
tainted 5.14.0-185.el9.x86_64 #1
[ 130.126091] Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS
1.18.0 01/17/2022
[ 130.133806] RIP: 0010:refcount_warn_saturate+0xba/0x110
[ 130.139041] Code: 01 01 e8 6d bd 55 00 0f 0b e9 72 9d 8a 00 80 3d
26 18 9c 01 00 75 85 48 c7 c7 f8 a3 03 9d c6 05 16 18 9c 01 01 e8 4a
bd 55 00 <0f> 0b e9 4f 9d 8a 00 80 3d 01 18 9c 01 00 0f 85 5e ff ff ff
48 c7
[ 130.157807] RSP: 0018:ffffbf98898afe68 EFLAGS: 00010286
[ 130.163036] RAX: 0000000000000000 RBX: ffff9da06028e598 RCX: 0000000000000000
[ 130.170172] RDX: ffff9daf9de26480 RSI: ffff9daf9de198a0 RDI: ffff9daf9de198a0
[ 130.177316] RBP: ffff9da7cddf3970 R08: 0000000000000000 R09: 00000000ffff7fff
[ 130.184459] R10: ffffbf98898afd00 R11: ffffffff9d9e8c28 R12: ffff9da7cddf1970
[ 130.191596] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 130.198739] FS: 00007f646435c740(0000) GS:ffff9daf9de00000(0000)
knlGS:0000000000000000
[ 130.206832] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 130.212586] CR2: 00007f6463b214f0 CR3: 00000008ab98c000 CR4: 00000000003506e0
[ 130.219729] Call Trace:
[ 130.222192] <TASK>
[ 130.224305] dma_chan_put+0x10d/0x110
[ 130.227988] dmaengine_put+0x7a/0xa0
[ 130.231575] __do_sys_delete_module.constprop.0+0x178/0x280
[ 130.237157] ? syscall_trace_enter.constprop.0+0x145/0x1d0
[ 130.242652] do_syscall_64+0x5c/0x90
[ 130.246240] ? exc_page_fault+0x62/0x150
[ 130.250178] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 130.255243] RIP: 0033:0x7f6463a3f5ab
[ 130.258830] Code: 73 01 c3 48 8b 0d 75 a8 1b 00 f7 d8 64 89 01 48
83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00
00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89
01 48
[ 130.277591] RSP: 002b:00007fff22f972c8 EFLAGS: 00000206 ORIG_RAX:
00000000000000b0
[ 130.285164] RAX: ffffffffffffffda RBX: 000055b6786edd40 RCX: 00007f6463a3f5ab
[ 130.292303] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055b6786edda8
[ 130.299443] RBP: 000055b6786edd40 R08: 0000000000000000 R09: 0000000000000000
[ 130.306584] R10: 00007f6463b9eac0 R11: 0000000000000206 R12: 000055b6786edda8
[ 130.313731] R13: 0000000000000000 R14: 000055b6786edda8 R15: 00007fff22f995f8
[ 130.320875] </TASK>
[ 130.323081] ---[ end trace eff7156d56b5cf25 ]---
cat /sys/class/dma/dma0chan*/in_use would get the wrong result.
2
2
2
Test-by: Jie Hai <haijie1@huawei.com> |
["https://git.kernel.org/stable/c/142d644fd2cc059ffa042fbfb68e766433ef3afd","https://git.kernel.org/stable/c/18dd3b30d4c7e8440c63118c7a7b687372b9567f","https://git.kernel.org/stable/c/1b409e14b4b7af034e0450f95c165b6c5c87dbc1","https://git.kernel.org/stable/c/42ecd72f02cd657b00b559621e7ef7d2c4d3e5f1","https://git.kernel.org/stable/c/71c601965532c38030133535f7cd93c1efa75af1","https://git.kernel.org/stable/c/c6221afe573413fd2981e291f7df4a58283e0654","https://git.kernel.org/stable/c/f3dc1b3b4750851a94212dba249703dd0e50bb20"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-58013
|
High |
fixed |
- 6.1.129
- 6.6.78
- 6.12.14
- 6.13.3
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: Fix slab-use-after-free Read in mgmt_remove_adv_monitor_sync
This fixes the following crash:
==================================================================
BUG: KASAN: slab-use-after-free in mgmt_remove_adv_monitor_sync+0x3a/0xd0 net/bluetooth/mgmt.c:5543
Read of size 8 at addr ffff88814128f898 by task kworker/u9:4/5961
CPU: 1 UID: 0 PID: 5961 Comm: kworker/u9:4 Not tainted 6.12.0-syzkaller-10684-gf1cd565ce577 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Workqueue: hci0 hci_cmd_sync_work
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0x169/0x550 mm/kasan/report.c:489
kasan_report+0x143/0x180 mm/kasan/report.c:602
mgmt_remove_adv_monitor_sync+0x3a/0xd0 net/bluetooth/mgmt.c:5543
hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332
process_one_work kernel/workqueue.c:3229 [inline]
process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310
worker_thread+0x870/0xd30 kernel/workqueue.c:3391
kthread+0x2f0/0x390 kernel/kthread.c:389
ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
</TASK>
Allocated by task 16026:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
__kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394
kasan_kmalloc include/linux/kasan.h:260 [inline]
__kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4314
kmalloc_noprof include/linux/slab.h:901 [inline]
kzalloc_noprof include/linux/slab.h:1037 [inline]
mgmt_pending_new+0x65/0x250 net/bluetooth/mgmt_util.c:269
mgmt_pending_add+0x36/0x120 net/bluetooth/mgmt_util.c:296
remove_adv_monitor+0x102/0x1b0 net/bluetooth/mgmt.c:5568
hci_mgmt_cmd+0xc47/0x11d0 net/bluetooth/hci_sock.c:1712
hci_sock_sendmsg+0x7b8/0x11c0 net/bluetooth/hci_sock.c:1832
sock_sendmsg_nosec net/socket.c:711 [inline]
__sock_sendmsg+0x221/0x270 net/socket.c:726
sock_write_iter+0x2d7/0x3f0 net/socket.c:1147
new_sync_write fs/read_write.c:586 [inline]
vfs_write+0xaeb/0xd30 fs/read_write.c:679
ksys_write+0x18f/0x2b0 fs/read_write.c:731
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 16022:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582
poison_slab_object mm/kasan/common.c:247 [inline]
__kasan_slab_free+0x59/0x70 mm/kasan/common.c:264
kasan_slab_free include/linux/kasan.h:233 [inline]
slab_free_hook mm/slub.c:2338 [inline]
slab_free mm/slub.c:4598 [inline]
kfree+0x196/0x420 mm/slub.c:4746
mgmt_pending_foreach+0xd1/0x130 net/bluetooth/mgmt_util.c:259
__mgmt_power_off+0x183/0x430 net/bluetooth/mgmt.c:9550
hci_dev_close_sync+0x6c4/0x11c0 net/bluetooth/hci_sync.c:5208
hci_dev_do_close net/bluetooth/hci_core.c:483 [inline]
hci_dev_close+0x112/0x210 net/bluetooth/hci_core.c:508
sock_do_ioctl+0x158/0x460 net/socket.c:1209
sock_ioctl+0x626/0x8e0 net/socket.c:1328
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:906 [inline]
__se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f |
["https://git.kernel.org/stable/c/0f3d05aacbfcf3584bbd9caaee34cb02508dab68","https://git.kernel.org/stable/c/26fbd3494a7dd26269cb0817c289267dbcfdec06","https://git.kernel.org/stable/c/4ebbcb9bc794e5be647ee28fdf14eb1ae0659405","https://git.kernel.org/stable/c/75e65b983c5e2ee51962bfada98a79d805f28827","https://git.kernel.org/stable/c/ebb90f23f0ac21044aacf4c61cc5d7841fe99987"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26589
|
High |
fixed |
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS
For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off
for validation. However, variable offset ptr alu is not prohibited
for this ptr kind. So the variable offset is not checked.
The following prog is accepted:
func#0 @0
0: R1=ctx() R10=fp0
0: (bf) r6 = r1 ; R1=ctx() R6_w=ctx()
1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys()
2: (b7) r8 = 1024 ; R8_w=1024
3: (37) r8 /= 1 ; R8_w=scalar()
4: (57) r8 &= 1024 ; R8_w=scalar(smin=smin32=0,
smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400))
5: (0f) r7 += r8
mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1
mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024
mark_precise: frame0: regs=r8 stack= before 3: (37) r8 /= 1
mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024
6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off
=(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024,
var_off=(0x0; 0x400))
6: (79) r0 = *(u64 *)(r7 +0) ; R0_w=scalar()
7: (95) exit
This prog loads flow_keys to r7, and adds the variable offset r8
to r7, and finally causes out-of-bounds access:
BUG: unable to handle page fault for address: ffffc90014c80038
[...]
Call Trace:
<TASK>
bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline]
__bpf_prog_run include/linux/filter.h:651 [inline]
bpf_prog_run include/linux/filter.h:658 [inline]
bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline]
bpf_flow_dissect+0x15f/0x350 net/core/flow_dissector.c:991
bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359
bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline]
__sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475
__do_sys_bpf kernel/bpf/syscall.c:5561 [inline]
__se_sys_bpf kernel/bpf/syscall.c:5559 [inline]
__x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Fix this by rejecting ptr alu with variable offset on flow_keys.
Applying the patch rejects the program with "R7 pointer arithmetic
on flow_keys prohibited". |
["https://git.kernel.org/stable/c/1b500d5d6cecf98dd6ca88bc9e7ae1783c83e6d3","https://git.kernel.org/stable/c/22c7fa171a02d310e3a3f6ed46a698ca8a0060ed","https://git.kernel.org/stable/c/29ffa63f21bcdcef3e36b03cccf9d0cd031f6ab0","https://git.kernel.org/stable/c/4108b86e324da42f7ed425bd71632fd844300dc8","https://git.kernel.org/stable/c/e8d3872b617c21100c5ee4f64e513997a68c2e3d","https://git.kernel.org/stable/c/1b500d5d6cecf98dd6ca88bc9e7ae1783c83e6d3","https://git.kernel.org/stable/c/22c7fa171a02d310e3a3f6ed46a698ca8a0060ed","https://git.kernel.org/stable/c/29ffa63f21bcdcef3e36b03cccf9d0cd031f6ab0","https://git.kernel.org/stable/c/4108b86e324da42f7ed425bd71632fd844300dc8","https://git.kernel.org/stable/c/e8d3872b617c21100c5ee4f64e513997a68c2e3d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1078
|
High |
fixed |
- 4.19.273
- 5.4.232
- 5.10.168
- 5.15.94
- 6.1.12
|
A flaw was found in the Linux Kernel in RDS (Reliable Datagram Sockets) protocol. The rds_rm_zerocopy_callback() uses list_entry() on the head of a list causing a type confusion. Local user can trigger this with rds_message_put(). Type confusion leads to `struct rds_msg_zcopy_info *info` actually points to something else that is potentially controlled by local user. It is known how to trigger this, which causes an out of bounds access, and a lock corruption. |
["http://www.openwall.com/lists/oss-security/2023/11/05/1","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=f753a68980cf4b59a80fe677619da2b1804f526d","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230505-0004/","http://www.openwall.com/lists/oss-security/2023/11/05/1","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=f753a68980cf4b59a80fe677619da2b1804f526d","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230505-0004/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49894
|
High |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix index out of bounds in degamma hardware format translation
Fixes index out of bounds issue in
`cm_helper_translate_curve_to_degamma_hw_format` function. The issue
could occur when the index 'i' exceeds the number of transfer function
points (TRANSFER_FUNC_POINTS).
The fix adds a check to ensure 'i' is within bounds before accessing the
transfer function points. If 'i' is out of bounds the function returns
false to indicate an error.
Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max |
["https://git.kernel.org/stable/c/07078fa5d589a7fbce8f81ea8acf7aa0021ab38e","https://git.kernel.org/stable/c/122e3a7a8c7bcbe3aacddd6103f67f9f36bed473","https://git.kernel.org/stable/c/2495c8e272d84685403506833a664fad932e453a","https://git.kernel.org/stable/c/2f5da549535be8ccd2ab7c9abac8562ad370b181","https://git.kernel.org/stable/c/b3dfa878257a7e98830b3009ca5831a01d8f85fc","https://git.kernel.org/stable/c/b7e99058eb2e86aabd7a10761e76cae33d22b49f","https://git.kernel.org/stable/c/c130a3c09e3746c1a09ce26c20d21d449d039b1d","https://git.kernel.org/stable/c/c6979719012a90e5b8e3bc31725fbfdd0b9b2b79","https://git.kernel.org/stable/c/f5f6d90087131812c1e4b9d3103f400f1624396d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49063
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ice: arfs: fix use-after-free when freeing @rx_cpu_rmap
The CI testing bots triggered the following splat:
[ 718.203054] BUG: KASAN: use-after-free in free_irq_cpu_rmap+0x53/0x80
[ 718.206349] Read of size 4 at addr ffff8881bd127e00 by task sh/20834
[ 718.212852] CPU: 28 PID: 20834 Comm: sh Kdump: loaded Tainted: G S W IOE 5.17.0-rc8_nextqueue-devqueue-02643-g23f3121aca93 #1
[ 718.219695] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0012.070720200218 07/07/2020
[ 718.223418] Call Trace:
[ 718.227139]
[ 718.230783] dump_stack_lvl+0x33/0x42
[ 718.234431] print_address_description.constprop.9+0x21/0x170
[ 718.238177] ? free_irq_cpu_rmap+0x53/0x80
[ 718.241885] ? free_irq_cpu_rmap+0x53/0x80
[ 718.245539] kasan_report.cold.18+0x7f/0x11b
[ 718.249197] ? free_irq_cpu_rmap+0x53/0x80
[ 718.252852] free_irq_cpu_rmap+0x53/0x80
[ 718.256471] ice_free_cpu_rx_rmap.part.11+0x37/0x50 [ice]
[ 718.260174] ice_remove_arfs+0x5f/0x70 [ice]
[ 718.263810] ice_rebuild_arfs+0x3b/0x70 [ice]
[ 718.267419] ice_rebuild+0x39c/0xb60 [ice]
[ 718.270974] ? asm_sysvec_apic_timer_interrupt+0x12/0x20
[ 718.274472] ? ice_init_phy_user_cfg+0x360/0x360 [ice]
[ 718.278033] ? delay_tsc+0x4a/0xb0
[ 718.281513] ? preempt_count_sub+0x14/0xc0
[ 718.284984] ? delay_tsc+0x8f/0xb0
[ 718.288463] ice_do_reset+0x92/0xf0 [ice]
[ 718.292014] ice_pci_err_resume+0x91/0xf0 [ice]
[ 718.295561] pci_reset_function+0x53/0x80
<...>
[ 718.393035] Allocated by task 690:
[ 718.433497] Freed by task 20834:
[ 718.495688] Last potentially related work creation:
[ 718.568966] The buggy address belongs to the object at ffff8881bd127e00
which belongs to the cache kmalloc-96 of size 96
[ 718.574085] The buggy address is located 0 bytes inside of
96-byte region [ffff8881bd127e00, ffff8881bd127e60)
[ 718.579265] The buggy address belongs to the page:
[ 718.598905] Memory state around the buggy address:
[ 718.601809] ffff8881bd127d00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
[ 718.604796] ffff8881bd127d80: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc
[ 718.607794] >ffff8881bd127e00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
[ 718.610811] ^
[ 718.613819] ffff8881bd127e80: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc
[ 718.617107] ffff8881bd127f00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
This is due to that free_irq_cpu_rmap() is always being called
*after* (devm_)free_irq() and thus it tries to work with IRQ descs
already freed. For example, on device reset the driver frees the
rmap right before allocating a new one (the splat above).
Make rmap creation and freeing function symmetrical with
{request,free}_irq() calls i.e. do that on ifup/ifdown instead
of device probe/remove/resume. These operations can be performed
independently from the actual device aRFS configuration.
Also, make sure ice_vsi_free_irq() clears IRQ affinity notifiers
only when aRFS is disabled -- otherwise, CPU rmap sets and clears
its own and they must not be touched manually. |
["https://git.kernel.org/stable/c/618df75f2e30c7838a3e010ca32cd4893ec9fe33","https://git.kernel.org/stable/c/d08d2fb6d99d82da1c63aba5c0d1c6f237e150f3","https://git.kernel.org/stable/c/d7442f512b71fc63a99c8a801422dde4fbbf9f93"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49359
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/panfrost: Job should reference MMU not file_priv
For a while now it's been allowed for a MMU context to outlive it's
corresponding panfrost_priv, however the job structure still references
panfrost_priv to get hold of the MMU context. If panfrost_priv has been
freed this is a use-after-free which I've been able to trigger resulting
in a splat.
To fix this, drop the reference to panfrost_priv in the job structure
and add a direct reference to the MMU structure which is what's actually
needed. |
["https://git.kernel.org/stable/c/472dd7ea5e19a1aeabf1711ddc756777e05ee7c2","https://git.kernel.org/stable/c/6e516faf04317db2c46cbec4e3b78b4653a5b109","https://git.kernel.org/stable/c/8c8e8cc91a6ffc79865108279a74fd57d9070a17"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49390
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
macsec: fix UAF bug for real_dev
Create a new macsec device but not get reference to real_dev. That can
not ensure that real_dev is freed after macsec. That will trigger the
UAF bug for real_dev as following:
==================================================================
BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662
Call Trace:
...
macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662
dev_get_iflink+0x73/0xe0 net/core/dev.c:637
default_operstate net/core/link_watch.c:42 [inline]
rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54
linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161
Allocated by task 22209:
...
alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549
rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235
veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748
Freed by task 8:
...
kfree+0xd6/0x4d0 mm/slub.c:4552
kvfree+0x42/0x50 mm/util.c:615
device_release+0x9f/0x240 drivers/base/core.c:2229
kobject_cleanup lib/kobject.c:673 [inline]
kobject_release lib/kobject.c:704 [inline]
kref_put include/linux/kref.h:65 [inline]
kobject_put+0x1c8/0x540 lib/kobject.c:721
netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327
After commit faab39f63c1f ("net: allow out-of-order netdev unregistration")
and commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"), we
can add dev_hold_track() in macsec_dev_init() and dev_put_track() in
macsec_free_netdev() to fix the problem. |
["https://git.kernel.org/stable/c/196a888ca6571deb344468e1d7138e3273206335","https://git.kernel.org/stable/c/78933cbc143b82d02330e00900d2fd08f2682f4e","https://git.kernel.org/stable/c/d130282179aa6051449ac8f8df1115769998a665"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49465
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
blk-throttle: Set BIO_THROTTLED when bio has been throttled
1.In current process, all bio will set the BIO_THROTTLED flag
after __blk_throtl_bio().
2.If bio needs to be throttled, it will start the timer and
stop submit bio directly. Bio will submit in
blk_throtl_dispatch_work_fn() when the timer expires.But in
the current process, if bio is throttled. The BIO_THROTTLED
will be set to bio after timer start. If the bio has been
completed, it may cause use-after-free blow.
BUG: KASAN: use-after-free in blk_throtl_bio+0x12f0/0x2c70
Read of size 2 at addr ffff88801b8902d4 by task fio/26380
dump_stack+0x9b/0xce
print_address_description.constprop.6+0x3e/0x60
kasan_report.cold.9+0x22/0x3a
blk_throtl_bio+0x12f0/0x2c70
submit_bio_checks+0x701/0x1550
submit_bio_noacct+0x83/0xc80
submit_bio+0xa7/0x330
mpage_readahead+0x380/0x500
read_pages+0x1c1/0xbf0
page_cache_ra_unbounded+0x471/0x6f0
do_page_cache_ra+0xda/0x110
ondemand_readahead+0x442/0xae0
page_cache_async_ra+0x210/0x300
generic_file_buffered_read+0x4d9/0x2130
generic_file_read_iter+0x315/0x490
blkdev_read_iter+0x113/0x1b0
aio_read+0x2ad/0x450
io_submit_one+0xc8e/0x1d60
__se_sys_io_submit+0x125/0x350
do_syscall_64+0x2d/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Allocated by task 26380:
kasan_save_stack+0x19/0x40
__kasan_kmalloc.constprop.2+0xc1/0xd0
kmem_cache_alloc+0x146/0x440
mempool_alloc+0x125/0x2f0
bio_alloc_bioset+0x353/0x590
mpage_alloc+0x3b/0x240
do_mpage_readpage+0xddf/0x1ef0
mpage_readahead+0x264/0x500
read_pages+0x1c1/0xbf0
page_cache_ra_unbounded+0x471/0x6f0
do_page_cache_ra+0xda/0x110
ondemand_readahead+0x442/0xae0
page_cache_async_ra+0x210/0x300
generic_file_buffered_read+0x4d9/0x2130
generic_file_read_iter+0x315/0x490
blkdev_read_iter+0x113/0x1b0
aio_read+0x2ad/0x450
io_submit_one+0xc8e/0x1d60
__se_sys_io_submit+0x125/0x350
do_syscall_64+0x2d/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Freed by task 0:
kasan_save_stack+0x19/0x40
kasan_set_track+0x1c/0x30
kasan_set_free_info+0x1b/0x30
__kasan_slab_free+0x111/0x160
kmem_cache_free+0x94/0x460
mempool_free+0xd6/0x320
bio_free+0xe0/0x130
bio_put+0xab/0xe0
bio_endio+0x3a6/0x5d0
blk_update_request+0x590/0x1370
scsi_end_request+0x7d/0x400
scsi_io_completion+0x1aa/0xe50
scsi_softirq_done+0x11b/0x240
blk_mq_complete_request+0xd4/0x120
scsi_mq_done+0xf0/0x200
virtscsi_vq_done+0xbc/0x150
vring_interrupt+0x179/0x390
__handle_irq_event_percpu+0xf7/0x490
handle_irq_event_percpu+0x7b/0x160
handle_irq_event+0xcc/0x170
handle_edge_irq+0x215/0xb20
common_interrupt+0x60/0x120
asm_common_interrupt+0x1e/0x40
Fix this by move BIO_THROTTLED set into the queue_lock. |
["https://git.kernel.org/stable/c/0cfc8a0fb07cde61915e4a77c4794c47de3114a4","https://git.kernel.org/stable/c/5a011f889b4832aa80c2a872a5aade5c48d2756f","https://git.kernel.org/stable/c/935fa666534d7b7185e8c6b0191cd06281be4290"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49471
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
rtw89: cfo: check mac_id to avoid out-of-bounds
Somehow, hardware reports incorrect mac_id and pollute memory. Check index
before we access the array.
UBSAN: array-index-out-of-bounds in rtw89/phy.c:2517:23
index 188 is out of range for type 's32 [64]'
CPU: 1 PID: 51550 Comm: irq/35-rtw89_pc Tainted: G OE
Call Trace:
<IRQ>
show_stack+0x52/0x58
dump_stack_lvl+0x4c/0x63
dump_stack+0x10/0x12
ubsan_epilogue+0x9/0x45
__ubsan_handle_out_of_bounds.cold+0x44/0x49
? __alloc_skb+0x92/0x1d0
rtw89_phy_cfo_parse+0x44/0x7f [rtw89_core]
rtw89_core_rx+0x261/0x871 [rtw89_core]
? __alloc_skb+0xee/0x1d0
rtw89_pci_napi_poll+0x3fa/0x4ea [rtw89_pci]
__napi_poll+0x33/0x1a0
net_rx_action+0x126/0x260
? __queue_work+0x217/0x4c0
__do_softirq+0xd9/0x315
? disable_irq_nosync+0x10/0x10
do_softirq.part.0+0x6d/0x90
</IRQ>
<TASK>
__local_bh_enable_ip+0x62/0x70
rtw89_pci_interrupt_threadfn+0x182/0x1a6 [rtw89_pci]
irq_thread_fn+0x28/0x60
irq_thread+0xc8/0x190
? irq_thread_fn+0x60/0x60
kthread+0x16b/0x190
? irq_thread_check_affinity+0xe0/0xe0
? set_kthread_struct+0x50/0x50
ret_from_fork+0x22/0x30
</TASK> |
["https://git.kernel.org/stable/c/03ed236480aeec8c2fd327a1ea6d711364c495e3","https://git.kernel.org/stable/c/97df85871a5b187609d30fca6d85b912d9e02f29","https://git.kernel.org/stable/c/c32fafe68298bb599e825c298e1d0ba30186f0a5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49535
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix null pointer dereference after failing to issue FLOGI and PLOGI
If lpfc_issue_els_flogi() fails and returns non-zero status, the node
reference count is decremented to trigger the release of the nodelist
structure. However, if there is a prior registration or dev-loss-evt work
pending, the node may be released prematurely. When dev-loss-evt
completes, the released node is referenced causing a use-after-free null
pointer dereference.
Similarly, when processing non-zero ELS PLOGI completion status in
lpfc_cmpl_els_plogi(), the ndlp flags are checked for a transport
registration before triggering node removal. If dev-loss-evt work is
pending, the node may be released prematurely and a subsequent call to
lpfc_dev_loss_tmo_handler() results in a use after free ndlp dereference.
Add test for pending dev-loss before decrementing the node reference count
for FLOGI, PLOGI, PRLI, and ADISC handling. |
["https://git.kernel.org/stable/c/10663ebec0ad5c78493a0dd34c9ee4d73d7ca0df","https://git.kernel.org/stable/c/577a942df3de2666f6947bdd3a5c9e8d30073424","https://git.kernel.org/stable/c/c7dc74ab7975c9b96284abfe4cca756d75fa4604"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49711
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bus: fsl-mc-bus: fix KASAN use-after-free in fsl_mc_bus_remove()
In fsl_mc_bus_remove(), mc->root_mc_bus_dev->mc_io is passed to
fsl_destroy_mc_io(). However, mc->root_mc_bus_dev is already freed in
fsl_mc_device_remove(). Then reference to mc->root_mc_bus_dev->mc_io
triggers KASAN use-after-free. To avoid the use-after-free, keep the
reference to mc->root_mc_bus_dev->mc_io in a local variable and pass to
fsl_destroy_mc_io().
This patch needs rework to apply to kernels older than v5.15. |
["https://git.kernel.org/stable/c/161b68b0a728377aaa10a8e14c70e7734f3c9ff7","https://git.kernel.org/stable/c/928ea98252ad75118950941683893cf904541da9","https://git.kernel.org/stable/c/ccd1751092341ac120a961835211f9f2e3735963"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49730
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Resolve NULL ptr dereference after an ELS LOGO is aborted
A use-after-free crash can occur after an ELS LOGO is aborted.
Specifically, a nodelist structure is freed and then
ndlp->vport->cfg_log_verbose is dereferenced in lpfc_nlp_get() when the
discovery state machine is mistakenly called a second time with
NLP_EVT_DEVICE_RM argument.
Rework lpfc_cmpl_els_logo() to prevent the duplicate calls to release a
nodelist structure. |
["https://git.kernel.org/stable/c/5e83869e29448958f8ae2c6911f350318f75e4fc","https://git.kernel.org/stable/c/b1b3440f437b75fb2a9b0cfe58df461e40eca474","https://git.kernel.org/stable/c/eea34ce23dc3a595695856dc73bb132a9c5a2902"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21714
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix implicit ODP use after free
Prevent double queueing of implicit ODP mr destroy work by using
__xa_cmpxchg() to make sure this is the only time we are destroying this
specific mr.
Without this change, we could try to invalidate this mr twice, which in
turn could result in queuing a MR work destroy twice, and eventually the
second work could execute after the MR was freed due to the first work,
causing a user after free and trace below.
refcount_t: underflow; use-after-free.
WARNING: CPU: 2 PID: 12178 at lib/refcount.c:28 refcount_warn_saturate+0x12b/0x130
Modules linked in: bonding ib_ipoib vfio_pci ip_gre geneve nf_tables ip6_gre gre ip6_tunnel tunnel6 ipip tunnel4 ib_umad rdma_ucm mlx5_vfio_pci vfio_pci_core vfio_iommu_type1 mlx5_ib vfio ib_uverbs mlx5_core iptable_raw openvswitch nsh rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay zram zsmalloc fuse [last unloaded: ib_uverbs]
CPU: 2 PID: 12178 Comm: kworker/u20:5 Not tainted 6.5.0-rc1_net_next_mlx5_58c644e #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Workqueue: events_unbound free_implicit_child_mr_work [mlx5_ib]
RIP: 0010:refcount_warn_saturate+0x12b/0x130
Code: 48 c7 c7 38 95 2a 82 c6 05 bc c6 fe 00 01 e8 0c 66 aa ff 0f 0b 5b c3 48 c7 c7 e0 94 2a 82 c6 05 a7 c6 fe 00 01 e8 f5 65 aa ff <0f> 0b 5b c3 90 8b 07 3d 00 00 00 c0 74 12 83 f8 01 74 13 8d 50 ff
RSP: 0018:ffff8881008e3e40 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000027
RDX: ffff88852c91b5c8 RSI: 0000000000000001 RDI: ffff88852c91b5c0
RBP: ffff8881dacd4e00 R08: 00000000ffffffff R09: 0000000000000019
R10: 000000000000072e R11: 0000000063666572 R12: ffff88812bfd9e00
R13: ffff8881c792d200 R14: ffff88810011c005 R15: ffff8881002099c0
FS: 0000000000000000(0000) GS:ffff88852c900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f5694b5e000 CR3: 00000001153f6003 CR4: 0000000000370ea0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
? refcount_warn_saturate+0x12b/0x130
free_implicit_child_mr_work+0x180/0x1b0 [mlx5_ib]
process_one_work+0x1cc/0x3c0
worker_thread+0x218/0x3c0
kthread+0xc6/0xf0
ret_from_fork+0x1f/0x30
</TASK> |
["https://git.kernel.org/stable/c/7cc8f681f6d4ae4478ae0f60485fc768f2b450da","https://git.kernel.org/stable/c/d3d930411ce390e532470194296658a960887773","https://git.kernel.org/stable/c/edfb65dbb9ffd3102f3ff4dd21316158e56f1976"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21739
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Fix use-after free in init error and remove paths
devm_blk_crypto_profile_init() registers a cleanup handler to run when
the associated (platform-) device is being released. For UFS, the
crypto private data and pointers are stored as part of the ufs_hba's
data structure 'struct ufs_hba::crypto_profile'. This structure is
allocated as part of the underlying ufshcd and therefore Scsi_host
allocation.
During driver release or during error handling in ufshcd_pltfrm_init(),
this structure is released as part of ufshcd_dealloc_host() before the
(platform-) device associated with the crypto call above is released.
Once this device is released, the crypto cleanup code will run, using
the just-released 'struct ufs_hba::crypto_profile'. This causes a
use-after-free situation:
Call trace:
kfree+0x60/0x2d8 (P)
kvfree+0x44/0x60
blk_crypto_profile_destroy_callback+0x28/0x70
devm_action_release+0x1c/0x30
release_nodes+0x6c/0x108
devres_release_all+0x98/0x100
device_unbind_cleanup+0x20/0x70
really_probe+0x218/0x2d0
In other words, the initialisation code flow is:
platform-device probe
ufshcd_pltfrm_init()
ufshcd_alloc_host()
scsi_host_alloc()
allocation of struct ufs_hba
creation of scsi-host devices
devm_blk_crypto_profile_init()
devm registration of cleanup handler using platform-device
and during error handling of ufshcd_pltfrm_init() or during driver
removal:
ufshcd_dealloc_host()
scsi_host_put()
put_device(scsi-host)
release of struct ufs_hba
put_device(platform-device)
crypto cleanup handler
To fix this use-after free, change ufshcd_alloc_host() to register a
devres action to automatically cleanup the underlying SCSI device on
ufshcd destruction, without requiring explicit calls to
ufshcd_dealloc_host(). This way:
* the crypto profile and all other ufs_hba-owned resources are
destroyed before SCSI (as they've been registered after)
* a memleak is plugged in tc-dwc-g210-pci.c remove() as a
side-effect
* EXPORT_SYMBOL_GPL(ufshcd_dealloc_host) can be removed fully as
it's not needed anymore
* no future drivers using ufshcd_alloc_host() could ever forget
adding the cleanup |
["https://git.kernel.org/stable/c/0c77c0d754fe83cb154715fcfec6c3faef94f207","https://git.kernel.org/stable/c/9c185beae09a3eb85f54777edafa227f7e03075d","https://git.kernel.org/stable/c/f8fb2403ddebb5eea0033d90d9daae4c88749ada"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21786
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
workqueue: Put the pwq after detaching the rescuer from the pool
The commit 68f83057b913("workqueue: Reap workers via kthread_stop() and
remove detach_completion") adds code to reap the normal workers but
mistakenly does not handle the rescuer and also removes the code waiting
for the rescuer in put_unbound_pool(), which caused a use-after-free bug
reported by Cheung Wall.
To avoid the use-after-free bug, the pool’s reference must be held until
the detachment is complete. Therefore, move the code that puts the pwq
after detaching the rescuer from the pool. |
["https://git.kernel.org/stable/c/835b69c868f53f959d4986bbecd561ba6f38e492","https://git.kernel.org/stable/c/e76946110137703c16423baf6ee177b751a34b7e","https://git.kernel.org/stable/c/e7c16028a424dd35be1064a68fa318be4359310f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53155
|
High |
fixed |
- 4.19.325
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix uninitialized value in ocfs2_file_read_iter()
Syzbot has reported the following KMSAN splat:
BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80
ocfs2_file_read_iter+0x9a4/0xf80
__io_read+0x8d4/0x20f0
io_read+0x3e/0xf0
io_issue_sqe+0x42b/0x22c0
io_wq_submit_work+0xaf9/0xdc0
io_worker_handle_work+0xd13/0x2110
io_wq_worker+0x447/0x1410
ret_from_fork+0x6f/0x90
ret_from_fork_asm+0x1a/0x30
Uninit was created at:
__alloc_pages_noprof+0x9a7/0xe00
alloc_pages_mpol_noprof+0x299/0x990
alloc_pages_noprof+0x1bf/0x1e0
allocate_slab+0x33a/0x1250
___slab_alloc+0x12ef/0x35e0
kmem_cache_alloc_bulk_noprof+0x486/0x1330
__io_alloc_req_refill+0x84/0x560
io_submit_sqes+0x172f/0x2f30
__se_sys_io_uring_enter+0x406/0x41c0
__x64_sys_io_uring_enter+0x11f/0x1a0
x64_sys_call+0x2b54/0x3ba0
do_syscall_64+0xcd/0x1e0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Since an instance of 'struct kiocb' may be passed from the block layer
with 'private' field uninitialized, introduce 'ocfs2_iocb_init_rw_locked()'
and use it from where 'ocfs2_dio_end_io()' might take care, i.e. in
'ocfs2_file_read_iter()' and 'ocfs2_file_write_iter()'. |
["https://git.kernel.org/stable/c/366c933c2ab34dd6551acc03b4872726b7605143","https://git.kernel.org/stable/c/66b7ddd1804e2c4216dd7ead8eeb746cdbb3b62f","https://git.kernel.org/stable/c/6c8f8d1e595dabd5389817f6d798cc8bd95c40ab","https://git.kernel.org/stable/c/83f8713a0ef1d55d6a287bcfadcaab8245ac5098","https://git.kernel.org/stable/c/8c966150d5abff58c3c2bdb9a6e63fd773782905","https://git.kernel.org/stable/c/8e0de82ed18ba0e71f817adbd81317fd1032ca5a","https://git.kernel.org/stable/c/adc77b19f62d7e80f98400b2fca9d700d2afdd6f","https://git.kernel.org/stable/c/dc78efe556fed162d48736ef24066f42e463e27c","https://git.kernel.org/stable/c/f4078ef38d3163e6be47403a619558b19c4bfccd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-6356
|
High |
fixed |
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver and causing kernel panic and a denial of service. |
["https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:0881","https://access.redhat.com/errata/RHSA-2024:0897","https://access.redhat.com/errata/RHSA-2024:1248","https://access.redhat.com/errata/RHSA-2024:2094","https://access.redhat.com/errata/RHSA-2024:3810","https://access.redhat.com/security/cve/CVE-2023-6356","https://bugzilla.redhat.com/show_bug.cgi?id=2254054","https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:0881","https://access.redhat.com/errata/RHSA-2024:0897","https://access.redhat.com/errata/RHSA-2024:1248","https://access.redhat.com/errata/RHSA-2024:2094","https://access.redhat.com/errata/RHSA-2024:3810","https://access.redhat.com/security/cve/CVE-2023-6356","https://bugzilla.redhat.com/show_bug.cgi?id=2254054","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://security.netapp.com/advisory/ntap-20240415-0002/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53055
|
Medium |
fixed |
- 5.15.171
- 6.1.116
- 6.6.60
- 6.11.7
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: fix 6 GHz scan construction
If more than 255 colocated APs exist for the set of all
APs found during 2.4/5 GHz scanning, then the 6 GHz scan
construction will loop forever since the loop variable
has type u8, which can never reach the number found when
that's bigger than 255, and is stored in a u32 variable.
Also move it into the loops to have a smaller scope.
Using a u32 there is fine, we limit the number of APs in
the scan list and each has a limit on the number of RNR
entries due to the frame size. With a limit of 1000 scan
results, a frame size upper bound of 4096 (really it's
more like ~2300) and a TBTT entry size of at least 11,
we get an upper bound for the number of ~372k, well in
the bounds of a u32. |
["https://git.kernel.org/stable/c/2ac15e5a8f42fed5d90ed9e1197600913678c50f","https://git.kernel.org/stable/c/2ccd5badadab2d586e91546bf5af3deda07fef1f","https://git.kernel.org/stable/c/7245012f0f496162dd95d888ed2ceb5a35170f1a","https://git.kernel.org/stable/c/cde8a7eb5c6762264ff0f4433358e0a0d250c875","https://git.kernel.org/stable/c/fc621e7a043de346c33bd7ae7e2e0c651d6152ef"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21673
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix double free of TCP_Server_Info::hostname
When shutting down the server in cifs_put_tcp_session(), cifsd thread
might be reconnecting to multiple DFS targets before it realizes it
should exit the loop, so @server->hostname can't be freed as long as
cifsd thread isn't done. Otherwise the following can happen:
RIP: 0010:__slab_free+0x223/0x3c0
Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89
1c 24 e8 fb cf 8e 00 44 8b 44 24 08 4c 8b 1c 24 e9 5f fe ff ff <0f>
0b 41 f7 45 08 00 0d 21 00 0f 85 2d ff ff ff e9 1f ff ff ff 80
RSP: 0018:ffffb26180dbfd08 EFLAGS: 00010246
RAX: ffff8ea34728e510 RBX: ffff8ea34728e500 RCX: 0000000000800068
RDX: 0000000000800068 RSI: 0000000000000000 RDI: ffff8ea340042400
RBP: ffffe112041ca380 R08: 0000000000000001 R09: 0000000000000000
R10: 6170732e31303000 R11: 70726f632e786563 R12: ffff8ea34728e500
R13: ffff8ea340042400 R14: ffff8ea34728e500 R15: 0000000000800068
FS: 0000000000000000(0000) GS:ffff8ea66fd80000(0000)
000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffc25376080 CR3: 000000012a2ba001 CR4:
PKRU: 55555554
Call Trace:
<TASK>
? show_trace_log_lvl+0x1c4/0x2df
? show_trace_log_lvl+0x1c4/0x2df
? __reconnect_target_unlocked+0x3e/0x160 [cifs]
? __die_body.cold+0x8/0xd
? die+0x2b/0x50
? do_trap+0xce/0x120
? __slab_free+0x223/0x3c0
? do_error_trap+0x65/0x80
? __slab_free+0x223/0x3c0
? exc_invalid_op+0x4e/0x70
? __slab_free+0x223/0x3c0
? asm_exc_invalid_op+0x16/0x20
? __slab_free+0x223/0x3c0
? extract_hostname+0x5c/0xa0 [cifs]
? extract_hostname+0x5c/0xa0 [cifs]
? __kmalloc+0x4b/0x140
__reconnect_target_unlocked+0x3e/0x160 [cifs]
reconnect_dfs_server+0x145/0x430 [cifs]
cifs_handle_standard+0x1ad/0x1d0 [cifs]
cifs_demultiplex_thread+0x592/0x730 [cifs]
? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs]
kthread+0xdd/0x100
? __pfx_kthread+0x10/0x10
ret_from_fork+0x29/0x50
</TASK> |
["https://git.kernel.org/stable/c/1ea68070338518a1d31ce71e6abfe1b30001b27a","https://git.kernel.org/stable/c/a2be5f2ba34d0c6d5ef2624b24e3d852561fcd6a","https://git.kernel.org/stable/c/fa2f9906a7b333ba757a7dbae0713d8a5396186e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57834
|
Medium |
fixed |
- 6.1.129
- 6.6.79
- 6.12.16
- 6.13.4
|
In the Linux kernel, the following vulnerability has been resolved:
media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread
syzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1]
If dvb->mux is not initialized successfully by vidtv_mux_init() in the
vidtv_start_streaming(), it will trigger null pointer dereference about mux
in vidtv_mux_stop_thread().
Adjust the timing of streaming initialization and check it before
stopping it.
[1]
KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f]
CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
RIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471
Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8
RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125
RDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128
RBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188
R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710
FS: 00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline]
vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252
dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000
dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486
dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559
dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline]
dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246
__fput+0x3f8/0xb60 fs/file_table.c:450
task_work_run+0x14e/0x250 kernel/task_work.c:239
get_signal+0x1d3/0x2610 kernel/signal.c:2790
arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337
exit_to_user_mode_loop kernel/entry/common.c:111 [inline]
exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]
__syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]
syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218
do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89
entry_SYSCALL_64_after_hwframe+0x77/0x7f |
["https://git.kernel.org/stable/c/1221989555db711578a327a9367f1be46500cb48","https://git.kernel.org/stable/c/2c5601b99d79d196fe4a37159e3dfb38e778ea18","https://git.kernel.org/stable/c/52d3512f9a7a52ef92864679b1e8e8aa16202c6a","https://git.kernel.org/stable/c/59a707ad952eb2ea8d59457d662b6f4138f17b08","https://git.kernel.org/stable/c/86307e443c5844f38e1b98e2c51a4195c55576cd","https://git.kernel.org/stable/c/904a8323cc8afa7eb9ce3e67303a2b3f2f787306","https://git.kernel.org/stable/c/95432a37778c9c5dd105b7b9f19e9695c9e166cf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-58005
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
tpm: Change to kvalloc() in eventlog/acpi.c
The following failure was reported on HPE ProLiant D320:
[ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0)
[ 10.848132][ T1] ------------[ cut here ]------------
[ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330
[ 10.862827][ T1] Modules linked in:
[ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375
[ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024
[ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330
[ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1
[ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246
[ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000
[ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0
The above transcript shows that ACPI pointed a 16 MiB buffer for the log
events because RSI maps to the 'order' parameter of __alloc_pages_noprof().
Address the bug by moving from devm_kmalloc() to devm_add_action() and
kvmalloc() and devm_add_action(). |
["https://git.kernel.org/stable/c/0621d2599d6e02d05c85d6bbd58eaea2f15b3503","https://git.kernel.org/stable/c/422d7f4e8d817be467986589c7968d3ea402f7da","https://git.kernel.org/stable/c/4c8bfe643bbd00b04ee8f9545ef33bf6a68c38db","https://git.kernel.org/stable/c/50365a6304a57266e8f4d3078060743c3b7a1e0d","https://git.kernel.org/stable/c/77779d1258a287f2c5c2c6aeae203e0996209c77","https://git.kernel.org/stable/c/a3a860bc0fd6c07332e4911cf9a238d20de90173","https://git.kernel.org/stable/c/a676c0401de59548a5bc1b7aaf98f556ae8ea6db"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-58076
|
Medium |
fixed |
- 5.15.179
- 6.1.129
- 6.6.78
- 6.12.14
- 6.13.3
|
In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: gcc-sm6350: Add missing parent_map for two clocks
If a clk_rcg2 has a parent, it should also have parent_map defined,
otherwise we'll get a NULL pointer dereference when calling clk_set_rate
like the following:
[ 3.388105] Call trace:
[ 3.390664] qcom_find_src_index+0x3c/0x70 (P)
[ 3.395301] qcom_find_src_index+0x1c/0x70 (L)
[ 3.399934] _freq_tbl_determine_rate+0x48/0x100
[ 3.404753] clk_rcg2_determine_rate+0x1c/0x28
[ 3.409387] clk_core_determine_round_nolock+0x58/0xe4
[ 3.421414] clk_core_round_rate_nolock+0x48/0xfc
[ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc
[ 3.444483] clk_core_set_rate_nolock+0x8c/0x300
[ 3.455886] clk_set_rate+0x38/0x14c
Add the parent_map property for two clocks where it's missing and also
un-inline the parent_data as well to keep the matching parent_map and
parent_data together. |
["https://git.kernel.org/stable/c/08b77ed7cfaac62bba51ac7a0487409ec9fcbc84","https://git.kernel.org/stable/c/175af15551ed5aa6af16ff97aff75cfffb42da21","https://git.kernel.org/stable/c/39336edd14a59dc086fb19957655e0f340bb28e8","https://git.kernel.org/stable/c/3e567032233a240b903dc11c9f18eeb3faa10ffa","https://git.kernel.org/stable/c/96fe1a7ee477d701cfc98ab9d3c730c35d966861","https://git.kernel.org/stable/c/b6fe13566bf5676b1e3b72d2a06d875733e93ee6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21707
|
Medium |
fixed |
- 6.1.129
- 6.6.76
- 6.12.13
- 6.13.2
|
In the Linux kernel, the following vulnerability has been resolved:
mptcp: consolidate suboption status
MPTCP maintains the received sub-options status is the bitmask carrying
the received suboptions and in several bitfields carrying per suboption
additional info.
Zeroing the bitmask before parsing is not enough to ensure a consistent
status, and the MPTCP code has to additionally clear some bitfiled
depending on the actually parsed suboption.
The above schema is fragile, and syzbot managed to trigger a path where
a relevant bitfield is not cleared/initialized:
BUG: KMSAN: uninit-value in __mptcp_expand_seq net/mptcp/options.c:1030 [inline]
BUG: KMSAN: uninit-value in mptcp_expand_seq net/mptcp/protocol.h:864 [inline]
BUG: KMSAN: uninit-value in ack_update_msk net/mptcp/options.c:1060 [inline]
BUG: KMSAN: uninit-value in mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209
__mptcp_expand_seq net/mptcp/options.c:1030 [inline]
mptcp_expand_seq net/mptcp/protocol.h:864 [inline]
ack_update_msk net/mptcp/options.c:1060 [inline]
mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209
tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233
tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264
tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916
tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351
ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205
ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233
NF_HOOK include/linux/netfilter.h:314 [inline]
ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254
dst_input include/net/dst.h:460 [inline]
ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447
NF_HOOK include/linux/netfilter.h:314 [inline]
ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567
__netif_receive_skb_one_core net/core/dev.c:5704 [inline]
__netif_receive_skb+0x319/0xa00 net/core/dev.c:5817
process_backlog+0x4ad/0xa50 net/core/dev.c:6149
__napi_poll+0xe7/0x980 net/core/dev.c:6902
napi_poll net/core/dev.c:6971 [inline]
net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093
handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561
__do_softirq+0x14/0x1a kernel/softirq.c:595
do_softirq+0x9a/0x100 kernel/softirq.c:462
__local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389
local_bh_enable include/linux/bottom_half.h:33 [inline]
rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]
__dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4493
dev_queue_xmit include/linux/netdevice.h:3168 [inline]
neigh_hh_output include/net/neighbour.h:523 [inline]
neigh_output include/net/neighbour.h:537 [inline]
ip_finish_output2+0x187c/0x1b70 net/ipv4/ip_output.c:236
__ip_finish_output+0x287/0x810
ip_finish_output+0x4b/0x600 net/ipv4/ip_output.c:324
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
ip_output+0x15f/0x3f0 net/ipv4/ip_output.c:434
dst_output include/net/dst.h:450 [inline]
ip_local_out net/ipv4/ip_output.c:130 [inline]
__ip_queue_xmit+0x1f2a/0x20d0 net/ipv4/ip_output.c:536
ip_queue_xmit+0x60/0x80 net/ipv4/ip_output.c:550
__tcp_transmit_skb+0x3cea/0x4900 net/ipv4/tcp_output.c:1468
tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline]
tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829
__tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012
tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618
__tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130
__mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496
mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550
mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889
mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline]
mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline]
mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline]
mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750
genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]
---truncated--- |
["https://git.kernel.org/stable/c/3a7fda57b0f91f7ea34476b165f91a92feb17c96","https://git.kernel.org/stable/c/3b5332d416d151a15742d1b16e7319368e3cc5c6","https://git.kernel.org/stable/c/6169e942370b4b6f9442d35c51519bf6c346843b","https://git.kernel.org/stable/c/7f6c72b8ef8130760710e337dc8fbe7263954884","https://git.kernel.org/stable/c/ba0518f9e8688cd4fcb569e8df2a74874b4f3894","https://git.kernel.org/stable/c/c86b000782daba926c627d2fa00c3f60a75e7472"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21711
|
Medium |
fixed |
- 6.1.129
- 6.6.76
- 6.12.13
- 6.13.2
|
In the Linux kernel, the following vulnerability has been resolved:
net/rose: prevent integer overflows in rose_setsockopt()
In case of possible unpredictably large arguments passed to
rose_setsockopt() and multiplied by extra values on top of that,
integer overflows may occur.
Do the safest minimum and fix these issues by checking the
contents of 'opt' and returning -EINVAL if they are too large. Also,
switch to unsigned int and remove useless check for negative 'opt'
in ROSE_IDLE case. |
["https://git.kernel.org/stable/c/352daa50946c3bbb662432e8daf54d6760796589","https://git.kernel.org/stable/c/4bdd449977e2364a53d0b2a5427e71beb1cd702d","https://git.kernel.org/stable/c/9bdee49ad6bbd26ab5e13cc6731e54fb1b6c1dca","https://git.kernel.org/stable/c/b8583b54455cbec2fc038fa32b6700890b369815","https://git.kernel.org/stable/c/d08f4074f9c69f7e95502587eb1b258a965ba7f0","https://git.kernel.org/stable/c/d640627663bfe7d8963c7615316d7d4ef60f3b0b","https://git.kernel.org/stable/c/e5338930a29d0ab2a5af402f5f664aeba0d1a676"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21745
|
Medium |
fixed |
- 6.1.129
- 6.6.78
- 6.12.14
- 6.13.3
|
In the Linux kernel, the following vulnerability has been resolved:
blk-cgroup: Fix class @block_class's subsystem refcount leakage
blkcg_fill_root_iostats() iterates over @block_class's devices by
class_dev_iter_(init|next)(), but does not end iterating with
class_dev_iter_exit(), so causes the class's subsystem refcount leakage.
Fix by ending the iterating with class_dev_iter_exit(). |
["https://git.kernel.org/stable/c/2ce09aabe009453d641a2ceb79e6461a2d4f3876","https://git.kernel.org/stable/c/38287f779b34dfe959b4b681e909f2d3d52b88be","https://git.kernel.org/stable/c/431b6ef2714be4d5babb802114987541a88b43b0","https://git.kernel.org/stable/c/67c7f213e052b1aa6caba4a7e25e303bc6997126","https://git.kernel.org/stable/c/993121481b5a87829f1e8163f47158b72679f309","https://git.kernel.org/stable/c/d1248436cbef1f924c04255367ff4845ccd9025e","https://git.kernel.org/stable/c/ffb494f1e7a047bd7a41b13796fcfb08fe5beafb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21779
|
Medium |
fixed |
- 6.1.129
- 6.6.79
- 6.12.16
- 6.13.4
|
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel
Advertise support for Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls if and
only if the local API is emulated/virtualized by KVM, and explicitly reject
said hypercalls if the local APIC is emulated in userspace, i.e. don't rely
on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID.
Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if
Hyper-V enlightenments are exposed to the guest without an in-kernel local
APIC:
dump_stack+0xbe/0xfd
__kasan_report.cold+0x34/0x84
kasan_report+0x3a/0x50
__apic_accept_irq+0x3a/0x5c0
kvm_hv_send_ipi.isra.0+0x34e/0x820
kvm_hv_hypercall+0x8d9/0x9d0
kvm_emulate_hypercall+0x506/0x7e0
__vmx_handle_exit+0x283/0xb60
vmx_handle_exit+0x1d/0xd0
vcpu_enter_guest+0x16b0/0x24c0
vcpu_run+0xc0/0x550
kvm_arch_vcpu_ioctl_run+0x170/0x6d0
kvm_vcpu_ioctl+0x413/0xb20
__se_sys_ioctl+0x111/0x160
do_syscal1_64+0x30/0x40
entry_SYSCALL_64_after_hwframe+0x67/0xd1
Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode
can't be modified after vCPUs are created, i.e. if one vCPU has an
in-kernel local APIC, then all vCPUs have an in-kernel local APIC. |
["https://git.kernel.org/stable/c/45fa526b0f5a34492ed0536c3cdf88b78380e4de","https://git.kernel.org/stable/c/5393cf22312418262679eaadb130d608c75fe690","https://git.kernel.org/stable/c/61224533f2b61e252b03e214195d27d64b22989a","https://git.kernel.org/stable/c/874ff13c73c45ecb38cb82191e8c1d523f0dc81b","https://git.kernel.org/stable/c/a8de7f100bb5989d9c3627d3a223ee1c863f3b69","https://git.kernel.org/stable/c/aca8be4403fb90db7adaf63830e27ebe787a76e8","https://git.kernel.org/stable/c/ca29f58ca374c40a0e69c5306fc5c940a0069074"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26767
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: fixed integer types and null check locations
[why]:
issues fixed:
- comparison with wider integer type in loop condition which can cause
infinite loops
- pointer dereference before null check |
["https://git.kernel.org/stable/c/0484e05d048b66d01d1f3c1d2306010bb57d8738","https://git.kernel.org/stable/c/070fda699dfdce560755379bc428d9edada7a54e","https://git.kernel.org/stable/c/71783d1ff65204d69207fd156d4b2eb1d3882375","https://git.kernel.org/stable/c/beea9ab9080cd2ef46296070bb327af066ee09d7","https://git.kernel.org/stable/c/0484e05d048b66d01d1f3c1d2306010bb57d8738","https://git.kernel.org/stable/c/71783d1ff65204d69207fd156d4b2eb1d3882375","https://git.kernel.org/stable/c/beea9ab9080cd2ef46296070bb327af066ee09d7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27062
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
nouveau: lock the client object tree.
It appears the client object tree has no locking unless I've missed
something else. Fix races around adding/removing client objects,
mostly vram bar mappings.
4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI
[ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27
[ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021
[ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau]
[ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 <48> 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe
[ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206
[ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58
[ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400
[ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000
[ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0
[ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007
[ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000
[ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0
[ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 4562.099544] Call Trace:
[ 4562.099555] <TASK>
[ 4562.099573] ? die_addr+0x36/0x90
[ 4562.099583] ? exc_general_protection+0x246/0x4a0
[ 4562.099593] ? asm_exc_general_protection+0x26/0x30
[ 4562.099600] ? nvkm_object_search+0x1d/0x70 [nouveau]
[ 4562.099730] nvkm_ioctl+0xa1/0x250 [nouveau]
[ 4562.099861] nvif_object_map_handle+0xc8/0x180 [nouveau]
[ 4562.099986] nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau]
[ 4562.100156] ? dma_resv_test_signaled+0x26/0xb0
[ 4562.100163] ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm]
[ 4562.100182] ? __mutex_unlock_slowpath+0x2a/0x270
[ 4562.100189] nouveau_ttm_fault+0x69/0xb0 [nouveau]
[ 4562.100356] __do_fault+0x32/0x150
[ 4562.100362] do_fault+0x7c/0x560
[ 4562.100369] __handle_mm_fault+0x800/0xc10
[ 4562.100382] handle_mm_fault+0x17c/0x3e0
[ 4562.100388] do_user_addr_fault+0x208/0x860
[ 4562.100395] exc_page_fault+0x7f/0x200
[ 4562.100402] asm_exc_page_fault+0x26/0x30
[ 4562.100412] RIP: 0033:0x9b9870
[ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 <44> 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7
[ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246
[ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000
[ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066
[ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000
[ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff
[ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 4562.100446] </TASK>
[ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink
---truncated--- |
["https://git.kernel.org/stable/c/6887314f5356389fc219b8152e951ac084a10ef7","https://git.kernel.org/stable/c/96c8751844171af4b3898fee3857ee180586f589","https://git.kernel.org/stable/c/b7cc4ff787a572edf2c55caeffaa88cd801eb135","https://git.kernel.org/stable/c/6887314f5356389fc219b8152e951ac084a10ef7","https://git.kernel.org/stable/c/96c8751844171af4b3898fee3857ee180586f589","https://git.kernel.org/stable/c/b7cc4ff787a572edf2c55caeffaa88cd801eb135"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35784
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix deadlock with fiemap and extent locking
While working on the patchset to remove extent locking I got a lockdep
splat with fiemap and pagefaulting with my new extent lock replacement
lock.
This deadlock exists with our normal code, we just don't have lockdep
annotations with the extent locking so we've never noticed it.
Since we're copying the fiemap extent to user space on every iteration
we have the chance of pagefaulting. Because we hold the extent lock for
the entire range we could mkwrite into a range in the file that we have
mmap'ed. This would deadlock with the following stack trace
[<0>] lock_extent+0x28d/0x2f0
[<0>] btrfs_page_mkwrite+0x273/0x8a0
[<0>] do_page_mkwrite+0x50/0xb0
[<0>] do_fault+0xc1/0x7b0
[<0>] __handle_mm_fault+0x2fa/0x460
[<0>] handle_mm_fault+0xa4/0x330
[<0>] do_user_addr_fault+0x1f4/0x800
[<0>] exc_page_fault+0x7c/0x1e0
[<0>] asm_exc_page_fault+0x26/0x30
[<0>] rep_movs_alternative+0x33/0x70
[<0>] _copy_to_user+0x49/0x70
[<0>] fiemap_fill_next_extent+0xc8/0x120
[<0>] emit_fiemap_extent+0x4d/0xa0
[<0>] extent_fiemap+0x7f8/0xad0
[<0>] btrfs_fiemap+0x49/0x80
[<0>] __x64_sys_ioctl+0x3e1/0xb50
[<0>] do_syscall_64+0x94/0x1a0
[<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
I wrote an fstest to reproduce this deadlock without my replacement lock
and verified that the deadlock exists with our existing locking.
To fix this simply don't take the extent lock for the entire duration of
the fiemap. This is safe in general because we keep track of where we
are when we're searching the tree, so if an ordered extent updates in
the middle of our fiemap call we'll still emit the correct extents
because we know what offset we were on before.
The only place we maintain the lock is searching delalloc. Since the
delalloc stuff can change during writeback we want to lock the extent
range so we have a consistent view of delalloc at the time we're
checking to see if we need to set the delalloc flag.
With this patch applied we no longer deadlock with my testcase. |
["https://git.kernel.org/stable/c/89bca7fe6382d61e88c67a0b0e7bce315986fb8b","https://git.kernel.org/stable/c/b0ad381fa7690244802aed119b478b4bdafc31dd","https://git.kernel.org/stable/c/ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf","https://git.kernel.org/stable/c/89bca7fe6382d61e88c67a0b0e7bce315986fb8b","https://git.kernel.org/stable/c/b0ad381fa7690244802aed119b478b4bdafc31dd","https://git.kernel.org/stable/c/ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57996
|
Medium |
fixed |
- 6.1.129
- 6.6.76
- 6.12.13
- 6.13.2
|
In the Linux kernel, the following vulnerability has been resolved:
net_sched: sch_sfq: don't allow 1 packet limit
The current implementation does not work correctly with a limit of
1. iproute2 actually checks for this and this patch adds the check in
kernel as well.
This fixes the following syzkaller reported crash:
UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:210:6
index 65535 is out of range for type 'struct sfq_head[128]'
CPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x125/0x19f lib/dump_stack.c:120
ubsan_epilogue lib/ubsan.c:148 [inline]
__ubsan_handle_out_of_bounds+0xed/0x120 lib/ubsan.c:347
sfq_link net/sched/sch_sfq.c:210 [inline]
sfq_dec+0x528/0x600 net/sched/sch_sfq.c:238
sfq_dequeue+0x39b/0x9d0 net/sched/sch_sfq.c:500
sfq_reset+0x13/0x50 net/sched/sch_sfq.c:525
qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026
tbf_reset+0x3d/0x100 net/sched/sch_tbf.c:319
qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026
dev_reset_queue+0x8c/0x140 net/sched/sch_generic.c:1296
netdev_for_each_tx_queue include/linux/netdevice.h:2350 [inline]
dev_deactivate_many+0x6dc/0xc20 net/sched/sch_generic.c:1362
__dev_close_many+0x214/0x350 net/core/dev.c:1468
dev_close_many+0x207/0x510 net/core/dev.c:1506
unregister_netdevice_many+0x40f/0x16b0 net/core/dev.c:10738
unregister_netdevice_queue+0x2be/0x310 net/core/dev.c:10695
unregister_netdevice include/linux/netdevice.h:2893 [inline]
__tun_detach+0x6b6/0x1600 drivers/net/tun.c:689
tun_detach drivers/net/tun.c:705 [inline]
tun_chr_close+0x104/0x1b0 drivers/net/tun.c:3640
__fput+0x203/0x840 fs/file_table.c:280
task_work_run+0x129/0x1b0 kernel/task_work.c:185
exit_task_work include/linux/task_work.h:33 [inline]
do_exit+0x5ce/0x2200 kernel/exit.c:931
do_group_exit+0x144/0x310 kernel/exit.c:1046
__do_sys_exit_group kernel/exit.c:1057 [inline]
__se_sys_exit_group kernel/exit.c:1055 [inline]
__x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1055
do_syscall_64+0x6c/0xd0
entry_SYSCALL_64_after_hwframe+0x61/0xcb
RIP: 0033:0x7fe5e7b52479
Code: Unable to access opcode bytes at RIP 0x7fe5e7b5244f.
RSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479
RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000
RBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0
R13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270
The crash can be also be reproduced with the following (with a tc
recompiled to allow for sfq limits of 1):
tc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s
../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1
ifconfig dummy0 up
ping -I dummy0 -f -c2 -W0.1 8.8.8.8
sleep 1
Scenario that triggers the crash:
* the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1
* TBF dequeues: it peeks from SFQ which moves the packet to the
gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so
it schedules itself for later.
* the second packet is sent and TBF tries to queues it to SFQ. qdisc
qlen is now 2 and because the SFQ limit is 1 the packet is dropped
by SFQ. At this point qlen is 1, and all of the SFQ slots are empty,
however q->tail is not NULL.
At this point, assuming no more packets are queued, when sch_dequeue
runs again it will decrement the qlen for the current empty slot
causing an underflow and the subsequent out of bounds access. |
["https://git.kernel.org/stable/c/10685681bafce6febb39770f3387621bf5d67d0b","https://git.kernel.org/stable/c/35d0137305ae2f97260a9047f445bd4434bd6cc7","https://git.kernel.org/stable/c/7d8947f2153ee9c5ab4cb17861a11cc45f30e8c4","https://git.kernel.org/stable/c/7fefc294204f10a3405f175f4ac2be16d63f135e","https://git.kernel.org/stable/c/833e9a1c27b82024db7ff5038a51651f48f05e5e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47704
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check link_res->hpo_dp_link_enc before using it
[WHAT & HOW]
Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res
without initializing hpo_dp_link_enc and it is necessary to check for
null before dereferencing.
This fixes 2 FORWARD_NULL issues reported by Coverity. |
["https://git.kernel.org/stable/c/0508a4e95ac1aefd851ceb97ea050d8abb93262c","https://git.kernel.org/stable/c/0beca868cde8742240cd0038141c30482d2b7eb8","https://git.kernel.org/stable/c/530e29452b955c30cf2102fa4d07420dc6e0c953","https://git.kernel.org/stable/c/be2ca7a2c1561390d28bf2f92654d819659ba510"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49901
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs
There are some cases, such as the one uncovered by Commit 46d4efcccc68
("drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails")
where
msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL);
is called on gpu->pdev == NULL, as the GPU device has not been fully
initialized yet.
Turns out that there's more than just the aforementioned path that
causes this to happen (e.g. the case when there's speedbin data in the
catalog, but opp-supported-hw is missing in DT).
Assigning msm_gpu->pdev earlier seems like the least painful solution
to this, therefore do so.
Patchwork: https://patchwork.freedesktop.org/patch/602742/ |
["https://git.kernel.org/stable/c/16007768551d5bfe53426645401435ca8d2ef54f","https://git.kernel.org/stable/c/9288a9676c529ad9c856096db68fad812499bc4a","https://git.kernel.org/stable/c/9773737375b20070ea935203fd66cb9fa17c5acb","https://git.kernel.org/stable/c/e8ac2060597a5768e4699bb61d604b4c09927b85"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49919
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer
This commit addresses a potential null pointer dereference issue in the
`dcn201_acquire_free_pipe_for_layer` function. The issue could occur
when `head_pipe` is null.
The fix adds a check to ensure `head_pipe` is not null before asserting
it. If `head_pipe` is null, the function returns NULL to prevent a
potential null pointer dereference.
Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed 'head_pipe' could be null (see line 1010) |
["https://git.kernel.org/stable/c/16ce8fd94da8599bb6f0496895d392a69aead1c0","https://git.kernel.org/stable/c/390d757621f5f35d11a63ed7d9d3262ead240064","https://git.kernel.org/stable/c/8a1b1655a490a492a5a6987254c935ecce4eb9de","https://git.kernel.org/stable/c/f22f4754aaa47d8c59f166ba3042182859e5dff7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49923
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags
[WHAT & HOW]
"dcn20_validate_apply_pipe_split_flags" dereferences merge, and thus it
cannot be a null pointer. Let's pass a valid pointer to avoid null
dereference.
This fixes 2 FORWARD_NULL issues reported by Coverity. |
["https://git.kernel.org/stable/c/39a580cd15397e102aaec25986ae5acf492f8930","https://git.kernel.org/stable/c/5559598742fb4538e4c51c48ef70563c49c2af23","https://git.kernel.org/stable/c/85aa996ecfaa95d1e922867390502d23ce21b905","https://git.kernel.org/stable/c/9a05270869f40c89f8d184fe2d37cb86e0d7e5f5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49926
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb()
For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is
defined as NR_CPUS instead of the number of possible cpus, this
will cause the following system panic:
smpboot: Allowing 4 CPUs, 0 hotplug CPUs
...
setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1
...
BUG: unable to handle page fault for address: ffffffff9911c8c8
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W
6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6
RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0
RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082
CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0
Call Trace:
<TASK>
? __die+0x23/0x80
? page_fault_oops+0xa4/0x180
? exc_page_fault+0x152/0x180
? asm_exc_page_fault+0x26/0x40
? rcu_tasks_need_gpcb+0x25d/0x2c0
? __pfx_rcu_tasks_kthread+0x40/0x40
rcu_tasks_one_gp+0x69/0x180
rcu_tasks_kthread+0x94/0xc0
kthread+0xe8/0x140
? __pfx_kthread+0x40/0x40
ret_from_fork+0x34/0x80
? __pfx_kthread+0x40/0x40
ret_from_fork_asm+0x1b/0x80
</TASK>
Considering that there may be holes in the CPU numbers, use the
maximum possible cpu number, instead of nr_cpu_ids, for configuring
enqueue and dequeue limits.
[ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ] |
["https://git.kernel.org/stable/c/05095271a4fb0f6497121a057f9a2edf386d5d96","https://git.kernel.org/stable/c/3104bddc666ff64b90491868bbc4c7ebdd90aedf","https://git.kernel.org/stable/c/b3b2431ed27f4ebc28e26cdf005c1de42dc60bdf","https://git.kernel.org/stable/c/fd70e9f1d85f5323096ad313ba73f5fe3d15ea41"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49987
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpftool: Fix undefined behavior in qsort(NULL, 0, ...)
When netfilter has no entry to display, qsort is called with
qsort(NULL, 0, ...). This results in undefined behavior, as UBSan
reports:
net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null
Although the C standard does not explicitly state whether calling qsort
with a NULL pointer when the size is 0 constitutes undefined behavior,
Section 7.1.4 of the C standard (Use of library functions) mentions:
"Each of the following statements applies unless explicitly stated
otherwise in the detailed descriptions that follow: If an argument to a
function has an invalid value (such as a value outside the domain of
the function, or a pointer outside the address space of the program, or
a null pointer, or a pointer to non-modifiable storage when the
corresponding parameter is not const-qualified) or a type (after
promotion) not expected by a function with variable number of
arguments, the behavior is undefined."
To avoid this, add an early return when nf_link_info is NULL to prevent
calling qsort with a NULL pointer. |
["https://git.kernel.org/stable/c/2e0f6f33f2aa87493b365a38a8fd87b8854b7734","https://git.kernel.org/stable/c/c208b02827eb642758cef65641995fd3f38c89af","https://git.kernel.org/stable/c/c2d9f9a7837ab29ccae0c42252f17d436bf0a501","https://git.kernel.org/stable/c/f04e2ad394e2755d0bb2d858ecb5598718bf00d5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49988
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: add refcnt to ksmbd_conn struct
When sending an oplock break request, opinfo->conn is used,
But freed ->conn can be used on multichannel.
This patch add a reference count to the ksmbd_conn struct
so that it can be freed when it is no longer used. |
["https://git.kernel.org/stable/c/18f06bacc197d4ac9b518ad1c69999bc3d83e7aa","https://git.kernel.org/stable/c/9fd3cde4628bcd3549ab95061f2bab74d2ed4f3b","https://git.kernel.org/stable/c/e9dac92f4482a382e8c0fe1bc243da5fc3526b0c","https://git.kernel.org/stable/c/ee426bfb9d09b29987369b897fe9b6485ac2be27"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-43098
|
Medium |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
i3c: Use i3cdev->desc->info instead of calling i3c_device_get_info() to avoid deadlock
A deadlock may happen since the i3c_master_register() acquires
&i3cbus->lock twice. See the log below.
Use i3cdev->desc->info instead of calling i3c_device_info() to
avoid acquiring the lock twice.
v2:
- Modified the title and commit message
============================================
WARNING: possible recursive locking detected
6.11.0-mainline
--------------------------------------------
init/1 is trying to acquire lock:
f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_bus_normaluse_lock
but task is already holding lock:
f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&i3cbus->lock);
lock(&i3cbus->lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by init/1:
#0: fcffff809b6798f8 (&dev->mutex){....}-{3:3}, at: __driver_attach
#1: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register
stack backtrace:
CPU: 6 UID: 0 PID: 1 Comm: init
Call trace:
dump_backtrace+0xfc/0x17c
show_stack+0x18/0x28
dump_stack_lvl+0x40/0xc0
dump_stack+0x18/0x24
print_deadlock_bug+0x388/0x390
__lock_acquire+0x18bc/0x32ec
lock_acquire+0x134/0x2b0
down_read+0x50/0x19c
i3c_bus_normaluse_lock+0x14/0x24
i3c_device_get_info+0x24/0x58
i3c_device_uevent+0x34/0xa4
dev_uevent+0x310/0x384
kobject_uevent_env+0x244/0x414
kobject_uevent+0x14/0x20
device_add+0x278/0x460
device_register+0x20/0x34
i3c_master_register_new_i3c_devs+0x78/0x154
i3c_master_register+0x6a0/0x6d4
mtk_i3c_master_probe+0x3b8/0x4d8
platform_probe+0xa0/0xe0
really_probe+0x114/0x454
__driver_probe_device+0xa0/0x15c
driver_probe_device+0x3c/0x1ac
__driver_attach+0xc4/0x1f0
bus_for_each_dev+0x104/0x160
driver_attach+0x24/0x34
bus_add_driver+0x14c/0x294
driver_register+0x68/0x104
__platform_driver_register+0x20/0x30
init_module+0x20/0xfe4
do_one_initcall+0x184/0x464
do_init_module+0x58/0x1ec
load_module+0xefc/0x10c8
__arm64_sys_finit_module+0x238/0x33c
invoke_syscall+0x58/0x10c
el0_svc_common+0xa8/0xdc
do_el0_svc+0x1c/0x28
el0_svc+0x50/0xac
el0t_64_sync_handler+0x70/0xbc
el0t_64_sync+0x1a8/0x1ac |
["https://git.kernel.org/stable/c/1f51ae217d09c361ede900b94735a6d2df6c0344","https://git.kernel.org/stable/c/2d98fa2a50b8058de52ada168fa5dbabb574711b","https://git.kernel.org/stable/c/5ac1dd51aaa0ce8b5421d1137e857955a4b6f55e","https://git.kernel.org/stable/c/6cf7b65f7029914dc0cd7db86fac9ee5159008c6","https://git.kernel.org/stable/c/816187b1833908941286e71b0041059a4acd52ed","https://git.kernel.org/stable/c/9a2173660ee53d5699744f02e6ab7bf89fcd0b1a","https://git.kernel.org/stable/c/ffe19e363c6f8b992ba835a361542568dea17409"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47143
|
Medium |
fixed |
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
dma-debug: fix a possible deadlock on radix_lock
radix_lock() shouldn't be held while holding dma_hash_entry[idx].lock
otherwise, there's a possible deadlock scenario when
dma debug API is called holding rq_lock():
CPU0 CPU1 CPU2
dma_free_attrs()
check_unmap() add_dma_entry() __schedule() //out
(A) rq_lock()
get_hash_bucket()
(A) dma_entry_hash
check_sync()
(A) radix_lock() (W) dma_entry_hash
dma_entry_free()
(W) radix_lock()
// CPU2's one
(W) rq_lock()
CPU1 situation can happen when it extending radix tree and
it tries to wake up kswapd via wake_all_kswapd().
CPU2 situation can happen while perf_event_task_sched_out()
(i.e. dma sync operation is called while deleting perf_event using
etm and etr tmc which are Arm Coresight hwtracing driver backends).
To remove this possible situation, call dma_entry_free() after
put_hash_bucket() in check_unmap(). |
["https://git.kernel.org/stable/c/3ccce34a5c3f5c9541108a451657ade621524b32","https://git.kernel.org/stable/c/7543c3e3b9b88212fcd0aaf5cab5588797bdc7de","https://git.kernel.org/stable/c/8c1b4fea8d62285f5e1a8194889b39661608bd8a","https://git.kernel.org/stable/c/c212d91070beca0d03fef7bf988baf4ff4b3eee4","https://git.kernel.org/stable/c/efe1b9bbf356357fdff0399af361133d6e3ba18e","https://git.kernel.org/stable/c/f2b95248a16c5186d1c658fc0aeb2f3bd95e5259"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57946
|
Medium |
fixed |
- 5.4.289
- 5.10.233
- 5.15.176
- 6.1.123
- 6.6.69
- 6.12.8
|
In the Linux kernel, the following vulnerability has been resolved:
virtio-blk: don't keep queue frozen during system suspend
Commit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues before
deleting vqs.") replaces queue quiesce with queue freeze in virtio-blk's
PM callbacks. And the motivation is to drain inflight IOs before suspending.
block layer's queue freeze looks very handy, but it is also easy to cause
deadlock, such as, any attempt to call into bio_queue_enter() may run into
deadlock if the queue is frozen in current context. There are all kinds
of ->suspend() called in suspend context, so keeping queue frozen in the
whole suspend context isn't one good idea. And Marek reported lockdep
warning[1] caused by virtio-blk's freeze queue in virtblk_freeze().
[1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/
Given the motivation is to drain in-flight IOs, it can be done by calling
freeze & unfreeze, meantime restore to previous behavior by keeping queue
quiesced during suspend. |
["https://git.kernel.org/stable/c/12c0ddd6c551c1e438b087f874b4f1223a75f7ea","https://git.kernel.org/stable/c/6dea8e3de59928974bf157dd0499d3958d744ae4","https://git.kernel.org/stable/c/7678abee0867e6b7fb89aa40f6e9f575f755fb37","https://git.kernel.org/stable/c/92d5139b91147ab372a17daf5dc27a5b9278e516","https://git.kernel.org/stable/c/9ca428c6397abaa8c38f5c69133a2299e1efbbf2","https://git.kernel.org/stable/c/9e323f856cf4963120e0e3892a84ef8bd764a0e4","https://git.kernel.org/stable/c/d738f3215bb4f88911ff4579780a44960c8e0ca5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44931
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
gpio: prevent potential speculation leaks in gpio_device_get_desc()
Userspace may trigger a speculative read of an address outside the gpio
descriptor array.
Users can do that by calling gpio_ioctl() with an offset out of range.
Offset is copied from user and then used as an array index to get
the gpio descriptor without sanitization in gpio_device_get_desc().
This change ensures that the offset is sanitized by using
array_index_nospec() to mitigate any possibility of speculative
information leaks.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc. |
["https://git.kernel.org/stable/c/18504710442671b02d00e6db9804a0ad26c5a479","https://git.kernel.org/stable/c/1b955f786a4bcde8c0ccb2b7d519def2acb6f3cc","https://git.kernel.org/stable/c/672c19165fc96dfad531a5458e0b3cdab414aae4","https://git.kernel.org/stable/c/9ae2d8e75b741dbcb0da374753f972410e83b5f3","https://git.kernel.org/stable/c/9d682e89c44bd5819b01f3fbb45a8e3681a4b6d0","https://git.kernel.org/stable/c/c65ab97efcd438cb4e9f299400f2ea55251f3a67","https://git.kernel.org/stable/c/d776c0486b03a5c4afca65b8ff44573592bf93bb","https://git.kernel.org/stable/c/d795848ecce24a75dfd46481aee066ae6fe39775"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46809
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check BIOS images before it is used
BIOS images may fail to load and null checks are added before they are
used.
This fixes 6 NULL_RETURNS issues reported by Coverity. |
["https://git.kernel.org/stable/c/4fcd903a5d9e897420d7d8b3ca55c6e5dbb47379","https://git.kernel.org/stable/c/8b0ddf19cca2a352b2a7e01d99d3ba949a99c84c","https://git.kernel.org/stable/c/c5cb98554c4c6265b494d040c1c62f1db2fa28a6","https://git.kernel.org/stable/c/e46b70a7cfed71cb84e985c785c39c16df5c28cb","https://git.kernel.org/stable/c/e50bec62acaeec03afc6fa5dfb2426e52d049cf5","https://git.kernel.org/stable/c/eef7301e674438913134539e77dd887960949f20"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46822
|
Medium |
fixed |
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry
In a review discussion of the changes to support vCPU hotplug where
a check was added on the GICC being enabled if was online, it was
noted that there is need to map back to the cpu and use that to index
into a cpumask. As such, a valid ID is needed.
If an MPIDR check fails in acpi_map_gic_cpu_interface() it is possible
for the entry in cpu_madt_gicc[cpu] == NULL. This function would
then cause a NULL pointer dereference. Whilst a path to trigger
this has not been established, harden this caller against the
possibility. |
["https://git.kernel.org/stable/c/2488444274c70038eb6b686cba5f1ce48ebb9cdd","https://git.kernel.org/stable/c/40cae0df42e5e7f7a1c0f32deed9c4027c1ba94e","https://git.kernel.org/stable/c/4c3b21204abb4fa3ab310fbbb5cf7f0e85f3a1bc","https://git.kernel.org/stable/c/62ca6d3a905b4c40cd942f3cc645a6718f8bc7e7","https://git.kernel.org/stable/c/945be49f4e832a9184c313fdf8917475438a795b","https://git.kernel.org/stable/c/bc7fbb37e3d2df59336eadbd6a56be632e3c7df7","https://git.kernel.org/stable/c/f57769ff6fa7f97f1296965f20e8a2bb3ee9fd0f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46832
|
Medium |
fixed |
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
MIPS: cevt-r4k: Don't call get_c0_compare_int if timer irq is installed
This avoids warning:
[ 0.118053] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283
Caused by get_c0_compare_int on secondary CPU.
We also skipped saving IRQ number to struct clock_event_device *cd as
it's never used by clockevent core, as per comments it's only meant
for "non CPU local devices". |
["https://git.kernel.org/stable/c/189d3ed3b25beee26ffe2abed278208bece13f52","https://git.kernel.org/stable/c/32ee0520159f1e8c2d6597c19690df452c528f30","https://git.kernel.org/stable/c/50f2b98dc83de7809a5c5bf0ccf9af2e75c37c13","https://git.kernel.org/stable/c/b1d2051373bfc65371ce4ac8911ed984d0178c98","https://git.kernel.org/stable/c/d3ff0f98a52f0aafe35aa314d1c442f4318be3db","https://git.kernel.org/stable/c/e6cd871627abbb459d0ff6521d6bb9cf9d9f7522"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46840
|
Medium |
fixed |
- 4.19.322
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: clean up our handling of refs == 0 in snapshot delete
In reada we BUG_ON(refs == 0), which could be unkind since we aren't
holding a lock on the extent leaf and thus could get a transient
incorrect answer. In walk_down_proc we also BUG_ON(refs == 0), which
could happen if we have extent tree corruption. Change that to return
-EUCLEAN. In do_walk_down() we catch this case and handle it correctly,
however we return -EIO, which -EUCLEAN is a more appropriate error code.
Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convert
that to proper error handling. Also adjust the error message so we can
actually do something with the information. |
["https://git.kernel.org/stable/c/03804641ec2d0da4fa088ad21c88e703d151ce16","https://git.kernel.org/stable/c/71291aa7246645ef622621934d2067400380645e","https://git.kernel.org/stable/c/728d4d045b628e006b48a448f3326a7194c88d32","https://git.kernel.org/stable/c/7d1df13bf078ffebfedd361d714ff6cee1ff01b9","https://git.kernel.org/stable/c/9cc887ac24b7a0598f4042ae9af6b9a33072f75b","https://git.kernel.org/stable/c/b8ccef048354074a548f108e51d0557d6adfd3a3","https://git.kernel.org/stable/c/c60676b81fab456b672796830f6d8057058f029c","https://git.kernel.org/stable/c/c847b28a799733b04574060ab9d00f215970627d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42079
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix NULL pointer dereference in gfs2_log_flush
In gfs2_jindex_free(), set sdp->sd_jdesc to NULL under the log flush
lock to provide exclusion against gfs2_log_flush().
In gfs2_log_flush(), check if sdp->sd_jdesc is non-NULL before
dereferencing it. Otherwise, we could run into a NULL pointer
dereference when outstanding glock work races with an unmount
(glock_work_func -> run_queue -> do_xmote -> inode_go_sync ->
gfs2_log_flush). |
["https://git.kernel.org/stable/c/3429ef5f50909cee9e498c50f0c499b9397116ce","https://git.kernel.org/stable/c/35264909e9d1973ab9aaa2a1b07cda70f12bb828","https://git.kernel.org/stable/c/f54f9d5368a4e92ede7dd078a62788dae3a7c6ef","https://git.kernel.org/stable/c/3429ef5f50909cee9e498c50f0c499b9397116ce","https://git.kernel.org/stable/c/35264909e9d1973ab9aaa2a1b07cda70f12bb828","https://git.kernel.org/stable/c/f54f9d5368a4e92ede7dd078a62788dae3a7c6ef"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50148
|
Medium |
fixed |
- 4.19.323
- 5.4.285
- 5.10.229
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: bnep: fix wild-memory-access in proto_unregister
There's issue as follows:
KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f]
CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W
RIP: 0010:proto_unregister+0xee/0x400
Call Trace:
<TASK>
__do_sys_delete_module+0x318/0x580
do_syscall_64+0xc1/0x1d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
As bnep_init() ignore bnep_sock_init()'s return value, and bnep_sock_init()
will cleanup all resource. Then when remove bnep module will call
bnep_sock_cleanup() to cleanup sock's resource.
To solve above issue just return bnep_sock_init()'s return value in
bnep_exit(). |
["https://git.kernel.org/stable/c/03015b6329e6de42f03ec917c25c4cf944f81f66","https://git.kernel.org/stable/c/20c424bc475b2b2a6e0e2225d2aae095c2ab2f41","https://git.kernel.org/stable/c/2c439470b23d78095a0d2f923342df58b155f669","https://git.kernel.org/stable/c/64a90991ba8d4e32e3173ddd83d0b24167a5668c","https://git.kernel.org/stable/c/6c151aeb6dc414db8f4daf51be072e802fae6667","https://git.kernel.org/stable/c/d10cd7bf574ead01fae140ce117a11bcdacbe6a8","https://git.kernel.org/stable/c/e232728242c4e98fb30e4c6bedb6ba8b482b6301","https://git.kernel.org/stable/c/fa58e23ea1359bd24b323916d191e2e9b4b19783"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50168
|
Medium |
fixed |
- 4.19.323
- 5.4.285
- 5.10.229
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
net/sun3_82586: fix potential memory leak in sun3_82586_send_packet()
The sun3_82586_send_packet() returns NETDEV_TX_OK without freeing skb
in case of skb->len being too long, add dev_kfree_skb() to fix it. |
["https://git.kernel.org/stable/c/137010d26dc5cd47cd62fef77cbe952d31951b7a","https://git.kernel.org/stable/c/1a17a4ac2d57102497fac53b53c666dba6a0c20d","https://git.kernel.org/stable/c/2cb3f56e827abb22c4168ad0c1bbbf401bb2f3b8","https://git.kernel.org/stable/c/6dc937a3086e344f965ca5c459f8f3eb6b68d890","https://git.kernel.org/stable/c/84f2bac74000dbb7a177d9b98a17031ec8d07ec5","https://git.kernel.org/stable/c/8d5b20fbc548650019afa96822b6a33ea4ec8aa5","https://git.kernel.org/stable/c/9c6ce55e6f0bd1541f112833006b4052614c7d94","https://git.kernel.org/stable/c/db755e55349045375c5c7036e8650afb3ff419d8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50171
|
Medium |
fixed |
- 3.16
- 4.19.323
- 5.4.285
- 5.10.229
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
net: systemport: fix potential memory leak in bcm_sysport_xmit()
The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skb
in case of dma_map_single() fails, add dev_kfree_skb() to fix it. |
["https://git.kernel.org/stable/c/31701ef0c4547973991ff63596c927f841dfd133","https://git.kernel.org/stable/c/4b70478b984af3c9d0279c121df5ff94e2533dbd","https://git.kernel.org/stable/c/533d2f30aef272dade17870a509521c3afc38a03","https://git.kernel.org/stable/c/5febfc545389805ce83d37f9f4317055b26dd7d7","https://git.kernel.org/stable/c/7d5030a819c3589cf9948b1eee397b626ec590f5","https://git.kernel.org/stable/c/8e81ce7d0166a2249deb6d5e42f28a8b8c9ea72f","https://git.kernel.org/stable/c/b6321146773dcbbc372a54dbada67e0b50e0a25c","https://git.kernel.org/stable/c/c401ed1c709948e57945485088413e1bb5e94bd1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53101
|
Medium |
fixed |
- 4.19.324
- 5.4.286
- 5.10.230
- 5.15.173
- 6.1.118
- 6.6.62
- 6.11.9
|
In the Linux kernel, the following vulnerability has been resolved:
fs: Fix uninitialized value issue in from_kuid and from_kgid
ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in
a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set.
Initialize all fields of newattrs to avoid uninitialized variables, by
checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0. |
["https://git.kernel.org/stable/c/15f34347481648a567db67fb473c23befb796af5","https://git.kernel.org/stable/c/17ecb40c5cc7755a321fb6148cba5797431ee5b8","https://git.kernel.org/stable/c/1c28bca1256aecece6e94b26b85cd07e08b0dc90","https://git.kernel.org/stable/c/1cb5bfc5bfc651982b6203c224d49b7ddacf28bc","https://git.kernel.org/stable/c/5a72b0d3497b818d8f000c347a7c11801eb27bfc","https://git.kernel.org/stable/c/9db25c2b41c34963c3ccf473b08171f87670652e","https://git.kernel.org/stable/c/a0c77e5e3dcbffc7c6080ccc89c037f0c86496cf","https://git.kernel.org/stable/c/b3e612bd8f64ce62e731e95f635e06a2efe3c80c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48808
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: fix panic when DSA master device unbinds on shutdown
Rafael reports that on a system with LX2160A and Marvell DSA switches,
if a reboot occurs while the DSA master (dpaa2-eth) is up, the following
panic can be seen:
systemd-shutdown[1]: Rebooting.
Unable to handle kernel paging request at virtual address 00a0000800000041
[00a0000800000041] address between user and kernel address ranges
Internal error: Oops: 96000004 [#1] PREEMPT SMP
CPU: 6 PID: 1 Comm: systemd-shutdow Not tainted 5.16.5-00042-g8f5585009b24 #32
pc : dsa_slave_netdevice_event+0x130/0x3e4
lr : raw_notifier_call_chain+0x50/0x6c
Call trace:
dsa_slave_netdevice_event+0x130/0x3e4
raw_notifier_call_chain+0x50/0x6c
call_netdevice_notifiers_info+0x54/0xa0
__dev_close_many+0x50/0x130
dev_close_many+0x84/0x120
unregister_netdevice_many+0x130/0x710
unregister_netdevice_queue+0x8c/0xd0
unregister_netdev+0x20/0x30
dpaa2_eth_remove+0x68/0x190
fsl_mc_driver_remove+0x20/0x5c
__device_release_driver+0x21c/0x220
device_release_driver_internal+0xac/0xb0
device_links_unbind_consumers+0xd4/0x100
__device_release_driver+0x94/0x220
device_release_driver+0x28/0x40
bus_remove_device+0x118/0x124
device_del+0x174/0x420
fsl_mc_device_remove+0x24/0x40
__fsl_mc_device_remove+0xc/0x20
device_for_each_child+0x58/0xa0
dprc_remove+0x90/0xb0
fsl_mc_driver_remove+0x20/0x5c
__device_release_driver+0x21c/0x220
device_release_driver+0x28/0x40
bus_remove_device+0x118/0x124
device_del+0x174/0x420
fsl_mc_bus_remove+0x80/0x100
fsl_mc_bus_shutdown+0xc/0x1c
platform_shutdown+0x20/0x30
device_shutdown+0x154/0x330
__do_sys_reboot+0x1cc/0x250
__arm64_sys_reboot+0x20/0x30
invoke_syscall.constprop.0+0x4c/0xe0
do_el0_svc+0x4c/0x150
el0_svc+0x24/0xb0
el0t_64_sync_handler+0xa8/0xb0
el0t_64_sync+0x178/0x17c
It can be seen from the stack trace that the problem is that the
deregistration of the master causes a dev_close(), which gets notified
as NETDEV_GOING_DOWN to dsa_slave_netdevice_event().
But dsa_switch_shutdown() has already run, and this has unregistered the
DSA slave interfaces, and yet, the NETDEV_GOING_DOWN handler attempts to
call dev_close_many() on those slave interfaces, leading to the problem.
The previous attempt to avoid the NETDEV_GOING_DOWN on the master after
dsa_switch_shutdown() was called seems improper. Unregistering the slave
interfaces is unnecessary and unhelpful. Instead, after the slaves have
stopped being uppers of the DSA master, we can now reset to NULL the
master->dsa_ptr pointer, which will make DSA start ignoring all future
notifier events on the master. |
["https://git.kernel.org/stable/c/89b60402d43cdab4387dbbf24afebda5cf092ae7","https://git.kernel.org/stable/c/ee534378f00561207656663d93907583958339ae","https://git.kernel.org/stable/c/ff45899e732e57088985e3a497b1d9100571c0f5","https://git.kernel.org/stable/c/89b60402d43cdab4387dbbf24afebda5cf092ae7","https://git.kernel.org/stable/c/ee534378f00561207656663d93907583958339ae","https://git.kernel.org/stable/c/ff45899e732e57088985e3a497b1d9100571c0f5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48846
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
block: release rq qos structures for queue without disk
blkcg_init_queue() may add rq qos structures to request queue, previously
blk_cleanup_queue() calls rq_qos_exit() to release them, but commit
8e141f9eb803 ("block: drain file system I/O on del_gendisk")
moves rq_qos_exit() into del_gendisk(), so memory leak is caused
because queues may not have disk, such as un-present scsi luns, nvme
admin queue, ...
Fixes the issue by adding rq_qos_exit() to blk_cleanup_queue() back.
BTW, v5.18 won't need this patch any more since we move
blkcg_init_queue()/blkcg_exit_queue() into disk allocation/release
handler, and patches have been in for-5.18/block. |
["https://git.kernel.org/stable/c/60c2c8e2ef3a3ec79de8cbc80a06ca0c21df8c29","https://git.kernel.org/stable/c/d4ad8736ac982111bb0be8306bf19c8207f6600e","https://git.kernel.org/stable/c/daaca3522a8e67c46e39ef09c1d542e866f85f3b","https://git.kernel.org/stable/c/60c2c8e2ef3a3ec79de8cbc80a06ca0c21df8c29","https://git.kernel.org/stable/c/d4ad8736ac982111bb0be8306bf19c8207f6600e","https://git.kernel.org/stable/c/daaca3522a8e67c46e39ef09c1d542e866f85f3b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-6932
|
High |
fixed |
|
A use-after-free vulnerability in the Linux kernel's ipv4: igmp component can be exploited to achieve local privilege escalation.
A race condition can be exploited to cause a timer be mistakenly registered on a RCU read locked object which is freed by another thread.
We recommend upgrading past commit e2b706c691905fe78468c361aaabc719d0a496f1. |
["http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=e2b706c691905fe78468c361aaabc719d0a496f1","https://kernel.dance/e2b706c691905fe78468c361aaabc719d0a496f1","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=e2b706c691905fe78468c361aaabc719d0a496f1","https://kernel.dance/e2b706c691905fe78468c361aaabc719d0a496f1","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42229
|
Medium |
fixed |
- 5.10.222
- 5.15.163
- 6.1.98
- 6.6.39
- 6.9.9
|
In the Linux kernel, the following vulnerability has been resolved:
crypto: aead,cipher - zeroize key buffer after use
I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding
cryptographic information should be zeroized once they are no longer
needed. Accomplish this by using kfree_sensitive for buffers that
previously held the private key. |
["https://git.kernel.org/stable/c/23e4099bdc3c8381992f9eb975c79196d6755210","https://git.kernel.org/stable/c/28c8d274848feba552e95c5c2a7e3cfe8f15c534","https://git.kernel.org/stable/c/71dd428615375e36523f4d4f7685ddd54113646d","https://git.kernel.org/stable/c/89b9b6fa4463daf820e6a5ef65c3b0c2db239513","https://git.kernel.org/stable/c/9db8c299a521813630fcb4154298cb60c37f3133","https://git.kernel.org/stable/c/b502d4a08875ea2b4ea5d5b28dc7c991c8b90cfb","https://git.kernel.org/stable/c/b716e9c3603ee95ed45e938fe47227d22cf3ec35","https://git.kernel.org/stable/c/f58679996a831754a356974376f248aa0af2eb8e","https://git.kernel.org/stable/c/23e4099bdc3c8381992f9eb975c79196d6755210","https://git.kernel.org/stable/c/28c8d274848feba552e95c5c2a7e3cfe8f15c534","https://git.kernel.org/stable/c/71dd428615375e36523f4d4f7685ddd54113646d","https://git.kernel.org/stable/c/9db8c299a521813630fcb4154298cb60c37f3133","https://git.kernel.org/stable/c/b502d4a08875ea2b4ea5d5b28dc7c991c8b90cfb","https://git.kernel.org/stable/c/f58679996a831754a356974376f248aa0af2eb8e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-47636
|
High |
fixed |
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
ubifs: Fix read out-of-bounds in ubifs_wbuf_write_nolock()
Function ubifs_wbuf_write_nolock() may access buf out of bounds in
following process:
ubifs_wbuf_write_nolock():
aligned_len = ALIGN(len, 8); // Assume len = 4089, aligned_len = 4096
if (aligned_len <= wbuf->avail) ... // Not satisfy
if (wbuf->used) {
ubifs_leb_write() // Fill some data in avail wbuf
len -= wbuf->avail; // len is still not 8-bytes aligned
aligned_len -= wbuf->avail;
}
n = aligned_len >> c->max_write_shift;
if (n) {
n <<= c->max_write_shift;
err = ubifs_leb_write(c, wbuf->lnum, buf + written,
wbuf->offs, n);
// n > len, read out of bounds less than 8(n-len) bytes
}
, which can be catched by KASAN:
=========================================================
BUG: KASAN: slab-out-of-bounds in ecc_sw_hamming_calculate+0x1dc/0x7d0
Read of size 4 at addr ffff888105594ff8 by task kworker/u8:4/128
Workqueue: writeback wb_workfn (flush-ubifs_0_0)
Call Trace:
kasan_report.cold+0x81/0x165
nand_write_page_swecc+0xa9/0x160
ubifs_leb_write+0xf2/0x1b0 [ubifs]
ubifs_wbuf_write_nolock+0x421/0x12c0 [ubifs]
write_head+0xdc/0x1c0 [ubifs]
ubifs_jnl_write_inode+0x627/0x960 [ubifs]
wb_workfn+0x8af/0xb80
Function ubifs_wbuf_write_nolock() accepts that parameter 'len' is not 8
bytes aligned, the 'len' represents the true length of buf (which is
allocated in 'ubifs_jnl_xxx', eg. ubifs_jnl_write_inode), so
ubifs_wbuf_write_nolock() must handle the length read from 'buf' carefully
to write leb safely.
Fetch a reproducer in [Link]. |
["https://git.kernel.org/stable/c/07a209fadee7b53b46858538e1177597273862e4","https://git.kernel.org/stable/c/3b7fb89135a20587d57f8877c02e25003e9edbdf","https://git.kernel.org/stable/c/4f2262a334641e05f645364d5ade1f565c85f20b","https://git.kernel.org/stable/c/5343575aa11c5d7044107d59d43f84aec01312b0","https://git.kernel.org/stable/c/a7054aaf1909cf40489c0ec1b728fdcf79c751a6","https://git.kernel.org/stable/c/b80ccbec0e4804436c382d7dd60e943c386ed83a","https://git.kernel.org/stable/c/e09fa5318d51f522e1af4fbaf8f74999355980c8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49551
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
usb: isp1760: Fix out-of-bounds array access
Running the driver through kasan gives an interesting splat:
BUG: KASAN: global-out-of-bounds in isp1760_register+0x180/0x70c
Read of size 20 at addr f1db2e64 by task swapper/0/1
(...)
isp1760_register from isp1760_plat_probe+0x1d8/0x220
(...)
This happens because the loop reading the regmap fields for the
different ISP1760 variants look like this:
for (i = 0; i < HC_FIELD_MAX; i++) { ... }
Meaning it expects the arrays to be at least HC_FIELD_MAX - 1 long.
However the arrays isp1760_hc_reg_fields[], isp1763_hc_reg_fields[],
isp1763_hc_volatile_ranges[] and isp1763_dc_volatile_ranges[] are
dynamically sized during compilation.
Fix this by putting an empty assignment to the [HC_FIELD_MAX]
and [DC_FIELD_MAX] array member at the end of each array.
This will make the array one member longer than it needs to be,
but avoids the risk of overwriting whatever is inside
[HC_FIELD_MAX - 1] and is simple and intuitive to read. Also
add comments explaining what is going on. |
["https://git.kernel.org/stable/c/26ae2c942b5702f2e43d36b2a4389cfb7d616b6a","https://git.kernel.org/stable/c/463bddd3ff1acf4036ddb80c34a715eb99debf46","https://git.kernel.org/stable/c/47d39cb57e8669e507d17d9e0d067d2b3e3a87ae","https://git.kernel.org/stable/c/bf2558bbdce3ab1d6bcba09f354914e4515d0a2b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49623
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
powerpc/xive/spapr: correct bitmap allocation size
kasan detects access beyond the end of the xibm->bitmap allocation:
BUG: KASAN: slab-out-of-bounds in _find_first_zero_bit+0x40/0x140
Read of size 8 at addr c00000001d1d0118 by task swapper/0/1
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28
Call Trace:
[c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable)
[c00000001d98f7b0] [c00000000068faac] print_report+0x37c/0x710
[c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354
[c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0
[c00000001d98f970] [c0000000011c6ed0] _find_first_zero_bit+0x40/0x140
[c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260
[c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450
[c00000001d98fb30] [c000000004032a20] pSeries_smp_probe+0x5c/0x118
[c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac
[c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640
[c00000001d98fd90] [c0000000000131e8] kernel_init+0x28/0x1d0
[c00000001d98fe10] [c00000000000cd54] ret_from_kernel_thread+0x5c/0x64
Allocated by task 0:
kasan_save_stack+0x34/0x70
__kasan_kmalloc+0xb4/0xf0
__kmalloc+0x268/0x540
xive_spapr_init+0x4d0/0x77c
pseries_init_irq+0x40/0x27c
init_IRQ+0x44/0x84
start_kernel+0x2a4/0x538
start_here_common+0x1c/0x20
The buggy address belongs to the object at c00000001d1d0118
which belongs to the cache kmalloc-8 of size 8
The buggy address is located 0 bytes inside of
8-byte region [c00000001d1d0118, c00000001d1d0120)
The buggy address belongs to the physical page:
page:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558 pfn:0x1d1d
flags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff)
raw: 007ffff000000200 c00000001d0003c8 c00000001d0003c8 c00000001d010480
raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
c00000001d1d0000: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
c00000001d1d0080: fc fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc
>c00000001d1d0100: fc fc fc 02 fc fc fc fc fc fc fc fc fc fc fc fc
^
c00000001d1d0180: fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc
c00000001d1d0200: fc fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc
This happens because the allocation uses the wrong unit (bits) when it
should pass (BITS_TO_LONGS(count) * sizeof(long)) or equivalent. With small
numbers of bits, the allocated object can be smaller than sizeof(long),
which results in invalid accesses.
Use bitmap_zalloc() to allocate and initialize the irq bitmap, paired with
bitmap_free() for consistency. |
["https://git.kernel.org/stable/c/10f2cd373e65bcd3be8f3cdc71c330c25763dfd8","https://git.kernel.org/stable/c/19fc5bb93c6bbdce8292b4d7eed04e2fa118d2fe","https://git.kernel.org/stable/c/99d1c36bddd93919072b5a51a89297bbb5ad6a6f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57982
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
xfrm: state: fix out-of-bounds read during lookup
lookup and resize can run in parallel.
The xfrm_state_hash_generation seqlock ensures a retry, but the hash
functions can observe a hmask value that is too large for the new hlist
array.
rehash does:
rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..]
net->xfrm.state_hmask = nhashmask;
While state lookup does:
h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family);
hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) {
This is only safe in case the update to state_bydst is larger than
net->xfrm.xfrm_state_hmask (or if the lookup function gets
serialized via state spinlock again).
Fix this by prefetching state_hmask and the associated pointers.
The xfrm_state_hash_generation seqlock retry will ensure that the pointer
and the hmask will be consistent.
The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side,
add lockdep assertions to document that they are only safe for insert
side.
xfrm_state_lookup_byaddr() uses the spinlock rather than RCU.
AFAICS this is an oversight from back when state lookup was converted to
RCU, this lock should be replaced with RCU in a future patch. |
["https://git.kernel.org/stable/c/a16871c7832ea6435abb6e0b58289ae7dcb7e4fc","https://git.kernel.org/stable/c/dd4c2a174994238d55ab54da2545543d36f4e0d0","https://git.kernel.org/stable/c/e952837f3ddb0ff726d5b582aa1aad9aa38d024d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26865
|
High |
fixed |
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
rds: tcp: Fix use-after-free of net in reqsk_timer_handler().
syzkaller reported a warning of netns tracker [0] followed by KASAN
splat [1] and another ref tracker warning [1].
syzkaller could not find a repro, but in the log, the only suspicious
sequence was as follows:
18:26:22 executing program 1:
r0 = socket$inet6_mptcp(0xa, 0x1, 0x106)
...
connect$inet6(r0, &(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async)
The notable thing here is 0x4001 in connect(), which is RDS_TCP_PORT.
So, the scenario would be:
1. unshare(CLONE_NEWNET) creates a per netns tcp listener in
rds_tcp_listen_init().
2. syz-executor connect()s to it and creates a reqsk.
3. syz-executor exit()s immediately.
4. netns is dismantled. [0]
5. reqsk timer is fired, and UAF happens while freeing reqsk. [1]
6. listener is freed after RCU grace period. [2]
Basically, reqsk assumes that the listener guarantees netns safety
until all reqsk timers are expired by holding the listener's refcount.
However, this was not the case for kernel sockets.
Commit 740ea3c4a0b2 ("tcp: Clean up kernel listener's reqsk in
inet_twsk_purge()") fixed this issue only for per-netns ehash.
Let's apply the same fix for the global ehash.
[0]:
ref_tracker: net notrefcnt@0000000065449cc3 has 1/1 users at
sk_alloc (./include/net/net_namespace.h:337 net/core/sock.c:2146)
inet6_create (net/ipv6/af_inet6.c:192 net/ipv6/af_inet6.c:119)
__sock_create (net/socket.c:1572)
rds_tcp_listen_init (net/rds/tcp_listen.c:279)
rds_tcp_init_net (net/rds/tcp.c:577)
ops_init (net/core/net_namespace.c:137)
setup_net (net/core/net_namespace.c:340)
copy_net_ns (net/core/net_namespace.c:497)
create_new_namespaces (kernel/nsproxy.c:110)
unshare_nsproxy_namespaces (kernel/nsproxy.c:228 (discriminator 4))
ksys_unshare (kernel/fork.c:3429)
__x64_sys_unshare (kernel/fork.c:3496)
do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
...
WARNING: CPU: 0 PID: 27 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)
[1]:
BUG: KASAN: slab-use-after-free in inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)
Read of size 8 at addr ffff88801b370400 by task swapper/0/0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Call Trace:
<IRQ>
dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1))
print_report (mm/kasan/report.c:378 mm/kasan/report.c:488)
kasan_report (mm/kasan/report.c:603)
inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)
reqsk_timer_handler (net/ipv4/inet_connection_sock.c:979 net/ipv4/inet_connection_sock.c:1092)
call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701)
__run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2038)
run_timer_softirq (kernel/time/timer.c:2053)
__do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554)
irq_exit_rcu (kernel/softirq.c:427 kernel/softirq.c:632 kernel/softirq.c:644)
sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1076 (discriminator 14))
</IRQ>
Allocated by task 258 on cpu 0 at 83.612050s:
kasan_save_stack (mm/kasan/common.c:48)
kasan_save_track (mm/kasan/common.c:68)
__kasan_slab_alloc (mm/kasan/common.c:343)
kmem_cache_alloc (mm/slub.c:3813 mm/slub.c:3860 mm/slub.c:3867)
copy_net_ns (./include/linux/slab.h:701 net/core/net_namespace.c:421 net/core/net_namespace.c:480)
create_new_namespaces (kernel/nsproxy.c:110)
unshare_nsproxy_name
---truncated--- |
["https://git.kernel.org/stable/c/1e9fd5cf8d7f487332560f7bb312fc7d416817f3","https://git.kernel.org/stable/c/2a750d6a5b365265dbda33330a6188547ddb5c24","https://git.kernel.org/stable/c/9905a157048f441f1412e7bd13372f4a971d75c6","https://git.kernel.org/stable/c/9ceac040506a05a30b104b2aa2e9146810704500","https://git.kernel.org/stable/c/f901ee07853ce97e9f1104c7c898fbbe447f0279","https://git.kernel.org/stable/c/1e9fd5cf8d7f487332560f7bb312fc7d416817f3","https://git.kernel.org/stable/c/2a750d6a5b365265dbda33330a6188547ddb5c24","https://git.kernel.org/stable/c/9905a157048f441f1412e7bd13372f4a971d75c6","https://git.kernel.org/stable/c/9ceac040506a05a30b104b2aa2e9146810704500","https://git.kernel.org/stable/c/f901ee07853ce97e9f1104c7c898fbbe447f0279"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-47656
|
High |
fixed |
- 4.9.311
- 4.14.276
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
jffs2: fix use-after-free in jffs2_clear_xattr_subsystem
When we mount a jffs2 image, assume that the first few blocks of
the image are normal and contain at least one xattr-related inode,
but the next block is abnormal. As a result, an error is returned
in jffs2_scan_eraseblock(). jffs2_clear_xattr_subsystem() is then
called in jffs2_build_filesystem() and then again in
jffs2_do_fill_super().
Finally we can observe the following report:
==================================================================
BUG: KASAN: use-after-free in jffs2_clear_xattr_subsystem+0x95/0x6ac
Read of size 8 at addr ffff8881243384e0 by task mount/719
Call Trace:
dump_stack+0x115/0x16b
jffs2_clear_xattr_subsystem+0x95/0x6ac
jffs2_do_fill_super+0x84f/0xc30
jffs2_fill_super+0x2ea/0x4c0
mtd_get_sb+0x254/0x400
mtd_get_sb_by_nr+0x4f/0xd0
get_tree_mtd+0x498/0x840
jffs2_get_tree+0x25/0x30
vfs_get_tree+0x8d/0x2e0
path_mount+0x50f/0x1e50
do_mount+0x107/0x130
__se_sys_mount+0x1c5/0x2f0
__x64_sys_mount+0xc7/0x160
do_syscall_64+0x45/0x70
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Allocated by task 719:
kasan_save_stack+0x23/0x60
__kasan_kmalloc.constprop.0+0x10b/0x120
kasan_slab_alloc+0x12/0x20
kmem_cache_alloc+0x1c0/0x870
jffs2_alloc_xattr_ref+0x2f/0xa0
jffs2_scan_medium.cold+0x3713/0x4794
jffs2_do_mount_fs.cold+0xa7/0x2253
jffs2_do_fill_super+0x383/0xc30
jffs2_fill_super+0x2ea/0x4c0
[...]
Freed by task 719:
kmem_cache_free+0xcc/0x7b0
jffs2_free_xattr_ref+0x78/0x98
jffs2_clear_xattr_subsystem+0xa1/0x6ac
jffs2_do_mount_fs.cold+0x5e6/0x2253
jffs2_do_fill_super+0x383/0xc30
jffs2_fill_super+0x2ea/0x4c0
[...]
The buggy address belongs to the object at ffff8881243384b8
which belongs to the cache jffs2_xattr_ref of size 48
The buggy address is located 40 bytes inside of
48-byte region [ffff8881243384b8, ffff8881243384e8)
[...]
==================================================================
The triggering of the BUG is shown in the following stack:
-----------------------------------------------------------
jffs2_fill_super
jffs2_do_fill_super
jffs2_do_mount_fs
jffs2_build_filesystem
jffs2_scan_medium
jffs2_scan_eraseblock <--- ERROR
jffs2_clear_xattr_subsystem <--- free
jffs2_clear_xattr_subsystem <--- free again
-----------------------------------------------------------
An error is returned in jffs2_do_mount_fs(). If the error is returned
by jffs2_sum_init(), the jffs2_clear_xattr_subsystem() does not need to
be executed. If the error is returned by jffs2_build_filesystem(), the
jffs2_clear_xattr_subsystem() also does not need to be executed again.
So move jffs2_clear_xattr_subsystem() from 'out_inohash' to 'out_root'
to fix this UAF problem. |
["https://git.kernel.org/stable/c/22327bd7988f21de3a53c1373f3b81542bfe1f44","https://git.kernel.org/stable/c/30bf7244acf32f19cb722c39f7bc1c2a9f300422","https://git.kernel.org/stable/c/3bd2454162ec6bbb5503233c804fce6e4b6dcec5","https://git.kernel.org/stable/c/4c7c44ee1650677fbe89d86edbad9497b7679b5c","https://git.kernel.org/stable/c/7a75740206af5f17e9f3efa384211cba70213da1","https://git.kernel.org/stable/c/7bb7428dd73991bf4b3a7a61b493ca50046c2b13","https://git.kernel.org/stable/c/8c0f024f29e055840a5a89fe23b96ae3f921afed","https://git.kernel.org/stable/c/9150cb625b46f68d524f4cfd491f1aafc23e10a9","https://git.kernel.org/stable/c/c3b07c875fa8f906f932976460fd14798596f101"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49111
|
High |
fixed |
- 4.9.311
- 4.14.276
- 4.19.238
- 5.4.189
- 5.10.111
- 5.15.34
- 5.16.20
- 5.17.3
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix use after free in hci_send_acl
This fixes the following trace caused by receiving
HCI_EV_DISCONN_PHY_LINK_COMPLETE which does call hci_conn_del without
first checking if conn->type is in fact AMP_LINK and in case it is
do properly cleanup upper layers with hci_disconn_cfm:
==================================================================
BUG: KASAN: use-after-free in hci_send_acl+0xaba/0xc50
Read of size 8 at addr ffff88800e404818 by task bluetoothd/142
CPU: 0 PID: 142 Comm: bluetoothd Not tainted
5.17.0-rc5-00006-gda4022eeac1a #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x45/0x59
print_address_description.constprop.0+0x1f/0x150
kasan_report.cold+0x7f/0x11b
hci_send_acl+0xaba/0xc50
l2cap_do_send+0x23f/0x3d0
l2cap_chan_send+0xc06/0x2cc0
l2cap_sock_sendmsg+0x201/0x2b0
sock_sendmsg+0xdc/0x110
sock_write_iter+0x20f/0x370
do_iter_readv_writev+0x343/0x690
do_iter_write+0x132/0x640
vfs_writev+0x198/0x570
do_writev+0x202/0x280
do_syscall_64+0x38/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
RSP: 002b:00007ffce8a099b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3
0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 14 00 00 00 0f 05
<48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10
RDX: 0000000000000001 RSI: 00007ffce8a099e0 RDI: 0000000000000015
RAX: ffffffffffffffda RBX: 00007ffce8a099e0 RCX: 00007f788fc3cf77
R10: 00007ffce8af7080 R11: 0000000000000246 R12: 000055e4ccf75580
RBP: 0000000000000015 R08: 0000000000000002 R09: 0000000000000001
</TASK>
R13: 000055e4ccf754a0 R14: 000055e4ccf75cd0 R15: 000055e4ccf4a6b0
Allocated by task 45:
kasan_save_stack+0x1e/0x40
__kasan_kmalloc+0x81/0xa0
hci_chan_create+0x9a/0x2f0
l2cap_conn_add.part.0+0x1a/0xdc0
l2cap_connect_cfm+0x236/0x1000
le_conn_complete_evt+0x15a7/0x1db0
hci_le_conn_complete_evt+0x226/0x2c0
hci_le_meta_evt+0x247/0x450
hci_event_packet+0x61b/0xe90
hci_rx_work+0x4d5/0xc50
process_one_work+0x8fb/0x15a0
worker_thread+0x576/0x1240
kthread+0x29d/0x340
ret_from_fork+0x1f/0x30
Freed by task 45:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
kasan_set_free_info+0x20/0x30
__kasan_slab_free+0xfb/0x130
kfree+0xac/0x350
hci_conn_cleanup+0x101/0x6a0
hci_conn_del+0x27e/0x6c0
hci_disconn_phylink_complete_evt+0xe0/0x120
hci_event_packet+0x812/0xe90
hci_rx_work+0x4d5/0xc50
process_one_work+0x8fb/0x15a0
worker_thread+0x576/0x1240
kthread+0x29d/0x340
ret_from_fork+0x1f/0x30
The buggy address belongs to the object at ffff88800c0f0500
The buggy address is located 24 bytes inside of
which belongs to the cache kmalloc-128 of size 128
The buggy address belongs to the page:
128-byte region [ffff88800c0f0500, ffff88800c0f0580)
flags: 0x100000000000200(slab|node=0|zone=1)
page:00000000fe45cd86 refcount:1 mapcount:0
mapping:0000000000000000 index:0x0 pfn:0xc0f0
raw: 0000000000000000 0000000080100010 00000001ffffffff
0000000000000000
raw: 0100000000000200 ffffea00003a2c80 dead000000000004
ffff8880078418c0
page dumped because: kasan: bad access detected
ffff88800c0f0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc
Memory state around the buggy address:
>ffff88800c0f0500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88800c0f0480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88800c0f0580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
---truncated--- |
["https://git.kernel.org/stable/c/2cc803804ec9a296b3156855d6c8c4ca1c6b84be","https://git.kernel.org/stable/c/3803d896ddd97c7c16689a5381c0960040727647","https://git.kernel.org/stable/c/4da302b90b96c309987eb9b37c8547f939f042d2","https://git.kernel.org/stable/c/643a6c26bd32e339d00ad97b8822b6db009e803c","https://git.kernel.org/stable/c/684e505406abaeabe0058e9776f9210bf2747953","https://git.kernel.org/stable/c/b3c2ea1fd444b3bb7b82bfd2c3a45418f85c2502","https://git.kernel.org/stable/c/c41de54b0a963e59e4dd04c029a4a6d73f45ef9c","https://git.kernel.org/stable/c/d404765dffdbd8dcd14758695d0c96c52fb2e624","https://git.kernel.org/stable/c/f63d24baff787e13b723d86fe036f84bdbc35045"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49275
|
High |
fixed |
- 4.9.324
- 4.14.289
- 4.19.253
- 5.4.207
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
can: m_can: m_can_tx_handler(): fix use after free of skb
can_put_echo_skb() will clone skb then free the skb. Move the
can_put_echo_skb() for the m_can version 3.0.x directly before the
start of the xmit in hardware, similar to the 3.1.x branch. |
["https://git.kernel.org/stable/c/08d90846e438ac22dc56fc49ec0b0d195831c5ed","https://git.kernel.org/stable/c/2e8e79c416aae1de224c0f1860f2e3350fa171f8","https://git.kernel.org/stable/c/31417073493f302d26ab66b3abc098d43227b835","https://git.kernel.org/stable/c/4db7d6f481990dd179a9ee7126dc7aa31ea4fff3","https://git.kernel.org/stable/c/7728d937ec403a1ceff9483023252d2cb8777f81","https://git.kernel.org/stable/c/869016a2938ac44f7b2fb7fc22c89edad99eb9b3","https://git.kernel.org/stable/c/d3892a747ab16b1eb6593a19d29f62c3b3f020ac","https://git.kernel.org/stable/c/d93ed9aff64968f4cdad690712eb4f48ae537bde","https://git.kernel.org/stable/c/f43e64076ff1b1dcb893fb77ad1204105f710a29"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49416
|
High |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix use-after-free in chanctx code
In ieee80211_vif_use_reserved_context(), when we have an
old context and the new context's replace_state is set to
IEEE80211_CHANCTX_REPLACE_NONE, we free the old context
in ieee80211_vif_use_reserved_reassign(). Therefore, we
cannot check the old_ctx anymore, so we should set it to
NULL after this point.
However, since the new_ctx replace state is clearly not
IEEE80211_CHANCTX_REPLACES_OTHER, we're not going to do
anything else in this function and can just return to
avoid accessing the freed old_ctx. |
["https://git.kernel.org/stable/c/265bec4779a38b65e86a25120370f200822dfa76","https://git.kernel.org/stable/c/2965c4cdf7ad9ce0796fac5e57debb9519ea721e","https://git.kernel.org/stable/c/4ba81e794f0fad6234f644c2da1ae14d5b95e1c4","https://git.kernel.org/stable/c/4f05a9e15edcdf5b97e0d86ab6ecd5f187289f6c","https://git.kernel.org/stable/c/6118bbdf69f4718b02d26bbcf2e497eb66004331","https://git.kernel.org/stable/c/82c8e7bbdd06c7ed58e22450cc5b37f33a25bb2c","https://git.kernel.org/stable/c/88cc8f963febe192d6ded9df7217f92f380b449a","https://git.kernel.org/stable/c/9f1e5cc85ad77e52f54049a94db0407445ae2a34","https://git.kernel.org/stable/c/b79110f2bf6022e60e590d2e094728a8eec3e79e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49474
|
High |
fixed |
- 4.5
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.14
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: fix dangling sco_conn and use-after-free in sco_sock_timeout
Connecting the same socket twice consecutively in sco_sock_connect()
could lead to a race condition where two sco_conn objects are created
but only one is associated with the socket. If the socket is closed
before the SCO connection is established, the timer associated with the
dangling sco_conn object won't be canceled. As the sock object is being
freed, the use-after-free problem happens when the timer callback
function sco_sock_timeout() accesses the socket. Here's the call trace:
dump_stack+0x107/0x163
? refcount_inc+0x1c/
print_address_description.constprop.0+0x1c/0x47e
? refcount_inc+0x1c/0x7b
kasan_report+0x13a/0x173
? refcount_inc+0x1c/0x7b
check_memory_region+0x132/0x139
refcount_inc+0x1c/0x7b
sco_sock_timeout+0xb2/0x1ba
process_one_work+0x739/0xbd1
? cancel_delayed_work+0x13f/0x13f
? __raw_spin_lock_init+0xf0/0xf0
? to_kthread+0x59/0x85
worker_thread+0x593/0x70e
kthread+0x346/0x35a
? drain_workqueue+0x31a/0x31a
? kthread_bind+0x4b/0x4b
ret_from_fork+0x1f/0x30 |
["https://git.kernel.org/stable/c/36c644c63bfcaee2d3a426f45e89a9cd09799318","https://git.kernel.org/stable/c/390d82733a953c1fabf3de9c9618091a7a9c90a6","https://git.kernel.org/stable/c/537f619dea4e3fa8ed1f8f938abffe3615794bcc","https://git.kernel.org/stable/c/65d347cb39e2e6bd0c2a745ad7c928998ebb0162","https://git.kernel.org/stable/c/6f55fac0af3531cf60d11369454c41f5fc81ab3f","https://git.kernel.org/stable/c/7aa1e7d15f8a5b65f67bacb100d8fc033b21efa2","https://git.kernel.org/stable/c/7d61dbd7311ab978d8ddac1749a758de4de00374","https://git.kernel.org/stable/c/99df16007f4bbf9abfc3478cb17d10f0d7f8906e","https://git.kernel.org/stable/c/9de3dc09e56f8deacd2bdbf4cecb71e11a312405"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49478
|
High |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
media: pvrusb2: fix array-index-out-of-bounds in pvr2_i2c_core_init
Syzbot reported that -1 is used as array index. The problem was in
missing validation check.
hdw->unit_number is initialized with -1 and then if init table walk fails
this value remains unchanged. Since code blindly uses this member for
array indexing adding sanity check is the easiest fix for that.
hdw->workpoll initialization moved upper to prevent warning in
__flush_work. |
["https://git.kernel.org/stable/c/1310fc3538dcc375a2f46ef0a438512c2ca32827","https://git.kernel.org/stable/c/24e807541e4a9263ed928e6ae3498de3ad43bd1e","https://git.kernel.org/stable/c/2e004fe914b243db41fa96f9e583385f360ea58e","https://git.kernel.org/stable/c/3309c2c574e13b21b44729f5bdbf21f60189b79a","https://git.kernel.org/stable/c/4351bfe36aba9fa7dc9d68d498d25d41a0f45e67","https://git.kernel.org/stable/c/471bec68457aaf981add77b4f590d65dd7da1059","https://git.kernel.org/stable/c/a3304766d9384886e6d3092c776273526947a2e9","https://git.kernel.org/stable/c/a3660e06675bccec4bf149c7229ea1d491ba10d7","https://git.kernel.org/stable/c/f99a8b1ec0eddc2931aeaa4f490277a15b39f511"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49493
|
High |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: rt5645: Fix errorenous cleanup order
There is a logic error when removing rt5645 device as the function
rt5645_i2c_remove() first cancel the &rt5645->jack_detect_work and
delete the &rt5645->btn_check_timer latter. However, since the timer
handler rt5645_btn_check_callback() will re-queue the jack_detect_work,
this cleanup order is buggy.
That is, once the del_timer_sync in rt5645_i2c_remove is concurrently
run with the rt5645_btn_check_callback, the canceled jack_detect_work
will be rescheduled again, leading to possible use-after-free.
This patch fix the issue by placing the del_timer_sync function before
the cancel_delayed_work_sync. |
["https://git.kernel.org/stable/c/061a6159cea583f1155f67d1915917a6b9282662","https://git.kernel.org/stable/c/0941150100173d4eaf3fe08ff4b16740e7c3026f","https://git.kernel.org/stable/c/1a5a3dfd9f172dcb115072f0aea5e27d3083c20e","https://git.kernel.org/stable/c/236d29c5857f02e0a53fdf15d3dce1536c4322ce","https://git.kernel.org/stable/c/2def44d3aec59e38d2701c568d65540783f90f2f","https://git.kernel.org/stable/c/453f0920ffc1a28e28ddb9c3cd5562472b2895b0","https://git.kernel.org/stable/c/7d801e807536a9a9c2146c5f4a5836f154517ed3","https://git.kernel.org/stable/c/88c09e4812d72c3153afc8e5a45ecac2d0eae3ff","https://git.kernel.org/stable/c/abe7554da62cb489712a54de69ef5665c250e564"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49505
|
High |
fixed |
- 4.5
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
NFC: NULL out the dev->rfkill to prevent UAF
Commit 3e3b5dfcd16a ("NFC: reorder the logic in nfc_{un,}register_device")
assumes the device_is_registered() in function nfc_dev_up() will help
to check when the rfkill is unregistered. However, this check only
take effect when device_del(&dev->dev) is done in nfc_unregister_device().
Hence, the rfkill object is still possible be dereferenced.
The crash trace in latest kernel (5.18-rc2):
[ 68.760105] ==================================================================
[ 68.760330] BUG: KASAN: use-after-free in __lock_acquire+0x3ec1/0x6750
[ 68.760756] Read of size 8 at addr ffff888009c93018 by task fuzz/313
[ 68.760756]
[ 68.760756] CPU: 0 PID: 313 Comm: fuzz Not tainted 5.18.0-rc2 #4
[ 68.760756] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 68.760756] Call Trace:
[ 68.760756] <TASK>
[ 68.760756] dump_stack_lvl+0x57/0x7d
[ 68.760756] print_report.cold+0x5e/0x5db
[ 68.760756] ? __lock_acquire+0x3ec1/0x6750
[ 68.760756] kasan_report+0xbe/0x1c0
[ 68.760756] ? __lock_acquire+0x3ec1/0x6750
[ 68.760756] __lock_acquire+0x3ec1/0x6750
[ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410
[ 68.760756] ? register_lock_class+0x18d0/0x18d0
[ 68.760756] lock_acquire+0x1ac/0x4f0
[ 68.760756] ? rfkill_blocked+0xe/0x60
[ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410
[ 68.760756] ? mutex_lock_io_nested+0x12c0/0x12c0
[ 68.760756] ? nla_get_range_signed+0x540/0x540
[ 68.760756] ? _raw_spin_lock_irqsave+0x4e/0x50
[ 68.760756] _raw_spin_lock_irqsave+0x39/0x50
[ 68.760756] ? rfkill_blocked+0xe/0x60
[ 68.760756] rfkill_blocked+0xe/0x60
[ 68.760756] nfc_dev_up+0x84/0x260
[ 68.760756] nfc_genl_dev_up+0x90/0xe0
[ 68.760756] genl_family_rcv_msg_doit+0x1f4/0x2f0
[ 68.760756] ? genl_family_rcv_msg_attrs_parse.constprop.0+0x230/0x230
[ 68.760756] ? security_capable+0x51/0x90
[ 68.760756] genl_rcv_msg+0x280/0x500
[ 68.760756] ? genl_get_cmd+0x3c0/0x3c0
[ 68.760756] ? lock_acquire+0x1ac/0x4f0
[ 68.760756] ? nfc_genl_dev_down+0xe0/0xe0
[ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410
[ 68.760756] netlink_rcv_skb+0x11b/0x340
[ 68.760756] ? genl_get_cmd+0x3c0/0x3c0
[ 68.760756] ? netlink_ack+0x9c0/0x9c0
[ 68.760756] ? netlink_deliver_tap+0x136/0xb00
[ 68.760756] genl_rcv+0x1f/0x30
[ 68.760756] netlink_unicast+0x430/0x710
[ 68.760756] ? memset+0x20/0x40
[ 68.760756] ? netlink_attachskb+0x740/0x740
[ 68.760756] ? __build_skb_around+0x1f4/0x2a0
[ 68.760756] netlink_sendmsg+0x75d/0xc00
[ 68.760756] ? netlink_unicast+0x710/0x710
[ 68.760756] ? netlink_unicast+0x710/0x710
[ 68.760756] sock_sendmsg+0xdf/0x110
[ 68.760756] __sys_sendto+0x19e/0x270
[ 68.760756] ? __ia32_sys_getpeername+0xa0/0xa0
[ 68.760756] ? fd_install+0x178/0x4c0
[ 68.760756] ? fd_install+0x195/0x4c0
[ 68.760756] ? kernel_fpu_begin_mask+0x1c0/0x1c0
[ 68.760756] __x64_sys_sendto+0xd8/0x1b0
[ 68.760756] ? lockdep_hardirqs_on+0xbf/0x130
[ 68.760756] ? syscall_enter_from_user_mode+0x1d/0x50
[ 68.760756] do_syscall_64+0x3b/0x90
[ 68.760756] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 68.760756] RIP: 0033:0x7f67fb50e6b3
...
[ 68.760756] RSP: 002b:00007f67fa91fe90 EFLAGS: 00000293 ORIG_RAX: 000000000000002c
[ 68.760756] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f67fb50e6b3
[ 68.760756] RDX: 000000000000001c RSI: 0000559354603090 RDI: 0000000000000003
[ 68.760756] RBP: 00007f67fa91ff00 R08: 00007f67fa91fedc R09: 000000000000000c
[ 68.760756] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffe824d496e
[ 68.760756] R13: 00007ffe824d496f R14: 00007f67fa120000 R15: 0000000000000003
[ 68.760756] </TASK>
[ 68.760756]
[ 68.760756] Allocated by task 279:
[ 68.760756] kasan_save_stack+0x1e/0x40
[
---truncated--- |
["https://git.kernel.org/stable/c/1632be63862f183cd5cf1cc094e698e6ec005dfd","https://git.kernel.org/stable/c/1b0e81416a24d6e9b8c2341e22e8bf48f8b8bfc9","https://git.kernel.org/stable/c/2a1b5110c95e4d49c8c3906270dfcde680a5a7be","https://git.kernel.org/stable/c/4a68938f43b7c2663e4c90bb9bbe29ac8b9a42a0","https://git.kernel.org/stable/c/4f5d71930f41be78557f9714393179025baacd65","https://git.kernel.org/stable/c/6abfaca8711803d0d7cc8c0fac1070a88509d463","https://git.kernel.org/stable/c/a8e03bcad52dc9afabf650fdbad84f739cec9efa","https://git.kernel.org/stable/c/f81270125b50532624400063281e6611ecd61ddf","https://git.kernel.org/stable/c/fbf9c4c714d3cdeb98b6a18e4d057f931cad1d81"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49530
|
High |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: fix double free in si_parse_power_table()
In function si_parse_power_table(), array adev->pm.dpm.ps and its member
is allocated. If the allocation of each member fails, the array itself
is freed and returned with an error code. However, the array is later
freed again in si_dpm_fini() function which is called when the function
returns an error.
This leads to potential double free of the array adev->pm.dpm.ps, as
well as leak of its array members, since the members are not freed in
the allocation function and the array is not nulled when freed.
In addition adev->pm.dpm.num_ps, which keeps track of the allocated
array member, is not updated until the member allocation is
successfully finished, this could also lead to either use after free,
or uninitialized variable access in si_dpm_fini().
Fix this by postponing the free of the array until si_dpm_fini() and
increment adev->pm.dpm.num_ps everytime the array member is allocated. |
["https://git.kernel.org/stable/c/2615464854505188f909d0c07c37a6623693b5c7","https://git.kernel.org/stable/c/43eb9b667b95f2a31c63e8949b0d2161b9be59c3","https://git.kernel.org/stable/c/6c5bdaa1325be7f04b79ea992ab216739192d342","https://git.kernel.org/stable/c/a5ce7051db044290b1a95045ff03c249005a3aa4","https://git.kernel.org/stable/c/af832028af6f44c6c45645757079c4ed6884ade5","https://git.kernel.org/stable/c/c0e811c4ccf3b42705976285e3a94cc82dea7300","https://git.kernel.org/stable/c/ca1ce206894dd976275c78ee38dbc19873f22de9","https://git.kernel.org/stable/c/f3fa2becf2fc25b6ac7cf8d8b1a2e4a86b3b72bd","https://git.kernel.org/stable/c/fd2eff8b9dcbe469c3b7bbbc7083ab5ed94de07b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52885
|
High |
fixed |
- 4.14.322
- 4.19.291
- 5.4.251
- 5.10.188
- 5.15.121
- 6.1.39
- 6.4.4
|
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix UAF in svc_tcp_listen_data_ready()
After the listener svc_sock is freed, and before invoking svc_tcp_accept()
for the established child sock, there is a window that the newsock
retaining a freed listener svc_sock in sk_user_data which cloning from
parent. In the race window, if data is received on the newsock, we will
observe use-after-free report in svc_tcp_listen_data_ready().
Reproduce by two tasks:
1. while :; do rpc.nfsd 0 ; rpc.nfsd; done
2. while :; do echo "" | ncat -4 127.0.0.1 2049 ; done
KASAN report:
==================================================================
BUG: KASAN: slab-use-after-free in svc_tcp_listen_data_ready+0x1cf/0x1f0 [sunrpc]
Read of size 8 at addr ffff888139d96228 by task nc/102553
CPU: 7 PID: 102553 Comm: nc Not tainted 6.3.0+ #18
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
Call Trace:
<IRQ>
dump_stack_lvl+0x33/0x50
print_address_description.constprop.0+0x27/0x310
print_report+0x3e/0x70
kasan_report+0xae/0xe0
svc_tcp_listen_data_ready+0x1cf/0x1f0 [sunrpc]
tcp_data_queue+0x9f4/0x20e0
tcp_rcv_established+0x666/0x1f60
tcp_v4_do_rcv+0x51c/0x850
tcp_v4_rcv+0x23fc/0x2e80
ip_protocol_deliver_rcu+0x62/0x300
ip_local_deliver_finish+0x267/0x350
ip_local_deliver+0x18b/0x2d0
ip_rcv+0x2fb/0x370
__netif_receive_skb_one_core+0x166/0x1b0
process_backlog+0x24c/0x5e0
__napi_poll+0xa2/0x500
net_rx_action+0x854/0xc90
__do_softirq+0x1bb/0x5de
do_softirq+0xcb/0x100
</IRQ>
<TASK>
...
</TASK>
Allocated by task 102371:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
__kasan_kmalloc+0x7b/0x90
svc_setup_socket+0x52/0x4f0 [sunrpc]
svc_addsock+0x20d/0x400 [sunrpc]
__write_ports_addfd+0x209/0x390 [nfsd]
write_ports+0x239/0x2c0 [nfsd]
nfsctl_transaction_write+0xac/0x110 [nfsd]
vfs_write+0x1c3/0xae0
ksys_write+0xed/0x1c0
do_syscall_64+0x38/0x90
entry_SYSCALL_64_after_hwframe+0x72/0xdc
Freed by task 102551:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
kasan_save_free_info+0x2a/0x50
__kasan_slab_free+0x106/0x190
__kmem_cache_free+0x133/0x270
svc_xprt_free+0x1e2/0x350 [sunrpc]
svc_xprt_destroy_all+0x25a/0x440 [sunrpc]
nfsd_put+0x125/0x240 [nfsd]
nfsd_svc+0x2cb/0x3c0 [nfsd]
write_threads+0x1ac/0x2a0 [nfsd]
nfsctl_transaction_write+0xac/0x110 [nfsd]
vfs_write+0x1c3/0xae0
ksys_write+0xed/0x1c0
do_syscall_64+0x38/0x90
entry_SYSCALL_64_after_hwframe+0x72/0xdc
Fix the UAF by simply doing nothing in svc_tcp_listen_data_ready()
if state != TCP_LISTEN, that will avoid dereferencing svsk for all
child socket. |
["https://git.kernel.org/stable/c/42725e5c1b181b757ba11d804443922982334d9b","https://git.kernel.org/stable/c/7e1f989055622fd086c5dfb291fc72adf5660b6f","https://git.kernel.org/stable/c/c7b8c2d06e437639694abe76978e915cfb73f428","https://git.kernel.org/stable/c/cd5ec3ee52ce4b7e283cc11facfa420c297c8065","https://git.kernel.org/stable/c/dfc896c4a75cb8cd7cb2dfd9b469cf1e3f004254","https://git.kernel.org/stable/c/ef047411887ff0845afd642d6a687819308e1a4e","https://git.kernel.org/stable/c/fbf4ace39b2e4f3833236afbb2336edbafd75eee","https://git.kernel.org/stable/c/fc80fc2d4e39137869da3150ee169b40bf879287","https://git.kernel.org/stable/c/42725e5c1b181b757ba11d804443922982334d9b","https://git.kernel.org/stable/c/7e1f989055622fd086c5dfb291fc72adf5660b6f","https://git.kernel.org/stable/c/c7b8c2d06e437639694abe76978e915cfb73f428","https://git.kernel.org/stable/c/cd5ec3ee52ce4b7e283cc11facfa420c297c8065","https://git.kernel.org/stable/c/dfc896c4a75cb8cd7cb2dfd9b469cf1e3f004254","https://git.kernel.org/stable/c/ef047411887ff0845afd642d6a687819308e1a4e","https://git.kernel.org/stable/c/fbf4ace39b2e4f3833236afbb2336edbafd75eee","https://git.kernel.org/stable/c/fc80fc2d4e39137869da3150ee169b40bf879287"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52664
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: atlantic: eliminate double free in error handling logic
Driver has a logic leak in ring data allocation/free,
where aq_ring_free could be called multiple times on same ring,
if system is under stress and got memory allocation error.
Ring pointer was used as an indicator of failure, but this is
not correct since only ring data is allocated/deallocated.
Ring itself is an array member.
Changing ring allocation functions to return error code directly.
This simplifies error handling and eliminates aq_ring_free
on higher layer. |
["https://git.kernel.org/stable/c/0edb3ae8bfa31cd544b0c195bdec00e036002b5d","https://git.kernel.org/stable/c/b3cb7a830a24527877b0bc900b9bd74a96aea928","https://git.kernel.org/stable/c/c11a870a73a3bc4cc7df6dd877a45b181795fcbf","https://git.kernel.org/stable/c/d1fde4a7e1dcc4d49cce285107a7a43c3030878d","https://git.kernel.org/stable/c/0edb3ae8bfa31cd544b0c195bdec00e036002b5d","https://git.kernel.org/stable/c/b3cb7a830a24527877b0bc900b9bd74a96aea928","https://git.kernel.org/stable/c/c11a870a73a3bc4cc7df6dd877a45b181795fcbf","https://git.kernel.org/stable/c/d1fde4a7e1dcc4d49cce285107a7a43c3030878d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52921
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix possible UAF in amdgpu_cs_pass1()
Since the gang_size check is outside of chunk parsing
loop, we need to reset i before we free the chunk data.
Suggested by Ye Zhang (@VAR10CK) of Baidu Security. |
["https://git.kernel.org/stable/c/90e065677e0362a777b9db97ea21d43a39211399","https://git.kernel.org/stable/c/9a2393af1f35d1975204fc00035c64a1c792b278","https://git.kernel.org/stable/c/e08e9dd09809b16f8f8cee8c466841b33d24ed96"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53126
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
vdpa: solidrun: Fix UB bug with devres
In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to
pcim_iomap_regions() is placed on the stack. Neither
pcim_iomap_regions() nor the functions it calls copy that string.
Should the string later ever be used, this, consequently, causes
undefined behavior since the stack frame will by then have disappeared.
Fix the bug by allocating the strings on the heap through
devm_kasprintf(). |
["https://git.kernel.org/stable/c/0b364cf53b20204e92bac7c6ebd1ee7d3ec62931","https://git.kernel.org/stable/c/5bb287da2d2d5bb8f7376e223b02edb16998982e","https://git.kernel.org/stable/c/d372dd09cfbf1324f54cbffd81fcaf6cdf3e608e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26928
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in cifs_debug_files_proc_show()
Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF. |
["https://git.kernel.org/stable/c/229042314602db62559ecacba127067c22ee7b88","https://git.kernel.org/stable/c/3402faf78b2516b0af1259baff50cc8453ef0bd1","https://git.kernel.org/stable/c/8f8718afd446cd4ea3b62bacc3eec09f8aae85ee","https://git.kernel.org/stable/c/a140224bcf87eb98a87b67ff4c6826c57e47b704","https://git.kernel.org/stable/c/a65f2b56334ba4dc30bd5ee9ce5b2691b973344d","https://git.kernel.org/stable/c/ca545b7f0823f19db0f1148d59bc5e1a56634502","https://git.kernel.org/stable/c/229042314602db62559ecacba127067c22ee7b88","https://git.kernel.org/stable/c/3402faf78b2516b0af1259baff50cc8453ef0bd1","https://git.kernel.org/stable/c/a65f2b56334ba4dc30bd5ee9ce5b2691b973344d","https://git.kernel.org/stable/c/ca545b7f0823f19db0f1148d59bc5e1a56634502"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-2977
|
High |
fixed |
- 4.14.276
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.1
|
A flaw was found in the Linux kernel implementation of proxied virtualized TPM devices. On a system where virtualized TPM devices are configured (this is not the default) a local attacker can create a use-after-free and create a situation where it may be possible to escalate privileges on the system. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d8e7007dc7c4d7c8366739bbcd3f5e51dcd470f","https://security.netapp.com/advisory/ntap-20230214-0006/","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d8e7007dc7c4d7c8366739bbcd3f5e51dcd470f","https://security.netapp.com/advisory/ntap-20230214-0006/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49622
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: avoid skb access on nf_stolen
When verdict is NF_STOLEN, the skb might have been freed.
When tracing is enabled, this can result in a use-after-free:
1. access to skb->nf_trace
2. access to skb->mark
3. computation of trace id
4. dump of packet payload
To avoid 1, keep a cached copy of skb->nf_trace in the
trace state struct.
Refresh this copy whenever verdict is != STOLEN.
Avoid 2 by skipping skb->mark access if verdict is STOLEN.
3 is avoided by precomputing the trace id.
Only dump the packet when verdict is not "STOLEN". |
["https://git.kernel.org/stable/c/0016d5d46d7440729a3132f61a8da3bf7f84e2ba","https://git.kernel.org/stable/c/e34b9ed96ce3b06c79bf884009b16961ca478f87"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49651
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
srcu: Tighten cleanup_srcu_struct() GP checks
Currently, cleanup_srcu_struct() checks for a grace period in progress,
but it does not check for a grace period that has not yet started but
which might start at any time. Such a situation could result in a
use-after-free bug, so this commit adds a check for a grace period that
is needed but not yet started to cleanup_srcu_struct(). |
["https://git.kernel.org/stable/c/8ed00760203d8018bee042fbfe8e076579be2c2b","https://git.kernel.org/stable/c/e997dda6502eefbc1032d6b0da7b353c53344b07"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-0562
|
High |
fixed |
|
A use-after-free flaw was found in the Linux Kernel. When a disk is removed, bdi_unregister is called to stop further write-back and waits for associated delayed work to complete. However, wb_inode_writeback_end() may schedule bandwidth estimation work after this has completed, which can result in the timer attempting to access the recently freed bdi_writeback. |
["https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/security/cve/CVE-2024-0562","https://bugzilla.redhat.com/show_bug.cgi?id=2258475","https://patchwork.kernel.org/project/linux-mm/patch/20220801155034.3772543-1-khazhy@google.com/","https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/security/cve/CVE-2024-0562","https://bugzilla.redhat.com/show_bug.cgi?id=2258475","https://patchwork.kernel.org/project/linux-mm/patch/20220801155034.3772543-1-khazhy@google.com/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21751
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: HWS, change error flow on matcher disconnect
Currently, when firmware failure occurs during matcher disconnect flow,
the error flow of the function reconnects the matcher back and returns
an error, which continues running the calling function and eventually
frees the matcher that is being disconnected.
This leads to a case where we have a freed matcher on the matchers list,
which in turn leads to use-after-free and eventual crash.
This patch fixes that by not trying to reconnect the matcher back when
some FW command fails during disconnect.
Note that we're dealing here with FW error. We can't overcome this
problem. This might lead to bad steering state (e.g. wrong connection
between matchers), and will also lead to resource leakage, as it is
the case with any other error handling during resource destruction.
However, the goal here is to allow the driver to continue and not crash
the machine with use-after-free error. |
["https://git.kernel.org/stable/c/1ce840c7a659aa53a31ef49f0271b4fd0dc10296","https://git.kernel.org/stable/c/23a86c76a1a197e8fbbbd0ce3e826eb58c471624"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21693
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mm: zswap: properly synchronize freeing resources during CPU hotunplug
In zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx of the
current CPU at the beginning of the operation is retrieved and used
throughout. However, since neither preemption nor migration are disabled,
it is possible that the operation continues on a different CPU.
If the original CPU is hotunplugged while the acomp_ctx is still in use,
we run into a UAF bug as some of the resources attached to the acomp_ctx
are freed during hotunplug in zswap_cpu_comp_dead() (i.e.
acomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp).
The problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to use
crypto_acomp API for hardware acceleration") when the switch to the
crypto_acomp API was made. Prior to that, the per-CPU crypto_comp was
retrieved using get_cpu_ptr() which disables preemption and makes sure the
CPU cannot go away from under us. Preemption cannot be disabled with the
crypto_acomp API as a sleepable context is needed.
Use the acomp_ctx.mutex to synchronize CPU hotplug callbacks allocating
and freeing resources with compression/decompression paths. Make sure
that acomp_ctx.req is NULL when the resources are freed. In the
compression/decompression paths, check if acomp_ctx.req is NULL after
acquiring the mutex (meaning the CPU was offlined) and retry on the new
CPU.
The initialization of acomp_ctx.mutex is moved from the CPU hotplug
callback to the pool initialization where it belongs (where the mutex is
allocated). In addition to adding clarity, this makes sure that CPU
hotplug cannot reinitialize a mutex that is already locked by
compression/decompression.
Previously a fix was attempted by holding cpus_read_lock() [1]. This
would have caused a potential deadlock as it is possible for code already
holding the lock to fall into reclaim and enter zswap (causing a
deadlock). A fix was also attempted using SRCU for synchronization, but
Johannes pointed out that synchronize_srcu() cannot be used in CPU hotplug
notifiers [2].
Alternative fixes that were considered/attempted and could have worked:
- Refcounting the per-CPU acomp_ctx. This involves complexity in
handling the race between the refcount dropping to zero in
zswap_[de]compress() and the refcount being re-initialized when the
CPU is onlined.
- Disabling migration before getting the per-CPU acomp_ctx [3], but
that's discouraged and is a much bigger hammer than needed, and could
result in subtle performance issues.
[1]https://lkml.kernel.org/20241219212437.2714151-1-yosryahmed@google.com/
[2]https://lkml.kernel.org/20250107074724.1756696-2-yosryahmed@google.com/
[3]https://lkml.kernel.org/20250107222236.2715883-2-yosryahmed@google.com/
[yosryahmed@google.com: remove comment] |
["https://git.kernel.org/stable/c/12dcb0ef540629a281533f9dedc1b6b8e14cfb65","https://git.kernel.org/stable/c/8d29ff5d50304daa41dc3cfdda4a9d1e46cf5be1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-51780
|
High |
fixed |
|
An issue was discovered in the Linux kernel before 6.6.8. do_vcc_ioctl in net/atm/ioctl.c has a use-after-free because of a vcc_recvmsg race condition. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.8","https://github.com/torvalds/linux/commit/24e90b9e34f9e039f56b5f25f6e6eb92cdd8f4b3","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://security.netapp.com/advisory/ntap-20240419-0001/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.8","https://github.com/torvalds/linux/commit/24e90b9e34f9e039f56b5f25f6e6eb92cdd8f4b3","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://security.netapp.com/advisory/ntap-20240419-0001/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-6270
|
High |
fixed |
|
A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution. |
["https://access.redhat.com/security/cve/CVE-2023-6270","https://bugzilla.redhat.com/show_bug.cgi?id=2256786","https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/block/aoe?h=v6.9\u0026id=f98364e926626c678fb4b9004b75cacf92ff0662","https://access.redhat.com/security/cve/CVE-2023-6270","https://bugzilla.redhat.com/show_bug.cgi?id=2256786","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1055
|
High |
fixed |
|
A use-after-free exists in the Linux Kernel in tc_new_tfilter that could allow a local attacker to gain privilege escalation. The exploit requires unprivileged user namespaces. We recommend upgrading past commit 04c2a47ffb13c29778e2a14e414ad4cb5a5db4b5 |
["http://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=04c2a47ffb13c29778e2a14e414ad4cb5a5db4b5","https://kernel.dance/#04c2a47ffb13c29778e2a14e414ad4cb5a5db4b5","https://security.netapp.com/advisory/ntap-20220506-0007/","https://syzkaller.appspot.com/bug?id=2212474c958978ab86525fe6832ac8102c309ffc","http://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=04c2a47ffb13c29778e2a14e414ad4cb5a5db4b5","https://kernel.dance/#04c2a47ffb13c29778e2a14e414ad4cb5a5db4b5","https://security.netapp.com/advisory/ntap-20220506-0007/","https://syzkaller.appspot.com/bug?id=2212474c958978ab86525fe6832ac8102c309ffc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46791
|
Medium |
fixed |
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open
The mcp251x_hw_wake() function is called with the mpc_lock mutex held and
disables the interrupt handler so that no interrupts can be processed while
waking the device. If an interrupt has already occurred then waiting for
the interrupt handler to complete will deadlock because it will be trying
to acquire the same mutex.
CPU0 CPU1
---- ----
mcp251x_open()
mutex_lock(&priv->mcp_lock)
request_threaded_irq()
<interrupt>
mcp251x_can_ist()
mutex_lock(&priv->mcp_lock)
mcp251x_hw_wake()
disable_irq() <-- deadlock
Use disable_irq_nosync() instead because the interrupt handler does
everything while holding the mutex so it doesn't matter if it's still
running. |
["https://git.kernel.org/stable/c/3a49b6b1caf5cefc05264d29079d52c99cb188e0","https://git.kernel.org/stable/c/513c8fc189b52f7922e36bdca58997482b198f0e","https://git.kernel.org/stable/c/7dd9c26bd6cf679bcfdef01a8659791aa6487a29","https://git.kernel.org/stable/c/8fecde9c3f9a4b97b68bb97c9f47e5b662586ba7","https://git.kernel.org/stable/c/e554113a1cd2a9cfc6c7af7bdea2141c5757e188","https://git.kernel.org/stable/c/f7ab9e14b23a3eac6714bdc4dba244d8aa1ef646"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57882
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix TCP options overflow.
Syzbot reported the following splat:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 1 UID: 0 PID: 5836 Comm: sshd Not tainted 6.13.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024
RIP: 0010:_compound_head include/linux/page-flags.h:242 [inline]
RIP: 0010:put_page+0x23/0x260 include/linux/mm.h:1552
Code: 90 90 90 90 90 90 90 55 41 57 41 56 53 49 89 fe 48 bd 00 00 00 00 00 fc ff df e8 f8 5e 12 f8 49 8d 5e 08 48 89 d8 48 c1 e8 03 <80> 3c 28 00 74 08 48 89 df e8 8f c7 78 f8 48 8b 1b 48 89 de 48 83
RSP: 0000:ffffc90003916c90 EFLAGS: 00010202
RAX: 0000000000000001 RBX: 0000000000000008 RCX: ffff888030458000
RDX: 0000000000000100 RSI: 0000000000000000 RDI: 0000000000000000
RBP: dffffc0000000000 R08: ffffffff898ca81d R09: 1ffff110054414ac
R10: dffffc0000000000 R11: ffffed10054414ad R12: 0000000000000007
R13: ffff88802a20a542 R14: 0000000000000000 R15: 0000000000000000
FS: 00007f34f496e800(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f9d6ec9ec28 CR3: 000000004d260000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
skb_page_unref include/linux/skbuff_ref.h:43 [inline]
__skb_frag_unref include/linux/skbuff_ref.h:56 [inline]
skb_release_data+0x483/0x8a0 net/core/skbuff.c:1119
skb_release_all net/core/skbuff.c:1190 [inline]
__kfree_skb+0x55/0x70 net/core/skbuff.c:1204
tcp_clean_rtx_queue net/ipv4/tcp_input.c:3436 [inline]
tcp_ack+0x2442/0x6bc0 net/ipv4/tcp_input.c:4032
tcp_rcv_state_process+0x8eb/0x44e0 net/ipv4/tcp_input.c:6805
tcp_v4_do_rcv+0x77d/0xc70 net/ipv4/tcp_ipv4.c:1939
tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2351
ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205
ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233
NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314
NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314
__netif_receive_skb_one_core net/core/dev.c:5672 [inline]
__netif_receive_skb+0x2bf/0x650 net/core/dev.c:5785
process_backlog+0x662/0x15b0 net/core/dev.c:6117
__napi_poll+0xcb/0x490 net/core/dev.c:6883
napi_poll net/core/dev.c:6952 [inline]
net_rx_action+0x89b/0x1240 net/core/dev.c:7074
handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561
__do_softirq kernel/softirq.c:595 [inline]
invoke_softirq kernel/softirq.c:435 [inline]
__irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662
irq_exit_rcu+0x9/0x30 kernel/softirq.c:678
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]
sysvec_apic_timer_interrupt+0x57/0xc0 arch/x86/kernel/apic/apic.c:1049
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702
RIP: 0033:0x7f34f4519ad5
Code: 85 d2 74 0d 0f 10 02 48 8d 54 24 20 0f 11 44 24 20 64 8b 04 25 18 00 00 00 85 c0 75 27 41 b8 08 00 00 00 b8 0f 01 00 00 0f 05 <48> 3d 00 f0 ff ff 76 75 48 8b 15 24 73 0d 00 f7 d8 64 89 02 48 83
RSP: 002b:00007ffec5b32ce0 EFLAGS: 00000246
RAX: 0000000000000001 RBX: 00000000000668a0 RCX: 00007f34f4519ad5
RDX: 00007ffec5b32d00 RSI: 0000000000000004 RDI: 0000564f4bc6cae0
RBP: 0000564f4bc6b5a0 R08: 0000000000000008 R09: 0000000000000000
R10: 00007ffec5b32de8 R11: 0000000000000246 R12: 0000564f48ea8aa4
R13: 0000000000000001 R14: 0000564f48ea93e8 R15: 00007ffec5b32d68
</TASK>
Eric noted a probable shinfo->nr_frags corruption, which indeed
occurs.
The root cause is a buggy MPTCP option len computation in some
circumstances: the ADD_ADDR option should be mutually exclusive
with DSS since the blamed commit.
Still, mptcp_established_options_add_addr() tries to set the
relevant info in mptcp_out_options, if
---truncated--- |
["https://git.kernel.org/stable/c/09ba95321a269019b5aa8e0c3bc80cf86d91fd18","https://git.kernel.org/stable/c/53fe947f67c93a5334aed3a7259fcc8a204f8bb6","https://git.kernel.org/stable/c/88b01048f286bb522f524ad99943ba86797d6514","https://git.kernel.org/stable/c/cbb26f7d8451fe56ccac802c6db48d16240feebd","https://git.kernel.org/stable/c/fb08e6b0ba284e3dcdc9378de26dcb51d90710f5","http://www.openwall.com/lists/oss-security/2025/04/01/3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57938
|
Medium |
fixed |
- 5.4.289
- 5.10.233
- 5.15.176
- 6.1.124
- 6.6.70
- 6.12.9
|
In the Linux kernel, the following vulnerability has been resolved:
net/sctp: Prevent autoclose integer overflow in sctp_association_init()
While by default max_autoclose equals to INT_MAX / HZ, one may set
net.sctp.max_autoclose to UINT_MAX. There is code in
sctp_association_init() that can consequently trigger overflow. |
["https://git.kernel.org/stable/c/081bdb3a31674339313c6d702af922bc29de2c53","https://git.kernel.org/stable/c/2297890b778b0e7c8200d6818154f7e461d78e94","https://git.kernel.org/stable/c/271f031f4c31c07e2a85a1ba2b4c8e734909a477","https://git.kernel.org/stable/c/4e86729d1ff329815a6e8a920cb554a1d4cb5b8d","https://git.kernel.org/stable/c/7af63ef5fe4d480064eb22583b24ffc8b408183a","https://git.kernel.org/stable/c/94b7ed0a4896420988e1776942f0a3f67167873e","https://git.kernel.org/stable/c/f9c3adb083d3278f065a83c3f667f1246c74c31f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52918
|
Medium |
fixed |
- 4.19.321
- 5.4.283
- 5.10.225
- 5.15.166
- 6.1.107
- 6.6.48
|
In the Linux kernel, the following vulnerability has been resolved:
media: pci: cx23885: check cx23885_vdev_init() return
cx23885_vdev_init() can return a NULL pointer, but that pointer
is used in the next line without a check.
Add a NULL pointer check and go to the error unwind if it is NULL. |
["https://git.kernel.org/stable/c/06ee04a907d64ee3910fecedd05d7f1be4b1b70e","https://git.kernel.org/stable/c/15126b916e39b0cb67026b0af3c014bfeb1f76b3","https://git.kernel.org/stable/c/199a42fc4c45e8b7f19efeb15dbc36889a599ac2","https://git.kernel.org/stable/c/8e31b096e2e1949bc8f0be019c9ae70d414404c6","https://git.kernel.org/stable/c/a5f1d30c51c485cec7a7de60205667c3ff86c303","https://git.kernel.org/stable/c/b1397fb4a779fca560c43d2acf6702d41b4a495b","https://git.kernel.org/stable/c/e7385510e2550a9f8b6f3d5f33c5b894ab9ba976"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47667
|
Medium |
fixed |
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)
Errata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0
(SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an
inbound PCIe TLP spans more than two internal AXI 128-byte bursts,
the bus may corrupt the packet payload and the corrupt data may
cause associated applications or the processor to hang.
The workaround for Errata #i2037 is to limit the maximum read
request size and maximum payload size to 128 bytes. Add workaround
for Errata #i2037 here.
The errata and workaround is applicable only to AM65x SR 1.0 and
later versions of the silicon will have this fixed.
[1] -> https://www.ti.com/lit/er/sprz452i/sprz452i.pdf |
["https://git.kernel.org/stable/c/135843c351c08df72bdd4b4ebea53c8052a76881","https://git.kernel.org/stable/c/576d0fb6f8d4bd4695e70eee173a1b9c7bae9572","https://git.kernel.org/stable/c/86f271f22bbb6391410a07e08d6ca3757fda01fa","https://git.kernel.org/stable/c/af218c803fe298ddf00abef331aa526b20d7ea61","https://git.kernel.org/stable/c/cfb006e185f64edbbdf7869eac352442bc76b8f6","https://git.kernel.org/stable/c/dd47051c76c8acd8cb983f01b4d1265da29cb66a","https://git.kernel.org/stable/c/ebbdbbc580c1695dec283d0ba6448729dc993246"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47674
|
Medium |
fixed |
- 5.15.168
- 6.1.111
- 6.6.52
- 6.10.11
|
In the Linux kernel, the following vulnerability has been resolved:
mm: avoid leaving partial pfn mappings around in error case
As Jann points out, PFN mappings are special, because unlike normal
memory mappings, there is no lifetime information associated with the
mapping - it is just a raw mapping of PFNs with no reference counting of
a 'struct page'.
That's all very much intentional, but it does mean that it's easy to
mess up the cleanup in case of errors. Yes, a failed mmap() will always
eventually clean up any partial mappings, but without any explicit
lifetime in the page table mapping itself, it's very easy to do the
error handling in the wrong order.
In particular, it's easy to mistakenly free the physical backing store
before the page tables are actually cleaned up and (temporarily) have
stale dangling PTE entries.
To make this situation less error-prone, just make sure that any partial
pfn mapping is torn down early, before any other error handling. |
["https://git.kernel.org/stable/c/3213fdcab961026203dd587a4533600c70b3336b","https://git.kernel.org/stable/c/35770ca6180caa24a2b258c99a87bd437a1ee10f","https://git.kernel.org/stable/c/5b2c8b34f6d76bfbd1dd4936eb8a0fbfb9af3959","https://git.kernel.org/stable/c/65d0db500d7c07f0f76fc24a4d837791c4862cd2","https://git.kernel.org/stable/c/79a61cc3fc0466ad2b7b89618a6157785f0293b3","https://git.kernel.org/stable/c/954fd4c81f22c4b6ba65379a81fd252971bf4ef3","https://git.kernel.org/stable/c/a95a24fcaee1b892e47d5e6dcc403f713874ee80","https://project-zero.issues.chromium.org/issues/366053091"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49868
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix a NULL pointer dereference when failed to start a new trasacntion
[BUG]
Syzbot reported a NULL pointer dereference with the following crash:
FAULT_INJECTION: forcing a failure.
start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676
prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642
relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678
...
BTRFS info (device loop0): balance: ended with status: -12
Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667]
RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926
Call Trace:
<TASK>
commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496
btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430
del_balance_item fs/btrfs/volumes.c:3678 [inline]
reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742
btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574
btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
[CAUSE]
The allocation failure happens at the start_transaction() inside
prepare_to_relocate(), and during the error handling we call
unset_reloc_control(), which makes fs_info->balance_ctl to be NULL.
Then we continue the error path cleanup in btrfs_balance() by calling
reset_balance_state() which will call del_balance_item() to fully delete
the balance item in the root tree.
However during the small window between set_reloc_contrl() and
unset_reloc_control(), we can have a subvolume tree update and created a
reloc_root for that subvolume.
Then we go into the final btrfs_commit_transaction() of
del_balance_item(), and into btrfs_update_reloc_root() inside
commit_fs_roots().
That function checks if fs_info->reloc_ctl is in the merge_reloc_tree
stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer
dereference.
[FIX]
Just add extra check on fs_info->reloc_ctl inside
btrfs_update_reloc_root(), before checking
fs_info->reloc_ctl->merge_reloc_tree.
That DEAD_RELOC_TREE handling is to prevent further modification to the
reloc tree during merge stage, but since there is no reloc_ctl at all,
we do not need to bother that. |
["https://git.kernel.org/stable/c/1282f001cbf56e5dd6e90a18e205a566793f4be0","https://git.kernel.org/stable/c/37fee9c220b92c3b7bf22b51c51dde5364e7590b","https://git.kernel.org/stable/c/39356ec0e319ed07627b3a0f402d0608546509e6","https://git.kernel.org/stable/c/7ad0c5868f2f0418619089513d95230c66cb7eb4","https://git.kernel.org/stable/c/c3b47f49e83197e8dffd023ec568403bcdbb774b","https://git.kernel.org/stable/c/d13249c0df7aab885acb149695f82c54c0822a70","https://git.kernel.org/stable/c/d73d48acf36f57362df7e4f9d76568168bf5e944","https://git.kernel.org/stable/c/dc02c1440705e3451abd1c2c8114a5c1bb188e9f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49890
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: ensure the fw_info is not null before using it
This resolves the dereference null return value warning
reported by Coverity. |
["https://git.kernel.org/stable/c/016bf0294b401246471c6710c6bf9251616228b6","https://git.kernel.org/stable/c/186fb12e7a7b038c2710ceb2fb74068f1b5d55a4","https://git.kernel.org/stable/c/29f388945770bd0a6c82711436b2bc98b0dfac92","https://git.kernel.org/stable/c/8adf4408d482faa51b2c14e60bfd9946ec1911a4","https://git.kernel.org/stable/c/9550d8d6f19fac7623f044ae8d9503825b325497","https://git.kernel.org/stable/c/b511474f49588cdca355ebfce54e7eddbf7b75a5","https://git.kernel.org/stable/c/fd5f4ac1a986f0e7e9fa019201b5890554f87bcf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49892
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Initialize get_bytes_per_element's default to 1
Variables, used as denominators and maybe not assigned to other values,
should not be 0. bytes_per_element_y & bytes_per_element_c are
initialized by get_bytes_per_element() which should never return 0.
This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity. |
["https://git.kernel.org/stable/c/1f9f8186e239222f1c8d3dd73bf3bc6ae86c5e76","https://git.kernel.org/stable/c/3334ab72cbba55a632f24579cd47c4a4e5e69cda","https://git.kernel.org/stable/c/4067f4fa0423a89fb19a30b57231b384d77d2610","https://git.kernel.org/stable/c/8f0abb39c16e719129de10596b3ae3363fa178b4","https://git.kernel.org/stable/c/a23d6029e730f8a151b1a34afb169baac1274583","https://git.kernel.org/stable/c/bc00d211da4ffad5314a2043b50bdc8ff8a33724","https://git.kernel.org/stable/c/c7630935d9a4986e8c0ed91658a781b7a77d73f7","https://git.kernel.org/stable/c/f921335123f6620c3dce5c96fbb95f18524a021c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49907
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check null pointers before using dc->clk_mgr
[WHY & HOW]
dc->clk_mgr is null checked previously in the same function, indicating
it might be null.
Passing "dc" to "dc->hwss.apply_idle_power_optimizations", which
dereferences null "dc->clk_mgr". (The function pointer resolves to
"dcn35_apply_idle_power_optimizations".)
This fixes 1 FORWARD_NULL issue reported by Coverity. |
["https://git.kernel.org/stable/c/3f7e533c10db3d0158709a99e2129ff63add6bcd","https://git.kernel.org/stable/c/5ba3fbf75b243b2863a8be9e7c393e003d3b88f3","https://git.kernel.org/stable/c/8d54001f8dccd56146973f23f3ab2ba037a21251","https://git.kernel.org/stable/c/95d9e0803e51d5a24276b7643b244c7477daf463","https://git.kernel.org/stable/c/9641bc4adf8446034e490ed543ae7e9833cfbdf5","https://git.kernel.org/stable/c/a2773e0a4b79e7a6463abdffaf8cc4f24428ba18","https://git.kernel.org/stable/c/a545a9403e04c6e17fdc04a26a61d9feebbba106"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49913
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream
This commit addresses a null pointer dereference issue in the
`commit_planes_for_stream` function at line 4140. The issue could occur
when `top_pipe_to_program` is null.
The fix adds a check to ensure `top_pipe_to_program` is not null before
accessing its stream_res. This prevents a null pointer dereference.
Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906) |
["https://git.kernel.org/stable/c/1ebfa6663807c144be8c8b6727375012409d2356","https://git.kernel.org/stable/c/3929e382e4758aff42da0102a60d13337c99d3b8","https://git.kernel.org/stable/c/40193ff73630adf76bc0d82398f7d90fb576dba4","https://git.kernel.org/stable/c/66d71a72539e173a9b00ca0b1852cbaa5f5bf1ad","https://git.kernel.org/stable/c/73efd2a611b62fee71a7b7f27d9d08bb60da8a72","https://git.kernel.org/stable/c/8ab59527852a6f7780aad6185729550ca0569122","https://git.kernel.org/stable/c/e47e563c6f0db7d792a559301862c19ead0dfc2f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49927
|
Medium |
fixed |
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
x86/ioapic: Handle allocation failures gracefully
Breno observed panics when using failslab under certain conditions during
runtime:
can not alloc irq_pin_list (-1,0,20)
Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed
panic+0x4e9/0x590
mp_irqdomain_alloc+0x9ab/0xa80
irq_domain_alloc_irqs_locked+0x25d/0x8d0
__irq_domain_alloc_irqs+0x80/0x110
mp_map_pin_to_irq+0x645/0x890
acpi_register_gsi_ioapic+0xe6/0x150
hpet_open+0x313/0x480
That's a pointless panic which is a leftover of the historic IO/APIC code
which panic'ed during early boot when the interrupt allocation failed.
The only place which might justify panic is the PIT/HPET timer_check() code
which tries to figure out whether the timer interrupt is delivered through
the IO/APIC. But that code does not require to handle interrupt allocation
failures. If the interrupt cannot be allocated then timer delivery fails
and it either panics due to that or falls back to legacy mode.
Cure this by removing the panic wrapper around __add_pin_to_irq_node() and
making mp_irqdomain_alloc() aware of the failure condition and handle it as
any other failure in this function gracefully. |
["https://git.kernel.org/stable/c/077e1b7cd521163ded545987bbbd389519aeed71","https://git.kernel.org/stable/c/649a5c2ffae797ce792023a70e84c7fe4b6fb8e0","https://git.kernel.org/stable/c/830802a0fea8fb39d3dc9fb7d6b5581e1343eb1f","https://git.kernel.org/stable/c/e479cb835feeb2abff97f25766e23b96a6eabe28","https://git.kernel.org/stable/c/ec862cd843faa6f0e84a7a07362f2786446bf697","https://git.kernel.org/stable/c/f17efbeb2922327ea01a9efa8829fea9a30e547d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49933
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
blk_iocost: fix more out of bound shifts
Recently running UBSAN caught few out of bound shifts in the
ioc_forgive_debts() function:
UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38
shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long
long')
...
UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30
shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long
long')
...
Call Trace:
<IRQ>
dump_stack_lvl+0xca/0x130
__ubsan_handle_shift_out_of_bounds+0x22c/0x280
? __lock_acquire+0x6441/0x7c10
ioc_timer_fn+0x6cec/0x7750
? blk_iocost_init+0x720/0x720
? call_timer_fn+0x5d/0x470
call_timer_fn+0xfa/0x470
? blk_iocost_init+0x720/0x720
__run_timer_base+0x519/0x700
...
Actual impact of this issue was not identified but I propose to fix the
undefined behaviour.
The proposed fix to prevent those out of bound shifts consist of
precalculating exponent before using it the shift operations by taking
min value from the actual exponent and maximum possible number of bits. |
["https://git.kernel.org/stable/c/1ab2cfe19700fb3dde4c7dfec392acff34db3120","https://git.kernel.org/stable/c/1b120f151871eb47ce9f283c007af3f8ae1d990e","https://git.kernel.org/stable/c/1f61d509257d6a05763d05bf37943b35306522b1","https://git.kernel.org/stable/c/364022095bdd4108efdaaa68576afa4712a5d085","https://git.kernel.org/stable/c/59121bb38fdc01434ea3fe361ee02b59f036227f","https://git.kernel.org/stable/c/9bce8005ec0dcb23a58300e8522fe4a31da606fa","https://git.kernel.org/stable/c/f4ef9bef023d5c543cb0f3194ecacfd47ef590ec"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49935
|
Medium |
fixed |
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
ACPI: PAD: fix crash in exit_round_robin()
The kernel occasionally crashes in cpumask_clear_cpu(), which is called
within exit_round_robin(), because when executing clear_bit(nr, addr) with
nr set to 0xffffffff, the address calculation may cause misalignment within
the memory, leading to access to an invalid memory address.
----------
BUG: unable to handle kernel paging request at ffffffffe0740618
...
CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1
...
RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad]
Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 <f0> 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31
RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202
RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8
R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e
R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e
FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
? acpi_pad_add+0x120/0x120 [acpi_pad]
kthread+0x10b/0x130
? set_kthread_struct+0x50/0x50
ret_from_fork+0x1f/0x40
...
CR2: ffffffffe0740618
crash> dis -lr ffffffffc0726923
...
/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114
0xffffffffc0726918 <power_saving_thread+776>: mov %r12d,%r12d
/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325
0xffffffffc072691b <power_saving_thread+779>: mov -0x3f8d7de0(,%r12,4),%eax
/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80
0xffffffffc0726923 <power_saving_thread+787>: lock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 <pad_busy_cpus_bits>
crash> px tsk_in_cpu[14]
$66 = 0xffffffff
crash> px 0xffffffffc072692c+0x19cf4
$99 = 0xffffffffc0740620
crash> sym 0xffffffffc0740620
ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad]
crash> px pad_busy_cpus_bits[0]
$42 = 0xfffc0
----------
To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling
cpumask_clear_cpu() in exit_round_robin(), just as it is done in
round_robin_cpu().
[ rjw: Subject edit, avoid updates to the same value ] |
["https://git.kernel.org/stable/c/03593dbb0b272ef7b0358b099841e65735422aca","https://git.kernel.org/stable/c/0a2ed70a549e61c5181bad5db418d223b68ae932","https://git.kernel.org/stable/c/27c045f868f0e5052c6b532868a65e0cd250c8fc","https://git.kernel.org/stable/c/68a599da16ebad442ce295d8d2d5c488e3992822","https://git.kernel.org/stable/c/68a8e45743d6a120f863fb14b72dc59616597019","https://git.kernel.org/stable/c/92e5661b7d0727ab912b76625a88b33fdb9b609a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50003
|
Medium |
fixed |
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix system hang while resume with TBT monitor
[Why]
Connected with a Thunderbolt monitor and do the suspend and the system
may hang while resume.
The TBT monitor HPD will be triggered during the resume procedure
and call the drm_client_modeset_probe() while
struct drm_connector connector->dev->master is NULL.
It will mess up the pipe topology after resume.
[How]
Skip the TBT monitor HPD during the resume procedure because we
currently will probe the connectors after resume by default.
(cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85) |
["https://git.kernel.org/stable/c/52d4e3fb3d340447dcdac0e14ff21a764f326907","https://git.kernel.org/stable/c/68d603f467a75618eeae5bfe8af32cda47097010","https://git.kernel.org/stable/c/722d2d8fc423108597b97efbf165187d16d9aa1e","https://git.kernel.org/stable/c/73e441be033d3ed0bdff09b575da3e7d4606ffc9","https://git.kernel.org/stable/c/c2356296f546326f9f06c109e201d42201e1e783","https://git.kernel.org/stable/c/eb9329cd882aa274e92bdb1003bc088433fdee86"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50049
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check null pointer before dereferencing se
[WHAT & HOW]
se is null checked previously in the same function, indicating
it might be null; therefore, it must be checked when used again.
This fixes 1 FORWARD_NULL issue reported by Coverity. |
["https://git.kernel.org/stable/c/65b2d49e55fe13ae56da3a7685bdccadca31134a","https://git.kernel.org/stable/c/97a79933fb08a002ba9400d1a7a5df707ecdb896","https://git.kernel.org/stable/c/a9b4fd1946678fa0e069e442f3c5a7d3fa446fac","https://git.kernel.org/stable/c/c643ef59390e49f1dfab35e8ea65f5db5e527d64","https://git.kernel.org/stable/c/f4149eec960110ffd5bcb161075dd9f1d7773075","https://git.kernel.org/stable/c/ff599ef6970ee000fa5bc38d02fa5ff5f3fc7575"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50058
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
serial: protect uart_port_dtr_rts() in uart_shutdown() too
Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part
3) added few uport == NULL checks. It added one to uart_shutdown(), so
the commit assumes, uport can be NULL in there. But right after that
protection, there is an unprotected "uart_port_dtr_rts(uport, false);"
call. That is invoked only if HUPCL is set, so I assume that is the
reason why we do not see lots of these reports.
Or it cannot be NULL at this point at all for some reason :P.
Until the above is investigated, stay on the safe side and move this
dereference to the if too.
I got this inconsistency from Coverity under CID 1585130. Thanks. |
["https://git.kernel.org/stable/c/2fe399bb8efd0d325ab1138cf8e3ecf23a39e96d","https://git.kernel.org/stable/c/399927f0f875b93f3d5a0336d382ba48b8671eb2","https://git.kernel.org/stable/c/602babaa84d627923713acaf5f7e9a4369e77473","https://git.kernel.org/stable/c/76ed24a34223bb2c6b6162e1d8389ec4e602a290","https://git.kernel.org/stable/c/d7b5876a6e74cdf8468a478be6b23f2f5464ac7a","https://git.kernel.org/stable/c/e418d91195d29d5f9c9685ff309b92b04b41dc40"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50095
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mad: Improve handling of timed out WRs of mad agent
Current timeout handler of mad agent acquires/releases mad_agent_priv
lock for every timed out WRs. This causes heavy locking contention
when higher no. of WRs are to be handled inside timeout handler.
This leads to softlockup with below trace in some use cases where
rdma-cm path is used to establish connection between peer nodes
Trace:
-----
BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767]
CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE
------- --- 5.14.0-427.13.1.el9_4.x86_64 #1
Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019
Workqueue: ib_mad1 timeout_sends [ib_core]
RIP: 0010:__do_softirq+0x78/0x2ac
RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246
RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f
RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b
RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000
R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040
FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<IRQ>
? show_trace_log_lvl+0x1c4/0x2df
? show_trace_log_lvl+0x1c4/0x2df
? __irq_exit_rcu+0xa1/0xc0
? watchdog_timer_fn+0x1b2/0x210
? __pfx_watchdog_timer_fn+0x10/0x10
? __hrtimer_run_queues+0x127/0x2c0
? hrtimer_interrupt+0xfc/0x210
? __sysvec_apic_timer_interrupt+0x5c/0x110
? sysvec_apic_timer_interrupt+0x37/0x90
? asm_sysvec_apic_timer_interrupt+0x16/0x20
? __do_softirq+0x78/0x2ac
? __do_softirq+0x60/0x2ac
__irq_exit_rcu+0xa1/0xc0
sysvec_call_function_single+0x72/0x90
</IRQ>
<TASK>
asm_sysvec_call_function_single+0x16/0x20
RIP: 0010:_raw_spin_unlock_irq+0x14/0x30
RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247
RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800
RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c
RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000
R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538
R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c
cm_process_send_error+0x122/0x1d0 [ib_cm]
timeout_sends+0x1dd/0x270 [ib_core]
process_one_work+0x1e2/0x3b0
? __pfx_worker_thread+0x10/0x10
worker_thread+0x50/0x3a0
? __pfx_worker_thread+0x10/0x10
kthread+0xdd/0x100
? __pfx_kthread+0x10/0x10
ret_from_fork+0x29/0x50
</TASK>
Simplified timeout handler by creating local list of timed out WRs
and invoke send handler post creating the list. The new method acquires/
releases lock once to fetch the list and hence helps to reduce locking
contetiong when processing higher no. of WRs |
["https://git.kernel.org/stable/c/2a777679b8ccd09a9a65ea0716ef10365179caac","https://git.kernel.org/stable/c/3e799fa463508abe7a738ce5d0f62a8dfd05262a","https://git.kernel.org/stable/c/7022a517bf1ca37ef5a474365bcc5eafd345a13a","https://git.kernel.org/stable/c/713adaf0ecfc49405f6e5d9e409d984f628de818","https://git.kernel.org/stable/c/a195a42dd25ca4f12489687065d00be64939409f","https://git.kernel.org/stable/c/e80eadb3604a92d2d086e956b8b2692b699d4d0a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50134
|
Medium |
fixed |
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA
Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with
a real VLA to fix a "memcpy: detected field-spanning write error" warning:
[ 13.319813] memcpy: detected field-spanning write (size 16896) of single field "p->data" at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4)
[ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo]
[ 13.320038] Call Trace:
[ 13.320173] hgsmi_update_pointer_shape [vboxvideo]
[ 13.320184] vbox_cursor_atomic_update [vboxvideo]
Note as mentioned in the added comment it seems the original length
calculation for the allocated and send hgsmi buffer is 4 bytes too large.
Changing this is not the goal of this patch, so this behavior is kept. |
["https://git.kernel.org/stable/c/02c86c5d5ef4bbba17d38859c74872825f536617","https://git.kernel.org/stable/c/34a422274b693507025a7db21519865d1862afcb","https://git.kernel.org/stable/c/7458a6cdaebb3dc59af8578ee354fae78a154c4a","https://git.kernel.org/stable/c/75f828e944dacaac8870418461d3d48a1ecf2331","https://git.kernel.org/stable/c/9eb32bd23bbcec44bcbef27b7f282b7a7f3d0391","https://git.kernel.org/stable/c/d92b90f9a54d9300a6e883258e79f36dab53bfae","https://git.kernel.org/stable/c/fae9dc12c61ce23cf29d09824a741b7b1ff8f01f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47736
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
erofs: handle overlapped pclusters out of crafted images properly
syzbot reported a task hang issue due to a deadlock case where it is
waiting for the folio lock of a cached folio that will be used for
cache I/Os.
After looking into the crafted fuzzed image, I found it's formed with
several overlapped big pclusters as below:
Ext: logical offset | length : physical offset | length
0: 0.. 16384 | 16384 : 151552.. 167936 | 16384
1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384
2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384
...
Here, extent 0/1 are physically overlapped although it's entirely
_impossible_ for normal filesystem images generated by mkfs.
First, managed folios containing compressed data will be marked as
up-to-date and then unlocked immediately (unlike in-place folios) when
compressed I/Os are complete. If physical blocks are not submitted in
the incremental order, there should be separate BIOs to avoid dependency
issues. However, the current code mis-arranges z_erofs_fill_bio_vec()
and BIO submission which causes unexpected BIO waits.
Second, managed folios will be connected to their own pclusters for
efficient inter-queries. However, this is somewhat hard to implement
easily if overlapped big pclusters exist. Again, these only appear in
fuzzed images so let's simply fall back to temporary short-lived pages
for correctness.
Additionally, it justifies that referenced managed folios cannot be
truncated for now and reverts part of commit 2080ca1ed3e4 ("erofs: tidy
up `struct z_erofs_bvec`") for simplicity although it shouldn't be any
difference. |
["https://git.kernel.org/stable/c/1bf7e414cac303c9aec1be67872e19be8b64980c","https://git.kernel.org/stable/c/9cfa199bcbbbba31cbf97b2786f44f4464f3f29a","https://git.kernel.org/stable/c/9e2f9d34dd12e6e5b244ec488bcebd0c2d566c50","https://git.kernel.org/stable/c/b9b30af0e86ffb485301ecd83b9129c9dfb7ebf8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56369
|
Medium |
fixed |
- 5.15.176
- 6.1.122
- 6.6.68
- 6.12.7
|
In the Linux kernel, the following vulnerability has been resolved:
drm/modes: Avoid divide by zero harder in drm_mode_vrefresh()
drm_mode_vrefresh() is trying to avoid divide by zero
by checking whether htotal or vtotal are zero. But we may
still end up with a div-by-zero of vtotal*htotal*... |
["https://git.kernel.org/stable/c/47c8b6cf1d08f0ad40d7ea7b025442e51b35ee1f","https://git.kernel.org/stable/c/69fbb01e891701e6d04db1ddb5ad49e42c4dd963","https://git.kernel.org/stable/c/9398332f23fab10c5ec57c168b44e72997d6318e","https://git.kernel.org/stable/c/b39de5a71bac5641d0fda33d1cf5682d82cf1ae5","https://git.kernel.org/stable/c/e7c7b48a0fc5ed83baae400a1b15e33978c25d7f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49891
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths
When the HBA is undergoing a reset or is handling an errata event, NULL ptr
dereference crashes may occur in routines such as
lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or
lpfc_abort_handler().
Add NULL ptr checks before dereferencing hdwq pointers that may have been
freed due to operations colliding with a reset or errata event handler. |
["https://git.kernel.org/stable/c/232a138bd843d48cb2368f604646d990db7640f3","https://git.kernel.org/stable/c/2be1d4f11944cd6283cb97268b3e17c4424945ca","https://git.kernel.org/stable/c/5873aa7f814754085d418848b2089ef406a02dd0","https://git.kernel.org/stable/c/99a801e2fca39a6f31e543fc3383058a8955896f","https://git.kernel.org/stable/c/fd665c8dbdb19548965b0ae80c490de00e906366"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49897
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check phantom_stream before it is used
dcn32_enable_phantom_stream can return null, so returned value
must be checked before used.
This fixes 1 NULL_RETURNS issue reported by Coverity. |
["https://git.kernel.org/stable/c/1decf695ce08e23d9ded6ce83d121b2282ce9899","https://git.kernel.org/stable/c/3718a619a8c0a53152e76bb6769b6c414e1e83f4","https://git.kernel.org/stable/c/3ba1219e299ab5462b5cb374c2fa2a67af0ea190","https://git.kernel.org/stable/c/d247af7c5dbf143ad6be8179bb1550e76d6af57e","https://git.kernel.org/stable/c/db1d7e1794fed62ee16d6a72a85997bb069e2e27"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49898
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check null-initialized variables
[WHAT & HOW]
drr_timing and subvp_pipe are initialized to null and they are not
always assigned new values. It is necessary to check for null before
dereferencing.
This fixes 2 FORWARD_NULL issues reported by Coverity. |
["https://git.kernel.org/stable/c/115b1a3b0944b4d8ef0b4b0c5a625bdd9474131f","https://git.kernel.org/stable/c/26d262b79a3587aaa84368586a55e9026c67841b","https://git.kernel.org/stable/c/367cd9ceba1933b63bc1d87d967baf6d9fd241d2","https://git.kernel.org/stable/c/3fc70ae048fe0936761b73b50700a810ff61e853","https://git.kernel.org/stable/c/c3a3b6d9a9383e3c1a4a08878ba5046e68647595"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49909
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func
This commit adds a null check for the set_output_gamma function pointer
in the dcn32_set_output_transfer_func function. Previously,
set_output_gamma was being checked for null, but then it was being
dereferenced without any null check. This could lead to a null pointer
dereference if set_output_gamma is null.
To fix this, we now ensure that set_output_gamma is not null before
dereferencing it. We do this by adding a null check for set_output_gamma
before the call to set_output_gamma. |
["https://git.kernel.org/stable/c/28574b08c70e56d34d6f6379326a860b96749051","https://git.kernel.org/stable/c/496486950c3d2aebf46a3be300296ac091da7a2d","https://git.kernel.org/stable/c/5298270bdabe97be5b8236e544c9e936415fe1f2","https://git.kernel.org/stable/c/e087c9738ee1cdeebde346f4dfc819e5f7057e90","https://git.kernel.org/stable/c/f38b09ba6a335c511eb27920bb9bb4a1b2c20084"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49911
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func
This commit adds a null check for the set_output_gamma function pointer
in the dcn20_set_output_transfer_func function. Previously,
set_output_gamma was being checked for null at line 1030, but then it
was being dereferenced without any null check at line 1048. This could
potentially lead to a null pointer dereference error if set_output_gamma
is null.
To fix this, we now ensure that set_output_gamma is not null before
dereferencing it. We do this by adding a null check for set_output_gamma
before the call to set_output_gamma at line 1048. |
["https://git.kernel.org/stable/c/02411e9359297512946705b1cd8cf5e6b0806fa0","https://git.kernel.org/stable/c/62ed6f0f198da04e884062264df308277628004f","https://git.kernel.org/stable/c/827380b114f83c30b3e56d1a675980b6d65f7c88","https://git.kernel.org/stable/c/8c854138b593efbbd8fa46a25f3288c121c1d1a1","https://git.kernel.org/stable/c/e8a24767899c86f4c5f1e4d3b2608942d054900f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49915
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw
This commit addresses a potential null pointer dereference issue in the
`dcn32_init_hw` function. The issue could occur when `dc->clk_mgr` is
null.
The fix adds a check to ensure `dc->clk_mgr` is not null before
accessing its functions. This prevents a potential null pointer
dereference.
Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782) |
["https://git.kernel.org/stable/c/0d94d9cbd9fec7344d230c4f7b781826f7799c60","https://git.kernel.org/stable/c/7d1854c86d02cea8f8a0c0ca05f4ab14292baf3d","https://git.kernel.org/stable/c/c395fd47d1565bd67671f45cca281b3acc2c31ef","https://git.kernel.org/stable/c/ec1be3c527b4a5fc85bcc1b0be7cec08bf60c796","https://git.kernel.org/stable/c/f0454b3cb0584a6bf275aeb49be61a760fd546a2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49917
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw
This commit addresses a potential null pointer dereference issue in the
`dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or
`dc->clk_mgr->funcs` is null.
The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is
not null before accessing its functions. This prevents a potential null
pointer dereference.
Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628) |
["https://git.kernel.org/stable/c/205e3b96cc9aa9211fd2c849a16245cf236b2d36","https://git.kernel.org/stable/c/23cb6139543580dc36743586ca86fbb3f7ab2c9d","https://git.kernel.org/stable/c/5443c83eb8fd2f88c71ced38848fbf744d6206a2","https://git.kernel.org/stable/c/56c326577971adc3a230f29dfd3aa3abdd505f5d","https://git.kernel.org/stable/c/cba7fec864172dadd953daefdd26e01742b71a6a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49925
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
fbdev: efifb: Register sysfs groups through driver core
The driver core can register and cleanup sysfs groups already.
Make use of that functionality to simplify the error handling and
cleanup.
Also avoid a UAF race during unregistering where the sysctl attributes
were usable after the info struct was freed. |
["https://git.kernel.org/stable/c/2a9c40c72097b583b23aeb2a26d429ccfc81fbc1","https://git.kernel.org/stable/c/36bfefb6baaa8e46de44f4fd919ce4347337620f","https://git.kernel.org/stable/c/4684d69b9670a83992189f6271dc0fcdec4ed0d7","https://git.kernel.org/stable/c/872cd2d029d2c970a8a1eea88b48dab2b3f2e93a","https://git.kernel.org/stable/c/95cdd538e0e5677efbdf8aade04ec098ab98f457"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49929
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: avoid NULL pointer dereference
iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta
pointer is not NULL.
It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is
dereferencing the ieee80211_sta pointer.
If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL
pointer.
Fix this by checking the sta pointer before retrieving the mvmsta
from it. If sta is not NULL, then mvmsta isn't either. |
["https://git.kernel.org/stable/c/557a6cd847645e667f3b362560bd7e7c09aac284","https://git.kernel.org/stable/c/6dcadb2ed3b76623ab96e3e7fbeda1a374d01c28","https://git.kernel.org/stable/c/c0b4f5d94934c290479180868a32c15ba36a6d9e","https://git.kernel.org/stable/c/cbc6fc9cfcde151ff5eadaefdc6155f99579384f","https://git.kernel.org/stable/c/cdbf51bfa4b0411820806777da36d93d49bc49a1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49939
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: avoid to add interface to list twice when SER
If SER L2 occurs during the WoWLAN resume flow, the add interface flow
is triggered by ieee80211_reconfig(). However, due to
rtw89_wow_resume() return failure, it will cause the add interface flow
to be executed again, resulting in a double add list and causing a kernel
panic. Therefore, we have added a check to prevent double adding of the
list.
list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628.
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:37!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7
Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021
Workqueue: events_freezable ieee80211_restart_work [mac80211]
RIP: 0010:__list_add_valid_or_report+0x5e/0xb0
Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12
RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246
RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900
RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001
RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0
R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060
R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010
FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0
Call Trace:
<TASK>
? __die_body+0x1f/0x70
? die+0x3d/0x60
? do_trap+0xa4/0x110
? __list_add_valid_or_report+0x5e/0xb0
? do_error_trap+0x6d/0x90
? __list_add_valid_or_report+0x5e/0xb0
? handle_invalid_op+0x30/0x40
? __list_add_valid_or_report+0x5e/0xb0
? exc_invalid_op+0x3c/0x50
? asm_exc_invalid_op+0x16/0x20
? __list_add_valid_or_report+0x5e/0xb0
rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f]
drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]
ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]
? finish_wait+0x3e/0x90
? synchronize_rcu_expedited+0x174/0x260
? sync_rcu_exp_done_unlocked+0x50/0x50
? wake_bit_function+0x40/0x40
ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]
process_scheduled_works+0x1e5/0x480
worker_thread+0xea/0x1e0
kthread+0xdb/0x110
? move_linked_works+0x90/0x90
? kthread_associate_blkcg+0xa0/0xa0
ret_from_fork+0x3b/0x50
? kthread_associate_blkcg+0xa0/0xa0
ret_from_fork_asm+0x11/0x20
</TASK>
Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev
gsmi: Log Shutdown Reason 0x03
---[ end trace 0000000000000000 ]--- |
["https://git.kernel.org/stable/c/37c319503023de49a4c87301c8998c8d928112cb","https://git.kernel.org/stable/c/490eddc836b2a6ec286e5df14bed4c7cf5e1f475","https://git.kernel.org/stable/c/7dd5d2514a8ea58f12096e888b0bd050d7eae20a","https://git.kernel.org/stable/c/b04650b5a9990cf5c0de480e62c68199f1396a04","https://git.kernel.org/stable/c/fdc73f2cfbe897f4733156df211d79ced649b23c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-58071
|
Medium |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.129
- 6.6.76
- 6.12.13
- 6.13.2
|
In the Linux kernel, the following vulnerability has been resolved:
team: prevent adding a device which is already a team device lower
Prevent adding a device which is already a team device lower,
e.g. adding veth0 if vlan1 was already added and veth0 is a lower of
vlan1.
This is not useful in practice and can lead to recursive locking:
$ ip link add veth0 type veth peer name veth1
$ ip link set veth0 up
$ ip link set veth1 up
$ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1
$ ip link add team0 type team
$ ip link set veth0.1 down
$ ip link set veth0.1 master team0
team0: Port device veth0.1 added
$ ip link set veth0 down
$ ip link set veth0 master team0
============================================
WARNING: possible recursive locking detected
6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted
--------------------------------------------
ip/7684 is trying to acquire lock:
ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
but task is already holding lock:
ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977)
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(team->team_lock_key);
lock(team->team_lock_key);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by ip/7684:
stack backtrace:
CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl (lib/dump_stack.c:122)
print_deadlock_bug.cold (kernel/locking/lockdep.c:3040)
__lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226)
? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548)
lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851)
? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2))
? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
? lock_acquire (kernel/locking/lockdep.c:5822)
? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
__mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735)
? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
? fib_sync_up (net/ipv4/fib_semantics.c:2167)
? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
notifier_call_chain (kernel/notifier.c:85)
call_netdevice_notifiers_info (net/core/dev.c:1996)
__dev_notify_flags (net/core/dev.c:8993)
? __dev_change_flags (net/core/dev.c:8975)
dev_change_flags (net/core/dev.c:9027)
vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470)
? br_device_event (net/bridge/br.c:143)
notifier_call_chain (kernel/notifier.c:85)
call_netdevice_notifiers_info (net/core/dev.c:1996)
dev_open (net/core/dev.c:1519 net/core/dev.c:1505)
team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977)
? __pfx_team_add_slave (drivers/net/team/team_core.c:1972)
do_set_master (net/core/rtnetlink.c:2917)
do_setlink.isra.0 (net/core/rtnetlink.c:3117) |
["https://git.kernel.org/stable/c/0a7794b9ca78c8e7d001c583bf05736169de3f20","https://git.kernel.org/stable/c/184a564e6000b41582f160a5be9a9b5aabe22ac1","https://git.kernel.org/stable/c/1bb06f919fa5bec77ad9b6002525c3dcc5c1fd6c","https://git.kernel.org/stable/c/3fff5da4ca2164bb4d0f1e6cd33f6eb8a0e73e50","https://git.kernel.org/stable/c/62ff1615815d565448c37cb8a7a2a076492ec471","https://git.kernel.org/stable/c/adff6ac889e16d97abd1e4543f533221127e978a","https://git.kernel.org/stable/c/bd099a2fa9be983ba0e90a57a59484fe9d520ba8","https://git.kernel.org/stable/c/d9bce1310c0e2a55888e3e08c9f69d8377b3a377"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21749
|
Medium |
fixed |
- 6.1.129
- 6.6.78
- 6.12.14
- 6.13.3
|
In the Linux kernel, the following vulnerability has been resolved:
net: rose: lock the socket in rose_bind()
syzbot reported a soft lockup in rose_loopback_timer(),
with a repro calling bind() from multiple threads.
rose_bind() must lock the socket to avoid this issue. |
["https://git.kernel.org/stable/c/4c04b0ab3a647e76d0e752b013de8e404abafc63","https://git.kernel.org/stable/c/667f61b3498df751c8b3f0be1637e7226cbe3ed0","https://git.kernel.org/stable/c/970cd2ed26cdab2b0f15b6d90d7eaa36538244a5","https://git.kernel.org/stable/c/a1300691aed9ee852b0a9192e29e2bdc2411a7e6","https://git.kernel.org/stable/c/b8bf5c3fb778bbb1f3ff7d98ec577c969f687513","https://git.kernel.org/stable/c/d308661a0f4e7c8e86dfc7074a55ee5894c61538","https://git.kernel.org/stable/c/e0384efd45f615603e6869205b72040c209e69cc","https://git.kernel.org/stable/c/ed00c5f907d08a647b8bf987514ad8c6b17971a7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21859
|
Medium |
fixed |
- 6.1.130
- 6.6.80
- 6.12.17
- 6.13.5
|
In the Linux kernel, the following vulnerability has been resolved:
USB: gadget: f_midi: f_midi_complete to call queue_work
When using USB MIDI, a lock is attempted to be acquired twice through a
re-entrant call to f_midi_transmit, causing a deadlock.
Fix it by using queue_work() to schedule the inner f_midi_transmit() via
a high priority work queue from the completion handler. |
["https://git.kernel.org/stable/c/1f10923404705a94891e612dff3b75e828a78368","https://git.kernel.org/stable/c/24a942610ee9bafb2692a456ae850c5b2e409b05","https://git.kernel.org/stable/c/4ab37fcb42832cdd3e9d5e50653285ca84d6686f","https://git.kernel.org/stable/c/727dee0857946b85232526de4f5a957fe163e89a","https://git.kernel.org/stable/c/8aa6b4be1f4efccbfc533e6ec8841d26e4fa8dba","https://git.kernel.org/stable/c/b09957657d7767d164b3432af2129bd72947553c","https://git.kernel.org/stable/c/deeee3adb2c01eedab32c3b4519337689ad02e8a","https://git.kernel.org/stable/c/e9fec6f42c45db2f62dc373fb1a10d2488c04e79"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47809
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
dlm: fix possible lkb_resource null dereference
This patch fixes a possible null pointer dereference when this function is
called from request_lock() as lkb->lkb_resource is not assigned yet,
only after validate_lock_args() by calling attach_lkb(). Another issue
is that a resource name could be a non printable bytearray and we cannot
assume to be ASCII coded.
The log functionality is probably never being hit when DLM is used in
normal way and no debug logging is enabled. The null pointer dereference
can only occur on a new created lkb that does not have the resource
assigned yet, it probably never hits the null pointer dereference but we
should be sure that other changes might not change this behaviour and we
actually can hit the mentioned null pointer dereference.
In this patch we just drop the printout of the resource name, the lkb id
is enough to make a possible connection to a resource name if this
exists. |
["https://git.kernel.org/stable/c/2db11504ef82a60c1a2063ba7431a5cd013ecfcb","https://git.kernel.org/stable/c/6fbdc3980b70e9c1c86eccea7d5ee68108008fa7","https://git.kernel.org/stable/c/b98333c67daf887c724cd692e88e2db9418c0861"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21658
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: avoid NULL pointer dereference if no valid extent tree
[BUG]
Syzbot reported a crash with the following call trace:
BTRFS info (device loop0): scrub: started on devid 1
BUG: kernel NULL pointer dereference, address: 0000000000000208
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 106e70067 P4D 106e70067 PUD 107143067 PMD 0
Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 1 UID: 0 PID: 689 Comm: repro Kdump: loaded Tainted: G O 6.13.0-rc4-custom+ #206
Tainted: [O]=OOT_MODULE
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
RIP: 0010:find_first_extent_item+0x26/0x1f0 [btrfs]
Call Trace:
<TASK>
scrub_find_fill_first_stripe+0x13d/0x3b0 [btrfs]
scrub_simple_mirror+0x175/0x260 [btrfs]
scrub_stripe+0x5d4/0x6c0 [btrfs]
scrub_chunk+0xbb/0x170 [btrfs]
scrub_enumerate_chunks+0x2f4/0x5f0 [btrfs]
btrfs_scrub_dev+0x240/0x600 [btrfs]
btrfs_ioctl+0x1dc8/0x2fa0 [btrfs]
? do_sys_openat2+0xa5/0xf0
__x64_sys_ioctl+0x97/0xc0
do_syscall_64+0x4f/0x120
entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>
[CAUSE]
The reproducer is using a corrupted image where extent tree root is
corrupted, thus forcing to use "rescue=all,ro" mount option to mount the
image.
Then it triggered a scrub, but since scrub relies on extent tree to find
where the data/metadata extents are, scrub_find_fill_first_stripe()
relies on an non-empty extent root.
But unfortunately scrub_find_fill_first_stripe() doesn't really expect
an NULL pointer for extent root, it use extent_root to grab fs_info and
triggered a NULL pointer dereference.
[FIX]
Add an extra check for a valid extent root at the beginning of
scrub_find_fill_first_stripe().
The new error path is introduced by 42437a6386ff ("btrfs: introduce
mount option rescue=ignorebadroots"), but that's pretty old, and later
commit b979547513ff ("btrfs: scrub: introduce helper to find and fill
sector info for a scrub_stripe") changed how we do scrub.
So for kernels older than 6.6, the fix will need manual backport. |
["https://git.kernel.org/stable/c/24b85a8b0310e0144da9ab30be42e87e6476638a","https://git.kernel.org/stable/c/6aecd91a5c5b68939cf4169e32bc49f3cd2dd329","https://git.kernel.org/stable/c/aee5f69f3e6cd82bfefaca1b70b40b6cd8f3f784"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44956
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/preempt_fence: enlarge the fence critical section
It is really easy to introduce subtle deadlocks in
preempt_fence_work_func() since we operate on single global ordered-wq
for signalling our preempt fences behind the scenes, so even though we
signal a particular fence, everything in the callback should be in the
fence critical section, since blocking in the callback will prevent
other published fences from signalling. If we enlarge the fence critical
section to cover the entire callback, then lockdep should be able to
understand this better, and complain if we grab a sensitive lock like
vm->lock, which is also held when waiting on preempt fences. |
["https://git.kernel.org/stable/c/3cd1585e57908b6efcd967465ef7685f40b2a294","https://git.kernel.org/stable/c/458bb83119dfee5d14c677f7846dd9363817006f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48952
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
PCI: mt7621: Add sentinel to quirks table
Current driver is missing a sentinel in the struct soc_device_attribute
array, which causes an oops when assessed by the
soc_device_match(mt7621_pcie_quirks_match) call.
This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr
was fixed to register the SOC as a device, in:
commit 7c18b64bba3b ("mips: ralink: mt7621: do not use kzalloc too early")
Fix it by adding the required sentinel. |
["https://git.kernel.org/stable/c/19098934f910b4d47cb30251dd39ffa57bef9523","https://git.kernel.org/stable/c/3e9c395ef2d52975b2c2894d2da09d6db2958bc6","https://git.kernel.org/stable/c/a4997bae1b5b012c8a6e2643e26578a7bc2cae36","https://git.kernel.org/stable/c/cb7323ece786f243f6d6ccf2e5b2b27b736bdc04"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48959
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: sja1105: fix memory leak in sja1105_setup_devlink_regions()
When dsa_devlink_region_create failed in sja1105_setup_devlink_regions(),
priv->regions is not released. |
["https://git.kernel.org/stable/c/4be43e46c3f945fc7dd9e23c73a7a66927a3b814","https://git.kernel.org/stable/c/78a9ea43fc1a7c06a420b132d2d47cbf4344a5df","https://git.kernel.org/stable/c/e5e59629654b8826f0167dae480d0e3fa0f8f038","https://git.kernel.org/stable/c/f3b5dda26cd0535aac09ed09c5d83f19b979ec9f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48995
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
Input: raydium_ts_i2c - fix memory leak in raydium_i2c_send()
There is a kmemleak when test the raydium_i2c_ts with bpf mock device:
unreferenced object 0xffff88812d3675a0 (size 8):
comm "python3", pid 349, jiffies 4294741067 (age 95.695s)
hex dump (first 8 bytes):
11 0e 10 c0 01 00 04 00 ........
backtrace:
[<0000000068427125>] __kmalloc+0x46/0x1b0
[<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts]
[<000000006e631aee>] raydium_i2c_initialize.cold+0xbc/0x3e4 [raydium_i2c_ts]
[<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts]
[<00000000a310de16>] i2c_device_probe+0x651/0x680
[<00000000f5a96bf3>] really_probe+0x17c/0x3f0
[<00000000096ba499>] __driver_probe_device+0xe3/0x170
[<00000000c5acb4d9>] driver_probe_device+0x49/0x120
[<00000000264fe082>] __device_attach_driver+0xf7/0x150
[<00000000f919423c>] bus_for_each_drv+0x114/0x180
[<00000000e067feca>] __device_attach+0x1e5/0x2d0
[<0000000054301fc2>] bus_probe_device+0x126/0x140
[<00000000aad93b22>] device_add+0x810/0x1130
[<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0
[<000000003c2c248c>] of_i2c_register_device+0xf1/0x110
[<00000000ffec4177>] of_i2c_notify+0x100/0x160
unreferenced object 0xffff88812d3675c8 (size 8):
comm "python3", pid 349, jiffies 4294741070 (age 95.692s)
hex dump (first 8 bytes):
22 00 36 2d 81 88 ff ff ".6-....
backtrace:
[<0000000068427125>] __kmalloc+0x46/0x1b0
[<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts]
[<000000001d5c9620>] raydium_i2c_initialize.cold+0x223/0x3e4 [raydium_i2c_ts]
[<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts]
[<00000000a310de16>] i2c_device_probe+0x651/0x680
[<00000000f5a96bf3>] really_probe+0x17c/0x3f0
[<00000000096ba499>] __driver_probe_device+0xe3/0x170
[<00000000c5acb4d9>] driver_probe_device+0x49/0x120
[<00000000264fe082>] __device_attach_driver+0xf7/0x150
[<00000000f919423c>] bus_for_each_drv+0x114/0x180
[<00000000e067feca>] __device_attach+0x1e5/0x2d0
[<0000000054301fc2>] bus_probe_device+0x126/0x140
[<00000000aad93b22>] device_add+0x810/0x1130
[<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0
[<000000003c2c248c>] of_i2c_register_device+0xf1/0x110
[<00000000ffec4177>] of_i2c_notify+0x100/0x160
After BANK_SWITCH command from i2c BUS, no matter success or error
happened, the tx_buf should be freed. |
["https://git.kernel.org/stable/c/097c1c7a28e3da8f2811ba532be6e81faab15aab","https://git.kernel.org/stable/c/53b9b1201e34ccc895971218559123625c56fbcd","https://git.kernel.org/stable/c/8c9a59939deb4bfafdc451100c03d1e848b4169b","https://git.kernel.org/stable/c/a82869ac52f3d9db4b2cf8fd41edc2dee7a75a61"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50098
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down
There is a history of deadlock if reboot is performed at the beginning
of booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFS
shutdown, and at that time the audio driver was waiting on
blk_mq_submit_bio() holding a mutex_lock while reading the fw binary.
After that, a deadlock issue occurred while audio driver shutdown was
waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set
SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down
after a UFS shutdown will return an error.
[ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown]
[ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49]
[ 31.907806]I[0: swapper/0: 0] Call trace:
[ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338
[ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc
[ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8
[ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40
[ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac
[ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24
[ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec
[ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280
[ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c
[ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280
[ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158
[ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4
[ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0
[ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0
[ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4
[ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4
[ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter]
[ 31.908783]I[0: swapper/0: 0] Call trace:
[ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338
[ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc
[ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8
[ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178
[ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c
[ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c |
["https://git.kernel.org/stable/c/19a198b67767d952c8f3d0cf24eb3100522a8223","https://git.kernel.org/stable/c/7774d23622416dbbbdb21bf342b3f0d92cf1dc0f","https://git.kernel.org/stable/c/7bd9af254275fad7071d85f04616560deb598d7d","https://git.kernel.org/stable/c/7de759fceacff5660abf9590d11114215a9d5f3c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47735
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled
Fix missuse of spin_lock_irq()/spin_unlock_irq() when
spin_lock_irqsave()/spin_lock_irqrestore() was hold.
This was discovered through the lock debugging, and the corresponding
log is as follows:
raw_local_irq_restore() called with IRQs enabled
WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40
...
Call trace:
warn_bogus_irq_restore+0x30/0x40
_raw_spin_unlock_irqrestore+0x84/0xc8
add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2]
hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2]
hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2]
create_qp+0x138/0x258
ib_create_qp_kernel+0x50/0xe8
create_mad_qp+0xa8/0x128
ib_mad_port_open+0x218/0x448
ib_mad_init_device+0x70/0x1f8
add_client_context+0xfc/0x220
enable_device_and_get+0xd0/0x140
ib_register_device.part.0+0xf4/0x1c8
ib_register_device+0x34/0x50
hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2]
hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2]
__hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2]
hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2] |
["https://git.kernel.org/stable/c/07f0f643d7e570dbe8ef6f5c3367a43e3086a335","https://git.kernel.org/stable/c/094a1821903f33fb91de4b71087773ee16aeb3a0","https://git.kernel.org/stable/c/2656336a84fcb6802f6e6c233f4661891deea24f","https://git.kernel.org/stable/c/29c0f546d3fd66238b42cf25bcd5f193bb1cf794","https://git.kernel.org/stable/c/425589d4af09c49574bd71ac31f811362a5126c3","https://git.kernel.org/stable/c/74d315b5af180220d561684d15897730135733a6","https://git.kernel.org/stable/c/a1a3403bb1826c8ec787f0d60c3e7b54f419129e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49985
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume
In case there is any sort of clock controller attached to this I2C bus
controller, for example Versaclock or even an AIC32x4 I2C codec, then
an I2C transfer triggered from the clock controller clk_ops .prepare
callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex.
This is because the clock controller first grabs the prepare_lock mutex
and then performs the prepare operation, including its I2C access. The
I2C access resumes this I2C bus controller via .runtime_resume callback,
which calls clk_prepare_enable(), which attempts to grab the prepare_lock
mutex again and deadlocks.
Since the clock are already prepared since probe() and unprepared in
remove(), use simple clk_enable()/clk_disable() calls to enable and
disable the clock on runtime suspend and resume, to avoid hitting the
prepare_lock mutex. |
["https://git.kernel.org/stable/c/048bbbdbf85e5e00258dfb12f5e368f908801d7b","https://git.kernel.org/stable/c/1883cad2cc629ded4a3556c0bbb8b42533ad8764","https://git.kernel.org/stable/c/22a1f8a5b56ba93d3e8b7a1dafa24e01c8bb48ba","https://git.kernel.org/stable/c/894cd5f5fd9061983445bbd1fa3d81be43095344","https://git.kernel.org/stable/c/9b8bc33ad64192f54142396470cc34ce539a8940","https://git.kernel.org/stable/c/c2024b1a583ab9176c797ea1e5f57baf8d5e2682","https://git.kernel.org/stable/c/d6f1250a4d5773f447740b9fe37b8692105796d4","https://git.kernel.org/stable/c/fac3c9f7784e8184c0338e9f0877b81e55d3ef1c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49858
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption
The TPM event log table is a Linux specific construct, where the data
produced by the GetEventLog() boot service is cached in memory, and
passed on to the OS using an EFI configuration table.
The use of EFI_LOADER_DATA here results in the region being left
unreserved in the E820 memory map constructed by the EFI stub, and this
is the memory description that is passed on to the incoming kernel by
kexec, which is therefore unaware that the region should be reserved.
Even though the utility of the TPM2 event log after a kexec is
questionable, any corruption might send the parsing code off into the
weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY
instead, which is always treated as reserved by the E820 conversion
logic. |
["https://git.kernel.org/stable/c/11690d7e76842f29b60fbb5b35bc97d206ea0e83","https://git.kernel.org/stable/c/19fd2f2c5fb36b61506d3208474bfd8fdf1cada3","https://git.kernel.org/stable/c/2e6871a632a99d9b9e2ce3a7847acabe99e5a26e","https://git.kernel.org/stable/c/38d9b07d99b789efb6d8dda21f1aaad636c38993","https://git.kernel.org/stable/c/5b22c038fb2757c652642933de5664da471f8cb7","https://git.kernel.org/stable/c/77d48d39e99170b528e4f2e9fc5d1d64cdedd386","https://git.kernel.org/stable/c/f76b69ab9cf04358266e3cea5748c0c2791fbb08"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42239
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fail bpf_timer_cancel when callback is being cancelled
Given a schedule:
timer1 cb timer2 cb
bpf_timer_cancel(timer2); bpf_timer_cancel(timer1);
Both bpf_timer_cancel calls would wait for the other callback to finish
executing, introducing a lockup.
Add an atomic_t count named 'cancelling' in bpf_hrtimer. This keeps
track of all in-flight cancellation requests for a given BPF timer.
Whenever cancelling a BPF timer, we must check if we have outstanding
cancellation requests, and if so, we must fail the operation with an
error (-EDEADLK) since cancellation is synchronous and waits for the
callback to finish executing. This implies that we can enter a deadlock
situation involving two or more timer callbacks executing in parallel
and attempting to cancel one another.
Note that we avoid incrementing the cancelling counter for the target
timer (the one being cancelled) if bpf_timer_cancel is not invoked from
a callback, to avoid spurious errors. The whole point of detecting
cur->cancelling and returning -EDEADLK is to not enter a busy wait loop
(which may or may not lead to a lockup). This does not apply in case the
caller is in a non-callback context, the other side can continue to
cancel as it sees fit without running into errors.
Background on prior attempts:
Earlier versions of this patch used a bool 'cancelling' bit and used the
following pattern under timer->lock to publish cancellation status.
lock(t->lock);
t->cancelling = true;
mb();
if (cur->cancelling)
return -EDEADLK;
unlock(t->lock);
hrtimer_cancel(t->timer);
t->cancelling = false;
The store outside the critical section could overwrite a parallel
requests t->cancelling assignment to true, to ensure the parallely
executing callback observes its cancellation status.
It would be necessary to clear this cancelling bit once hrtimer_cancel
is done, but lack of serialization introduced races. Another option was
explored where bpf_timer_start would clear the bit when (re)starting the
timer under timer->lock. This would ensure serialized access to the
cancelling bit, but may allow it to be cleared before in-flight
hrtimer_cancel has finished executing, such that lockups can occur
again.
Thus, we choose an atomic counter to keep track of all outstanding
cancellation requests and use it to prevent lockups in case callbacks
attempt to cancel each other while executing in parallel. |
["https://git.kernel.org/stable/c/3e4e8178a8666c56813bd167b848fca0f4c9af0a","https://git.kernel.org/stable/c/9369830518688ecd5b08ffc08ab3302ce2b5d0f7","https://git.kernel.org/stable/c/d4523831f07a267a943f0dde844bf8ead7495f13"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50166
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
fsl/fman: Fix refcount handling of fman-related devices
In mac_probe() there are multiple calls to of_find_device_by_node(),
fman_bind() and fman_port_bind() which takes references to of_dev->dev.
Not all references taken by these calls are released later on error path
in mac_probe() and in mac_remove() which lead to reference leaks.
Add references release. |
["https://git.kernel.org/stable/c/1dec67e0d9fbb087c2ab17bf1bd17208231c3bb1","https://git.kernel.org/stable/c/3c2a3619d565fe16bf59b0a047bab103a2ee4490","https://git.kernel.org/stable/c/5ed4334fc9512f934fe2ae9c4cf7f8142e451b8b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46783
|
Medium |
fixed |
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
tcp_bpf: fix return value of tcp_bpf_sendmsg()
When we cork messages in psock->cork, the last message triggers the
flushing will result in sending a sk_msg larger than the current
message size. In this case, in tcp_bpf_send_verdict(), 'copied' becomes
negative at least in the following case:
468 case __SK_DROP:
469 default:
470 sk_msg_free_partial(sk, msg, tosend);
471 sk_msg_apply_bytes(psock, tosend);
472 *copied -= (tosend + delta); // <==== HERE
473 return -EACCES;
Therefore, it could lead to the following BUG with a proper value of
'copied' (thanks to syzbot). We should not use negative 'copied' as a
return value here.
------------[ cut here ]------------
kernel BUG at net/socket.c:733!
Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 UID: 0 PID: 3265 Comm: syz-executor510 Not tainted 6.11.0-rc3-syzkaller-00060-gd07b43284ab3 #0
Hardware name: linux,dummy-virt (DT)
pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
pc : sock_sendmsg_nosec net/socket.c:733 [inline]
pc : sock_sendmsg_nosec net/socket.c:728 [inline]
pc : __sock_sendmsg+0x5c/0x60 net/socket.c:745
lr : sock_sendmsg_nosec net/socket.c:730 [inline]
lr : __sock_sendmsg+0x54/0x60 net/socket.c:745
sp : ffff800088ea3b30
x29: ffff800088ea3b30 x28: fbf00000062bc900 x27: 0000000000000000
x26: ffff800088ea3bc0 x25: ffff800088ea3bc0 x24: 0000000000000000
x23: f9f00000048dc000 x22: 0000000000000000 x21: ffff800088ea3d90
x20: f9f00000048dc000 x19: ffff800088ea3d90 x18: 0000000000000001
x17: 0000000000000000 x16: 0000000000000000 x15: 000000002002ffaf
x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000000 x10: ffff8000815849c0 x9 : ffff8000815b49c0
x8 : 0000000000000000 x7 : 000000000000003f x6 : 0000000000000000
x5 : 00000000000007e0 x4 : fff07ffffd239000 x3 : fbf00000062bc900
x2 : 0000000000000000 x1 : 0000000000000000 x0 : 00000000fffffdef
Call trace:
sock_sendmsg_nosec net/socket.c:733 [inline]
__sock_sendmsg+0x5c/0x60 net/socket.c:745
____sys_sendmsg+0x274/0x2ac net/socket.c:2597
___sys_sendmsg+0xac/0x100 net/socket.c:2651
__sys_sendmsg+0x84/0xe0 net/socket.c:2680
__do_sys_sendmsg net/socket.c:2689 [inline]
__se_sys_sendmsg net/socket.c:2687 [inline]
__arm64_sys_sendmsg+0x24/0x30 net/socket.c:2687
__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
invoke_syscall+0x48/0x110 arch/arm64/kernel/syscall.c:49
el0_svc_common.constprop.0+0x40/0xe0 arch/arm64/kernel/syscall.c:132
do_el0_svc+0x1c/0x28 arch/arm64/kernel/syscall.c:151
el0_svc+0x34/0xec arch/arm64/kernel/entry-common.c:712
el0t_64_sync_handler+0x100/0x12c arch/arm64/kernel/entry-common.c:730
el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:598
Code: f9404463 d63f0060 3108441f 54fffe81 (d4210000)
---[ end trace 0000000000000000 ]--- |
["https://git.kernel.org/stable/c/126d72b726c4cf1119f3a7fe413a78d341c3fea9","https://git.kernel.org/stable/c/3efe53eb221a38e207c1e3f81c51e4ca057d50c2","https://git.kernel.org/stable/c/6f9fdf5806cced888c43512bccbdf7fefd50f510","https://git.kernel.org/stable/c/78bb38d9c5a311c5f8bdef7c9557d7d81ca30e4a","https://git.kernel.org/stable/c/810a4e7d92dea4074cb04c25758320909d752193","https://git.kernel.org/stable/c/c8219a27fa43a2cbf99f5176f6dddfe73e7a24ae","https://git.kernel.org/stable/c/fe1910f9337bd46a9343967b547ccab26b4b2c6e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46817
|
Medium |
fixed |
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.109
- 6.6.50
- 6.10.9
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Stop amdgpu_dm initialize when stream nums greater than 6
[Why]
Coverity reports OVERRUN warning. Should abort amdgpu_dm
initialize.
[How]
Return failure to amdgpu_dm_init. |
["https://git.kernel.org/stable/c/21bbb39863f10f5fb4bf772d15b07d5d13590e9d","https://git.kernel.org/stable/c/28b515c458aa9c92bfcb99884c94713a5f471cea","https://git.kernel.org/stable/c/754321ed63f0a4a31252ca72e0bd89a9e1888018","https://git.kernel.org/stable/c/84723eb6068c50610c5c0893980d230d7afa2105","https://git.kernel.org/stable/c/94cb77700fa4ae6200486bfa0ba2ac547534afd2","https://git.kernel.org/stable/c/d398c74c881dee695f6eb6138c9891644e1c3d9d","https://git.kernel.org/stable/c/d619b91d3c4af60ac422f1763ce53d721fb91262"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50177
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: fix a UBSAN warning in DML2.1
When programming phantom pipe, since cursor_width is explicity set to 0,
this causes calculation logic to trigger overflow for an unsigned int
triggering the kernel's UBSAN check as below:
[ 40.962845] UBSAN: shift-out-of-bounds in /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34
[ 40.962849] shift exponent 4294967170 is too large for 32-bit type 'unsigned int'
[ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu
[ 40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024
[ 40.962856] Call Trace:
[ 40.962857] <TASK>
[ 40.962860] dump_stack_lvl+0x48/0x70
[ 40.962870] dump_stack+0x10/0x20
[ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360
[ 40.962878] calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu]
[ 40.963099] dml_core_mode_support+0x6b91/0x16bc0 [amdgpu]
[ 40.963327] ? srso_alias_return_thunk+0x5/0x7f
[ 40.963331] ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu]
[ 40.963534] ? srso_alias_return_thunk+0x5/0x7f
[ 40.963536] ? dml_core_mode_support+0xb3db/0x16bc0 [amdgpu]
[ 40.963730] dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu]
[ 40.963906] ? srso_alias_return_thunk+0x5/0x7f
[ 40.963909] ? dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu]
[ 40.964078] core_dcn4_mode_support+0x72/0xbf0 [amdgpu]
[ 40.964247] dml2_top_optimization_perform_optimization_phase+0x1d3/0x2a0 [amdgpu]
[ 40.964420] dml2_build_mode_programming+0x23d/0x750 [amdgpu]
[ 40.964587] dml21_validate+0x274/0x770 [amdgpu]
[ 40.964761] ? srso_alias_return_thunk+0x5/0x7f
[ 40.964763] ? resource_append_dpp_pipes_for_plane_composition+0x27c/0x3b0 [amdgpu]
[ 40.964942] dml2_validate+0x504/0x750 [amdgpu]
[ 40.965117] ? dml21_copy+0x95/0xb0 [amdgpu]
[ 40.965291] ? srso_alias_return_thunk+0x5/0x7f
[ 40.965295] dcn401_validate_bandwidth+0x4e/0x70 [amdgpu]
[ 40.965491] update_planes_and_stream_state+0x38d/0x5c0 [amdgpu]
[ 40.965672] update_planes_and_stream_v3+0x52/0x1e0 [amdgpu]
[ 40.965845] ? srso_alias_return_thunk+0x5/0x7f
[ 40.965849] dc_update_planes_and_stream+0x71/0xb0 [amdgpu]
Fix this by adding a guard for checking cursor width before triggering
the size calculation. |
["https://git.kernel.org/stable/c/27bc3da5eae57e3af8f5648b4498ffde48781434","https://git.kernel.org/stable/c/eaf3adb8faab611ba57594fa915893fc93a7788c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46803
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Check debug trap enable before write dbg_ev_file
In interrupt context, write dbg_ev_file will be run by work queue. It
will cause write dbg_ev_file execution after debug_trap_disable, which
will cause NULL pointer access.
v2: cancel work "debug_event_workarea" before set dbg_ev_file as NULL. |
["https://git.kernel.org/stable/c/547033b593063eb85bfdf9b25a5f1b8fd1911be2","https://git.kernel.org/stable/c/820dcbd38a77bd5fdc4236d521c1c122841227d0","https://git.kernel.org/stable/c/e6ea3b8fe398915338147fe54dd2db8155fdafd8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2020-10742
|
Medium |
|
N/A
|
A flaw was found in the Linux kernel. An index buffer overflow during Direct IO write leading to the NFS client to crash. In some cases, a reach out of the index after one memory allocation by kmalloc will cause a kernel panic. The highest threat from this vulnerability is to data confidentiality and system availability. |
["https://bugzilla.redhat.com/show_bug.cgi?id=1835127","https://bugzilla.redhat.com/show_bug.cgi?id=1835127"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-2327
|
High |
|
N/A
|
io_uring use work_flags to determine which identity need to grab from the calling process to make sure it is consistent with the calling process when executing IORING_OP. Some operations are missing some types, which can lead to incorrect reference counts which can then lead to a double free. We recommend upgrading the kernel past commit df3f3bb5059d20ef094d6b2f0256c4bf4127a859 |
["https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y\u0026id=df3f3bb5059d20ef094d6b2f0256c4bf4127a859","https://kernel.dance/#df3f3bb5059d20ef094d6b2f0256c4bf4127a859","https://security.netapp.com/advisory/ntap-20230203-0009/","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y\u0026id=df3f3bb5059d20ef094d6b2f0256c4bf4127a859","https://kernel.dance/#df3f3bb5059d20ef094d6b2f0256c4bf4127a859","https://security.netapp.com/advisory/ntap-20230203-0009/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52746
|
Low |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
xfrm/compat: prevent potential spectre v1 gadget in xfrm_xlate32_attr()
int type = nla_type(nla);
if (type > XFRMA_MAX) {
return -EOPNOTSUPP;
}
@type is then used as an array index and can be used
as a Spectre v1 gadget.
if (nla_len(nla) < compat_policy[type].len) {
array_index_nospec() can be used to prevent leaking
content of kernel memory to malicious users. |
["https://git.kernel.org/stable/c/419674224390fca298020fc0751a20812f84b12d","https://git.kernel.org/stable/c/5dc688fae6b7be9dbbf5304a3d2520d038e06db5","https://git.kernel.org/stable/c/a893cc644812728e86e9aff517fd5698812ecef0","https://git.kernel.org/stable/c/b6ee896385380aa621102e8ea402ba12db1cabff","https://git.kernel.org/stable/c/419674224390fca298020fc0751a20812f84b12d","https://git.kernel.org/stable/c/5dc688fae6b7be9dbbf5304a3d2520d038e06db5","https://git.kernel.org/stable/c/a893cc644812728e86e9aff517fd5698812ecef0","https://git.kernel.org/stable/c/b6ee896385380aa621102e8ea402ba12db1cabff"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42156
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
s390/pkey: Wipe copies of clear-key structures on failure
Wipe all sensitive data from stack for all IOCTLs, which convert a
clear-key into a protected- or secure-key. |
["https://git.kernel.org/stable/c/7f6243edd901b75aaece326c90a1cc0dcb60cc3d","https://git.kernel.org/stable/c/a891938947f4427f98cb1ce54f27223501efe750","https://git.kernel.org/stable/c/d65d76a44ffe74c73298ada25b0f578680576073","https://git.kernel.org/stable/c/7f6243edd901b75aaece326c90a1cc0dcb60cc3d","https://git.kernel.org/stable/c/d65d76a44ffe74c73298ada25b0f578680576073"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1943
|
High |
fixed |
|
A flaw out of bounds memory write in the Linux kernel UDF file system functionality was found in the way user triggers some file operation which triggers udf_write_fi(). A local user could use this flaw to crash the system or potentially |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c1ad35dd0548ce947d97aaf92f7f2f9a202951cf","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c1ad35dd0548ce947d97aaf92f7f2f9a202951cf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-28893
|
High |
fixed |
- 5.4.196
- 5.10.117
- 5.15.41
- 5.16.20
- 5.17.3
|
The SUNRPC subsystem in the Linux kernel through 5.17.2 can call xs_xprt_free before ensuring that sockets are in the intended state. |
["http://www.openwall.com/lists/oss-security/2022/04/11/3","http://www.openwall.com/lists/oss-security/2022/04/11/4","http://www.openwall.com/lists/oss-security/2022/04/11/5","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1a3b1bba7c7a5eb8a11513cf88427cb9d77bc60a","https://security.netapp.com/advisory/ntap-20220526-0002/","https://www.debian.org/security/2022/dsa-5161","http://www.openwall.com/lists/oss-security/2022/04/11/3","http://www.openwall.com/lists/oss-security/2022/04/11/4","http://www.openwall.com/lists/oss-security/2022/04/11/5","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1a3b1bba7c7a5eb8a11513cf88427cb9d77bc60a","https://security.netapp.com/advisory/ntap-20220526-0002/","https://www.debian.org/security/2022/dsa-5161"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-30594
|
High |
fixed |
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
The Linux kernel before 5.17.2 mishandles seccomp permissions. The PTRACE_SEIZE code path allows attackers to bypass intended restrictions on setting the PT_SUSPEND_SECCOMP flag. |
["http://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html","http://packetstormsecurity.com/files/170362/Linux-PT_SUSPEND_SECCOMP-Permission-Bypass-Ptracer-Death-Race.html","https://bugs.chromium.org/p/project-zero/issues/detail?id=2276","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ee1fee900537b5d9560e9f937402de5ddc8412f3","https://github.com/torvalds/linux/commit/ee1fee900537b5d9560e9f937402de5ddc8412f3","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://security.netapp.com/advisory/ntap-20220707-0001/","https://www.debian.org/security/2022/dsa-5173","http://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html","http://packetstormsecurity.com/files/170362/Linux-PT_SUSPEND_SECCOMP-Permission-Bypass-Ptracer-Death-Race.html","https://bugs.chromium.org/p/project-zero/issues/detail?id=2276","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ee1fee900537b5d9560e9f937402de5ddc8412f3","https://github.com/torvalds/linux/commit/ee1fee900537b5d9560e9f937402de5ddc8412f3","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://security.netapp.com/advisory/ntap-20220707-0001/","https://www.debian.org/security/2022/dsa-5173"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48958
|
Medium |
fixed |
- 4.9.336
- 4.14.302
- 4.19.269
- 5.4.227
- 5.10.159
- 5.15.83
- 6.0.13
|
In the Linux kernel, the following vulnerability has been resolved:
ethernet: aeroflex: fix potential skb leak in greth_init_rings()
The greth_init_rings() function won't free the newly allocated skb when
dma_mapping_error() returns error, so add dev_kfree_skb() to fix it.
Compile tested only. |
["https://git.kernel.org/stable/c/063a932b64db3317ec020c94466fe52923a15f60","https://git.kernel.org/stable/c/223654e2e2c8d05347cd8e300f8d1ec6023103dd","https://git.kernel.org/stable/c/87277bdf2c370ab2d07cfe77dfa9b37f82bbe1e5","https://git.kernel.org/stable/c/99669d94ce145389f1d6f197e6e18ed50d43fb76","https://git.kernel.org/stable/c/bfaa8f6c5b84b295dd73b0138b57c5555ca12b1c","https://git.kernel.org/stable/c/c7adcbd0fd3fde1b19150c3e955fb4a30c5bd9b7","https://git.kernel.org/stable/c/cb1e293f858e5e1152b8791047ed4bdaaf392189","https://git.kernel.org/stable/c/dd62867a6383f78f75f07039394aac25924a3307"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48971
|
Medium |
fixed |
- 4.19.269
- 5.4.227
- 5.10.159
- 5.15.83
- 6.0.13
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix not cleanup led when bt_init fails
bt_init() calls bt_leds_init() to register led, but if it fails later,
bt_leds_cleanup() is not called to unregister it.
This can cause panic if the argument "bluetooth-power" in text is freed
and then another led_trigger_register() tries to access it:
BUG: unable to handle page fault for address: ffffffffc06d3bc0
RIP: 0010:strcmp+0xc/0x30
Call Trace:
<TASK>
led_trigger_register+0x10d/0x4f0
led_trigger_register_simple+0x7d/0x100
bt_init+0x39/0xf7 [bluetooth]
do_one_initcall+0xd0/0x4e0 |
["https://git.kernel.org/stable/c/2c6cf0afc3856359e620e96edd952457d258e16c","https://git.kernel.org/stable/c/2f3957c7eb4e07df944169a3e50a4d6790e1c744","https://git.kernel.org/stable/c/5ecf7cd6fde5e72c87122084cf00d63e35d8dd9f","https://git.kernel.org/stable/c/8a66c3a94285552f6a8e45d73b34ebbad11d388b","https://git.kernel.org/stable/c/e7b950458156d410509a08c41930b75e72985938","https://git.kernel.org/stable/c/edf7284a98296369dd0891a0457eec37df244873"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48973
|
Medium |
fixed |
- 4.9.336
- 4.14.302
- 4.19.269
- 5.4.227
- 5.10.159
- 5.15.83
- 6.0.13
|
In the Linux kernel, the following vulnerability has been resolved:
gpio: amd8111: Fix PCI device reference count leak
for_each_pci_dev() is implemented by pci_get_device(). The comment of
pci_get_device() says that it will increase the reference count for the
returned pci_dev and also decrease the reference count for the input
pci_dev @from if it is not NULL.
If we break for_each_pci_dev() loop with pdev not NULL, we need to call
pci_dev_put() to decrease the reference count. Add the missing
pci_dev_put() after the 'out' label. Since pci_dev_put() can handle NULL
input parameter, there is no problem for the 'Device not found' branch.
For the normal path, add pci_dev_put() in amd_gpio_exit(). |
["https://git.kernel.org/stable/c/4271515f189bd5fe2ec86b4089dab7cb804625d2","https://git.kernel.org/stable/c/45fecdb9f658d9c82960c98240bc0770ade19aca","https://git.kernel.org/stable/c/4749c5cc147c9860b96db1e71cc36d1de1bd3f59","https://git.kernel.org/stable/c/48bd5d3801f6b67cc144449d434abbd5043a6d37","https://git.kernel.org/stable/c/5ee6413d3dd972930af787b2c0c7aaeb379fa521","https://git.kernel.org/stable/c/71d591ef873f9ebb86cd8d053b3caee785b2de6a","https://git.kernel.org/stable/c/b2bc053ebbba57a06fa655db5ea796de2edce445","https://git.kernel.org/stable/c/e364ce04d8f840478b09eee57b614de7cf1e743e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49005
|
Medium |
fixed |
- 4.9.335
- 4.14.301
- 4.19.268
- 5.4.226
- 5.10.158
- 5.15.82
- 5.17
- 6.0.12
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: ops: Fix bounds check for _sx controls
For _sx controls the semantics of the max field is not the usual one, max
is the number of steps rather than the maximum value. This means that our
check in snd_soc_put_volsw_sx() needs to just check against the maximum
value. |
["https://git.kernel.org/stable/c/325d94d16e3131b54bdf07356e4cd855e0d853fc","https://git.kernel.org/stable/c/46bab25cc0230df60d1c02b651cc5640a14b08df","https://git.kernel.org/stable/c/4a95a49f26308782b4056401989ecd7768fda8fa","https://git.kernel.org/stable/c/698813ba8c580efb356ace8dbf55f61dac6063a8","https://git.kernel.org/stable/c/73dce3c1d48c4662bdf3ccbde1492c2cb4bfd8ce","https://git.kernel.org/stable/c/98b15c706644bebc19d2e77ccc360cc51444f6d0","https://git.kernel.org/stable/c/b50c9641897274c3faef5f95ac852f54b94be2e8","https://git.kernel.org/stable/c/e46adadf19248d59af3aa6bc52e09115bf479bf7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49010
|
Medium |
fixed |
- 4.9.335
- 4.14.301
- 4.19.268
- 5.4.226
- 5.10.158
- 5.15.82
- 6.0.12
|
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (coretemp) Check for null before removing sysfs attrs
If coretemp_add_core() gets an error then pdata->core_data[indx]
is already NULL and has been kfreed. Don't pass that to
sysfs_remove_group() as that will crash in sysfs_remove_group().
[Shortened for readability]
[91854.020159] sysfs: cannot create duplicate filename '/devices/platform/coretemp.0/hwmon/hwmon2/temp20_label'
<cpu offline>
[91855.126115] BUG: kernel NULL pointer dereference, address: 0000000000000188
[91855.165103] #PF: supervisor read access in kernel mode
[91855.194506] #PF: error_code(0x0000) - not-present page
[91855.224445] PGD 0 P4D 0
[91855.238508] Oops: 0000 [#1] PREEMPT SMP PTI
...
[91855.342716] RIP: 0010:sysfs_remove_group+0xc/0x80
...
[91855.796571] Call Trace:
[91855.810524] coretemp_cpu_offline+0x12b/0x1dd [coretemp]
[91855.841738] ? coretemp_cpu_online+0x180/0x180 [coretemp]
[91855.871107] cpuhp_invoke_callback+0x105/0x4b0
[91855.893432] cpuhp_thread_fun+0x8e/0x150
...
Fix this by checking for NULL first. |
["https://git.kernel.org/stable/c/070d5ea4a0592a37ad96ce7f7b6b024f90bb009f","https://git.kernel.org/stable/c/280110db1a7d62ad635b103bafc3ae96e8bef75c","https://git.kernel.org/stable/c/7692700ac818866d138a8de555130a6e70e6ac16","https://git.kernel.org/stable/c/89eecabe6a47403237f45aafd7d24f93cb973653","https://git.kernel.org/stable/c/a89ff5f5cc64b9fe7a992cf56988fd36f56ca82a","https://git.kernel.org/stable/c/ae6c8b6e5d5628df1c475c0a8fca1465e205c95b","https://git.kernel.org/stable/c/f06e0cd01eab954bd5f2190c9faa79bb5357e05b","https://git.kernel.org/stable/c/fb503d077ff7b43913503eaf72995d1239028b99"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49011
|
Medium |
fixed |
- 4.9.335
- 4.14.301
- 4.19.268
- 5.4.226
- 5.10.158
- 5.15.82
- 6.0.12
|
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new()
As comment of pci_get_domain_bus_and_slot() says, it returns
a pci device with refcount increment, when finish using it,
the caller must decrement the reference count by calling
pci_dev_put(). So call it after using to avoid refcount leak. |
["https://git.kernel.org/stable/c/0dd1da5a15eeecb2fe4cf131b3216fb455af783c","https://git.kernel.org/stable/c/2f74cffc7c85f770b1b1833dccb03b8cde3be102","https://git.kernel.org/stable/c/6e035d5a2a6b907cfce9a80c5f442c2e459cd34e","https://git.kernel.org/stable/c/7dec14537c5906b8bf40fd6fd6d9c3850f8df11d","https://git.kernel.org/stable/c/bb75a0d1223d43f97089841aecb28a9b4de687a9","https://git.kernel.org/stable/c/c40db1e5f316792b557d2be37e447c20d9ac4635","https://git.kernel.org/stable/c/ea5844f946b1ec5c0b7c115cd7684f34fd48021b","https://git.kernel.org/stable/c/f598da27acbeee414679cacd14294db3e273e3d2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49020
|
Medium |
fixed |
- 4.9.335
- 4.14.301
- 4.19.268
- 5.4.226
- 5.10.158
- 5.15.82
- 6.0.12
|
In the Linux kernel, the following vulnerability has been resolved:
net/9p: Fix a potential socket leak in p9_socket_open
Both p9_fd_create_tcp() and p9_fd_create_unix() will call
p9_socket_open(). If the creation of p9_trans_fd fails,
p9_fd_create_tcp() and p9_fd_create_unix() will return an
error directly instead of releasing the cscoket, which will
result in a socket leak.
This patch adds sock_release() to fix the leak issue. |
["https://git.kernel.org/stable/c/0396227f4daf4792a6a8aaa3b7771dc25c4cd443","https://git.kernel.org/stable/c/2d24d91b9f44620824fc37b766f7cae00ca32748","https://git.kernel.org/stable/c/8782b32ef867de7981bbe9e86ecb90e92e8780bd","https://git.kernel.org/stable/c/8b14bd0b500aec1458b51cb621c8e5fab3304260","https://git.kernel.org/stable/c/aa08323fe18cb7cf95317ffa2d54ca1de8e74ebd","https://git.kernel.org/stable/c/dcc14cfd7debe11b825cb077e75d91d2575b4cb8","https://git.kernel.org/stable/c/ded893965b895b2dccd3d1436d8d3daffa23ea64","https://git.kernel.org/stable/c/e01c1542379fb395e7da53706df598f38905dfbf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48868
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Let probe fail when workqueue cannot be enabled
The workqueue is enabled when the appropriate driver is loaded and
disabled when the driver is removed. When the driver is removed it
assumes that the workqueue was enabled successfully and proceeds to
free allocations made during workqueue enabling.
Failure during workqueue enabling does not prevent the driver from
being loaded. This is because the error path within drv_enable_wq()
returns success unless a second failure is encountered
during the error path. By returning success it is possible to load
the driver even if the workqueue cannot be enabled and
allocations that do not exist are attempted to be freed during
driver remove.
Some examples of problematic flows:
(a)
idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq():
In above flow, if idxd_wq_request_irq() fails then
idxd_wq_unmap_portal() is called on error exit path, but
drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The
driver is thus loaded successfully.
idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal()
Above flow on driver unload triggers the WARN in devm_iounmap() because
the device resource has already been removed during error path of
drv_enable_wq().
(b)
idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq():
In above flow, if idxd_wq_request_irq() fails then
idxd_wq_init_percpu_ref() is never called to initialize the percpu
counter, yet the driver loads successfully because drv_enable_wq()
returns 0.
idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill():
Above flow on driver unload triggers a BUG when attempting to drop the
initial ref of the uninitialized percpu ref:
BUG: kernel NULL pointer dereference, address: 0000000000000010
Fix the drv_enable_wq() error path by returning the original error that
indicates failure of workqueue enabling. This ensures that the probe
fails when an error is encountered and the driver remove paths are only
attempted when the workqueue was enabled successfully. |
["https://git.kernel.org/stable/c/0f150134dd795ffcd60b798a85ab737d8d010fb7","https://git.kernel.org/stable/c/99dc4520b74e7ca8e9dc9abe37a0b10b49467960","https://git.kernel.org/stable/c/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48903
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix relocation crash due to premature return from btrfs_commit_transaction()
We are seeing crashes similar to the following trace:
[38.969182] WARNING: CPU: 20 PID: 2105 at fs/btrfs/relocation.c:4070 btrfs_relocate_block_group+0x2dc/0x340 [btrfs]
[38.973556] CPU: 20 PID: 2105 Comm: btrfs Not tainted 5.17.0-rc4 #54
[38.974580] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
[38.976539] RIP: 0010:btrfs_relocate_block_group+0x2dc/0x340 [btrfs]
[38.980336] RSP: 0000:ffffb0dd42e03c20 EFLAGS: 00010206
[38.981218] RAX: ffff96cfc4ede800 RBX: ffff96cfc3ce0000 RCX: 000000000002ca14
[38.982560] RDX: 0000000000000000 RSI: 4cfd109a0bcb5d7f RDI: ffff96cfc3ce0360
[38.983619] RBP: ffff96cfc309c000 R08: 0000000000000000 R09: 0000000000000000
[38.984678] R10: ffff96cec0000001 R11: ffffe84c80000000 R12: ffff96cfc4ede800
[38.985735] R13: 0000000000000000 R14: 0000000000000000 R15: ffff96cfc3ce0360
[38.987146] FS: 00007f11c15218c0(0000) GS:ffff96d6dfb00000(0000) knlGS:0000000000000000
[38.988662] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[38.989398] CR2: 00007ffc922c8e60 CR3: 00000001147a6001 CR4: 0000000000370ee0
[38.990279] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[38.991219] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[38.992528] Call Trace:
[38.992854] <TASK>
[38.993148] btrfs_relocate_chunk+0x27/0xe0 [btrfs]
[38.993941] btrfs_balance+0x78e/0xea0 [btrfs]
[38.994801] ? vsnprintf+0x33c/0x520
[38.995368] ? __kmalloc_track_caller+0x351/0x440
[38.996198] btrfs_ioctl_balance+0x2b9/0x3a0 [btrfs]
[38.997084] btrfs_ioctl+0x11b0/0x2da0 [btrfs]
[38.997867] ? mod_objcg_state+0xee/0x340
[38.998552] ? seq_release+0x24/0x30
[38.999184] ? proc_nr_files+0x30/0x30
[38.999654] ? call_rcu+0xc8/0x2f0
[39.000228] ? __x64_sys_ioctl+0x84/0xc0
[39.000872] ? btrfs_ioctl_get_supported_features+0x30/0x30 [btrfs]
[39.001973] __x64_sys_ioctl+0x84/0xc0
[39.002566] do_syscall_64+0x3a/0x80
[39.003011] entry_SYSCALL_64_after_hwframe+0x44/0xae
[39.003735] RIP: 0033:0x7f11c166959b
[39.007324] RSP: 002b:00007fff2543e998 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[39.008521] RAX: ffffffffffffffda RBX: 00007f11c1521698 RCX: 00007f11c166959b
[39.009833] RDX: 00007fff2543ea40 RSI: 00000000c4009420 RDI: 0000000000000003
[39.011270] RBP: 0000000000000003 R08: 0000000000000013 R09: 00007f11c16f94e0
[39.012581] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff25440df3
[39.014046] R13: 0000000000000000 R14: 00007fff2543ea40 R15: 0000000000000001
[39.015040] </TASK>
[39.015418] ---[ end trace 0000000000000000 ]---
[43.131559] ------------[ cut here ]------------
[43.132234] kernel BUG at fs/btrfs/extent-tree.c:2717!
[43.133031] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[43.133702] CPU: 1 PID: 1839 Comm: btrfs Tainted: G W 5.17.0-rc4 #54
[43.134863] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
[43.136426] RIP: 0010:unpin_extent_range+0x37a/0x4f0 [btrfs]
[43.139913] RSP: 0000:ffffb0dd4216bc70 EFLAGS: 00010246
[43.140629] RAX: 0000000000000000 RBX: ffff96cfc34490f8 RCX: 0000000000000001
[43.141604] RDX: 0000000080000001 RSI: 0000000051d00000 RDI: 00000000ffffffff
[43.142645] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff96cfd07dca50
[43.143669] R10: ffff96cfc46e8a00 R11: fffffffffffec000 R12: 0000000041d00000
[43.144657] R13: ffff96cfc3ce0000 R14: ffffb0dd4216bd08 R15: 0000000000000000
[43.145686] FS: 00007f7657dd68c0(0000) GS:ffff96d6df640000(0000) knlGS:0000000000000000
[43.146808] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[43.147584] CR2: 00007f7fe81bf5b0 CR3: 00000001093ee004 CR4: 0000000000370ee0
[43.148589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[43.149581] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000
---truncated--- |
["https://git.kernel.org/stable/c/5fd76bf31ccfecc06e2e6b29f8c809e934085b99","https://git.kernel.org/stable/c/725a6ac389b182261af174176e561a36b0f39ffc","https://git.kernel.org/stable/c/a4378947ae39f08c6ae4c6a87ccdebc981a7bbcb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48906
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mptcp: Correctly set DATA_FIN timeout when number of retransmits is large
Syzkaller with UBSAN uncovered a scenario where a large number of
DATA_FIN retransmits caused a shift-out-of-bounds in the DATA_FIN
timeout calculation:
================================================================================
UBSAN: shift-out-of-bounds in net/mptcp/protocol.c:470:29
shift exponent 32 is too large for 32-bit type 'unsigned int'
CPU: 1 PID: 13059 Comm: kworker/1:0 Not tainted 5.17.0-rc2-00630-g5fbf21c90c60 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Workqueue: events mptcp_worker
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
ubsan_epilogue+0xb/0x5a lib/ubsan.c:151
__ubsan_handle_shift_out_of_bounds.cold+0xb2/0x20e lib/ubsan.c:330
mptcp_set_datafin_timeout net/mptcp/protocol.c:470 [inline]
__mptcp_retrans.cold+0x72/0x77 net/mptcp/protocol.c:2445
mptcp_worker+0x58a/0xa70 net/mptcp/protocol.c:2528
process_one_work+0x9df/0x16d0 kernel/workqueue.c:2307
worker_thread+0x95/0xe10 kernel/workqueue.c:2454
kthread+0x2f4/0x3b0 kernel/kthread.c:377
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
</TASK>
================================================================================
This change limits the maximum timeout by limiting the size of the
shift, which keeps all intermediate values in-bounds. |
["https://git.kernel.org/stable/c/03ae283bd71f761feae3f402668d698b393b0e79","https://git.kernel.org/stable/c/0c3f34beb459753f9f80d0cc14c1b50ab615c631","https://git.kernel.org/stable/c/877d11f0332cd2160e19e3313e262754c321fa36"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48907
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
auxdisplay: lcd2s: Fix memory leak in ->remove()
Once allocated the struct lcd2s_data is never freed.
Fix the memory leak by switching to devm_kzalloc(). |
["https://git.kernel.org/stable/c/3585ed5f9b11a6094dd991d76a1541e5d03b986a","https://git.kernel.org/stable/c/5d53cd33f4253aa4cf02bf7e670b3c6a99674351","https://git.kernel.org/stable/c/898c0a15425a5bcaa8d44bd436eae5afd2483796"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48916
|
Medium |
fixed |
- 5.13
- 5.14
- 5.15.27
- 5.16.13
|
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Fix double list_add when enabling VMD in scalable mode
When enabling VMD and IOMMU scalable mode, the following kernel panic
call trace/kernel log is shown in Eagle Stream platform (Sapphire Rapids
CPU) during booting:
pci 0000:59:00.5: Adding to iommu group 42
...
vmd 0000:59:00.5: PCI host bridge to bus 10000:80
pci 10000:80:01.0: [8086:352a] type 01 class 0x060400
pci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]
pci 10000:80:01.0: enabling Extended Tags
pci 10000:80:01.0: PME# supported from D0 D3hot D3cold
pci 10000:80:01.0: DMAR: Setup RID2PASID failed
pci 10000:80:01.0: Failed to add to iommu group 42: -16
pci 10000:80:03.0: [8086:352b] type 01 class 0x060400
pci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]
pci 10000:80:03.0: enabling Extended Tags
pci 10000:80:03.0: PME# supported from D0 D3hot D3cold
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:29!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7
Hardware name: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/2022
Workqueue: events work_for_cpu_fn
RIP: 0010:__list_add_valid.cold+0x26/0x3f
Code: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f
0b 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1
fe ff <0f> 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9
9e e8 8b b1 fe
RSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246
RAX: 0000000000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8
RDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20
RBP: ff4d611d8e245c00 R08: 0000000000000000 R09: ff5ad434865b3888
R10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0
R13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70
FS: 0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<TASK>
intel_pasid_alloc_table+0x9c/0x1d0
dmar_insert_one_dev_info+0x423/0x540
? device_to_iommu+0x12d/0x2f0
intel_iommu_attach_device+0x116/0x290
__iommu_attach_device+0x1a/0x90
iommu_group_add_device+0x190/0x2c0
__iommu_probe_device+0x13e/0x250
iommu_probe_device+0x24/0x150
iommu_bus_notifier+0x69/0x90
blocking_notifier_call_chain+0x5a/0x80
device_add+0x3db/0x7b0
? arch_memremap_can_ram_remap+0x19/0x50
? memremap+0x75/0x140
pci_device_add+0x193/0x1d0
pci_scan_single_device+0xb9/0xf0
pci_scan_slot+0x4c/0x110
pci_scan_child_bus_extend+0x3a/0x290
vmd_enable_domain.constprop.0+0x63e/0x820
vmd_probe+0x163/0x190
local_pci_probe+0x42/0x80
work_for_cpu_fn+0x13/0x20
process_one_work+0x1e2/0x3b0
worker_thread+0x1c4/0x3a0
? rescuer_thread+0x370/0x370
kthread+0xc7/0xf0
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x1f/0x30
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
...
Kernel panic - not syncing: Fatal exception
Kernel Offset: 0x1ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
---[ end Kernel panic - not syncing: Fatal exception ]---
The following 'lspci' output shows devices '10000:80:*' are subdevices of
the VMD device 0000:59:00.5:
$ lspci
...
0000:59:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 20)
...
10000:80:01.0 PCI bridge: Intel Corporation Device 352a (rev 03)
10000:80:03.0 PCI bridge: Intel Corporation Device 352b (rev 03)
10000:80:05.0 PCI bridge: Intel Corporation Device 352c (rev 03)
10000:80:07.0 PCI bridge: Intel Corporation Device 352d (rev 03)
10000:81:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller]
10000:82:00
---truncated--- |
["https://git.kernel.org/stable/c/2aaa085bd012a83be7104356301828585a2253ed","https://git.kernel.org/stable/c/b00833768e170a31af09268f7ab96aecfcca9623","https://git.kernel.org/stable/c/d5ad4214d9c6c6e465c192789020a091282dfee7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48944
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
sched: Fix yet more sched_fork() races
Where commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an
invalid sched_task_group") fixed a fork race vs cgroup, it opened up a
race vs syscalls by not placing the task on the runqueue before it
gets exposed through the pidhash.
Commit 13765de8148f ("sched/fair: Fix fault in reweight_entity") is
trying to fix a single instance of this, instead fix the whole class
of issues, effectively reverting this commit. |
["https://git.kernel.org/stable/c/3411613611a5cddf7e80908010dc87cb527dd13b","https://git.kernel.org/stable/c/b1e8206582f9d680cff7d04828708c8b6ab32957","https://git.kernel.org/stable/c/c65cfd89cef669d90c59f3bf150af6458137a04f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49019
|
Medium |
fixed |
- 5.4.226
- 5.10.158
- 5.15.82
- 6.0.12
|
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: nixge: fix NULL dereference
In function nixge_hw_dma_bd_release() dereference of NULL pointer
priv->rx_bd_v is possible for the case of its allocation failure in
nixge_hw_dma_bd_init().
Move for() loop with priv->rx_bd_v dereference under the check for
its validity.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/45752af0247589e6d3dede577415bfe117b4392c","https://git.kernel.org/stable/c/80e82f7b440b65cf131dce10f487dc73a7046e6b","https://git.kernel.org/stable/c/910c0264b64ef2dad8887714a7c56c93e39a0ed3","https://git.kernel.org/stable/c/9256db4e45e8b497b0e993cc3ed4ad08eb2389b6","https://git.kernel.org/stable/c/9c584d6d9cfb935dce8fc81a4c26debac0a3049b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50093
|
Medium |
fixed |
- 5.15.168
- 6.1.113
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
thermal: intel: int340x: processor: Fix warning during module unload
The processor_thermal driver uses pcim_device_enable() to enable a PCI
device, which means the device will be automatically disabled on driver
detach. Thus there is no need to call pci_disable_device() again on it.
With recent PCI device resource management improvements, e.g. commit
f748a07a0b64 ("PCI: Remove legacy pcim_release()"), this problem is
exposed and triggers the warining below.
[ 224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device
[ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100
...
[ 224.010844] Call Trace:
[ 224.010845] <TASK>
[ 224.010847] ? show_regs+0x6d/0x80
[ 224.010851] ? __warn+0x8c/0x140
[ 224.010854] ? pci_disable_device+0xe5/0x100
[ 224.010856] ? report_bug+0x1c9/0x1e0
[ 224.010859] ? handle_bug+0x46/0x80
[ 224.010862] ? exc_invalid_op+0x1d/0x80
[ 224.010863] ? asm_exc_invalid_op+0x1f/0x30
[ 224.010867] ? pci_disable_device+0xe5/0x100
[ 224.010869] ? pci_disable_device+0xe5/0x100
[ 224.010871] ? kfree+0x21a/0x2b0
[ 224.010873] pcim_disable_device+0x20/0x30
[ 224.010875] devm_action_release+0x16/0x20
[ 224.010878] release_nodes+0x47/0xc0
[ 224.010880] devres_release_all+0x9f/0xe0
[ 224.010883] device_unbind_cleanup+0x12/0x80
[ 224.010885] device_release_driver_internal+0x1ca/0x210
[ 224.010887] driver_detach+0x4e/0xa0
[ 224.010889] bus_remove_driver+0x6f/0xf0
[ 224.010890] driver_unregister+0x35/0x60
[ 224.010892] pci_unregister_driver+0x44/0x90
[ 224.010894] proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci]
...
[ 224.010921] ---[ end trace 0000000000000000 ]---
Remove the excess pci_disable_device() calls.
[ rjw: Subject and changelog edits ] |
["https://git.kernel.org/stable/c/434525a864136c928b54fd2512b4c0167c207463","https://git.kernel.org/stable/c/8403021b6f32d68a7e3a6b8428ecaf5c153a9974","https://git.kernel.org/stable/c/99ca0b57e49fb73624eede1c4396d9e3d10ccf14","https://git.kernel.org/stable/c/b4ab78f4adeaf6c98be5d375518dd4fb666eac5e","https://git.kernel.org/stable/c/dd64ea03375618684477f946be4f5e253f8676c2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52903
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
io_uring: lock overflowing for IOPOLL
syzbot reports an issue with overflow filling for IOPOLL:
WARNING: CPU: 0 PID: 28 at io_uring/io_uring.c:734 io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734
CPU: 0 PID: 28 Comm: kworker/u4:1 Not tainted 6.2.0-rc3-syzkaller-16369-g358a161a6a9e #0
Workqueue: events_unbound io_ring_exit_work
Call trace:
io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734
io_req_cqe_overflow+0x5c/0x70 io_uring/io_uring.c:773
io_fill_cqe_req io_uring/io_uring.h:168 [inline]
io_do_iopoll+0x474/0x62c io_uring/rw.c:1065
io_iopoll_try_reap_events+0x6c/0x108 io_uring/io_uring.c:1513
io_uring_try_cancel_requests+0x13c/0x258 io_uring/io_uring.c:3056
io_ring_exit_work+0xec/0x390 io_uring/io_uring.c:2869
process_one_work+0x2d8/0x504 kernel/workqueue.c:2289
worker_thread+0x340/0x610 kernel/workqueue.c:2436
kthread+0x12c/0x158 kernel/kthread.c:376
ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:863
There is no real problem for normal IOPOLL as flush is also called with
uring_lock taken, but it's getting more complicated for IOPOLL|SQPOLL,
for which __io_cqring_overflow_flush() happens from the CQ waiting path. |
["https://git.kernel.org/stable/c/544d163d659d45a206d8929370d5a2984e546cb7","https://git.kernel.org/stable/c/7fc3990dad04a677606337ebc61964094d6cb41b","https://git.kernel.org/stable/c/de77faee280163ff03b7ab64af6c9d779a43d4c4","https://git.kernel.org/stable/c/ed4629d1e968359fbb91d0a3780b1e86a2c08845"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49896
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check stream before comparing them
[WHAT & HOW]
amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is
necessary to check for null before dereferencing them.
This fixes 1 FORWARD_NULL issue reported by Coverity. |
["https://git.kernel.org/stable/c/0167d570f6a0b38689c4a0e50bf79c518d827500","https://git.kernel.org/stable/c/14db8692afe1aa2143b673856bb603713d8ea93f","https://git.kernel.org/stable/c/35ff747c86767937ee1e0ca987545b7eed7a0810","https://git.kernel.org/stable/c/3944d226f55235a960d8f1135927f95e9801be12","https://git.kernel.org/stable/c/42d31a33643813cce55ee1ebbad3a2d0d24a08e0","https://git.kernel.org/stable/c/471c53350ab83e47a2a117c2738ce0363785976e","https://git.kernel.org/stable/c/5b4b13e678b15975055f4ff1ce4cf0ce4c19b6c4","https://git.kernel.org/stable/c/e41a291e1bef1153bba091b6580ecc7affc53c82","https://git.kernel.org/stable/c/e8da54b7f8a17e44e67ea6d1037f35450af28115"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49902
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
jfs: check if leafidx greater than num leaves per dmap tree
syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater
than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf.
Shaggy:
Modified sanity check to apply to control pages as well as leaf pages. |
["https://git.kernel.org/stable/c/058aa89b3318be3d66a103ba7c68d717561e1dc6","https://git.kernel.org/stable/c/2451e5917c56be45d4add786e2a059dd9c2c37c4","https://git.kernel.org/stable/c/25d2a3ff02f22e215ce53355619df10cc5faa7ab","https://git.kernel.org/stable/c/35b91f15f44ce3c01eba058ccb864bb04743e792","https://git.kernel.org/stable/c/4a7bf6a01fb441009a6698179a739957efd88e38","https://git.kernel.org/stable/c/7fff9a9f866e99931cf6fa260288e55d01626582","https://git.kernel.org/stable/c/cb0eb10558802764f07de1dc439c4609e27cb4f0","https://git.kernel.org/stable/c/d64ff0d2306713ff084d4b09f84ed1a8c75ecc32","https://git.kernel.org/stable/c/d76b9a4c283c7535ae7c7c9b14984e75402951e1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49938
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit
Syzbot points out that skb_trim() has a sanity check on the existing length of
the skb, which can be uninitialised in some error paths. The intent here is
clearly just to reset the length to zero before resubmitting, so switch to
calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length()
already contains a call to skb_reset_tail_pointer(), so remove the redundant
call.
The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar
usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it. |
["https://git.kernel.org/stable/c/012ae530afa0785102360de452745d33c99a321b","https://git.kernel.org/stable/c/2c230210ec0ae6ed08306ac70dc21c24b817bb95","https://git.kernel.org/stable/c/6a875220670475d9247e576c15dc29823100a4e4","https://git.kernel.org/stable/c/94745807f3ebd379f23865e6dab196f220664179","https://git.kernel.org/stable/c/a9f4e28e8adaf0715bd4e01462af0a52ee46b01f","https://git.kernel.org/stable/c/b02eb7c86ff2ef1411c3095ec8a52b13f68db04f","https://git.kernel.org/stable/c/d1f2fbc6a769081503f6ffedbb5cd1ac497f0e77","https://git.kernel.org/stable/c/e37e348835032d6940ec89308cc8996ded691d2d","https://git.kernel.org/stable/c/e6b9bf32e0695e4f374674002de0527d2a6768eb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49962
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package()
ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0
ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause
NULL pointer dereference later.
[ rjw: Subject and changelog edits ] |
["https://git.kernel.org/stable/c/1c9b8775062f8d854a80caf186af57fc617d454c","https://git.kernel.org/stable/c/402b4c6b7500c7cca6972d2456a4a422801035b5","https://git.kernel.org/stable/c/4588ea78d3904bebb613b0bb025669e75800f546","https://git.kernel.org/stable/c/4669da66ebc5b09881487f30669b0fcdb462188e","https://git.kernel.org/stable/c/a5242874488eba2b9062985bf13743c029821330","https://git.kernel.org/stable/c/a907c113a8b66972f15f084d7dff960207b1f71d","https://git.kernel.org/stable/c/ae5d4c7e76ba393d20366dfea1f39f24560ffb1d","https://git.kernel.org/stable/c/cbb67e245dacd02b5e1d82733892647df1523982","https://git.kernel.org/stable/c/f282db38953ad71dd4f3f8877a4e1d37e580e30a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50008
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext()
Replace one-element array with a flexible-array member in
`struct host_cmd_ds_802_11_scan_ext`.
With this, fix the following warning:
elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------
elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field "ext_scan->tlv_buffer" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1)
elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex] |
["https://git.kernel.org/stable/c/17199b69a84798efffc475040fbef44374ef1de1","https://git.kernel.org/stable/c/1756918f51e9ab247a0f4782cc28853c2bb457c1","https://git.kernel.org/stable/c/498365e52bebcbc36a93279fe7e9d6aec8479cee","https://git.kernel.org/stable/c/71267bd4e8c752d7af6c6b96bb83984a6a95273d","https://git.kernel.org/stable/c/a3a12c30f9510f3753286fadbc6cdb7dad78c1d5","https://git.kernel.org/stable/c/b55c8848fdc81514ec047b2a0ec782ffe9ab5323","https://git.kernel.org/stable/c/e59bdb1ba594104cd0ee0af3ee9e4435d842a8fe","https://git.kernel.org/stable/c/f9310a6704bf52e2493480edea896e1f9b795d40","https://git.kernel.org/stable/c/fef7b51f22cf2049b0ca6740adeb0ba6f2e671dc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38661
|
Medium |
fixed |
- 4.19.316
- 5.4.278
- 5.10.219
- 5.15.161
- 6.1.94
- 6.6.34
- 6.9.5
|
In the Linux kernel, the following vulnerability has been resolved:
s390/ap: Fix crash in AP internal function modify_bitmap()
A system crash like this
Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403
Fault in home space mode while using kernel ASCE.
AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d
Oops: 0038 ilc:3 [#1] PREEMPT SMP
Modules linked in: mlx5_ib ...
CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8
Hardware name: IBM 3931 A01 704 (LPAR)
Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8)
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3
000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0
000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff
000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8
Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a
0000014b75e7b600: 18b2 lr %r11,%r2
#0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616
>0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13)
0000014b75e7b60c: a7680001 lhi %r6,1
0000014b75e7b610: 187b lr %r7,%r11
0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654
0000014b75e7b616: 18e9 lr %r14,%r9
Call Trace:
[<0000014b75e7b606>] ap_parse_bitmap_str+0x10e/0x1f8
([<0000014b75e7b5dc>] ap_parse_bitmap_str+0xe4/0x1f8)
[<0000014b75e7b758>] apmask_store+0x68/0x140
[<0000014b75679196>] kernfs_fop_write_iter+0x14e/0x1e8
[<0000014b75598524>] vfs_write+0x1b4/0x448
[<0000014b7559894c>] ksys_write+0x74/0x100
[<0000014b7618a440>] __do_syscall+0x268/0x328
[<0000014b761a3558>] system_call+0x70/0x98
INFO: lockdep is turned off.
Last Breaking-Event-Address:
[<0000014b75e7b636>] ap_parse_bitmap_str+0x13e/0x1f8
Kernel panic - not syncing: Fatal exception: panic_on_oops
occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value
(like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.
The fix is simple: use unsigned long values for the internal variables. The
correct checks are already in place in the function but a simple int for
the internal variables was used with the possibility to overflow. |
["https://git.kernel.org/stable/c/2062e3f1f2374102f8014d7ca286b9aa527bd558","https://git.kernel.org/stable/c/4c0bfb4e867c1ec6616a5049bd3618021e127056","https://git.kernel.org/stable/c/67011123453b91ec03671d40712fa213e94a01b9","https://git.kernel.org/stable/c/7360cef95aa1ea2b5efb7b5e2ed32e941664e1f0","https://git.kernel.org/stable/c/7c72af16abf2ec7520407098360bbba312289e05","https://git.kernel.org/stable/c/7dabe54a016defe11bb2a278cd9f1ff6db3feba6","https://git.kernel.org/stable/c/8c5f5911c1b13170d3404eb992c6a0deaa8d81ad","https://git.kernel.org/stable/c/d4f9d5a99a3fd1b1c691b7a1a6f8f3f25f4116c9","https://git.kernel.org/stable/c/2062e3f1f2374102f8014d7ca286b9aa527bd558","https://git.kernel.org/stable/c/4c0bfb4e867c1ec6616a5049bd3618021e127056","https://git.kernel.org/stable/c/67011123453b91ec03671d40712fa213e94a01b9","https://git.kernel.org/stable/c/7360cef95aa1ea2b5efb7b5e2ed32e941664e1f0","https://git.kernel.org/stable/c/7c72af16abf2ec7520407098360bbba312289e05","https://git.kernel.org/stable/c/7dabe54a016defe11bb2a278cd9f1ff6db3feba6","https://git.kernel.org/stable/c/8c5f5911c1b13170d3404eb992c6a0deaa8d81ad","https://git.kernel.org/stable/c/d4f9d5a99a3fd1b1c691b7a1a6f8f3f25f4116c9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-47520
|
High |
fixed |
|
An issue was discovered in the Linux kernel before 6.0.11. Missing offset validation in drivers/net/wireless/microchip/wilc1000/hif.c in the WILC1000 wireless driver can trigger an out-of-bounds read when parsing a Robust Security Network (RSN) information element from a Netlink packet. |
["https://github.com/torvalds/linux/commit/cd21d99e595ec1d8721e1058dcdd4f1f7de1d793","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lore.kernel.org/r/20221123153543.8568-2-philipturnbull%40github.com","https://security.netapp.com/advisory/ntap-20230113-0007/","https://github.com/torvalds/linux/commit/cd21d99e595ec1d8721e1058dcdd4f1f7de1d793","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lore.kernel.org/r/20221123153543.8568-2-philipturnbull%40github.com","https://security.netapp.com/advisory/ntap-20230113-0007/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49368
|
High |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: mtk_eth_soc: out of bounds read in mtk_hwlro_get_fdir_entry()
The "fsp->location" variable comes from user via ethtool_get_rxnfc().
Check that it is valid to prevent an out of bounds read. |
["https://git.kernel.org/stable/c/0b238f75b65ed4462ef4cdfa718cac0ac7fce3b8","https://git.kernel.org/stable/c/2bd1faedb74dc2a2be3972abcd4239b75a3e7b00","https://git.kernel.org/stable/c/4cde554c70d7397cfa2e4116bacb4accdfb6fd48","https://git.kernel.org/stable/c/5ba81f82607ead85fe36f50869fc4f5661359ab8","https://git.kernel.org/stable/c/657e7174603f0aab2cdedc64ac81edffd2a87afe","https://git.kernel.org/stable/c/71ae30662ec610b92644d13f79c78f76f17873b3","https://git.kernel.org/stable/c/b24ca1cf846273361d5bd73a35de95a486a54b6d","https://git.kernel.org/stable/c/b4f0e57ea0d867aacffad7999527e48bd4ea9293","https://git.kernel.org/stable/c/e7e7104e2d5ddf3806a28695670f21bef471f1e1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49395
|
High |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
um: Fix out-of-bounds read in LDT setup
syscall_stub_data() expects the data_count parameter to be the number of
longs, not bytes.
==================================================================
BUG: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0
Read of size 128 at addr 000000006411f6f0 by task swapper/1
CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18
Call Trace:
show_stack.cold+0x166/0x2a7
__dump_stack+0x3a/0x43
dump_stack_lvl+0x1f/0x27
print_report.cold+0xdb/0xf81
kasan_report+0x119/0x1f0
kasan_check_range+0x3a3/0x440
memcpy+0x52/0x140
syscall_stub_data+0x70/0xe0
write_ldt_entry+0xac/0x190
init_new_ldt+0x515/0x960
init_new_context+0x2c4/0x4d0
mm_init.constprop.0+0x5ed/0x760
mm_alloc+0x118/0x170
0x60033f48
do_one_initcall+0x1d7/0x860
0x60003e7b
kernel_init+0x6e/0x3d4
new_thread_handler+0x1e7/0x2c0
The buggy address belongs to stack of task swapper/1
and is located at offset 64 in frame:
init_new_ldt+0x0/0x960
This frame has 2 objects:
[32, 40) 'addr'
[64, 80) 'desc'
================================================================== |
["https://git.kernel.org/stable/c/10995a382271254bd276627ec74136da4a23c4a6","https://git.kernel.org/stable/c/24ca648bf5f72ed8878cf09b5d4431935779681e","https://git.kernel.org/stable/c/2a4a62a14be1947fa945c5c11ebf67326381a568","https://git.kernel.org/stable/c/3549ab4b962cf619e8c55484a0d870a34b3f845f","https://git.kernel.org/stable/c/668ca34a428d6ffc0f99a1a6a9b661a288d4183b","https://git.kernel.org/stable/c/91e5ba2af2d729d5126aefd5aa3eadc69b8426e5","https://git.kernel.org/stable/c/9caad70819aef3431abaf73ba5163b55b161aba0","https://git.kernel.org/stable/c/cf0dabc37446c5ee538ae7b4c467ab0e53fa5463","https://git.kernel.org/stable/c/ef1dc929a1e5fa1b2d842256db9fb8710d3be910"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49218
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/dp: Fix OOB read when handling Post Cursor2 register
The link_status array was not large enough to read the Adjust Request
Post Cursor2 register, so remove the common helper function to avoid
an OOB read, found with a -Warray-bounds build:
drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_get_adjust_request_post_cursor':
drivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is outside array bounds of 'const u8[6]' {aka 'const unsigned char[6]'} [-Werror=array-bounds]
59 | return link_status[r - DP_LANE0_1_STATUS];
| ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing 'link_status'
147 | u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZE],
| ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Replace the only user of the helper with an open-coded fetch and decode,
similar to drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c. |
["https://git.kernel.org/stable/c/a2151490cc6c57b368d7974ffd447a8b36ade639","https://git.kernel.org/stable/c/aeaed9a9fe694f8b1462fb81e2d33298c929180b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26585
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
tls: fix race between tx work scheduling and socket close
Similarly to previous commit, the submitting thread (recvmsg/sendmsg)
may exit as soon as the async crypto handler calls complete().
Reorder scheduling the work before calling complete().
This seems more logical in the first place, as it's
the inverse order of what the submitting thread will do. |
["https://git.kernel.org/stable/c/196f198ca6fce04ba6ce262f5a0e4d567d7d219d","https://git.kernel.org/stable/c/6db22d6c7a6dc914b12c0469b94eb639b6a8a146","https://git.kernel.org/stable/c/dd32621f19243f89ce830919496a5dcc2158aa33","https://git.kernel.org/stable/c/e01e3934a1b2d122919f73bc6ddbe1cdafc4bbdb","https://git.kernel.org/stable/c/e327ed60bff4a991cd7a709c47c4f0c5b4a4fd57","https://git.kernel.org/stable/c/196f198ca6fce04ba6ce262f5a0e4d567d7d219d","https://git.kernel.org/stable/c/6db22d6c7a6dc914b12c0469b94eb639b6a8a146","https://git.kernel.org/stable/c/e01e3934a1b2d122919f73bc6ddbe1cdafc4bbdb","https://git.kernel.org/stable/c/e327ed60bff4a991cd7a709c47c4f0c5b4a4fd57"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52749
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
spi: Fix null dereference on suspend
A race condition exists where a synchronous (noqueue) transfer can be
active during a system suspend. This can cause a null pointer
dereference exception to occur when the system resumes.
Example order of events leading to the exception:
1. spi_sync() calls __spi_transfer_message_noqueue() which sets
ctlr->cur_msg
2. Spi transfer begins via spi_transfer_one_message()
3. System is suspended interrupting the transfer context
4. System is resumed
6. spi_controller_resume() calls spi_start_queue() which resets cur_msg
to NULL
7. Spi transfer context resumes and spi_finalize_current_message() is
called which dereferences cur_msg (which is now NULL)
Wait for synchronous transfers to complete before suspending by
acquiring the bus mutex and setting/checking a suspend flag. |
["https://git.kernel.org/stable/c/4ec4508db97502a12daee88c74782e8d35ced068","https://git.kernel.org/stable/c/96474ea47dc67b0704392d59192b233c8197db0e","https://git.kernel.org/stable/c/bef4a48f4ef798c4feddf045d49e53c8a97d5e37","https://git.kernel.org/stable/c/4ec4508db97502a12daee88c74782e8d35ced068","https://git.kernel.org/stable/c/96474ea47dc67b0704392d59192b233c8197db0e","https://git.kernel.org/stable/c/bef4a48f4ef798c4feddf045d49e53c8a97d5e37"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42227
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix overlapping copy within dml_core_mode_programming
[WHY]
&mode_lib->mp.Watermark and &locals->Watermark are
the same address. memcpy may lead to unexpected behavior.
[HOW]
memmove should be used. |
["https://git.kernel.org/stable/c/9342da15f2491d8600eca89c8e0da08876fb969b","https://git.kernel.org/stable/c/f1fd8a0a54e6d23a6d16ee29159f247862460fd1","https://git.kernel.org/stable/c/9342da15f2491d8600eca89c8e0da08876fb969b","https://git.kernel.org/stable/c/f1fd8a0a54e6d23a6d16ee29159f247862460fd1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3577
|
High |
fixed |
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
An out-of-bounds memory write flaw was found in the Linux kernel’s Kid-friendly Wired Controller driver. This flaw allows a local user to crash or potentially escalate their privileges on the system. It is in bigben_probe of drivers/hid/hid-bigbenff.c. The reason is incorrect assumption - bigben devices all have inputs. However, malicious devices can break this assumption, leaking to out-of-bound write. |
["https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/?h=char-misc-next\u0026id=9d64d2405f7d30d49818f6682acd0392348f0fdb","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=945a9a8e448b65bec055d37eba58f711b39f66f0","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc4ef9d5724973193bfa5ebed181dba6de3a56db","https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/?h=char-misc-next\u0026id=9d64d2405f7d30d49818f6682acd0392348f0fdb","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=945a9a8e448b65bec055d37eba58f711b39f66f0","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc4ef9d5724973193bfa5ebed181dba6de3a56db"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3610
|
High |
fixed |
- 5.10.188
- 5.15.119
- 6.1.36
- 6.3.10
|
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.
Flaw in the error handling of bound chains causes a use-after-free in the abort path of NFT_MSG_NEWRULE. The vulnerability requires CAP_NET_ADMIN to be triggered.
We recommend upgrading past commit 4bedf9eee016286c835e3d8fa981ddece5338795. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=4bedf9eee016286c835e3d8fa981ddece5338795","https://kernel.dance/4bedf9eee016286c835e3d8fa981ddece5338795","https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html","https://security.netapp.com/advisory/ntap-20230818-0005/","https://www.debian.org/security/2023/dsa-5461","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=4bedf9eee016286c835e3d8fa981ddece5338795","https://kernel.dance/4bedf9eee016286c835e3d8fa981ddece5338795","https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html","https://security.netapp.com/advisory/ntap-20230818-0005/","https://www.debian.org/security/2023/dsa-5461"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-2124
|
High |
fixed |
|
An out-of-bounds memory access flaw was found in the Linux kernel’s XFS file system in how a user restores an XFS image after failure (with a dirty log journal). This flaw allows a local user to crash or potentially escalate their privileges on the system. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/xfs/xfs_buf_item_recover.c?h=v6.4-rc1\u0026id=22ed903eee23a5b174e240f1cdfa9acf393a5210","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20230622-0010/","https://syzkaller.appspot.com/bug?extid=7e9494b8b399902e994e","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5480","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/xfs/xfs_buf_item_recover.c?h=v6.4-rc1\u0026id=22ed903eee23a5b174e240f1cdfa9acf393a5210","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20230622-0010/","https://syzkaller.appspot.com/bug?extid=7e9494b8b399902e994e","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5480"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3424
|
High |
fixed |
- 4.9.337
- 4.14.303
- 4.19.270
- 5.4.229
- 5.10.163
- 5.15.86
- 6.0.16
- 6.1.2
|
A use-after-free flaw was found in the Linux kernel’s SGI GRU driver in the way the first gru_file_unlocked_ioctl function is called by the user, where a fail pass occurs in the gru_check_chiplet_assignment function. This flaw allows a local user to crash or potentially escalate their privileges on the system. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2132640","https://github.com/torvalds/linux/commit/643a16a0eb1d6ac23744bb6e90a00fc21148a9dc","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20221019031445.901570-1-zyytlz.wz%40163.com/","https://security.netapp.com/advisory/ntap-20230406-0005/","https://www.spinics.net/lists/kernel/msg4518970.html","https://bugzilla.redhat.com/show_bug.cgi?id=2132640","https://github.com/torvalds/linux/commit/643a16a0eb1d6ac23744bb6e90a00fc21148a9dc","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20221019031445.901570-1-zyytlz.wz%40163.com/","https://security.netapp.com/advisory/ntap-20230406-0005/","https://www.spinics.net/lists/kernel/msg4518970.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-36123
|
High |
fixed |
|
The Linux kernel before 5.18.13 lacks a certain clear operation for the block starting symbol (.bss). This allows Xen PV guest OS users to cause a denial of service or gain privileges. |
["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.13","https://github.com/sickcodes/security/blob/master/advisories/SICK-2022-128.md","https://github.com/torvalds/linux/commit/74a0032b8524ee2bd4443128c0bf9775928680b0","https://github.com/torvalds/linux/commit/96e8fc5818686d4a1591bb6907e7fdb64ef29884","https://security.netapp.com/advisory/ntap-20220901-0003/","https://sick.codes/sick-2022-128","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.13","https://github.com/sickcodes/security/blob/master/advisories/SICK-2022-128.md","https://github.com/torvalds/linux/commit/74a0032b8524ee2bd4443128c0bf9775928680b0","https://github.com/torvalds/linux/commit/96e8fc5818686d4a1591bb6907e7fdb64ef29884","https://security.netapp.com/advisory/ntap-20220901-0003/","https://sick.codes/sick-2022-128"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21928
|
High |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.131
- 6.6.83
- 6.12.19
- 6.13.7
|
In the Linux kernel, the following vulnerability has been resolved:
HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove()
The system can experience a random crash a few minutes after the driver is
removed. This issue occurs due to improper handling of memory freeing in
the ishtp_hid_remove() function.
The function currently frees the `driver_data` directly within the loop
that destroys the HID devices, which can lead to accessing freed memory.
Specifically, `hid_destroy_device()` uses `driver_data` when it calls
`hid_ishtp_set_feature()` to power off the sensor, so freeing
`driver_data` beforehand can result in accessing invalid memory.
This patch resolves the issue by storing the `driver_data` in a temporary
variable before calling `hid_destroy_device()`, and then freeing the
`driver_data` after the device is destroyed. |
["https://git.kernel.org/stable/c/01b18a330cda61cc21423a7d1af92cf31ded8f60","https://git.kernel.org/stable/c/07583a0010696a17fb0942e0b499a62785c5fc9f","https://git.kernel.org/stable/c/0c1fb475ef999d6c22fc3f963fdf20cb3ed1b03d","https://git.kernel.org/stable/c/560f4d1299342504a6ab8a47f575b5e6b8345ada","https://git.kernel.org/stable/c/cf1a6015d2f6b1f0afaa0fd6a0124ff2c7943394","https://git.kernel.org/stable/c/d3faae7f42181865c799d88c5054176f38ae4625","https://git.kernel.org/stable/c/dea6a349bcaf243fff95dfd0428a26be6a0fb44e","https://git.kernel.org/stable/c/eb0695d87a81e7c1f0509b7d8ee7c65fbc26aec9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21934
|
High |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.131
- 6.6.83
- 6.12.19
- 6.13.7
|
In the Linux kernel, the following vulnerability has been resolved:
rapidio: fix an API misues when rio_add_net() fails
rio_add_net() calls device_register() and fails when device_register()
fails. Thus, put_device() should be used rather than kfree(). Add
"mport->net = NULL;" to avoid a use after free issue. |
["https://git.kernel.org/stable/c/22e4977141dfc6d109bf29b495bf2187b4250990","https://git.kernel.org/stable/c/2537f01d57f08c527e40bbb5862aa6ff43344898","https://git.kernel.org/stable/c/88ddad53e4cfb6de861c6d4fb7b25427f46baed5","https://git.kernel.org/stable/c/a5f5e520e8fbc6294020ff8afa36f684d92c6e6a","https://git.kernel.org/stable/c/b2ef51c74b0171fde7eb69b6152d3d2f743ef269","https://git.kernel.org/stable/c/cdd9f58f7fe41a55fae4305ea51fc234769fd466","https://git.kernel.org/stable/c/d4ec862ce80f64db923a1d942b5d11cf6fc87d36","https://git.kernel.org/stable/c/f0aa4ee1cbbf7789907e5a3f6810de01c146c211"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-1085
|
High |
fixed |
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.
The nft_setelem_catchall_deactivate() function checks whether the catch-all set element is active in the current generation instead of the next generation before freeing it, but only flags it inactive in the next generation, making it possible to free the element multiple times, leading to a double free vulnerability.
We recommend upgrading past commit b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7","https://kernel.dance/b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7","https://kernel.dance/b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21718
|
High |
fixed |
- 6.1.129
- 6.6.76
- 6.12.13
- 6.13.2
|
In the Linux kernel, the following vulnerability has been resolved:
net: rose: fix timer races against user threads
Rose timers only acquire the socket spinlock, without
checking if the socket is owned by one user thread.
Add a check and rearm the timers if needed.
BUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174
Read of size 2 at addr ffff88802f09b82a by task swapper/0/0
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0x169/0x550 mm/kasan/report.c:489
kasan_report+0x143/0x180 mm/kasan/report.c:602
rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174
call_timer_fn+0x187/0x650 kernel/time/timer.c:1793
expire_timers kernel/time/timer.c:1844 [inline]
__run_timers kernel/time/timer.c:2418 [inline]
__run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430
run_timer_base kernel/time/timer.c:2439 [inline]
run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449
handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561
__do_softirq kernel/softirq.c:595 [inline]
invoke_softirq kernel/softirq.c:435 [inline]
__irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662
irq_exit_rcu+0x9/0x30 kernel/softirq.c:678
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]
sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049
</IRQ> |
["https://git.kernel.org/stable/c/0d5bca3be27bfcf8f980f2fed49b6cbb7dafe4a1","https://git.kernel.org/stable/c/1409b45d4690308c502c6caf22f01c3c205b4717","https://git.kernel.org/stable/c/1992fb261c90e9827cf5dc3115d89bb0853252c9","https://git.kernel.org/stable/c/51c128ba038cf1b79d605cbee325919b45ab95a5","https://git.kernel.org/stable/c/52f5aff33ca73b2c2fa93f40a3de308012e63cf4","https://git.kernel.org/stable/c/58051a284ac18a3bb815aac6289a679903ddcc3f","https://git.kernel.org/stable/c/5de7665e0a0746b5ad7943554b34db8f8614a196","https://git.kernel.org/stable/c/f55c88e3ca5939a6a8a329024aed8f3d98eea8e4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-2006
|
High |
fixed |
|
A race condition was found in the Linux kernel's RxRPC network protocol, within the processing of RxRPC bundles. This issue results from the lack of proper locking when performing operations on an object. This may allow an attacker to escalate privileges and execute arbitrary code in the context of the kernel. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2189112","https://github.com/torvalds/linux/commit/3bcd6c7eaa53","https://security.netapp.com/advisory/ntap-20230609-0004/","https://www.zerodayinitiative.com/advisories/ZDI-23-439/","https://bugzilla.redhat.com/show_bug.cgi?id=2189112","https://github.com/torvalds/linux/commit/3bcd6c7eaa53","https://security.netapp.com/advisory/ntap-20230609-0004/","https://www.zerodayinitiative.com/advisories/ZDI-23-439/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48634
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/gma500: Fix BUG: sleeping function called from invalid context errors
gma_crtc_page_flip() was holding the event_lock spinlock while calling
crtc_funcs->mode_set_base() which takes ww_mutex.
The only reason to hold event_lock is to clear gma_crtc->page_flip_event
on mode_set_base() errors.
Instead unlock it after setting gma_crtc->page_flip_event and on
errors re-take the lock and clear gma_crtc->page_flip_event it
it is still set.
This fixes the following WARN/stacktrace:
[ 512.122953] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:870
[ 512.123004] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1253, name: gnome-shell
[ 512.123031] preempt_count: 1, expected: 0
[ 512.123048] RCU nest depth: 0, expected: 0
[ 512.123066] INFO: lockdep is turned off.
[ 512.123080] irq event stamp: 0
[ 512.123094] hardirqs last enabled at (0): [<0000000000000000>] 0x0
[ 512.123134] hardirqs last disabled at (0): [<ffffffff8d0ec28c>] copy_process+0x9fc/0x1de0
[ 512.123176] softirqs last enabled at (0): [<ffffffff8d0ec28c>] copy_process+0x9fc/0x1de0
[ 512.123207] softirqs last disabled at (0): [<0000000000000000>] 0x0
[ 512.123233] Preemption disabled at:
[ 512.123241] [<0000000000000000>] 0x0
[ 512.123275] CPU: 3 PID: 1253 Comm: gnome-shell Tainted: G W 5.19.0+ #1
[ 512.123304] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013
[ 512.123323] Call Trace:
[ 512.123346] <TASK>
[ 512.123370] dump_stack_lvl+0x5b/0x77
[ 512.123412] __might_resched.cold+0xff/0x13a
[ 512.123458] ww_mutex_lock+0x1e/0xa0
[ 512.123495] psb_gem_pin+0x2c/0x150 [gma500_gfx]
[ 512.123601] gma_pipe_set_base+0x76/0x240 [gma500_gfx]
[ 512.123708] gma_crtc_page_flip+0x95/0x130 [gma500_gfx]
[ 512.123808] drm_mode_page_flip_ioctl+0x57d/0x5d0
[ 512.123897] ? drm_mode_cursor2_ioctl+0x10/0x10
[ 512.123936] drm_ioctl_kernel+0xa1/0x150
[ 512.123984] drm_ioctl+0x21f/0x420
[ 512.124025] ? drm_mode_cursor2_ioctl+0x10/0x10
[ 512.124070] ? rcu_read_lock_bh_held+0xb/0x60
[ 512.124104] ? lock_release+0x1ef/0x2d0
[ 512.124161] __x64_sys_ioctl+0x8d/0xd0
[ 512.124203] do_syscall_64+0x58/0x80
[ 512.124239] ? do_syscall_64+0x67/0x80
[ 512.124267] ? trace_hardirqs_on_prepare+0x55/0xe0
[ 512.124300] ? do_syscall_64+0x67/0x80
[ 512.124340] ? rcu_read_lock_sched_held+0x10/0x80
[ 512.124377] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 512.124411] RIP: 0033:0x7fcc4a70740f
[ 512.124442] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00
[ 512.124470] RSP: 002b:00007ffda73f5390 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 512.124503] RAX: ffffffffffffffda RBX: 000055cc9e474500 RCX: 00007fcc4a70740f
[ 512.124524] RDX: 00007ffda73f5420 RSI: 00000000c01864b0 RDI: 0000000000000009
[ 512.124544] RBP: 00007ffda73f5420 R08: 000055cc9c0b0cb0 R09: 0000000000000034
[ 512.124564] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c01864b0
[ 512.124584] R13: 0000000000000009 R14: 000055cc9df484d0 R15: 000055cc9af5d0c0
[ 512.124647] </TASK> |
["https://git.kernel.org/stable/c/63e37a79f7bd939314997e29c2f5a9f0ef184281","https://git.kernel.org/stable/c/a6ed7624bf4d0a32f2631e74828bca7b7bf15afd","https://git.kernel.org/stable/c/c5812807e416618477d1bb0049727ce8bb8292fd","https://git.kernel.org/stable/c/e5ae504c8623476e13032670f1a6d6344d53ec9b","https://git.kernel.org/stable/c/63e37a79f7bd939314997e29c2f5a9f0ef184281","https://git.kernel.org/stable/c/a6ed7624bf4d0a32f2631e74828bca7b7bf15afd","https://git.kernel.org/stable/c/c5812807e416618477d1bb0049727ce8bb8292fd","https://git.kernel.org/stable/c/e5ae504c8623476e13032670f1a6d6344d53ec9b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3534
|
High |
|
N/A
|
A vulnerability classified as critical has been found in Linux Kernel. Affected is the function btf_dump_name_dups of the file tools/lib/bpf/btf_dump.c of the component libbpf. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211032. |
["https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=93c660ca40b5d2f7c1b1626e955a8e9fa30e0749","https://vuldb.com/?id.211032","https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=93c660ca40b5d2f7c1b1626e955a8e9fa30e0749","https://vuldb.com/?id.211032"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49965
|
Medium |
fixed |
- 4.9
- 4.14
- 4.19
- 4.20
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: remove unreasonable unlock in ocfs2_read_blocks
Patch series "Misc fixes for ocfs2_read_blocks", v5.
This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix
the issue reported by syzbot, which detects bad unlock balance in
ocfs2_read_blocks(). The second patch fixes an issue reported by Heming
Zhao when reviewing above fix.
This patch (of 2):
There was a lock release before exiting, so remove the unreasonable unlock. |
["https://git.kernel.org/stable/c/39a88623af3f1c686bf6db1e677ed865ffe6fccc","https://git.kernel.org/stable/c/3f1ca6ba5452d53c598a45d21267a2c0c221eef3","https://git.kernel.org/stable/c/5245f109b4afb6595360d4c180d483a6d2009a59","https://git.kernel.org/stable/c/81aba693b129e82e11bb54f569504d943d018de9","https://git.kernel.org/stable/c/84543da867c967edffd5065fa910ebf56aaae49d","https://git.kernel.org/stable/c/9753bcb17b36c9add9b32c61766ddf8d2d161911","https://git.kernel.org/stable/c/c03a82b4a0c935774afa01fd6d128b444fd930a1","https://git.kernel.org/stable/c/df4f20fc3673cee11abf2c571987a95733cb638d","https://git.kernel.org/stable/c/f55a33fe0fb5274ef185fd61947cf142138958af"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49867
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: wait for fixup workers before stopping cleaner kthread during umount
During unmount, at close_ctree(), we have the following steps in this order:
1) Park the cleaner kthread - this doesn't destroy the kthread, it basically
halts its execution (wake ups against it work but do nothing);
2) We stop the cleaner kthread - this results in freeing the respective
struct task_struct;
3) We call btrfs_stop_all_workers() which waits for any jobs running in all
the work queues and then free the work queues.
Syzbot reported a case where a fixup worker resulted in a crash when doing
a delayed iput on its inode while attempting to wake up the cleaner at
btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread
was already freed. This can happen during unmount because we don't wait
for any fixup workers still running before we call kthread_stop() against
the cleaner kthread, which stops and free all its resources.
Fix this by waiting for any fixup workers at close_ctree() before we call
kthread_stop() against the cleaner and run pending delayed iputs.
The stack traces reported by syzbot were the following:
BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065
Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52
CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Workqueue: btrfs-fixup btrfs_work_helper
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x169/0x550 mm/kasan/report.c:488
kasan_report+0x143/0x180 mm/kasan/report.c:601
__lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065
lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162
class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline]
try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154
btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842
btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314
process_one_work kernel/workqueue.c:3229 [inline]
process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310
worker_thread+0x870/0xd30 kernel/workqueue.c:3391
kthread+0x2f0/0x390 kernel/kthread.c:389
ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
</TASK>
Allocated by task 2:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
unpoison_slab_object mm/kasan/common.c:319 [inline]
__kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345
kasan_slab_alloc include/linux/kasan.h:247 [inline]
slab_post_alloc_hook mm/slub.c:4086 [inline]
slab_alloc_node mm/slub.c:4135 [inline]
kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187
alloc_task_struct_node kernel/fork.c:180 [inline]
dup_task_struct+0x57/0x8c0 kernel/fork.c:1107
copy_process+0x5d1/0x3d50 kernel/fork.c:2206
kernel_clone+0x223/0x880 kernel/fork.c:2787
kernel_thread+0x1bc/0x240 kernel/fork.c:2849
create_kthread kernel/kthread.c:412 [inline]
kthreadd+0x60d/0x810 kernel/kthread.c:765
ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
Freed by task 61:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
poison_slab_object mm/kasan/common.c:247 [inline]
__kasan_slab_free+0x59/0x70 mm/kasan/common.c:264
kasan_slab_free include/linux/kasan.h:230 [inline]
slab_free_h
---truncated--- |
["https://git.kernel.org/stable/c/41fd1e94066a815a7ab0a7025359e9b40e4b3576","https://git.kernel.org/stable/c/4c98fe0dfa2ae83c4631699695506d8941db4bfe","https://git.kernel.org/stable/c/65d11eb276836d49003a8060cf31fa2284ad1047","https://git.kernel.org/stable/c/70b60c8d9b42763d6629e44f448aa5d8ae477d61","https://git.kernel.org/stable/c/9da40aea63f8769f28afb91aea0fac4cf6fbbb65","https://git.kernel.org/stable/c/a71349b692ab34ea197949e13e3cc42570fe73d9","https://git.kernel.org/stable/c/bf0de0f9a0544c11f96f93206da04ab87dcea1f4","https://git.kernel.org/stable/c/cd686dfff63f27d712877aef5b962fbf6b8bc264","https://git.kernel.org/stable/c/ed87190e9d9c80aad220fb6b0b03a84d22e2c95b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-0171
|
Medium |
fixed |
|
A flaw was found in the Linux kernel. The existing KVM SEV API has a vulnerability that allows a non-root (host) user-level application to crash the host kernel by creating a confidential guest VM instance in AMD CPU that supports Secure Encrypted Virtualization (SEV). |
["https://access.redhat.com/security/cve/CVE-2022-0171","https://bugzilla.redhat.com/show_bug.cgi?id=2038940","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=683412ccf61294d727ead4a73d97397396e69a6b","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://www.debian.org/security/2022/dsa-5257","https://access.redhat.com/security/cve/CVE-2022-0171","https://bugzilla.redhat.com/show_bug.cgi?id=2038940","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=683412ccf61294d727ead4a73d97397396e69a6b","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://www.debian.org/security/2022/dsa-5257"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21898
|
Medium |
fixed |
- 3.17
- 4.5
- 4.10
- 4.15
- 4.20
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.130
- 6.6.81
- 6.12.18
- 6.13.6
|
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Avoid potential division by zero in function_stat_show()
Check whether denominator expression x * (x - 1) * 1000 mod {2^32, 2^64}
produce zero and skip stddev computation in that case.
For now don't care about rec->counter * rec->counter overflow because
rec->time * rec->time overflow will likely happen earlier. |
["https://git.kernel.org/stable/c/3d738b53ed6cddb68e68c9874520a4bf846163b5","https://git.kernel.org/stable/c/5b3d32f607f0478b414b16516cf27f9170cf66c8","https://git.kernel.org/stable/c/746cc474a95473591853927b3a9792a2d671155b","https://git.kernel.org/stable/c/992775227843c9376773784b8b362add44592ad7","https://git.kernel.org/stable/c/9cdac46fa7e854e587eb5f393fe491b6d7a9bdf6","https://git.kernel.org/stable/c/a1a7eb89ca0b89dc1c326eeee2596f263291aca3","https://git.kernel.org/stable/c/ca381f60a3bb7cfaa618d73ca411610bd7fc3149","https://git.kernel.org/stable/c/f58a3f8e284d0bdf94164a8e61cd4e70d337a1a3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21904
|
Medium |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.131
- 6.6.83
- 6.12.19
- 6.13.7
|
In the Linux kernel, the following vulnerability has been resolved:
caif_virtio: fix wrong pointer check in cfv_probe()
del_vqs() frees virtqueues, therefore cfv->vq_tx pointer should be checked
for NULL before calling it, not cfv->vdev. Also the current implementation
is redundant because the pointer cfv->vdev is dereferenced before it is
checked for NULL.
Fix this by checking cfv->vq_tx for NULL instead of cfv->vdev before
calling del_vqs(). |
["https://git.kernel.org/stable/c/29e0cd296c87240278e2f7ea4cf3f496b60c03af","https://git.kernel.org/stable/c/56cddf71cce3b15b078e937fadab29962b6f6643","https://git.kernel.org/stable/c/597c27e5f04cb50e56cc9aeda75d3e42b6b89c3e","https://git.kernel.org/stable/c/7b5fe58959822e6cfa884327cabba6be3b01883d","https://git.kernel.org/stable/c/8e4e08ca4cc634b337bb74bc9a70758fdeda0bcb","https://git.kernel.org/stable/c/90d302619ee7ce5ed0c69c29c290bdccfde66418","https://git.kernel.org/stable/c/990fff6980d0c1693d60a812f58dbf93eab0473f","https://git.kernel.org/stable/c/a466fd7e9fafd975949e5945e2f70c33a94b1a70"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21922
|
Medium |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.131
- 6.6.83
- 6.12.19
- 6.13.7
|
In the Linux kernel, the following vulnerability has been resolved:
ppp: Fix KMSAN uninit-value warning with bpf
Syzbot caught an "KMSAN: uninit-value" warning [1], which is caused by the
ppp driver not initializing a 2-byte header when using socket filter.
The following code can generate a PPP filter BPF program:
'''
struct bpf_program fp;
pcap_t *handle;
handle = pcap_open_dead(DLT_PPP_PPPD, 65535);
pcap_compile(handle, &fp, "ip and outbound", 0, 0);
bpf_dump(&fp, 1);
'''
Its output is:
'''
(000) ldh [2]
(001) jeq #0x21 jt 2 jf 5
(002) ldb [0]
(003) jeq #0x1 jt 4 jf 5
(004) ret #65535
(005) ret #0
'''
Wen can find similar code at the following link:
https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680
The maintainer of this code repository is also the original maintainer
of the ppp driver.
As you can see the BPF program skips 2 bytes of data and then reads the
'Protocol' field to determine if it's an IP packet. Then it read the first
byte of the first 2 bytes to determine the direction.
The issue is that only the first byte indicating direction is initialized
in current ppp driver code while the second byte is not initialized.
For normal BPF programs generated by libpcap, uninitialized data won't be
used, so it's not a problem. However, for carefully crafted BPF programs,
such as those generated by syzkaller [2], which start reading from offset
0, the uninitialized data will be used and caught by KMSAN.
[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791
[2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000 |
["https://git.kernel.org/stable/c/1eacd47636a9de5bee25d9d5962dc538a82d9f0b","https://git.kernel.org/stable/c/2f591cb158807bdcf424f66f1fbfa6e4e50f3757","https://git.kernel.org/stable/c/3de809a768464528762757e433cd50de35bcb3c1","https://git.kernel.org/stable/c/4c2d14c40a68678d885eab4008a0129646805bae","https://git.kernel.org/stable/c/4e2191b0fd0c064d37b0db67396216f2d4787e0f","https://git.kernel.org/stable/c/8aa8a40c766b3945b40565a70349d5581458ff63","https://git.kernel.org/stable/c/c036f5f2680cbdabdbbace86baee3c83721634d6","https://git.kernel.org/stable/c/d685096c8129c9a92689975193e268945fd21dbf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21948
|
Medium |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.131
- 6.6.83
- 6.12.19
- 6.13.7
|
In the Linux kernel, the following vulnerability has been resolved:
HID: appleir: Fix potential NULL dereference at raw event handle
Syzkaller reports a NULL pointer dereference issue in input_event().
BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:68 [inline]
BUG: KASAN: null-ptr-deref in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
BUG: KASAN: null-ptr-deref in is_event_supported drivers/input/input.c:67 [inline]
BUG: KASAN: null-ptr-deref in input_event+0x42/0xa0 drivers/input/input.c:395
Read of size 8 at addr 0000000000000028 by task syz-executor199/2949
CPU: 0 UID: 0 PID: 2949 Comm: syz-executor199 Not tainted 6.13.0-rc4-syzkaller-00076-gf097a36ef88d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
kasan_report+0xd9/0x110 mm/kasan/report.c:602
check_region_inline mm/kasan/generic.c:183 [inline]
kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189
instrument_atomic_read include/linux/instrumented.h:68 [inline]
_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
is_event_supported drivers/input/input.c:67 [inline]
input_event+0x42/0xa0 drivers/input/input.c:395
input_report_key include/linux/input.h:439 [inline]
key_down drivers/hid/hid-appleir.c:159 [inline]
appleir_raw_event+0x3e5/0x5e0 drivers/hid/hid-appleir.c:232
__hid_input_report.constprop.0+0x312/0x440 drivers/hid/hid-core.c:2111
hid_ctrl+0x49f/0x550 drivers/hid/usbhid/hid-core.c:484
__usb_hcd_giveback_urb+0x389/0x6e0 drivers/usb/core/hcd.c:1650
usb_hcd_giveback_urb+0x396/0x450 drivers/usb/core/hcd.c:1734
dummy_timer+0x17f7/0x3960 drivers/usb/gadget/udc/dummy_hcd.c:1993
__run_hrtimer kernel/time/hrtimer.c:1739 [inline]
__hrtimer_run_queues+0x20a/0xae0 kernel/time/hrtimer.c:1803
hrtimer_run_softirq+0x17d/0x350 kernel/time/hrtimer.c:1820
handle_softirqs+0x206/0x8d0 kernel/softirq.c:561
__do_softirq kernel/softirq.c:595 [inline]
invoke_softirq kernel/softirq.c:435 [inline]
__irq_exit_rcu+0xfa/0x160 kernel/softirq.c:662
irq_exit_rcu+0x9/0x30 kernel/softirq.c:678
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]
sysvec_apic_timer_interrupt+0x90/0xb0 arch/x86/kernel/apic/apic.c:1049
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702
__mod_timer+0x8f6/0xdc0 kernel/time/timer.c:1185
add_timer+0x62/0x90 kernel/time/timer.c:1295
schedule_timeout+0x11f/0x280 kernel/time/sleep_timeout.c:98
usbhid_wait_io+0x1c7/0x380 drivers/hid/usbhid/hid-core.c:645
usbhid_init_reports+0x19f/0x390 drivers/hid/usbhid/hid-core.c:784
hiddev_ioctl+0x1133/0x15b0 drivers/hid/usbhid/hiddev.c:794
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:906 [inline]
__se_sys_ioctl fs/ioctl.c:892 [inline]
__x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
This happens due to the malformed report items sent by the emulated device
which results in a report, that has no fields, being added to the report list.
Due to this appleir_input_configured() is never called, hidinput_connect()
fails which results in the HID_CLAIMED_INPUT flag is not being set. However,
it does not make appleir_probe() fail and lets the event callback to be
called without the associated input device.
Thus, add a check for the HID_CLAIMED_INPUT flag and leave the event hook
early if the driver didn't claim any input_dev for some reason. Moreover,
some other hid drivers accessing input_dev in their event callbacks do have
similar checks, too.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller. |
["https://git.kernel.org/stable/c/0df1ac8ee417ad76760ff076faa4518a4d861894","https://git.kernel.org/stable/c/2ff5baa9b5275e3acafdf7f2089f74cccb2f38d1","https://git.kernel.org/stable/c/68cdf6710f228dfd74f66ec61fbe636da2646a73","https://git.kernel.org/stable/c/6db423b00940b05df2a1265d3c7eabafe9f1734c","https://git.kernel.org/stable/c/8d39eb8c5e14f2f0f441eed832ef8a7b654e6fee","https://git.kernel.org/stable/c/b1d95d733cd6e74f595653daddcfc357bea461e8","https://git.kernel.org/stable/c/d335fce8b88b2353f4bb20c631698e20384e3610","https://git.kernel.org/stable/c/fc69e2c3219d433caabba4b5d6371ba726a4b37f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21957
|
Medium |
fixed |
- 5.4.292
- 5.10.236
- 5.15.180
- 6.1.132
- 6.6.84
- 6.12.20
- 6.13.8
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla1280: Fix kernel oops when debug level > 2
A null dereference or oops exception will eventually occur when qla1280.c
driver is compiled with DEBUG_QLA1280 enabled and ql_debug_level > 2. I
think its clear from the code that the intention here is sg_dma_len(s) not
length of sg_next(s) when printing the debug info. |
["https://git.kernel.org/stable/c/11a8dac1177a596648a020a7f3708257a2f95fee","https://git.kernel.org/stable/c/24602e2664c515a4f2950d7b52c3d5997463418c","https://git.kernel.org/stable/c/5233e3235dec3065ccc632729675575dbe3c6b8a","https://git.kernel.org/stable/c/7ac2473e727d67a38266b2b7e55c752402ab588c","https://git.kernel.org/stable/c/af71ba921d08c241a817010f96458dc5e5e26762","https://git.kernel.org/stable/c/afa27b7c17a48e01546ccaad0ab017ad0496a522","https://git.kernel.org/stable/c/c737e2a5fb7f90b96a96121da1b50a9c74ae9b8c","https://git.kernel.org/stable/c/ea371d1cdefb0951c7127a33bcd7eb931cf44571"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21959
|
Medium |
fixed |
- 4.15
- 5.4.292
- 5.10.236
- 5.15.180
- 6.1.132
- 6.6.84
- 6.12.20
- 6.13.8
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conncount: Fully initialize struct nf_conncount_tuple in insert_tree()
Since commit b36e4523d4d5 ("netfilter: nf_conncount: fix garbage
collection confirm race"), `cpu` and `jiffies32` were introduced to
the struct nf_conncount_tuple.
The commit made nf_conncount_add() initialize `conn->cpu` and
`conn->jiffies32` when allocating the struct.
In contrast, count_tree() was not changed to initialize them.
By commit 34848d5c896e ("netfilter: nf_conncount: Split insert and
traversal"), count_tree() was split and the relevant allocation
code now resides in insert_tree().
Initialize `conn->cpu` and `conn->jiffies32` in insert_tree().
BUG: KMSAN: uninit-value in find_or_evict net/netfilter/nf_conncount.c:117 [inline]
BUG: KMSAN: uninit-value in __nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143
find_or_evict net/netfilter/nf_conncount.c:117 [inline]
__nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143
count_tree net/netfilter/nf_conncount.c:438 [inline]
nf_conncount_count+0x82f/0x1e80 net/netfilter/nf_conncount.c:521
connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72
__nft_match_eval net/netfilter/nft_compat.c:403 [inline]
nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433
expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288
nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23
nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626
nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663
NF_HOOK_LIST include/linux/netfilter.h:350 [inline]
ip_sublist_rcv+0x17b7/0x17f0 net/ipv4/ip_input.c:633
ip_list_rcv+0x9ef/0xa40 net/ipv4/ip_input.c:669
__netif_receive_skb_list_ptype net/core/dev.c:5936 [inline]
__netif_receive_skb_list_core+0x15c5/0x1670 net/core/dev.c:5983
__netif_receive_skb_list net/core/dev.c:6035 [inline]
netif_receive_skb_list_internal+0x1085/0x1700 net/core/dev.c:6126
netif_receive_skb_list+0x5a/0x460 net/core/dev.c:6178
xdp_recv_frames net/bpf/test_run.c:280 [inline]
xdp_test_run_batch net/bpf/test_run.c:361 [inline]
bpf_test_run_xdp_live+0x2e86/0x3480 net/bpf/test_run.c:390
bpf_prog_test_run_xdp+0xf1d/0x1ae0 net/bpf/test_run.c:1316
bpf_prog_test_run+0x5e5/0xa30 kernel/bpf/syscall.c:4407
__sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5813
__do_sys_bpf kernel/bpf/syscall.c:5902 [inline]
__se_sys_bpf kernel/bpf/syscall.c:5900 [inline]
__ia32_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5900
ia32_sys_call+0x394d/0x4180 arch/x86/include/generated/asm/syscalls_32.h:358
do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline]
__do_fast_syscall_32+0xb0/0x110 arch/x86/entry/common.c:387
do_fast_syscall_32+0x38/0x80 arch/x86/entry/common.c:412
do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:450
entry_SYSENTER_compat_after_hwframe+0x84/0x8e
Uninit was created at:
slab_post_alloc_hook mm/slub.c:4121 [inline]
slab_alloc_node mm/slub.c:4164 [inline]
kmem_cache_alloc_noprof+0x915/0xe10 mm/slub.c:4171
insert_tree net/netfilter/nf_conncount.c:372 [inline]
count_tree net/netfilter/nf_conncount.c:450 [inline]
nf_conncount_count+0x1415/0x1e80 net/netfilter/nf_conncount.c:521
connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72
__nft_match_eval net/netfilter/nft_compat.c:403 [inline]
nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433
expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288
nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23
nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626
nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663
NF_HOOK_LIST include/linux/netfilter.h:350 [inline]
ip_sublist_rcv+0x17b7/0x17f0 net/ipv4/ip_input.c:633
ip_list_rcv+0x9ef/0xa40 net/ip
---truncated--- |
["https://git.kernel.org/stable/c/2a154ce766b995494e88d8d117fa82cc6b73dd87","https://git.kernel.org/stable/c/2db5baaf047a7c8d6ed5e2cc657b7854e155b7fc","https://git.kernel.org/stable/c/a62a25c6ad58fae997f48a0749afeda1c252ae51","https://git.kernel.org/stable/c/d653bfeb07ebb3499c403404c21ac58a16531607","https://git.kernel.org/stable/c/db1e0c0856821c59a32ea3af79476bf20a6beeb2","https://git.kernel.org/stable/c/e8544a5a97bee3674e7cd6bf0f3a4af517fa9146","https://git.kernel.org/stable/c/f522229c5563b59b4240261e406779bba6754159","https://git.kernel.org/stable/c/fda50302a13701d47fbe01e1739c7a51114144fb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21996
|
Medium |
fixed |
- 5.4.292
- 5.10.236
- 5.15.180
- 6.1.132
- 6.6.85
- 6.12.21
- 6.13.9
|
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: fix uninitialized size issue in radeon_vce_cs_parse()
On the off chance that command stream passed from userspace via
ioctl() call to radeon_vce_cs_parse() is weirdly crafted and
first command to execute is to encode (case 0x03000001), the function
in question will attempt to call radeon_vce_cs_reloc() with size
argument that has not been properly initialized. Specifically, 'size'
will point to 'tmp' variable before the latter had a chance to be
assigned any value.
Play it safe and init 'tmp' with 0, thus ensuring that
radeon_vce_cs_reloc() will catch an early error in cases like these.
Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.
(cherry picked from commit 2d52de55f9ee7aaee0e09ac443f77855989c6b68) |
["https://git.kernel.org/stable/c/0effb378ebce52b897f85cd7f828854b8c7cb636","https://git.kernel.org/stable/c/3ce08215cad55c10a6eeeb33d3583b6cfffe3ab8","https://git.kernel.org/stable/c/5b4d9d20fd455a97920cf158dd19163b879cf65d","https://git.kernel.org/stable/c/78b07dada3f02f77762d0755a96d35f53b02be69","https://git.kernel.org/stable/c/9b2da9c673a0da1359a2151f7ce773e2f77d71a9","https://git.kernel.org/stable/c/dd1801aa01bba1760357f2a641346ae149686713","https://git.kernel.org/stable/c/dd8689b52a24807c2d5ce0a17cb26dc87f75235c","https://git.kernel.org/stable/c/f5e049028124f755283f2c07e7a3708361ed1dc8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50142
|
Medium |
fixed |
- 4.19.323
- 5.4.285
- 5.10.229
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
xfrm: validate new SA's prefixlen using SA family when sel.family is unset
This expands the validation introduced in commit 07bf7908950a ("xfrm:
Validate address prefix lengths in the xfrm selector.")
syzbot created an SA with
usersa.sel.family = AF_UNSPEC
usersa.sel.prefixlen_s = 128
usersa.family = AF_INET
Because of the AF_UNSPEC selector, verify_newsa_info doesn't put
limits on prefixlen_{s,d}. But then copy_from_user_state sets
x->sel.family to usersa.family (AF_INET). Do the same conversion in
verify_newsa_info before validating prefixlen_{s,d}, since that's how
prefixlen is going to be used later on. |
["https://git.kernel.org/stable/c/2d08a6c31c65f23db71a5385ee9cf9d8f9a67a71","https://git.kernel.org/stable/c/3f0ab59e6537c6a8f9e1b355b48f9c05a76e8563","https://git.kernel.org/stable/c/401ad99a5ae7180dd9449eac104cb755f442e7f3","https://git.kernel.org/stable/c/7d9868180bd1e4cf37e7c5067362658971162366","https://git.kernel.org/stable/c/8df5cd51fd70c33aa1776e5cbcd82b0a86649d73","https://git.kernel.org/stable/c/bce1afaa212ec380bf971614f70909a27882b862","https://git.kernel.org/stable/c/e68dd80ba498265d2266b12dc3459164f4ff0c4a","https://git.kernel.org/stable/c/f31398570acf0f0804c644006f7bfa9067106b0a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46795
|
Medium |
fixed |
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: unset the binding mark of a reused connection
Steve French reported null pointer dereference error from sha256 lib.
cifs.ko can send session setup requests on reused connection.
If reused connection is used for binding session, conn->binding can
still remain true and generate_preauth_hash() will not set
sess->Preauth_HashValue and it will be NULL.
It is used as a material to create an encryption key in
ksmbd_gen_smb311_encryptionkey. ->Preauth_HashValue cause null pointer
dereference error from crypto_shash_update().
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 8 PID: 429254 Comm: kworker/8:39
Hardware name: LENOVO 20MAS08500/20MAS08500, BIOS N2CET69W (1.52 )
Workqueue: ksmbd-io handle_ksmbd_work [ksmbd]
RIP: 0010:lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]
<TASK>
? show_regs+0x6d/0x80
? __die+0x24/0x80
? page_fault_oops+0x99/0x1b0
? do_user_addr_fault+0x2ee/0x6b0
? exc_page_fault+0x83/0x1b0
? asm_exc_page_fault+0x27/0x30
? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]
? lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]
? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]
? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]
_sha256_update+0x77/0xa0 [sha256_ssse3]
sha256_avx2_update+0x15/0x30 [sha256_ssse3]
crypto_shash_update+0x1e/0x40
hmac_update+0x12/0x20
crypto_shash_update+0x1e/0x40
generate_key+0x234/0x380 [ksmbd]
generate_smb3encryptionkey+0x40/0x1c0 [ksmbd]
ksmbd_gen_smb311_encryptionkey+0x72/0xa0 [ksmbd]
ntlm_authenticate.isra.0+0x423/0x5d0 [ksmbd]
smb2_sess_setup+0x952/0xaa0 [ksmbd]
__process_request+0xa3/0x1d0 [ksmbd]
__handle_ksmbd_work+0x1c4/0x2f0 [ksmbd]
handle_ksmbd_work+0x2d/0xa0 [ksmbd]
process_one_work+0x16c/0x350
worker_thread+0x306/0x440
? __pfx_worker_thread+0x10/0x10
kthread+0xef/0x120
? __pfx_kthread+0x10/0x10
ret_from_fork+0x44/0x70
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1b/0x30
</TASK> |
["https://git.kernel.org/stable/c/41bc256da7e47b679df87c7fc7a5b393052b9cce","https://git.kernel.org/stable/c/4c8496f44f5bb5c06cdef5eb130ab259643392a1","https://git.kernel.org/stable/c/78c5a6f1f630172b19af4912e755e1da93ef0ab5","https://git.kernel.org/stable/c/93d54a4b59c4b3d803d20aa645ab5ca71f3b3b02","https://git.kernel.org/stable/c/9914f1bd61d5e838bb1ab15a71076d37a6db65d1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4244
|
High |
fixed |
|
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.
Due to a race condition between nf_tables netlink control plane transaction and nft_set element garbage collection, it is possible to underflow the reference counter causing a use-after-free vulnerability.
We recommend upgrading past commit 3e91b0ebd994635df2346353322ac51ce84ce6d8. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e91b0ebd994635df2346353322ac51ce84ce6d8","https://kernel.dance/3e91b0ebd994635df2346353322ac51ce84ce6d8","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e91b0ebd994635df2346353322ac51ce84ce6d8","https://kernel.dance/3e91b0ebd994635df2346353322ac51ce84ce6d8","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56712
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
udmabuf: fix memory leak on last export_udmabuf() error path
In export_udmabuf(), if dma_buf_fd() fails because the FD table is full, a
dma_buf owning the udmabuf has already been created; but the error handling
in udmabuf_create() will tear down the udmabuf without doing anything about
the containing dma_buf.
This leaves a dma_buf in memory that contains a dangling pointer; though
that doesn't seem to lead to anything bad except a memory leak.
Fix it by moving the dma_buf_fd() call out of export_udmabuf() so that we
can give it different error handling.
Note that the shape of this code changed a lot in commit 5e72b2b41a21
("udmabuf: convert udmabuf driver to use folios"); but the memory leak
seems to have existed since the introduction of udmabuf. |
["https://git.kernel.org/stable/c/c9fc8428d4255c2128da9c4d5cd92e554d0150cf","https://git.kernel.org/stable/c/f49856f525acd5bef52ae28b7da2e001bbe7439e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27019
|
Medium |
fixed |
- 5.15.157
- 6.1.88
- 6.6.29
- 6.8.8
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()
nft_unregister_obj() can concurrent with __nft_obj_type_get(),
and there is not any protection when iterate over nf_tables_objects
list in __nft_obj_type_get(). Therefore, there is potential data-race
of nf_tables_objects list entry.
Use list_for_each_entry_rcu() to iterate over nf_tables_objects
list in __nft_obj_type_get(), and use rcu_read_lock() in the caller
nft_obj_type_get() to protect the entire type query process. |
["https://git.kernel.org/stable/c/379bf7257bc5f2a1b1ca8514e08a871b7bf6d920","https://git.kernel.org/stable/c/4ca946b19caf655a08d5e2266d4d5526025ebb73","https://git.kernel.org/stable/c/ad333578f736d56920e090d7db1f8dec891d815e","https://git.kernel.org/stable/c/cade34279c2249eafe528564bd2e203e4ff15f88","https://git.kernel.org/stable/c/d78d867dcea69c328db30df665be5be7d0148484","https://git.kernel.org/stable/c/df7c0fb8c2b9f9cac65659332581b19682a71349","https://git.kernel.org/stable/c/379bf7257bc5f2a1b1ca8514e08a871b7bf6d920","https://git.kernel.org/stable/c/4ca946b19caf655a08d5e2266d4d5526025ebb73","https://git.kernel.org/stable/c/ad333578f736d56920e090d7db1f8dec891d815e","https://git.kernel.org/stable/c/cade34279c2249eafe528564bd2e203e4ff15f88","https://git.kernel.org/stable/c/d78d867dcea69c328db30df665be5be7d0148484","https://git.kernel.org/stable/c/df7c0fb8c2b9f9cac65659332581b19682a71349"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50192
|
Medium |
fixed |
- 5.10.228
- 5.15.169
- 6.1.114
- 6.6.58
- 6.11.5
|
In the Linux kernel, the following vulnerability has been resolved:
irqchip/gic-v4: Don't allow a VMOVP on a dying VPE
Kunkun Jiang reported that there is a small window of opportunity for
userspace to force a change of affinity for a VPE while the VPE has already
been unmapped, but the corresponding doorbell interrupt still visible in
/proc/irq/.
Plug the race by checking the value of vmapp_count, which tracks whether
the VPE is mapped ot not, and returning an error in this case.
This involves making vmapp_count common to both GICv4.1 and its v4.0
ancestor. |
["https://git.kernel.org/stable/c/01282ab5182f85e42234df2ff42f0ce790f465ff","https://git.kernel.org/stable/c/1442ee0011983f0c5c4b92380e6853afb513841a","https://git.kernel.org/stable/c/64b12b061c5488e2d69e67c4eaae5da64fd30bfe","https://git.kernel.org/stable/c/755b9532c885b8761fb135fedcd705e21e61cccb","https://git.kernel.org/stable/c/b7d7b7fc876f836f40bf48a87e07ea18756ba196","https://git.kernel.org/stable/c/d960505a869e66184fff97fb334980a5b797c7c6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50010
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
exec: don't WARN for racy path_noexec check
Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact
of the previous implementation. They used to legitimately check for the
condition, but that got moved up in two commits:
633fb6ac3980 ("exec: move S_ISREG() check earlier")
0fd338b2d2cd ("exec: move path_noexec() check earlier")
Instead of being removed said checks are WARN_ON'ed instead, which
has some debug value.
However, the spurious path_noexec check is racy, resulting in
unwarranted warnings should someone race with setting the noexec flag.
One can note there is more to perm-checking whether execve is allowed
and none of the conditions are guaranteed to still hold after they were
tested for.
Additionally this does not validate whether the code path did any perm
checking to begin with -- it will pass if the inode happens to be
regular.
Keep the redundant path_noexec() check even though it's mindless
nonsense checking for guarantee that isn't given so drop the WARN.
Reword the commentary and do small tidy ups while here.
[brauner: keep redundant path_noexec() check] |
["https://git.kernel.org/stable/c/0bdf77be2330062b3a64f2bec39f62ab874a6796","https://git.kernel.org/stable/c/0d16f53c91111cec914f0811fcc526a2ba77b20d","https://git.kernel.org/stable/c/0d196e7589cefe207d5d41f37a0a28a1fdeeb7c6","https://git.kernel.org/stable/c/b723f96407a0a078cf75970e4dbf16b46d286a61","https://git.kernel.org/stable/c/c9b77438077d5a20c79ead95bcdaf9bd4797baaf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49866
|
Medium |
fixed |
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
tracing/timerlat: Fix a race during cpuhp processing
There is another found exception that the "timerlat/1" thread was
scheduled on CPU0, and lead to timer corruption finally:
```
ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220
WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0
Modules linked in:
CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:debug_print_object+0x7d/0xb0
...
Call Trace:
<TASK>
? __warn+0x7c/0x110
? debug_print_object+0x7d/0xb0
? report_bug+0xf1/0x1d0
? prb_read_valid+0x17/0x20
? handle_bug+0x3f/0x70
? exc_invalid_op+0x13/0x60
? asm_exc_invalid_op+0x16/0x20
? debug_print_object+0x7d/0xb0
? debug_print_object+0x7d/0xb0
? __pfx_timerlat_irq+0x10/0x10
__debug_object_init+0x110/0x150
hrtimer_init+0x1d/0x60
timerlat_main+0xab/0x2d0
? __pfx_timerlat_main+0x10/0x10
kthread+0xb7/0xe0
? __pfx_kthread+0x10/0x10
ret_from_fork+0x2d/0x40
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
```
After tracing the scheduling event, it was discovered that the migration
of the "timerlat/1" thread was performed during thread creation. Further
analysis confirmed that it is because the CPU online processing for
osnoise is implemented through workers, which is asynchronous with the
offline processing. When the worker was scheduled to create a thread, the
CPU may has already been removed from the cpu_online_mask during the offline
process, resulting in the inability to select the right CPU:
T1 | T2
[CPUHP_ONLINE] | cpu_device_down()
osnoise_hotplug_workfn() |
| cpus_write_lock()
| takedown_cpu(1)
| cpus_write_unlock()
[CPUHP_OFFLINE] |
cpus_read_lock() |
start_kthread(1) |
cpus_read_unlock() |
To fix this, skip online processing if the CPU is already offline. |
["https://git.kernel.org/stable/c/322920b53dc11f9c2b33397eb3ae5bc6a175b60d","https://git.kernel.org/stable/c/829e0c9f0855f26b3ae830d17b24aec103f7e915","https://git.kernel.org/stable/c/a0d9c0cd5856191e095cf43a2e141b73945b7716","https://git.kernel.org/stable/c/a6e9849063a6c8f4cb2f652a437e44e3ed24356c","https://git.kernel.org/stable/c/ce25f33ba89d6eefef64157655d318444580fa14","https://git.kernel.org/stable/c/f72b451dc75578f644a3019c1489e9ae2c14e6c4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21905
|
High |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.131
- 6.6.83
- 6.12.19
- 6.13.7
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: limit printed string from FW file
There's no guarantee here that the file is always with a
NUL-termination, so reading the string may read beyond the
end of the TLV. If that's the last TLV in the file, it can
perhaps even read beyond the end of the file buffer.
Fix that by limiting the print format to the size of the
buffer we have. |
["https://git.kernel.org/stable/c/38f0d398b6d7640d223db69df022c4a232f24774","https://git.kernel.org/stable/c/47616b82f2d42ea2060334746fed9a2988d845c9","https://git.kernel.org/stable/c/59cdda202829d1d6a095d233386870a59aff986f","https://git.kernel.org/stable/c/88ed69f924638c7503644e1f8eed1e976f3ffa7a","https://git.kernel.org/stable/c/b02f8d5a71c8571ccf77f285737c566db73ef5e5","https://git.kernel.org/stable/c/c0e626f2b2390472afac52dfe72b29daf9ed8e1d","https://git.kernel.org/stable/c/e0dc2c1bef722cbf16ae557690861e5f91208129","https://git.kernel.org/stable/c/f265e6031d0bc4fc40c4619cb42466722b46eaa9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21920
|
High |
fixed |
- 5.4.291
- 5.10.235
- 5.15.179
- 6.1.131
- 6.6.83
- 6.12.19
- 6.13.7
|
In the Linux kernel, the following vulnerability has been resolved:
vlan: enforce underlying device type
Currently, VLAN devices can be created on top of non-ethernet devices.
Besides the fact that it doesn't make much sense, this also causes a
bug which leaks the address of a kernel function to usermode.
When creating a VLAN device, we initialize GARP (garp_init_applicant)
and MRP (mrp_init_applicant) for the underlying device.
As part of the initialization process, we add the multicast address of
each applicant to the underlying device, by calling dev_mc_add.
__dev_mc_add uses dev->addr_len to determine the length of the new
multicast address.
This causes an out-of-bounds read if dev->addr_len is greater than 6,
since the multicast addresses provided by GARP and MRP are only 6
bytes long.
This behaviour can be reproduced using the following commands:
ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo
ip l set up dev gretest
ip link add link gretest name vlantest type vlan id 100
Then, the following command will display the address of garp_pdu_rcv:
ip maddr show | grep 01:80:c2:00:00:21
Fix the bug by enforcing the type of the underlying device during VLAN
device initialization. |
["https://git.kernel.org/stable/c/0fb7aa04c19eac4417f360a9f7611a60637bdacc","https://git.kernel.org/stable/c/30e8aee77899173a82ae5ed89f536c096f20aaeb","https://git.kernel.org/stable/c/3561442599804905c3defca241787cd4546e99a7","https://git.kernel.org/stable/c/5a515d13e15536e82c5c7c83eb6cf5bc4827fee5","https://git.kernel.org/stable/c/7f1564b2b2072b7aa1ac75350e9560a07c7a44fd","https://git.kernel.org/stable/c/b33a534610067ade2bdaf2052900aaad99701353","https://git.kernel.org/stable/c/b6c72479748b7ea09f53ed64b223cee6463dc278","https://git.kernel.org/stable/c/fa40ebef69234e39ec2d26930d045f2fb9a8cb2b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21993
|
High |
fixed |
- 6.1.132
- 6.6.84
- 6.12.20
- 6.13.8
|
In the Linux kernel, the following vulnerability has been resolved:
iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic()
When performing an iSCSI boot using IPv6, iscsistart still reads the
/sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefix
length is 64, this causes the shift exponent to become negative,
triggering a UBSAN warning. As the concept of a subnet mask does not
apply to IPv6, the value is set to ~0 to suppress the warning message. |
["https://git.kernel.org/stable/c/07e0d99a2f701123ad3104c0f1a1e66bce74d6e5","https://git.kernel.org/stable/c/2d1eef248107bdf3d5a69d0fde04c30a79a7bf5d","https://git.kernel.org/stable/c/9bfa80c8aa4e06dff55a953c3fffbfc68a3a3b1c","https://git.kernel.org/stable/c/a858cd58dea06cf85b142673deea8c5d87f11e70","https://git.kernel.org/stable/c/b253660fac5e0e9080d2c95e3a029e1898d49afb","https://git.kernel.org/stable/c/b388e185bfad32bfed6a97a6817f74ca00a4318f","https://git.kernel.org/stable/c/c1c6e527470e5eab0b2d57bd073530fbace39eab","https://git.kernel.org/stable/c/f763c82db8166e28f45b7cc4a5398a7859665940"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1973
|
High |
fixed |
|
A use-after-free flaw was found in the Linux kernel in log_replay in fs/ntfs3/fslog.c in the NTFS journal. This flaw allows a local attacker to crash the system and leads to a kernel information leak problem. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2092542","https://security.netapp.com/advisory/ntap-20230120-0001/","https://bugzilla.redhat.com/show_bug.cgi?id=2092542","https://security.netapp.com/advisory/ntap-20230120-0001/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49001
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
riscv: fix race when vmap stack overflow
Currently, when detecting vmap stack overflow, riscv firstly switches
to the so called shadow stack, then use this shadow stack to call the
get_overflow_stack() to get the overflow stack. However, there's
a race here if two or more harts use the same shadow stack at the same
time.
To solve this race, we introduce spin_shadow_stack atomic var, which
will be swap between its own address and 0 in atomic way, when the
var is set, it means the shadow_stack is being used; when the var
is cleared, it means the shadow_stack isn't being used.
[Palmer: Add AQ to the swap, and also some comments.] |
["https://git.kernel.org/stable/c/7e1864332fbc1b993659eab7974da9fe8bf8c128","https://git.kernel.org/stable/c/879fabc5a95401d9bce357e4b1d24ae4a360a81f","https://git.kernel.org/stable/c/ac00301adb19df54f2eae1efc4bad7447c0156ce"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1077
|
High |
fixed |
- 4.19.293
- 5.4.235
- 5.10.173
- 5.15.99
- 6.1.16
- 6.2.3
|
In the Linux kernel, pick_next_rt_entity() may return a type confused entry, not detected by the BUG_ON condition, as the confused entry will not be NULL, but list_head.The buggy error condition would lead to a type confused entry with the list head,which would then be used as a type confused sched_rt_entity,causing memory corruption. |
["https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=7c4a5b89a0b5a57a64b601775b296abf77a9fe97","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230511-0002/","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=7c4a5b89a0b5a57a64b601775b296abf77a9fe97","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230511-0002/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-51782
|
High |
fixed |
|
An issue was discovered in the Linux kernel before 6.6.8. rose_ioctl in net/rose/af_rose.c has a use-after-free because of a rose_accept race condition. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.8","https://github.com/torvalds/linux/commit/810c38a369a0a0ce625b5c12169abce1dd9ccd53","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.8","https://github.com/torvalds/linux/commit/810c38a369a0a0ce625b5c12169abce1dd9ccd53","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3389
|
High |
fixed |
|
A use-after-free vulnerability in the Linux Kernel io_uring subsystem can be exploited to achieve local privilege escalation.
Racing a io_uring cancel poll request with a linked timeout can cause a UAF in a hrtimer.
We recommend upgrading past commit ef7dfac51d8ed961b742218f526bd589f3900a59 (4716c73b188566865bdd79c3a6709696a224ac04 for 5.10 stable and 0e388fce7aec40992eadee654193cad345d62663 for 5.15 stable). |
["http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y\u0026id=4716c73b188566865bdd79c3a6709696a224ac04","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.15.y\u0026id=0e388fce7aec40992eadee654193cad345d62663","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ef7dfac51d8ed961b742218f526bd589f3900a59","https://kernel.dance/0e388fce7aec40992eadee654193cad345d62663","https://kernel.dance/4716c73b188566865bdd79c3a6709696a224ac04","https://kernel.dance/ef7dfac51d8ed961b742218f526bd589f3900a59","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20230731-0001/","https://www.debian.org/security/2023/dsa-5480","http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y\u0026id=4716c73b188566865bdd79c3a6709696a224ac04","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.15.y\u0026id=0e388fce7aec40992eadee654193cad345d62663","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ef7dfac51d8ed961b742218f526bd589f3900a59","https://kernel.dance/0e388fce7aec40992eadee654193cad345d62663","https://kernel.dance/4716c73b188566865bdd79c3a6709696a224ac04","https://kernel.dance/ef7dfac51d8ed961b742218f526bd589f3900a59","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20230731-0001/","https://www.debian.org/security/2023/dsa-5480"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21919
|
High |
fixed |
- 5.15.179
- 6.1.131
- 6.6.83
- 6.12.19
- 6.13.7
|
In the Linux kernel, the following vulnerability has been resolved:
sched/fair: Fix potential memory corruption in child_cfs_rq_on_list
child_cfs_rq_on_list attempts to convert a 'prev' pointer to a cfs_rq.
This 'prev' pointer can originate from struct rq's leaf_cfs_rq_list,
making the conversion invalid and potentially leading to memory
corruption. Depending on the relative positions of leaf_cfs_rq_list and
the task group (tg) pointer within the struct, this can cause a memory
fault or access garbage data.
The issue arises in list_add_leaf_cfs_rq, where both
cfs_rq->leaf_cfs_rq_list and rq->leaf_cfs_rq_list are added to the same
leaf list. Also, rq->tmp_alone_branch can be set to rq->leaf_cfs_rq_list.
This adds a check `if (prev == &rq->leaf_cfs_rq_list)` after the main
conditional in child_cfs_rq_on_list. This ensures that the container_of
operation will convert a correct cfs_rq struct.
This check is sufficient because only cfs_rqs on the same CPU are added
to the list, so verifying the 'prev' pointer against the current rq's list
head is enough.
Fixes a potential memory corruption issue that due to current struct
layout might not be manifesting as a crash but could lead to unpredictable
behavior when the layout changes. |
["https://git.kernel.org/stable/c/000c9ee43928f2ce68a156dd40bab7616256f4dd","https://git.kernel.org/stable/c/3b4035ddbfc8e4521f85569998a7569668cccf51","https://git.kernel.org/stable/c/5cb300dcdd27e6a351ac02541e0231261c775852","https://git.kernel.org/stable/c/9cc7f0018609f75a349e42e3aebc3b0e905ba775","https://git.kernel.org/stable/c/b5741e4b9ef3567613b2351384f91d3f16e59986","https://git.kernel.org/stable/c/e1dd09df30ba86716cb2ffab97dc35195c01eb8f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53174
|
High |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: make sure cache entry active before cache_show
The function `c_show` was called with protection from RCU. This only
ensures that `cp` will not be freed. Therefore, the reference count for
`cp` can drop to zero, which will trigger a refcount use-after-free
warning when `cache_get` is called. To resolve this issue, use
`cache_get_rcu` to ensure that `cp` remains active.
------------[ cut here ]------------
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 7 PID: 822 at lib/refcount.c:25
refcount_warn_saturate+0xb1/0x120
CPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.1-2.fc37 04/01/2014
RIP: 0010:refcount_warn_saturate+0xb1/0x120
Call Trace:
<TASK>
c_show+0x2fc/0x380 [sunrpc]
seq_read_iter+0x589/0x770
seq_read+0x1e5/0x270
proc_reg_read+0xe1/0x140
vfs_read+0x125/0x530
ksys_read+0xc1/0x160
do_syscall_64+0x5f/0x170
entry_SYSCALL_64_after_hwframe+0x76/0x7e |
["https://git.kernel.org/stable/c/02999e135b013d85c6df738746e8e24699befee4","https://git.kernel.org/stable/c/068c0b50f3f700b94f78850834cd91ae3b34c2c1","https://git.kernel.org/stable/c/2862eee078a4d2d1f584e7f24fa50dddfa5f3471","https://git.kernel.org/stable/c/acfaf37888e0f0732fb6a50ff093dce6d99994d0","https://git.kernel.org/stable/c/c7dac3af57e38b2054f990e573256d90bf887958","https://git.kernel.org/stable/c/d882e2b7fad3f5e5fac66184a347f408813f654a","https://git.kernel.org/stable/c/e9be26735d055c42543a4d047a769cc6d0fb1504","https://git.kernel.org/stable/c/ec305f303bf070b4f6896b7a76009f702956d402"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56558
|
High |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.12.4
|
In the Linux kernel, the following vulnerability has been resolved:
nfsd: make sure exp active before svc_export_show
The function `e_show` was called with protection from RCU. This only
ensures that `exp` will not be freed. Therefore, the reference count for
`exp` can drop to zero, which will trigger a refcount use-after-free
warning when `exp_get` is called. To resolve this issue, use
`cache_get_rcu` to ensure that `exp` remains active.
------------[ cut here ]------------
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 3 PID: 819 at lib/refcount.c:25
refcount_warn_saturate+0xb1/0x120
CPU: 3 UID: 0 PID: 819 Comm: cat Not tainted 6.12.0-rc3+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.1-2.fc37 04/01/2014
RIP: 0010:refcount_warn_saturate+0xb1/0x120
...
Call Trace:
<TASK>
e_show+0x20b/0x230 [nfsd]
seq_read_iter+0x589/0x770
seq_read+0x1e5/0x270
vfs_read+0x125/0x530
ksys_read+0xc1/0x160
do_syscall_64+0x5f/0x170
entry_SYSCALL_64_after_hwframe+0x76/0x7e |
["https://git.kernel.org/stable/c/1cecfdbc6bfc89c516d286884c7f29267b95de2b","https://git.kernel.org/stable/c/6cefcadd34e3c71c81ea64b899a0daa86314a51a","https://git.kernel.org/stable/c/7365d1f8de63cffdbbaa2287ce0205438e1a922f","https://git.kernel.org/stable/c/7d8f7816bebcd2e7400bb4d786eccb8f33c9f9ec","https://git.kernel.org/stable/c/7fd29d284b55c2274f7a748e6c5f25b4758b8da5","https://git.kernel.org/stable/c/be8f982c369c965faffa198b46060f8853e0f1f0","https://git.kernel.org/stable/c/e2fa0d0e327279a8defb87b263cd0bf288fd9261"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56678
|
High |
fixed |
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
powerpc/mm/fault: Fix kfence page fault reporting
copy_from_kernel_nofault() can be called when doing read of /proc/kcore.
/proc/kcore can have some unmapped kfence objects which when read via
copy_from_kernel_nofault() can cause page faults. Since *_nofault()
functions define their own fixup table for handling fault, use that
instead of asking kfence to handle such faults.
Hence we search the exception tables for the nip which generated the
fault. If there is an entry then we let the fixup table handler handle the
page fault by returning an error from within ___do_page_fault().
This can be easily triggered if someone tries to do dd from /proc/kcore.
eg. dd if=/proc/kcore of=/dev/null bs=1M
Some example false negatives:
===============================
BUG: KFENCE: invalid read in copy_from_kernel_nofault+0x9c/0x1a0
Invalid read at 0xc0000000fdff0000:
copy_from_kernel_nofault+0x9c/0x1a0
0xc00000000665f950
read_kcore_iter+0x57c/0xa04
proc_reg_read_iter+0xe4/0x16c
vfs_read+0x320/0x3ec
ksys_read+0x90/0x154
system_call_exception+0x120/0x310
system_call_vectored_common+0x15c/0x2ec
BUG: KFENCE: use-after-free read in copy_from_kernel_nofault+0x9c/0x1a0
Use-after-free read at 0xc0000000fe050000 (in kfence-#2):
copy_from_kernel_nofault+0x9c/0x1a0
0xc00000000665f950
read_kcore_iter+0x57c/0xa04
proc_reg_read_iter+0xe4/0x16c
vfs_read+0x320/0x3ec
ksys_read+0x90/0x154
system_call_exception+0x120/0x310
system_call_vectored_common+0x15c/0x2ec |
["https://git.kernel.org/stable/c/06dbbb4d5f7126b6307ab807cbf04ecfc459b933","https://git.kernel.org/stable/c/15f78d2c3d1452645bd8b9da909b0ca266f83c43","https://git.kernel.org/stable/c/4d2655754e94741b159aa807b72ea85518a65fd5","https://git.kernel.org/stable/c/7eaeb7a49b6d16640f9f3c9074c05175d74c710b","https://git.kernel.org/stable/c/9ea8d8bf9b625e8ad3be6b0432aecdc549914121","https://git.kernel.org/stable/c/e0a470b5733c1fe068d5c58b0bb91ad539604bc6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-4378
|
High |
|
N/A
|
A stack overflow flaw was found in the Linux kernel's SYSCTL subsystem in how a user changes certain kernel parameters and variables. This flaw allows a local user to crash or potentially escalate their privileges on the system. |
["http://packetstormsecurity.com/files/171289/Kernel-Live-Patch-Security-Notice-LNS-0092-1.html","https://bugzilla.redhat.com/show_bug.cgi?id=2152548","https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-6.0/proc-avoid-integer-type-confusion-in-get_proc_long.patch","https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-6.0/proc-proc_skip_spaces-shouldn-t-think-it-is-working-on-c-strings.patch","https://seclists.org/oss-sec/2022/q4/178","http://packetstormsecurity.com/files/171289/Kernel-Live-Patch-Security-Notice-LNS-0092-1.html","https://bugzilla.redhat.com/show_bug.cgi?id=2152548","https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-6.0/proc-avoid-integer-type-confusion-in-get_proc_long.patch","https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-6.0/proc-proc_skip_spaces-shouldn-t-think-it-is-working-on-c-strings.patch","https://seclists.org/oss-sec/2022/q4/178"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53168
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket
BUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0
Read of size 1 at addr ffff888111f322cd by task swapper/0/0
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1
Call Trace:
<IRQ>
dump_stack_lvl+0x68/0xa0
print_address_description.constprop.0+0x2c/0x3d0
print_report+0xb4/0x270
kasan_report+0xbd/0xf0
tcp_write_timer_handler+0x156/0x3e0
tcp_write_timer+0x66/0x170
call_timer_fn+0xfb/0x1d0
__run_timers+0x3f8/0x480
run_timer_softirq+0x9b/0x100
handle_softirqs+0x153/0x390
__irq_exit_rcu+0x103/0x120
irq_exit_rcu+0xe/0x20
sysvec_apic_timer_interrupt+0x76/0x90
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20
RIP: 0010:default_idle+0xf/0x20
Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90
90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 <fa> c3 cc cc cc
cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90
RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242
RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590f
RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835d
R10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000
R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0
default_idle_call+0x6b/0xa0
cpuidle_idle_call+0x1af/0x1f0
do_idle+0xbc/0x130
cpu_startup_entry+0x33/0x40
rest_init+0x11f/0x210
start_kernel+0x39a/0x420
x86_64_start_reservations+0x18/0x30
x86_64_start_kernel+0x97/0xa0
common_startup_64+0x13e/0x141
</TASK>
Allocated by task 595:
kasan_save_stack+0x24/0x50
kasan_save_track+0x14/0x30
__kasan_slab_alloc+0x87/0x90
kmem_cache_alloc_noprof+0x12b/0x3f0
copy_net_ns+0x94/0x380
create_new_namespaces+0x24c/0x500
unshare_nsproxy_namespaces+0x75/0xf0
ksys_unshare+0x24e/0x4f0
__x64_sys_unshare+0x1f/0x30
do_syscall_64+0x70/0x180
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 100:
kasan_save_stack+0x24/0x50
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x54/0x70
kmem_cache_free+0x156/0x5d0
cleanup_net+0x5d3/0x670
process_one_work+0x776/0xa90
worker_thread+0x2e2/0x560
kthread+0x1a8/0x1f0
ret_from_fork+0x34/0x60
ret_from_fork_asm+0x1a/0x30
Reproduction script:
mkdir -p /mnt/nfsshare
mkdir -p /mnt/nfs/netns_1
mkfs.ext4 /dev/sdb
mount /dev/sdb /mnt/nfsshare
systemctl restart nfs-server
chmod 777 /mnt/nfsshare
exportfs -i -o rw,no_root_squash *:/mnt/nfsshare
ip netns add netns_1
ip link add name veth_1_peer type veth peer veth_1
ifconfig veth_1_peer 11.11.0.254 up
ip link set veth_1 netns netns_1
ip netns exec netns_1 ifconfig veth_1 11.11.0.1
ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp \
--tcp-flags FIN FIN -j DROP
(note: In my environment, a DESTROY_CLIENTID operation is always sent
immediately, breaking the nfs tcp connection.)
ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 \
11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1
ip netns del netns_1
The reason here is that the tcp socket in netns_1 (nfs side) has been
shutdown and closed (done in xs_destroy), but the FIN message (with ack)
is discarded, and the nfsd side keeps sending retransmission messages.
As a result, when the tcp sock in netns_1 processes the received message,
it sends the message (FIN message) in the sending queue, and the tcp timer
is re-established. When the network namespace is deleted, the net structure
accessed by tcp's timer handler function causes problems.
To fix this problem, let's hold netns refcnt for the tcp kernel socket as
done in other modules. This is an ugly hack which can easily be backported
to earlier kernels. A proper fix which cleans up the interfaces will
follow, but may not be so easy to backport. |
["https://git.kernel.org/stable/c/0ca87e5063757132a044d35baba40a7d4bb25394","https://git.kernel.org/stable/c/3f23f96528e8fcf8619895c4c916c52653892ec1","https://git.kernel.org/stable/c/61c0a5eac96836de5e3a5897eccdc63162a94936","https://git.kernel.org/stable/c/694ccb05b79ee5f5a9f14c2f80d2635d3bb8bdc3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53177
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
smb: prevent use-after-free due to open_cached_dir error paths
If open_cached_dir() encounters an error parsing the lease from the
server, the error handling may race with receiving a lease break,
resulting in open_cached_dir() freeing the cfid while the queued work is
pending.
Update open_cached_dir() to drop refs rather than directly freeing the
cfid.
Have cached_dir_lease_break(), cfids_laundromat_worker(), and
invalidate_all_cached_dirs() clear has_lease immediately while still
holding cfids->cfid_list_lock, and then use this to also simplify the
reference counting in cfids_laundromat_worker() and
invalidate_all_cached_dirs().
Fixes this KASAN splat (which manually injects an error and lease break
in open_cached_dir()):
==================================================================
BUG: KASAN: slab-use-after-free in smb2_cached_lease_break+0x27/0xb0
Read of size 8 at addr ffff88811cc24c10 by task kworker/3:1/65
CPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 Not tainted 6.12.0-rc6-g255cf264e6e5-dirty #87
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
Workqueue: cifsiod smb2_cached_lease_break
Call Trace:
<TASK>
dump_stack_lvl+0x77/0xb0
print_report+0xce/0x660
kasan_report+0xd3/0x110
smb2_cached_lease_break+0x27/0xb0
process_one_work+0x50a/0xc50
worker_thread+0x2ba/0x530
kthread+0x17c/0x1c0
ret_from_fork+0x34/0x60
ret_from_fork_asm+0x1a/0x30
</TASK>
Allocated by task 2464:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
__kasan_kmalloc+0xaa/0xb0
open_cached_dir+0xa7d/0x1fb0
smb2_query_path_info+0x43c/0x6e0
cifs_get_fattr+0x346/0xf10
cifs_get_inode_info+0x157/0x210
cifs_revalidate_dentry_attr+0x2d1/0x460
cifs_getattr+0x173/0x470
vfs_statx_path+0x10f/0x160
vfs_statx+0xe9/0x150
vfs_fstatat+0x5e/0xc0
__do_sys_newfstatat+0x91/0xf0
do_syscall_64+0x95/0x1a0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 2464:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x51/0x70
kfree+0x174/0x520
open_cached_dir+0x97f/0x1fb0
smb2_query_path_info+0x43c/0x6e0
cifs_get_fattr+0x346/0xf10
cifs_get_inode_info+0x157/0x210
cifs_revalidate_dentry_attr+0x2d1/0x460
cifs_getattr+0x173/0x470
vfs_statx_path+0x10f/0x160
vfs_statx+0xe9/0x150
vfs_fstatat+0x5e/0xc0
__do_sys_newfstatat+0x91/0xf0
do_syscall_64+0x95/0x1a0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Last potentially related work creation:
kasan_save_stack+0x33/0x60
__kasan_record_aux_stack+0xad/0xc0
insert_work+0x32/0x100
__queue_work+0x5c9/0x870
queue_work_on+0x82/0x90
open_cached_dir+0x1369/0x1fb0
smb2_query_path_info+0x43c/0x6e0
cifs_get_fattr+0x346/0xf10
cifs_get_inode_info+0x157/0x210
cifs_revalidate_dentry_attr+0x2d1/0x460
cifs_getattr+0x173/0x470
vfs_statx_path+0x10f/0x160
vfs_statx+0xe9/0x150
vfs_fstatat+0x5e/0xc0
__do_sys_newfstatat+0x91/0xf0
do_syscall_64+0x95/0x1a0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
The buggy address belongs to the object at ffff88811cc24c00
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 16 bytes inside of
freed 1024-byte region [ffff88811cc24c00, ffff88811cc25000) |
["https://git.kernel.org/stable/c/47655a12c6b1bca8fa230085eab2e85a076932b7","https://git.kernel.org/stable/c/791f833053578b9fd24252ebb7162a61bc3f805b","https://git.kernel.org/stable/c/97e2afcac0bebfef6a5360f4267ce4c44507b845","https://git.kernel.org/stable/c/a9685b409a03b73d2980bbfa53eb47555802d0a9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53216
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
nfsd: release svc_expkey/svc_export with rcu_work
The last reference for `cache_head` can be reduced to zero in `c_show`
and `e_show`(using `rcu_read_lock` and `rcu_read_unlock`). Consequently,
`svc_export_put` and `expkey_put` will be invoked, leading to two
issues:
1. The `svc_export_put` will directly free ex_uuid. However,
`e_show`/`c_show` will access `ex_uuid` after `cache_put`, which can
trigger a use-after-free issue, shown below.
==================================================================
BUG: KASAN: slab-use-after-free in svc_export_show+0x362/0x430 [nfsd]
Read of size 1 at addr ff11000010fdc120 by task cat/870
CPU: 1 UID: 0 PID: 870 Comm: cat Not tainted 6.12.0-rc3+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.1-2.fc37 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x53/0x70
print_address_description.constprop.0+0x2c/0x3a0
print_report+0xb9/0x280
kasan_report+0xae/0xe0
svc_export_show+0x362/0x430 [nfsd]
c_show+0x161/0x390 [sunrpc]
seq_read_iter+0x589/0x770
seq_read+0x1e5/0x270
proc_reg_read+0xe1/0x140
vfs_read+0x125/0x530
ksys_read+0xc1/0x160
do_syscall_64+0x5f/0x170
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Allocated by task 830:
kasan_save_stack+0x20/0x40
kasan_save_track+0x14/0x30
__kasan_kmalloc+0x8f/0xa0
__kmalloc_node_track_caller_noprof+0x1bc/0x400
kmemdup_noprof+0x22/0x50
svc_export_parse+0x8a9/0xb80 [nfsd]
cache_do_downcall+0x71/0xa0 [sunrpc]
cache_write_procfs+0x8e/0xd0 [sunrpc]
proc_reg_write+0xe1/0x140
vfs_write+0x1a5/0x6d0
ksys_write+0xc1/0x160
do_syscall_64+0x5f/0x170
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 868:
kasan_save_stack+0x20/0x40
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x37/0x50
kfree+0xf3/0x3e0
svc_export_put+0x87/0xb0 [nfsd]
cache_purge+0x17f/0x1f0 [sunrpc]
nfsd_destroy_serv+0x226/0x2d0 [nfsd]
nfsd_svc+0x125/0x1e0 [nfsd]
write_threads+0x16a/0x2a0 [nfsd]
nfsctl_transaction_write+0x74/0xa0 [nfsd]
vfs_write+0x1a5/0x6d0
ksys_write+0xc1/0x160
do_syscall_64+0x5f/0x170
entry_SYSCALL_64_after_hwframe+0x76/0x7e
2. We cannot sleep while using `rcu_read_lock`/`rcu_read_unlock`.
However, `svc_export_put`/`expkey_put` will call path_put, which
subsequently triggers a sleeping operation due to the following
`dput`.
=============================
WARNING: suspicious RCU usage
5.10.0-dirty #141 Not tainted
-----------------------------
...
Call Trace:
dump_stack+0x9a/0xd0
___might_sleep+0x231/0x240
dput+0x39/0x600
path_put+0x1b/0x30
svc_export_put+0x17/0x80
e_show+0x1c9/0x200
seq_read_iter+0x63f/0x7c0
seq_read+0x226/0x2d0
vfs_read+0x113/0x2c0
ksys_read+0xc9/0x170
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x67/0xd1
Fix these issues by using `rcu_work` to help release
`svc_expkey`/`svc_export`. This approach allows for an asynchronous
context to invoke `path_put` and also facilitates the freeing of
`uuid/exp/key` after an RCU grace period. |
["https://git.kernel.org/stable/c/2e4854599200f4d021df8ae17e69221d7c149f3e","https://git.kernel.org/stable/c/ad4363a24a5746b257c0beb5d8cc68f9b62c173f","https://git.kernel.org/stable/c/bd8524148dd8c123334b066faa90590ba2ef8e6f","https://git.kernel.org/stable/c/f8c989a0c89a75d30f899a7cabdc14d72522bb8d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53218
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix race in concurrent f2fs_stop_gc_thread
In my test case, concurrent calls to f2fs shutdown report the following
stack trace:
Oops: general protection fault, probably for non-canonical address 0xc6cfff63bb5513fc: 0000 [#1] PREEMPT SMP PTI
CPU: 0 UID: 0 PID: 678 Comm: f2fs_rep_shutdo Not tainted 6.12.0-rc5-next-20241029-g6fb2fa9805c5-dirty #85
Call Trace:
<TASK>
? show_regs+0x8b/0xa0
? __die_body+0x26/0xa0
? die_addr+0x54/0x90
? exc_general_protection+0x24b/0x5c0
? asm_exc_general_protection+0x26/0x30
? kthread_stop+0x46/0x390
f2fs_stop_gc_thread+0x6c/0x110
f2fs_do_shutdown+0x309/0x3a0
f2fs_ioc_shutdown+0x150/0x1c0
__f2fs_ioctl+0xffd/0x2ac0
f2fs_ioctl+0x76/0xe0
vfs_ioctl+0x23/0x60
__x64_sys_ioctl+0xce/0xf0
x64_sys_call+0x2b1b/0x4540
do_syscall_64+0xa7/0x240
entry_SYSCALL_64_after_hwframe+0x76/0x7e
The root cause is a race condition in f2fs_stop_gc_thread() called from
different f2fs shutdown paths:
[CPU0] [CPU1]
---------------------- -----------------------
f2fs_stop_gc_thread f2fs_stop_gc_thread
gc_th = sbi->gc_thread
gc_th = sbi->gc_thread
kfree(gc_th)
sbi->gc_thread = NULL
< gc_th != NULL >
kthread_stop(gc_th->f2fs_gc_task) //UAF
The commit c7f114d864ac ("f2fs: fix to avoid use-after-free in
f2fs_stop_gc_thread()") attempted to fix this issue by using a read
semaphore to prevent races between shutdown and remount threads, but
it fails to prevent all race conditions.
Fix it by converting to write lock of s_umount in f2fs_do_shutdown(). |
["https://git.kernel.org/stable/c/60457ed6c67625c87861f96912b4179dc2293896","https://git.kernel.org/stable/c/794fa8792d4eacac191f1cbcc2e81b7369e4662a","https://git.kernel.org/stable/c/7b0033dbc48340a1c1c3f12448ba17d6587ca092","https://git.kernel.org/stable/c/c631207897a9b3d41167ceca58e07f8f94720e42"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21927
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
nvme-tcp: fix potential memory corruption in nvme_tcp_recv_pdu()
nvme_tcp_recv_pdu() doesn't check the validity of the header length.
When header digests are enabled, a target might send a packet with an
invalid header length (e.g. 255), causing nvme_tcp_verify_hdgst()
to access memory outside the allocated area and cause memory corruptions
by overwriting it with the calculated digest.
Fix this by rejecting packets with an unexpected header length. |
["https://git.kernel.org/stable/c/22b06c89aa6b2d1ecb8aea72edfb9d53af8d5126","https://git.kernel.org/stable/c/9fbc953d6b38bc824392e01850f0aeee3b348722","https://git.kernel.org/stable/c/ad95bab0cd28ed77c2c0d0b6e76e03e031391064"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4623
|
High |
fixed |
- 4.14.327
- 4.19.295
- 5.4.257
- 5.10.195
- 5.15.132
- 6.1.53
- 6.4.16
- 6.5.3
|
A use-after-free vulnerability in the Linux kernel's net/sched: sch_hfsc (HFSC qdisc traffic control) component can be exploited to achieve local privilege escalation.
If a class with a link-sharing curve (i.e. with the HFSC_FSC flag set) has a parent without a link-sharing curve, then init_vf() will call vttree_insert() on the parent, but vttree_remove() will be skipped in update_vf(). This leaves a dangling pointer that can cause a use-after-free.
We recommend upgrading past commit b3d26c5702c7d6c45456326e56d2ccf3f103e60f. |
["http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b3d26c5702c7d6c45456326e56d2ccf3f103e60f","https://kernel.dance/b3d26c5702c7d6c45456326e56d2ccf3f103e60f","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b3d26c5702c7d6c45456326e56d2ccf3f103e60f","https://kernel.dance/b3d26c5702c7d6c45456326e56d2ccf3f103e60f","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4015
|
High |
fixed |
- 5.10.190
- 5.15.124
- 6.1.43
- 6.4.8
|
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.
On an error when building a nftables rule, deactivating immediate expressions in nft_immediate_deactivate() can lead unbinding the chain and objects be deactivated but later used.
We recommend upgrading past commit 0a771f7b266b02d262900c75f1e175c7fe76fec2. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0a771f7b266b02d262900c75f1e175c7fe76fec2","https://kernel.dance/0a771f7b266b02d262900c75f1e175c7fe76fec2","https://www.debian.org/security/2023/dsa-5492","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0a771f7b266b02d262900c75f1e175c7fe76fec2","https://kernel.dance/0a771f7b266b02d262900c75f1e175c7fe76fec2","https://www.debian.org/security/2023/dsa-5492"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-24958
|
High |
fixed |
|
drivers/usb/gadget/legacy/inode.c in the Linux kernel through 5.16.8 mishandles dev->buf release. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=89f3594d0de58e8a57d92d497dea9fee3d4b9cda","https://github.com/torvalds/linux/commit/501e38a5531efbd77d5c73c0ba838a889bfc1d74","https://github.com/torvalds/linux/commit/89f3594d0de58e8a57d92d497dea9fee3d4b9cda","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/SUVZA2YVOQJBJTDIDQ5HF5TAU2C6WP6H/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/TCW2KZYJ2H6BKZE3CVLHRIXYDGNYYC5P/","https://security.netapp.com/advisory/ntap-20220225-0008/","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=89f3594d0de58e8a57d92d497dea9fee3d4b9cda","https://github.com/torvalds/linux/commit/501e38a5531efbd77d5c73c0ba838a889bfc1d74","https://github.com/torvalds/linux/commit/89f3594d0de58e8a57d92d497dea9fee3d4b9cda","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/SUVZA2YVOQJBJTDIDQ5HF5TAU2C6WP6H/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/TCW2KZYJ2H6BKZE3CVLHRIXYDGNYYC5P/","https://security.netapp.com/advisory/ntap-20220225-0008/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46728
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check index for aux_rd_interval before using
aux_rd_interval has size of 7 and should be checked.
This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity. |
["https://git.kernel.org/stable/c/48e0b68e2360b16edf2a0bae05c0051c00fbb48a","https://git.kernel.org/stable/c/6c588e9350dd7a9fb97a56fe74852c9ecc44450c","https://git.kernel.org/stable/c/9ba2ea6337b4f159aecb177555a6a81da92d302e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46749
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btnxpuart: Fix Null pointer dereference in btnxpuart_flush()
This adds a check before freeing the rx->skb in flush and close
functions to handle the kernel crash seen while removing driver after FW
download fails or before FW download completes.
dmesg log:
[ 54.634586] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000080
[ 54.643398] Mem abort info:
[ 54.646204] ESR = 0x0000000096000004
[ 54.649964] EC = 0x25: DABT (current EL), IL = 32 bits
[ 54.655286] SET = 0, FnV = 0
[ 54.658348] EA = 0, S1PTW = 0
[ 54.661498] FSC = 0x04: level 0 translation fault
[ 54.666391] Data abort info:
[ 54.669273] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 54.674768] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 54.674771] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 54.674775] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000048860000
[ 54.674780] [0000000000000080] pgd=0000000000000000, p4d=0000000000000000
[ 54.703880] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
[ 54.710152] Modules linked in: btnxpuart(-) overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce polyval_generic snd_soc_imx_spdif snd_soc_imx_card snd_soc_ak5558 snd_soc_ak4458 caam secvio error snd_soc_fsl_micfil snd_soc_fsl_spdif snd_soc_fsl_sai snd_soc_fsl_utils imx_pcm_dma gpio_ir_recv rc_core sch_fq_codel fuse
[ 54.744357] CPU: 3 PID: 72 Comm: kworker/u9:0 Not tainted 6.6.3-otbr-g128004619037 #2
[ 54.744364] Hardware name: FSL i.MX8MM EVK board (DT)
[ 54.744368] Workqueue: hci0 hci_power_on
[ 54.757244] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 54.757249] pc : kfree_skb_reason+0x18/0xb0
[ 54.772299] lr : btnxpuart_flush+0x40/0x58 [btnxpuart]
[ 54.782921] sp : ffff8000805ebca0
[ 54.782923] x29: ffff8000805ebca0 x28: ffffa5c6cf1869c0 x27: ffffa5c6cf186000
[ 54.782931] x26: ffff377b84852400 x25: ffff377b848523c0 x24: ffff377b845e7230
[ 54.782938] x23: ffffa5c6ce8dbe08 x22: ffffa5c6ceb65410 x21: 00000000ffffff92
[ 54.782945] x20: ffffa5c6ce8dbe98 x19: ffffffffffffffac x18: ffffffffffffffff
[ 54.807651] x17: 0000000000000000 x16: ffffa5c6ce2824ec x15: ffff8001005eb857
[ 54.821917] x14: 0000000000000000 x13: ffffa5c6cf1a02e0 x12: 0000000000000642
[ 54.821924] x11: 0000000000000040 x10: ffffa5c6cf19d690 x9 : ffffa5c6cf19d688
[ 54.821931] x8 : ffff377b86000028 x7 : 0000000000000000 x6 : 0000000000000000
[ 54.821938] x5 : ffff377b86000000 x4 : 0000000000000000 x3 : 0000000000000000
[ 54.843331] x2 : 0000000000000000 x1 : 0000000000000002 x0 : ffffffffffffffac
[ 54.857599] Call trace:
[ 54.857601] kfree_skb_reason+0x18/0xb0
[ 54.863878] btnxpuart_flush+0x40/0x58 [btnxpuart]
[ 54.863888] hci_dev_open_sync+0x3a8/0xa04
[ 54.872773] hci_power_on+0x54/0x2e4
[ 54.881832] process_one_work+0x138/0x260
[ 54.881842] worker_thread+0x32c/0x438
[ 54.881847] kthread+0x118/0x11c
[ 54.881853] ret_from_fork+0x10/0x20
[ 54.896406] Code: a9be7bfd 910003fd f9000bf3 aa0003f3 (b940d400)
[ 54.896410] ---[ end trace 0000000000000000 ]--- |
["https://git.kernel.org/stable/c/013dae4735d2010544d1f2121bdeb8e6c9ea171e","https://git.kernel.org/stable/c/056e0cd381d59a9124b7c43dd715e15f56a11635","https://git.kernel.org/stable/c/c68bbf5e334b35b36ac5b9f0419f1f93f796bad1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46760
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw88: usb: schedule rx work after everything is set up
Right now it's possible to hit NULL pointer dereference in
rtw_rx_fill_rx_status on hw object and/or its fields because
initialization routine can start getting USB replies before
rtw_dev is fully setup.
The stack trace looks like this:
rtw_rx_fill_rx_status
rtw8821c_query_rx_desc
rtw_usb_rx_handler
...
queue_work
rtw_usb_read_port_complete
...
usb_submit_urb
rtw_usb_rx_resubmit
rtw_usb_init_rx
rtw_usb_probe
So while we do the async stuff rtw_usb_probe continues and calls
rtw_register_hw, which does all kinds of initialization (e.g.
via ieee80211_register_hw) that rtw_rx_fill_rx_status relies on.
Fix this by moving the first usb_submit_urb after everything
is set up.
For me, this bug manifested as:
[ 8.893177] rtw_8821cu 1-1:1.2: band wrong, packet dropped
[ 8.910904] rtw_8821cu 1-1:1.2: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status
because I'm using Larry's backport of rtw88 driver with the NULL
checks in rtw_rx_fill_rx_status. |
["https://git.kernel.org/stable/c/25eaef533bf3ccc6fee5067aac16f41f280e343e","https://git.kernel.org/stable/c/adc539784c98a7cc602cbf557debfc2e7b9be8b3","https://git.kernel.org/stable/c/c83d464b82a8ad62ec9077637f75d73fe955635a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46762
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
xen: privcmd: Fix possible access to a freed kirqfd instance
Nothing prevents simultaneous ioctl calls to privcmd_irqfd_assign() and
privcmd_irqfd_deassign(). If that happens, it is possible that a kirqfd
created and added to the irqfds_list by privcmd_irqfd_assign() may get
removed by another thread executing privcmd_irqfd_deassign(), while the
former is still using it after dropping the locks.
This can lead to a situation where an already freed kirqfd instance may
be accessed and cause kernel oops.
Use SRCU locking to prevent the same, as is done for the KVM
implementation for irqfds. |
["https://git.kernel.org/stable/c/112fd2f02b308564724b8e81006c254d20945c4b","https://git.kernel.org/stable/c/611ff1b1ae989a7bcce3e2a8e132ee30e968c557","https://git.kernel.org/stable/c/e997b357b13a7d95de31681fc54fcc34235fa527"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46776
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Run DC_LOG_DC after checking link->link_enc
[WHAT]
The DC_LOG_DC should be run after link->link_enc is checked, not before.
This fixes 1 REVERSE_INULL issue reported by Coverity. |
["https://git.kernel.org/stable/c/3a82f62b0d9d7687eac47603bb6cd14a50fa718b","https://git.kernel.org/stable/c/874e3bb302f97b94ac548959ec4f925b8e7b45e2","https://git.kernel.org/stable/c/adc74d25cdbba978afbb57caec23bbcd0329f7b8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46806
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix the warning division or modulo by zero
Checks the partition mode and returns an error for an invalid mode. |
["https://git.kernel.org/stable/c/1a00f2ac82d6bc6689388c7edcd2a4bd82664f3c","https://git.kernel.org/stable/c/a01618adcba78c6bd6c4557a4a5e32f58b658cd1","https://git.kernel.org/stable/c/d116bb921e8b104f45d1f30a473ea99ef4262b9a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46843
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Remove SCSI host only if added
If host tries to remove ufshcd driver from a UFS device it would cause a
kernel panic if ufshcd_async_scan fails during ufshcd_probe_hba before
adding a SCSI host with scsi_add_host and MCQ is enabled since SCSI host
has been defered after MCQ configuration introduced by commit 0cab4023ec7b
("scsi: ufs: core: Defer adding host to SCSI if MCQ is supported").
To guarantee that SCSI host is removed only if it has been added, set the
scsi_host_added flag to true after adding a SCSI host and check whether it
is set or not before removing it. |
["https://git.kernel.org/stable/c/2f49e05d6b58d660f035a75ff96b77071b4bd5ed","https://git.kernel.org/stable/c/3844586e9bd9845140e1078f1e61896b576ac536","https://git.kernel.org/stable/c/7cbff570dbe8907e23bba06f6414899a0fbb2fcc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46860
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7921: fix NULL pointer access in mt7921_ipv6_addr_change
When disabling wifi mt7921_ipv6_addr_change() is called as a notifier.
At this point mvif->phy is already NULL so we cannot use it here. |
["https://git.kernel.org/stable/c/479ffee68d59c599f8aed8fa2dcc8e13e7bd13c3","https://git.kernel.org/stable/c/4bfee9346d8c17d928ef6da2b8bffab88fa2a553","https://git.kernel.org/stable/c/8d92bafd4c67efb692f722d73a07412b5f88c6d6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46861
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
usbnet: ipheth: do not stop RX on failing RX callback
RX callbacks can fail for multiple reasons:
* Payload too short
* Payload formatted incorrecly (e.g. bad NCM framing)
* Lack of memory
None of these should cause the driver to seize up.
Make such failures non-critical and continue processing further
incoming URBs. |
["https://git.kernel.org/stable/c/08ca800b0cd56d5e26722f68b18bbbf6840bf44b","https://git.kernel.org/stable/c/4d1cfa3afb8627435744ecdc6d8b58bc72ee0f4c","https://git.kernel.org/stable/c/74efed51e0a4d62f998f806c307778b47fc73395"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53094
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES
While running ISER over SIW, the initiator machine encounters a warning
from skb_splice_from_iter() indicating that a slab page is being used in
send_page. To address this, it is better to add a sendpage_ok() check
within the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag
should be disabled before entering the network stack.
A similar issue has been discussed for NVMe in this thread:
https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/
WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320
Call Trace:
tcp_sendmsg_locked+0x368/0xe40
siw_tx_hdt+0x695/0xa40 [siw]
siw_qp_sq_process+0x102/0xb00 [siw]
siw_sq_resume+0x39/0x110 [siw]
siw_run_sq+0x74/0x160 [siw]
kthread+0xd2/0x100
ret_from_fork+0x34/0x40
ret_from_fork_asm+0x1a/0x30 |
["https://git.kernel.org/stable/c/3406bfc813a9bbd9c3055795e985f527b7852e8c","https://git.kernel.org/stable/c/4e1e3dd88a4cedd5ccc1a3fc3d71e03b70a7a791","https://git.kernel.org/stable/c/bb5738957d92c8603a90c9664d34236641c221b2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52485
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Wake DMCUB before sending a command
[Why]
We can hang in place trying to send commands when the DMCUB isn't
powered on.
[How]
For functions that execute within a DC context or DC lock we can
wrap the direct calls to dm_execute_dmub_cmd/list with code that
exits idle power optimizations and reallows once we're done with
the command submission on success.
For DM direct submissions the DM will need to manage the enter/exit
sequencing manually.
We cannot invoke a DMCUB command directly within the DM execution
helper or we can deadlock. |
["https://git.kernel.org/stable/c/303197775a97416b62d4da69280d0c120a20e009","https://git.kernel.org/stable/c/8892780834ae294bc3697c7d0e056d7743900b39","https://git.kernel.org/stable/c/303197775a97416b62d4da69280d0c120a20e009","https://git.kernel.org/stable/c/8892780834ae294bc3697c7d0e056d7743900b39"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21634
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
cgroup/cpuset: remove kernfs active break
A warning was found:
WARNING: CPU: 10 PID: 3486953 at fs/kernfs/file.c:828
CPU: 10 PID: 3486953 Comm: rmdir Kdump: loaded Tainted: G
RIP: 0010:kernfs_should_drain_open_files+0x1a1/0x1b0
RSP: 0018:ffff8881107ef9e0 EFLAGS: 00010202
RAX: 0000000080000002 RBX: ffff888154738c00 RCX: dffffc0000000000
RDX: 0000000000000007 RSI: 0000000000000004 RDI: ffff888154738c04
RBP: ffff888154738c04 R08: ffffffffaf27fa15 R09: ffffed102a8e7180
R10: ffff888154738c07 R11: 0000000000000000 R12: ffff888154738c08
R13: ffff888750f8c000 R14: ffff888750f8c0e8 R15: ffff888154738ca0
FS: 00007f84cd0be740(0000) GS:ffff8887ddc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000555f9fbe00c8 CR3: 0000000153eec001 CR4: 0000000000370ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
kernfs_drain+0x15e/0x2f0
__kernfs_remove+0x165/0x300
kernfs_remove_by_name_ns+0x7b/0xc0
cgroup_rm_file+0x154/0x1c0
cgroup_addrm_files+0x1c2/0x1f0
css_clear_dir+0x77/0x110
kill_css+0x4c/0x1b0
cgroup_destroy_locked+0x194/0x380
cgroup_rmdir+0x2a/0x140
It can be explained by:
rmdir echo 1 > cpuset.cpus
kernfs_fop_write_iter // active=0
cgroup_rm_file
kernfs_remove_by_name_ns kernfs_get_active // active=1
__kernfs_remove // active=0x80000002
kernfs_drain cpuset_write_resmask
wait_event
//waiting (active == 0x80000001)
kernfs_break_active_protection
// active = 0x80000001
// continue
kernfs_unbreak_active_protection
// active = 0x80000002
...
kernfs_should_drain_open_files
// warning occurs
kernfs_put_active
This warning is caused by 'kernfs_break_active_protection' when it is
writing to cpuset.cpus, and the cgroup is removed concurrently.
The commit 3a5a6d0c2b03 ("cpuset: don't nest cgroup_mutex inside
get_online_cpus()") made cpuset_hotplug_workfn asynchronous, This change
involves calling flush_work(), which can create a multiple processes
circular locking dependency that involve cgroup_mutex, potentially leading
to a deadlock. To avoid deadlock. the commit 76bb5ab8f6e3 ("cpuset: break
kernfs active protection in cpuset_write_resmask()") added
'kernfs_break_active_protection' in the cpuset_write_resmask. This could
lead to this warning.
After the commit 2125c0034c5d ("cgroup/cpuset: Make cpuset hotplug
processing synchronous"), the cpuset_write_resmask no longer needs to
wait the hotplug to finish, which means that concurrent hotplug and cpuset
operations are no longer possible. Therefore, the deadlock doesn't exist
anymore and it does not have to 'break active protection' now. To fix this
warning, just remove kernfs_break_active_protection operation in the
'cpuset_write_resmask'. |
["https://git.kernel.org/stable/c/11cb1d643a74665a4e14749414f48f82cbc15c64","https://git.kernel.org/stable/c/3cb97a927fffe443e1e7e8eddbfebfdb062e86ed"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47678
|
Medium |
fixed |
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
icmp: change the order of rate limits
ICMP messages are ratelimited :
After the blamed commits, the two rate limiters are applied in this order:
1) host wide ratelimit (icmp_global_allow())
2) Per destination ratelimit (inetpeer based)
In order to avoid side-channels attacks, we need to apply
the per destination check first.
This patch makes the following change :
1) icmp_global_allow() checks if the host wide limit is reached.
But credits are not yet consumed. This is deferred to 3)
2) The per destination limit is checked/updated.
This might add a new node in inetpeer tree.
3) icmp_global_consume() consumes tokens if prior operations succeeded.
This means that host wide ratelimit is still effective
in keeping inetpeer tree small even under DDOS.
As a bonus, I removed icmp_global.lock as the fast path
can use a lock-free operation. |
["https://git.kernel.org/stable/c/483397b4ba280813e4a9c161a0a85172ddb43d19","https://git.kernel.org/stable/c/662ec52260cc07b9ae53ecd3925183c29d34288b","https://git.kernel.org/stable/c/8c2bd38b95f75f3d2a08c93e35303e26d480d24e","https://git.kernel.org/stable/c/997ba8889611891f91e8ad83583466aeab6239a3","https://git.kernel.org/stable/c/a7722921adb046e3836eb84372241f32584bdb07"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4134
|
Medium |
fixed |
|
A use-after-free vulnerability was found in the cyttsp4_core driver in the Linux kernel. This issue occurs in the device cleanup routine due to a possible rearming of the watchdog_timer from the workqueue. This could allow a local user to crash the system, causing a denial of service. |
["https://access.redhat.com/security/cve/CVE-2023-4134","https://bugzilla.redhat.com/show_bug.cgi?id=2221700"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47658
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
crypto: stm32/cryp - call finalize with bh disabled
The finalize operation in interrupt mode produce a produces a spinlock
recursion warning. The reason is the fact that BH must be disabled
during this process. |
["https://git.kernel.org/stable/c/56ddb9aa3b324c2d9645b5a7343e46010cf3f6ce","https://git.kernel.org/stable/c/5d734665cd5d93270731e0ff1dd673fec677f447","https://git.kernel.org/stable/c/d93a2f86b0a998aa1f0870c85a2a60a0771ef89a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47664
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware
If the value of max_speed_hz is 0, it may cause a division by zero
error in hisi_calc_effective_speed().
The value of max_speed_hz is provided by firmware.
Firmware is generally considered as a trusted domain. However, as
division by zero errors can cause system failure, for defense measure,
the value of max_speed is validated here. So 0 is regarded as invalid
and an error code is returned. |
["https://git.kernel.org/stable/c/16ccaf581da4fcf1e4d66086cf37263f9a656d43","https://git.kernel.org/stable/c/5127c42c77de18651aa9e8e0a3ced190103b449c","https://git.kernel.org/stable/c/ee73a15d4a8ce8fb02d7866f7cf78fcdd16f0fcc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47666
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: pm80xx: Set phy->enable_completion only when we wait for it
pm8001_phy_control() populates the enable_completion pointer with a stack
address, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, and
returns. The problem arises when a phy control response comes late. After
300 ms the pm8001_phy_control() function returns and the passed
enable_completion stack address is no longer valid. Late phy control
response invokes complete() on a dangling enable_completion pointer which
leads to a kernel crash. |
["https://git.kernel.org/stable/c/7b1d779647afaea9185fa2f150b1721e7c1aae89","https://git.kernel.org/stable/c/e4f949ef1516c0d74745ee54a0f4882c1f6c7aea","https://git.kernel.org/stable/c/f14d3e1aa613311c744af32d75125e95fc8ffb84"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49888
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix a sdiv overflow issue
Zac Ecob reported a problem where a bpf program may cause kernel crash due
to the following error:
Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI
The failure is due to the below signed divide:
LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808.
LLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808,
but it is impossible since for 64-bit system, the maximum positive
number is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will
cause a kernel exception. On arm64, the result for LLONG_MIN/-1 is
LLONG_MIN.
Further investigation found all the following sdiv/smod cases may trigger
an exception when bpf program is running on x86_64 platform:
- LLONG_MIN/-1 for 64bit operation
- INT_MIN/-1 for 32bit operation
- LLONG_MIN%-1 for 64bit operation
- INT_MIN%-1 for 32bit operation
where -1 can be an immediate or in a register.
On arm64, there are no exceptions:
- LLONG_MIN/-1 = LLONG_MIN
- INT_MIN/-1 = INT_MIN
- LLONG_MIN%-1 = 0
- INT_MIN%-1 = 0
where -1 can be an immediate or in a register.
Insn patching is needed to handle the above cases and the patched codes
produced results aligned with above arm64 result. The below are pseudo
codes to handle sdiv/smod exceptions including both divisor -1 and divisor 0
and the divisor is stored in a register.
sdiv:
tmp = rX
tmp += 1 /* [-1, 0] -> [0, 1]
if tmp >(unsigned) 1 goto L2
if tmp == 0 goto L1
rY = 0
L1:
rY = -rY;
goto L3
L2:
rY /= rX
L3:
smod:
tmp = rX
tmp += 1 /* [-1, 0] -> [0, 1]
if tmp >(unsigned) 1 goto L1
if tmp == 1 (is64 ? goto L2 : goto L3)
rY = 0;
goto L2
L1:
rY %= rX
L2:
goto L4 // only when !is64
L3:
wY = wY // only when !is64
L4:
[1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/ |
["https://git.kernel.org/stable/c/4902a6a0dc593c82055fc8c9ada371bafe26c9cc","https://git.kernel.org/stable/c/7dd34d7b7dcf9309fc6224caf4dd5b35bedddcb7","https://git.kernel.org/stable/c/d22e45a369afc7c28f11acfa5b5e8e478227ca5d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49904
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: add list empty check to avoid null pointer issue
Add list empty check to avoid null pointer issues in some corner cases.
- list_for_each_entry_safe() |
["https://git.kernel.org/stable/c/4416377ae1fdc41a90b665943152ccd7ff61d3c5","https://git.kernel.org/stable/c/5ec731ef47f1dba34daad3e51a93de793f9319ac","https://git.kernel.org/stable/c/8e87763946f708063d7e5303339598abbb8c5aac"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49918
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer
This commit addresses a potential null pointer dereference issue in the
`dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue
could occur when `head_pipe` is null.
The fix adds a check to ensure `head_pipe` is not null before asserting
it. If `head_pipe` is null, the function returns NULL to prevent a
potential null pointer dereference.
Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed 'head_pipe' could be null (see line 2681) |
["https://git.kernel.org/stable/c/4f47292f488fa7041284dca1f1244116c18721f1","https://git.kernel.org/stable/c/96d4c2ee18d732a248d053aae8c4a27cb1d68d1c","https://git.kernel.org/stable/c/ac2140449184a26eac99585b7f69814bd3ba8f2d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49922
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check null pointers before using them
[WHAT & HOW]
These pointers are null checked previously in the same function,
indicating they might be null as reported by Coverity. As a result,
they need to be checked when used again.
This fixes 3 FORWARD_NULL issue reported by Coverity. |
["https://git.kernel.org/stable/c/1ff12bcd7deaeed25efb5120433c6a45dd5504a8","https://git.kernel.org/stable/c/5e9386baa3033c369564d55de4bab62423e8a1d3","https://git.kernel.org/stable/c/65e1d2c291553ef3f433a0b7109cc3002a5f40ae"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49990
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/hdcp: Check GSC structure validity
Sometimes xe_gsc is not initialized when checked at HDCP capability
check. Add gsc structure check to avoid null pointer error. |
["https://git.kernel.org/stable/c/7266a424b1e502745170322e3c27f697d12de627","https://git.kernel.org/stable/c/b4224f6bae3801d589f815672ec62800a1501b0d","https://git.kernel.org/stable/c/c940627857eedca8407b84b40ceb4252b100d291"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50004
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: update DML2 policy EnhancedPrefetchScheduleAccelerationFinal DCN35
[WHY & HOW]
Mismatch in DCN35 DML2 cause bw validation failed to acquire unexpected DPP pipe to cause
grey screen and system hang. Remove EnhancedPrefetchScheduleAccelerationFinal value override
to match HW spec.
(cherry picked from commit 9dad21f910fcea2bdcff4af46159101d7f9cd8ba) |
["https://git.kernel.org/stable/c/0d5e5e8a0aa49ea2163abf128da3b509a6c58286","https://git.kernel.org/stable/c/4010efc8516899981cc3b57be2d4a2d5d9e50228","https://git.kernel.org/stable/c/945dc25eda88b5d6e30c9686dc619ab981c22d0e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-22066
|
Medium |
fixed |
- 5.15.180
- 6.1.134
- 6.6.87
- 6.12.23
- 6.13.11
- 6.14.2
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: imx-card: Add NULL check in imx_card_probe()
devm_kasprintf() returns NULL when memory allocation fails. Currently,
imx_card_probe() does not check for this case, which results in a NULL
pointer dereference.
Add NULL check after devm_kasprintf() to prevent this issue. |
["https://git.kernel.org/stable/c/018e6cf2503e60087747b0ebc190e18b3640766f","https://git.kernel.org/stable/c/38253922a89a742e7e622f626b41c64388367361","https://git.kernel.org/stable/c/4d8458e48ff135bddc402ad79821dc058ea163d0","https://git.kernel.org/stable/c/93d34608fd162f725172e780b1c60cc93a920719","https://git.kernel.org/stable/c/b01700e08be99e3842570142ec5973ccd7e73eaf","https://git.kernel.org/stable/c/dd2bbb9564d0d24a2643ad90008a79840368c4b4","https://git.kernel.org/stable/c/e283a5bf4337a7300ac5e6ae363cc8b242a0b4b7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46678
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bonding: change ipsec_lock from spin lock to mutex
In the cited commit, bond->ipsec_lock is added to protect ipsec_list,
hence xdo_dev_state_add and xdo_dev_state_delete are called inside
this lock. As ipsec_lock is a spin lock and such xfrmdev ops may sleep,
"scheduling while atomic" will be triggered when changing bond's
active slave.
[ 101.055189] BUG: scheduling while atomic: bash/902/0x00000200
[ 101.055726] Modules linked in:
[ 101.058211] CPU: 3 PID: 902 Comm: bash Not tainted 6.9.0-rc4+ #1
[ 101.058760] Hardware name:
[ 101.059434] Call Trace:
[ 101.059436] <TASK>
[ 101.060873] dump_stack_lvl+0x51/0x60
[ 101.061275] __schedule_bug+0x4e/0x60
[ 101.061682] __schedule+0x612/0x7c0
[ 101.062078] ? __mod_timer+0x25c/0x370
[ 101.062486] schedule+0x25/0xd0
[ 101.062845] schedule_timeout+0x77/0xf0
[ 101.063265] ? asm_common_interrupt+0x22/0x40
[ 101.063724] ? __bpf_trace_itimer_state+0x10/0x10
[ 101.064215] __wait_for_common+0x87/0x190
[ 101.064648] ? usleep_range_state+0x90/0x90
[ 101.065091] cmd_exec+0x437/0xb20 [mlx5_core]
[ 101.065569] mlx5_cmd_do+0x1e/0x40 [mlx5_core]
[ 101.066051] mlx5_cmd_exec+0x18/0x30 [mlx5_core]
[ 101.066552] mlx5_crypto_create_dek_key+0xea/0x120 [mlx5_core]
[ 101.067163] ? bonding_sysfs_store_option+0x4d/0x80 [bonding]
[ 101.067738] ? kmalloc_trace+0x4d/0x350
[ 101.068156] mlx5_ipsec_create_sa_ctx+0x33/0x100 [mlx5_core]
[ 101.068747] mlx5e_xfrm_add_state+0x47b/0xaa0 [mlx5_core]
[ 101.069312] bond_change_active_slave+0x392/0x900 [bonding]
[ 101.069868] bond_option_active_slave_set+0x1c2/0x240 [bonding]
[ 101.070454] __bond_opt_set+0xa6/0x430 [bonding]
[ 101.070935] __bond_opt_set_notify+0x2f/0x90 [bonding]
[ 101.071453] bond_opt_tryset_rtnl+0x72/0xb0 [bonding]
[ 101.071965] bonding_sysfs_store_option+0x4d/0x80 [bonding]
[ 101.072567] kernfs_fop_write_iter+0x10c/0x1a0
[ 101.073033] vfs_write+0x2d8/0x400
[ 101.073416] ? alloc_fd+0x48/0x180
[ 101.073798] ksys_write+0x5f/0xe0
[ 101.074175] do_syscall_64+0x52/0x110
[ 101.074576] entry_SYSCALL_64_after_hwframe+0x4b/0x53
As bond_ipsec_add_sa_all and bond_ipsec_del_sa_all are only called
from bond_change_active_slave, which requires holding the RTNL lock.
And bond_ipsec_add_sa and bond_ipsec_del_sa are xfrm state
xdo_dev_state_add and xdo_dev_state_delete APIs, which are in user
context. So ipsec_lock doesn't have to be spin lock, change it to
mutex, and thus the above issue can be resolved. |
["https://git.kernel.org/stable/c/2aeeef906d5a526dc60cf4af92eda69836c39b1f","https://git.kernel.org/stable/c/56354b0a2c24a7828eeed7de4b4dc9652d9affa3","https://git.kernel.org/stable/c/6b598069164ac1bb60996d6ff94e7f9169dbd2d3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-2873
|
Medium |
fixed |
|
An out-of-bounds memory access flaw was found in the Linux kernel Intel’s iSMT SMBus host controller driver in the way a user triggers the I2C_SMBUS_BLOCK_DATA (with the ioctl I2C_SMBUS) with malicious input data. This flaw allows a local user to crash the system. |
["https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/lkml/20220729093451.551672-1-zheyuma97%40gmail.com/T/","https://security.netapp.com/advisory/ntap-20230120-0001/","https://www.debian.org/security/2023/dsa-5324","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/lkml/20220729093451.551672-1-zheyuma97%40gmail.com/T/","https://security.netapp.com/advisory/ntap-20230120-0001/","https://www.debian.org/security/2023/dsa-5324"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26841
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Update cpu_sibling_map when disabling nonboot CPUs
Update cpu_sibling_map when disabling nonboot CPUs by defining & calling
clear_cpu_sibling_map(), otherwise we get such errors on SMT systems:
jump label: negative count!
WARNING: CPU: 6 PID: 45 at kernel/jump_label.c:263 __static_key_slow_dec_cpuslocked+0xec/0x100
CPU: 6 PID: 45 Comm: cpuhp/6 Not tainted 6.8.0-rc5+ #1340
pc 90000000004c302c ra 90000000004c302c tp 90000001005bc000 sp 90000001005bfd20
a0 000000000000001b a1 900000000224c278 a2 90000001005bfb58 a3 900000000224c280
a4 900000000224c278 a5 90000001005bfb50 a6 0000000000000001 a7 0000000000000001
t0 ce87a4763eb5234a t1 ce87a4763eb5234a t2 0000000000000000 t3 0000000000000000
t4 0000000000000006 t5 0000000000000000 t6 0000000000000064 t7 0000000000001964
t8 000000000009ebf6 u0 9000000001f2a068 s9 0000000000000000 s0 900000000246a2d8
s1 ffffffffffffffff s2 ffffffffffffffff s3 90000000021518c0 s4 0000000000000040
s5 9000000002151058 s6 9000000009828e40 s7 00000000000000b4 s8 0000000000000006
ra: 90000000004c302c __static_key_slow_dec_cpuslocked+0xec/0x100
ERA: 90000000004c302c __static_key_slow_dec_cpuslocked+0xec/0x100
CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
PRMD: 00000004 (PPLV0 +PIE -PWE)
EUEN: 00000000 (-FPE -SXE -ASXE -BTE)
ECFG: 00071c1c (LIE=2-4,10-12 VS=7)
ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0)
PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV)
CPU: 6 PID: 45 Comm: cpuhp/6 Not tainted 6.8.0-rc5+ #1340
Stack : 0000000000000000 900000000203f258 900000000179afc8 90000001005bc000
90000001005bf980 0000000000000000 90000001005bf988 9000000001fe0be0
900000000224c280 900000000224c278 90000001005bf8c0 0000000000000001
0000000000000001 ce87a4763eb5234a 0000000007f38000 90000001003f8cc0
0000000000000000 0000000000000006 0000000000000000 4c206e6f73676e6f
6f4c203a656d616e 000000000009ec99 0000000007f38000 0000000000000000
900000000214b000 9000000001fe0be0 0000000000000004 0000000000000000
0000000000000107 0000000000000009 ffffffffffafdabe 00000000000000b4
0000000000000006 90000000004c302c 9000000000224528 00005555939a0c7c
00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c
...
Call Trace:
[<9000000000224528>] show_stack+0x48/0x1a0
[<900000000179afc8>] dump_stack_lvl+0x78/0xa0
[<9000000000263ed0>] __warn+0x90/0x1a0
[<90000000017419b8>] report_bug+0x1b8/0x280
[<900000000179c564>] do_bp+0x264/0x420
[<90000000004c302c>] __static_key_slow_dec_cpuslocked+0xec/0x100
[<90000000002b4d7c>] sched_cpu_deactivate+0x2fc/0x300
[<9000000000266498>] cpuhp_invoke_callback+0x178/0x8a0
[<9000000000267f70>] cpuhp_thread_fun+0xf0/0x240
[<90000000002a117c>] smpboot_thread_fn+0x1dc/0x2e0
[<900000000029a720>] kthread+0x140/0x160
[<9000000000222288>] ret_from_kernel_thread+0xc/0xa4 |
["https://git.kernel.org/stable/c/0d862db64d26c2905ba1a6a8561466b215b664c2","https://git.kernel.org/stable/c/752cd08da320a667a833803a8fd6bb266114cce5","https://git.kernel.org/stable/c/b1ec3d6b86fdd057559a5908e6668279bf770e0e","https://git.kernel.org/stable/c/0d862db64d26c2905ba1a6a8561466b215b664c2","https://git.kernel.org/stable/c/752cd08da320a667a833803a8fd6bb266114cce5","https://git.kernel.org/stable/c/b1ec3d6b86fdd057559a5908e6668279bf770e0e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56757
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btusb: mediatek: add intf release flow when usb disconnect
MediaTek claim an special usb intr interface for ISO data transmission.
The interface need to be released before unregistering hci device when
usb disconnect. Removing BT usb dongle without properly releasing the
interface may cause Kernel panic while unregister hci device. |
["https://git.kernel.org/stable/c/489304e67087abddc2666c5af0159cb95afdcf59","https://git.kernel.org/stable/c/cc569d791ab2a0de74f76e470515d25d24c9b84b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57872
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: pltfrm: Dellocate HBA during ufshcd_pltfrm_remove()
This will ensure that the scsi host is cleaned up properly using
scsi_host_dev_release(). Otherwise, it may lead to memory leaks. |
["https://git.kernel.org/stable/c/897df60c16d54ad515a3d0887edab5c63da06d1f","https://git.kernel.org/stable/c/cd188519d2467ab4c2141587b0551ba030abff0e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21649
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix kernel crash when 1588 is sent on HIP08 devices
Currently, HIP08 devices does not register the ptp devices, so the
hdev->ptp is NULL. But the tx process would still try to set hardware time
stamp info with SKBTX_HW_TSTAMP flag and cause a kernel crash.
[ 128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018
...
[ 128.280251] pc : hclge_ptp_set_tx_info+0x2c/0x140 [hclge]
[ 128.286600] lr : hclge_ptp_set_tx_info+0x20/0x140 [hclge]
[ 128.292938] sp : ffff800059b93140
[ 128.297200] x29: ffff800059b93140 x28: 0000000000003280
[ 128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080
[ 128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001
[ 128.315969] x23: 0000000000000000 x22: 0000000000000194
[ 128.322219] x21: ffff0cd94f986000 x20: 0000000000000000
[ 128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000
[ 128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24
[ 128.340934] x15: 0000ffffd530a518 x14: 0000000000000000
[ 128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368
[ 128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02
[ 128.359606] x9 : ffffcf1f85a212b4 x8 : ffff0cd7cf27dab0
[ 128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000
[ 128.372040] x5 : 0000000000000000 x4 : 000000000000ffff
[ 128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294
[ 128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080
[ 128.390626] Call trace:
[ 128.393964] hclge_ptp_set_tx_info+0x2c/0x140 [hclge]
[ 128.399893] hns3_nic_net_xmit+0x39c/0x4c4 [hns3]
[ 128.405468] xmit_one.constprop.0+0xc4/0x200
[ 128.410600] dev_hard_start_xmit+0x54/0xf0
[ 128.415556] sch_direct_xmit+0xe8/0x634
[ 128.420246] __dev_queue_xmit+0x224/0xc70
[ 128.425101] dev_queue_xmit+0x1c/0x40
[ 128.429608] ovs_vport_send+0xac/0x1a0 [openvswitch]
[ 128.435409] do_output+0x60/0x17c [openvswitch]
[ 128.440770] do_execute_actions+0x898/0x8c4 [openvswitch]
[ 128.446993] ovs_execute_actions+0x64/0xf0 [openvswitch]
[ 128.453129] ovs_dp_process_packet+0xa0/0x224 [openvswitch]
[ 128.459530] ovs_vport_receive+0x7c/0xfc [openvswitch]
[ 128.465497] internal_dev_xmit+0x34/0xb0 [openvswitch]
[ 128.471460] xmit_one.constprop.0+0xc4/0x200
[ 128.476561] dev_hard_start_xmit+0x54/0xf0
[ 128.481489] __dev_queue_xmit+0x968/0xc70
[ 128.486330] dev_queue_xmit+0x1c/0x40
[ 128.490856] ip_finish_output2+0x250/0x570
[ 128.495810] __ip_finish_output+0x170/0x1e0
[ 128.500832] ip_finish_output+0x3c/0xf0
[ 128.505504] ip_output+0xbc/0x160
[ 128.509654] ip_send_skb+0x58/0xd4
[ 128.513892] udp_send_skb+0x12c/0x354
[ 128.518387] udp_sendmsg+0x7a8/0x9c0
[ 128.522793] inet_sendmsg+0x4c/0x8c
[ 128.527116] __sock_sendmsg+0x48/0x80
[ 128.531609] __sys_sendto+0x124/0x164
[ 128.536099] __arm64_sys_sendto+0x30/0x5c
[ 128.540935] invoke_syscall+0x50/0x130
[ 128.545508] el0_svc_common.constprop.0+0x10c/0x124
[ 128.551205] do_el0_svc+0x34/0xdc
[ 128.555347] el0_svc+0x20/0x30
[ 128.559227] el0_sync_handler+0xb8/0xc0
[ 128.563883] el0_sync+0x160/0x180 |
["https://git.kernel.org/stable/c/9741e72b2286de8b38de9db685588ac421a95c87","https://git.kernel.org/stable/c/f19ab3ef96d9626e5f1bdc56d3574c355e83d623"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21682
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
eth: bnxt: always recalculate features after XDP clearing, fix null-deref
Recalculate features when XDP is detached.
Before:
# ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp
# ip li set dev eth0 xdp off
# ethtool -k eth0 | grep gro
rx-gro-hw: off [requested on]
After:
# ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp
# ip li set dev eth0 xdp off
# ethtool -k eth0 | grep gro
rx-gro-hw: on
The fact that HW-GRO doesn't get re-enabled automatically is just
a minor annoyance. The real issue is that the features will randomly
come back during another reconfiguration which just happens to invoke
netdev_update_features(). The driver doesn't handle reconfiguring
two things at a time very robustly.
Starting with commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in
__bnxt_reserve_rings()") we only reconfigure the RSS hash table
if the "effective" number of Rx rings has changed. If HW-GRO is
enabled "effective" number of rings is 2x what user sees.
So if we are in the bad state, with HW-GRO re-enablement "pending"
after XDP off, and we lower the rings by / 2 - the HW-GRO rings
doing 2x and the ethtool -L doing / 2 may cancel each other out,
and the:
if (old_rx_rings != bp->hw_resc.resv_rx_rings &&
condition in __bnxt_reserve_rings() will be false.
The RSS map won't get updated, and we'll crash with:
BUG: kernel NULL pointer dereference, address: 0000000000000168
RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0
bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180
__bnxt_setup_vnic_p5+0x58/0x110
bnxt_init_nic+0xb72/0xf50
__bnxt_open_nic+0x40d/0xab0
bnxt_open_nic+0x2b/0x60
ethtool_set_channels+0x18c/0x1d0
As we try to access a freed ring.
The issue is present since XDP support was added, really, but
prior to commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in
__bnxt_reserve_rings()") it wasn't causing major issues. |
["https://git.kernel.org/stable/c/08831a894d18abfaabb5bbde7c2069a7fb41dd93","https://git.kernel.org/stable/c/f0aa6a37a3dbb40b272df5fc6db93c114688adcd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42253
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
gpio: pca953x: fix pca953x_irq_bus_sync_unlock race
Ensure that `i2c_lock' is held when setting interrupt latch and mask in
pca953x_irq_bus_sync_unlock() in order to avoid races.
The other (non-probe) call site pca953x_gpio_set_multiple() ensures the
lock is held before calling pca953x_write_regs().
The problem occurred when a request raced against irq_bus_sync_unlock()
approximately once per thousand reboots on an i.MX8MP based system.
* Normal case
0-0022: write register AI|3a {03,02,00,00,01} Input latch P0
0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0
0-0022: write register AI|08 {ff,00,00,00,00} Output P3
0-0022: write register AI|12 {fc,00,00,00,00} Config P3
* Race case
0-0022: write register AI|08 {ff,00,00,00,00} Output P3
0-0022: write register AI|08 {03,02,00,00,01} *** Wrong register ***
0-0022: write register AI|12 {fc,00,00,00,00} Config P3
0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0 |
["https://git.kernel.org/stable/c/58a5c93bd1a6e949267400080f07e57ffe05ec34","https://git.kernel.org/stable/c/bfc6444b57dc7186b6acc964705d7516cbaf3904","https://git.kernel.org/stable/c/de7cffa53149c7b48bd1bb29b02390c9f05b7f41","https://git.kernel.org/stable/c/e2ecdddca80dd845df42376e4b0197fe97018ba2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56623
|
Medium |
fixed |
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix use after free on unload
System crash is observed with stack trace warning of use after
free. There are 2 signals to tell dpc_thread to terminate (UNLOADING
flag and kthread_stop).
On setting the UNLOADING flag when dpc_thread happens to run at the time
and sees the flag, this causes dpc_thread to exit and clean up
itself. When kthread_stop is called for final cleanup, this causes use
after free.
Remove UNLOADING signal to terminate dpc_thread. Use the kthread_stop
as the main signal to exit dpc_thread.
[596663.812935] kernel BUG at mm/slub.c:294!
[596663.812950] invalid opcode: 0000 [#1] SMP PTI
[596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G IOE --------- - - 4.18.0-240.el8.x86_64 #1
[596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012
[596663.812974] RIP: 0010:__slab_free+0x17d/0x360
...
[596663.813008] Call Trace:
[596663.813022] ? __dentry_kill+0x121/0x170
[596663.813030] ? _cond_resched+0x15/0x30
[596663.813034] ? _cond_resched+0x15/0x30
[596663.813039] ? wait_for_completion+0x35/0x190
[596663.813048] ? try_to_wake_up+0x63/0x540
[596663.813055] free_task+0x5a/0x60
[596663.813061] kthread_stop+0xf3/0x100
[596663.813103] qla2x00_remove_one+0x284/0x440 [qla2xxx] |
["https://git.kernel.org/stable/c/07c903db0a2ff84b68efa1a74a4de353ea591eb0","https://git.kernel.org/stable/c/12f04fc8580eafb0510f805749553eb6213f323e","https://git.kernel.org/stable/c/15369e774f27ec790f207de87c0b541e3f90b22d","https://git.kernel.org/stable/c/6abf16d3c915b2feb68c1c8b25fcb71b13f98478","https://git.kernel.org/stable/c/b3e6f25176f248762a24d25ab8cf8c5e90874f80","https://git.kernel.org/stable/c/ca36d9d53745d5ec8946ef85006d4da605ea7c54"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52511
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
spi: sun6i: reduce DMA RX transfer width to single byte
Through empirical testing it has been determined that sometimes RX SPI
transfers with DMA enabled return corrupted data. This is down to single
or even multiple bytes lost during DMA transfer from SPI peripheral to
memory. It seems the RX FIFO within the SPI peripheral can become
confused when performing bus read accesses wider than a single byte to it
during an active SPI transfer.
This patch reduces the width of individual DMA read accesses to the
RX FIFO to a single byte to mitigate that issue. |
["https://git.kernel.org/stable/c/171f8a49f212e87a8b04087568e1b3d132e36a18","https://git.kernel.org/stable/c/b3c21c9c7289692f4019f163c3b06d8bdf78b355","https://git.kernel.org/stable/c/e15bb292b24630ee832bfc7fd616bd72c7682bbb","https://git.kernel.org/stable/c/ff05ed4ae214011464a0156f05cac1b0b46b5fbc","https://git.kernel.org/stable/c/171f8a49f212e87a8b04087568e1b3d132e36a18","https://git.kernel.org/stable/c/b3c21c9c7289692f4019f163c3b06d8bdf78b355","https://git.kernel.org/stable/c/e15bb292b24630ee832bfc7fd616bd72c7682bbb","https://git.kernel.org/stable/c/ff05ed4ae214011464a0156f05cac1b0b46b5fbc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3619
|
Medium |
|
N/A
|
A vulnerability has been found in Linux Kernel and classified as problematic. This vulnerability affects the function l2cap_recv_acldata of the file net/bluetooth/l2cap_core.c of the component Bluetooth. The manipulation leads to memory leak. It is recommended to apply a patch to fix this issue. VDB-211918 is the identifier assigned to this vulnerability. |
["https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=97097c85c088e11651146da32a4e1cdb9dfa6193","https://vuldb.com/?id.211918","https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=97097c85c088e11651146da32a4e1cdb9dfa6193","https://vuldb.com/?id.211918"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1192
|
Medium |
fixed |
|
A use-after-free flaw was found in smb2_is_status_io_timeout() in CIFS in the Linux Kernel. After CIFS transfers response data to a system call, there are still local variable points to the memory region, and if the system call frees it faster than CIFS uses it, CIFS will access a free memory region, leading to a denial of service. |
["https://access.redhat.com/security/cve/CVE-2023-1192","https://bugzilla.redhat.com/show_bug.cgi?id=2154178","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d527f51331cace562393a8038d870b3e9916686f","https://access.redhat.com/security/cve/CVE-2023-1192","https://bugzilla.redhat.com/show_bug.cgi?id=2154178","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d527f51331cace562393a8038d870b3e9916686f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42158
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
s390/pkey: Use kfree_sensitive() to fix Coccinelle warnings
Replace memzero_explicit() and kfree() with kfree_sensitive() to fix
warnings reported by Coccinelle:
WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1506)
WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1643)
WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1770) |
["https://git.kernel.org/stable/c/22e6824622e8a8889df0f8fc4ed5aea0e702a694","https://git.kernel.org/stable/c/62151a0acde90823bdfa991d598c85cf4b1d387d","https://git.kernel.org/stable/c/22e6824622e8a8889df0f8fc4ed5aea0e702a694","https://git.kernel.org/stable/c/62151a0acde90823bdfa991d598c85cf4b1d387d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1652
|
High |
fixed |
|
A use-after-free flaw was found in nfsd4_ssc_setup_dul in fs/nfsd/nfs4proc.c in the NFS filesystem in the Linux Kernel. This issue could allow a local attacker to crash the system or it may lead to a kernel information leak problem. |
["https://access.redhat.com/security/cve/cve-2023-1652","https://security.netapp.com/advisory/ntap-20230511-0006/","https://access.redhat.com/security/cve/cve-2023-1652","https://security.netapp.com/advisory/ntap-20230511-0006/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52479
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix uaf in smb20_oplock_break_ack
drop reference after use opinfo. |
["https://git.kernel.org/stable/c/694e13732e830cbbfedb562e57f28644927c33fd","https://git.kernel.org/stable/c/8226ffc759ea59f10067b9acdf7f94bae1c69930","https://git.kernel.org/stable/c/c69813471a1ec081a0b9bf0c6bd7e8afd818afce","https://git.kernel.org/stable/c/d5b0e9d3563e7e314a850e81f42b2ef6f39882f9","https://git.kernel.org/stable/c/694e13732e830cbbfedb562e57f28644927c33fd","https://git.kernel.org/stable/c/8226ffc759ea59f10067b9acdf7f94bae1c69930","https://git.kernel.org/stable/c/c69813471a1ec081a0b9bf0c6bd7e8afd818afce","https://git.kernel.org/stable/c/d5b0e9d3563e7e314a850e81f42b2ef6f39882f9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1380
|
High |
fixed |
- 4.14.315
- 4.19.283
- 5.4.243
- 5.10.180
- 5.15.110
- 6.1.27
- 6.2.14
|
A slab-out-of-bound read problem was found in brcmf_get_assoc_ies in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c in the Linux Kernel. This issue could occur when assoc_info->req_len data is bigger than the size of the buffer, defined as WL_EXTRA_BUF_MAX, leading to a denial of service. |
["http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html","http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html","https://bugzilla.redhat.com/show_bug.cgi?id=2177883","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/linux-wireless/20230309104457.22628-1-jisoo.jang%40yonsei.ac.kr/T/#u","https://security.netapp.com/advisory/ntap-20230511-0001/","https://www.debian.org/security/2023/dsa-5480","https://www.openwall.com/lists/oss-security/2023/03/14/1","http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html","http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html","https://bugzilla.redhat.com/show_bug.cgi?id=2177883","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/linux-wireless/20230309104457.22628-1-jisoo.jang%40yonsei.ac.kr/T/#u","https://security.netapp.com/advisory/ntap-20230511-0001/","https://www.debian.org/security/2023/dsa-5480","https://www.openwall.com/lists/oss-security/2023/03/14/1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26962
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape
For raid456, if reshape is still in progress, then IO across reshape
position will wait for reshape to make progress. However, for dm-raid,
in following cases reshape will never make progress hence IO will hang:
1) the array is read-only;
2) MD_RECOVERY_WAIT is set;
3) MD_RECOVERY_FROZEN is set;
After commit c467e97f079f ("md/raid6: use valid sector values to determine
if an I/O should wait on the reshape") fix the problem that IO across
reshape position doesn't wait for reshape, the dm-raid test
shell/lvconvert-raid-reshape.sh start to hang:
[root@fedora ~]# cat /proc/979/stack
[<0>] wait_woken+0x7d/0x90
[<0>] raid5_make_request+0x929/0x1d70 [raid456]
[<0>] md_handle_request+0xc2/0x3b0 [md_mod]
[<0>] raid_map+0x2c/0x50 [dm_raid]
[<0>] __map_bio+0x251/0x380 [dm_mod]
[<0>] dm_submit_bio+0x1f0/0x760 [dm_mod]
[<0>] __submit_bio+0xc2/0x1c0
[<0>] submit_bio_noacct_nocheck+0x17f/0x450
[<0>] submit_bio_noacct+0x2bc/0x780
[<0>] submit_bio+0x70/0xc0
[<0>] mpage_readahead+0x169/0x1f0
[<0>] blkdev_readahead+0x18/0x30
[<0>] read_pages+0x7c/0x3b0
[<0>] page_cache_ra_unbounded+0x1ab/0x280
[<0>] force_page_cache_ra+0x9e/0x130
[<0>] page_cache_sync_ra+0x3b/0x110
[<0>] filemap_get_pages+0x143/0xa30
[<0>] filemap_read+0xdc/0x4b0
[<0>] blkdev_read_iter+0x75/0x200
[<0>] vfs_read+0x272/0x460
[<0>] ksys_read+0x7a/0x170
[<0>] __x64_sys_read+0x1c/0x30
[<0>] do_syscall_64+0xc6/0x230
[<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74
This is because reshape can't make progress.
For md/raid, the problem doesn't exist because register new sync_thread
doesn't rely on the IO to be done any more:
1) If array is read-only, it can switch to read-write by ioctl/sysfs;
2) md/raid never set MD_RECOVERY_WAIT;
3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn't hold
'reconfig_mutex', hence it can be cleared and reshape can continue by
sysfs api 'sync_action'.
However, I'm not sure yet how to avoid the problem in dm-raid yet. This
patch on the one hand make sure raid_message() can't change
sync_thread() through raid_message() after presuspend(), on the other
hand detect the above 3 cases before wait for IO do be done in
dm_suspend(), and let dm-raid requeue those IO. |
["https://git.kernel.org/stable/c/41425f96d7aa59bc865f60f5dda3d7697b555677","https://git.kernel.org/stable/c/5943a34bf6bab5801e08a55f63e1b8d5bc90dae1","https://git.kernel.org/stable/c/a8d249d770cb357d16a2097b548d2e4c1c137304","https://git.kernel.org/stable/c/41425f96d7aa59bc865f60f5dda3d7697b555677","https://git.kernel.org/stable/c/5943a34bf6bab5801e08a55f63e1b8d5bc90dae1","https://git.kernel.org/stable/c/a8d249d770cb357d16a2097b548d2e4c1c137304"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-40969
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: don't set RO when shutting down f2fs
Shutdown does not check the error of thaw_super due to readonly, which
causes a deadlock like below.
f2fs_ioc_shutdown(F2FS_GOING_DOWN_FULLSYNC) issue_discard_thread
- bdev_freeze
- freeze_super
- f2fs_stop_checkpoint()
- f2fs_handle_critical_error - sb_start_write
- set RO - waiting
- bdev_thaw
- thaw_super_locked
- return -EINVAL, if sb_rdonly()
- f2fs_stop_discard_thread
-> wait for kthread_stop(discard_thread); |
["https://git.kernel.org/stable/c/1036d3ea7a32cb7cee00885c73a1f2ba7fbc499a","https://git.kernel.org/stable/c/3bdb7f161697e2d5123b89fe1778ef17a44858e7","https://git.kernel.org/stable/c/f47ed3b284b38f235355e281f57dfa8fffcc6563","https://git.kernel.org/stable/c/1036d3ea7a32cb7cee00885c73a1f2ba7fbc499a","https://git.kernel.org/stable/c/3bdb7f161697e2d5123b89fe1778ef17a44858e7","https://git.kernel.org/stable/c/f47ed3b284b38f235355e281f57dfa8fffcc6563"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56715
|
Medium |
fixed |
- 5.15.176
- 6.1.122
- 6.6.68
- 6.12.7
|
In the Linux kernel, the following vulnerability has been resolved:
ionic: Fix netdev notifier unregister on failure
If register_netdev() fails, then the driver leaks the netdev notifier.
Fix this by calling ionic_lif_unregister() on register_netdev()
failure. This will also call ionic_lif_unregister_phc() if it has
already been registered. |
["https://git.kernel.org/stable/c/87847938f5708b2509b279369c96572254bcf2ba","https://git.kernel.org/stable/c/9590d32e090ea2751e131ae5273859ca22f5ac14","https://git.kernel.org/stable/c/da5736f516a664a9e1ff74902663c64c423045d2","https://git.kernel.org/stable/c/da93a12876f8b969df7316dc93aac7e725f88252","https://git.kernel.org/stable/c/ee2e931b2b46de9af7f681258e8ec8e2cd81cfc6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50187
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: Stop the active perfmon before being destroyed
Upon closing the file descriptor, the active performance monitor is not
stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`,
the active performance monitor's pointer (`vc4->active_perfmon`) is still
retained.
If we open a new file descriptor and submit a few jobs with performance
monitors, the driver will attempt to stop the active performance monitor
using the stale pointer in `vc4->active_perfmon`. However, this pointer
is no longer valid because the previous process has already terminated,
and all performance monitors associated with it have been destroyed and
freed.
To fix this, when the active performance monitor belongs to a given
process, explicitly stop it before destroying and freeing it. |
["https://git.kernel.org/stable/c/0b2ad4f6f2bec74a5287d96cb2325a5e11706f22","https://git.kernel.org/stable/c/75452da51e2403e14be007df80d133e1443fc967","https://git.kernel.org/stable/c/937943c042503dc6087438bf3557f9057a588ba0","https://git.kernel.org/stable/c/c9adba739d5f7cdc47a7754df4a17b47b1ecf513"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53121
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: fs, lock FTE when checking if active
The referenced commits introduced a two-step process for deleting FTEs:
- Lock the FTE, delete it from hardware, set the hardware deletion function
to NULL and unlock the FTE.
- Lock the parent flow group, delete the software copy of the FTE, and
remove it from the xarray.
However, this approach encounters a race condition if a rule with the same
match value is added simultaneously. In this scenario, fs_core may set the
hardware deletion function to NULL prematurely, causing a panic during
subsequent rule deletions.
To prevent this, ensure the active flag of the FTE is checked under a lock,
which will prevent the fs_core layer from attaching a new steering rule to
an FTE that is in the process of deletion.
[ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func
[ 438.968205] ------------[ cut here ]------------
[ 438.968654] refcount_t: decrement hit 0; leaking memory.
[ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110
[ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower]
[ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8
[ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
[ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110
[ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90
[ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286
[ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000
[ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0
[ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0
[ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0
[ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0
[ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000
[ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0
[ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 438.986507] Call Trace:
[ 438.986799] <TASK>
[ 438.987070] ? __warn+0x7d/0x110
[ 438.987426] ? refcount_warn_saturate+0xfb/0x110
[ 438.987877] ? report_bug+0x17d/0x190
[ 438.988261] ? prb_read_valid+0x17/0x20
[ 438.988659] ? handle_bug+0x53/0x90
[ 438.989054] ? exc_invalid_op+0x14/0x70
[ 438.989458] ? asm_exc_invalid_op+0x16/0x20
[ 438.989883] ? refcount_warn_saturate+0xfb/0x110
[ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core]
[ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core]
[ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core]
[ 438.992054] ? xas_load+0x9/0xb0
[ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core]
[ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core]
[ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core]
[ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core]
[ 438.994728] tc_setup_cb_destroy+0xb9/0x190
[ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower]
[ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower]
[ 438.996105] tc_new_tfilter+0x347/0xbc0
[ 438.996503] ? __
---truncated--- |
["https://git.kernel.org/stable/c/094d1a2121cee1e85ab07d74388f94809dcfb5b9","https://git.kernel.org/stable/c/0d568258f99f2076ab02e9234cbabbd43e12f30e","https://git.kernel.org/stable/c/5b47c2f47c2fe921681f4a4fe2790375e6c04cdd","https://git.kernel.org/stable/c/933ef0d17f012b653e9e6006e3f50c8d0238b5ed","https://git.kernel.org/stable/c/9ca314419930f9135727e39d77e66262d5f7bef6","https://git.kernel.org/stable/c/a508c74ceae2f5a4647f67c362126516d6404ed9","https://git.kernel.org/stable/c/bfba288f53192db08c68d4c568db9783fb9cb838"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53122
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mptcp: cope racing subflow creation in mptcp_rcv_space_adjust
Additional active subflows - i.e. created by the in kernel path
manager - are included into the subflow list before starting the
3whs.
A racing recvmsg() spooling data received on an already established
subflow would unconditionally call tcp_cleanup_rbuf() on all the
current subflows, potentially hitting a divide by zero error on
the newly created ones.
Explicitly check that the subflow is in a suitable state before
invoking tcp_cleanup_rbuf(). |
["https://git.kernel.org/stable/c/0a9a182ea5c7bb0374e527130fd85024ace7279b","https://git.kernel.org/stable/c/24995851d58c4a205ad0ffa7b2f21e479a9c8527","https://git.kernel.org/stable/c/aad6412c63baa39dd813e81f16a14d976b3de2e8","https://git.kernel.org/stable/c/ce7356ae35943cc6494cc692e62d51a734062b7d","https://git.kernel.org/stable/c/ff825ab2f455299c0c7287550915a8878e2a66e0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-47929
|
Medium |
fixed |
|
In the Linux kernel before 6.1.6, a NULL pointer dereference bug in the traffic control subsystem allows an unprivileged user to trigger a denial of service (system crash) via a crafted traffic control configuration that is set up with "tc qdisc" and "tc class" commands. This affects qdisc_graft in net/sched/sch_api.c. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.6","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96398560f26aa07e8f2969d73c8197e6a6d10407","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://tldp.org/HOWTO/Traffic-Control-HOWTO/components.html","https://www.debian.org/security/2023/dsa-5324","https://www.spinics.net/lists/netdev/msg555705.html","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.6","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96398560f26aa07e8f2969d73c8197e6a6d10407","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://tldp.org/HOWTO/Traffic-Control-HOWTO/components.html","https://www.debian.org/security/2023/dsa-5324","https://www.spinics.net/lists/netdev/msg555705.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53145
|
Medium |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
um: Fix potential integer overflow during physmem setup
This issue happens when the real map size is greater than LONG_MAX,
which can be easily triggered on UML/i386. |
["https://git.kernel.org/stable/c/1575df968650d11771359e5ac78278c5b0cc19f3","https://git.kernel.org/stable/c/1bd118c5f887802cef2d9ba0d1917258667f1cae","https://git.kernel.org/stable/c/5c710f45811e7e2bfcf703980c306f19c7e1ecfe","https://git.kernel.org/stable/c/a875c023155ea92b75d6323977003e64d92ae7fc","https://git.kernel.org/stable/c/a98b7761f697e590ed5d610d87fa12be66f23419","https://git.kernel.org/stable/c/a9c95f787b88b29165563fd97761032db77116e7","https://git.kernel.org/stable/c/d1a211e5210d31da8f49fc0021bf7129b726468c","https://git.kernel.org/stable/c/e6102b72edc4eb8c0858df00ba74b5ce579c8fa2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56688
|
Medium |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport
Since transport->sock has been set to NULL during reset transport,
XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the
xs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request()
to dereference the transport->sock that has been set to NULL. |
["https://git.kernel.org/stable/c/3811172e8c98ceebd12fe526ca6cb37a1263c964","https://git.kernel.org/stable/c/4db9ad82a6c823094da27de4825af693a3475d51","https://git.kernel.org/stable/c/638a8fa5a7e641f9401346c57e236f02379a0c40","https://git.kernel.org/stable/c/66d11ca91bf5100ae2e6b5efad97e58d8448843a","https://git.kernel.org/stable/c/86a1f9fa24804cd7f9d7dd3f24af84fc7f8ec02e","https://git.kernel.org/stable/c/87a95ee34a48dfad198a2002e4966e1d63d53f2b","https://git.kernel.org/stable/c/cc91d59d34ff6a6fee1c0b48612081a451e05e9a","https://git.kernel.org/stable/c/fe6cbf0b2ac3cf4e21824a44eaa336564ed5e960"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56698
|
Medium |
fixed |
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: gadget: Fix looping of queued SG entries
The dwc3_request->num_queued_sgs is decremented on completion. If a
partially completed request is handled, then the
dwc3_request->num_queued_sgs no longer reflects the total number of
num_queued_sgs (it would be cleared).
Correctly check the number of request SG entries remained to be prepare
and queued. Failure to do this may cause null pointer dereference when
accessing non-existent SG entry. |
["https://git.kernel.org/stable/c/0247da93bf62d33304b7bf97850ebf2a86e06d28","https://git.kernel.org/stable/c/1534f6f69393aac773465d80d31801b554352627","https://git.kernel.org/stable/c/70777a23a54e359cfdfafc625a57cd56434f3859","https://git.kernel.org/stable/c/8ceb21d76426bbe7072cc3e43281e70c0d664cc7","https://git.kernel.org/stable/c/b7c3d0b59213ebeedff63d128728ce0b3d7a51ec","https://git.kernel.org/stable/c/b7fc65f5141c24785dc8c19249ca4efcf71b3524","https://git.kernel.org/stable/c/c9e72352a10ae89a430449f7bfeb043e75c255d9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56724
|
Medium |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device
While design wise the idea of converting the driver to use
the hierarchy of the IRQ chips is correct, the implementation
has (inherited) flaws. This was unveiled when platform_get_irq()
had started WARN() on IRQ 0 that is supposed to be a Linux
IRQ number (also known as vIRQ).
Rework the driver to respect IRQ domain when creating each MFD
device separately, as the domain is not the same for all of them. |
["https://git.kernel.org/stable/c/1b734ad0e33648c3988c6a37c2ac16c2d63eda06","https://git.kernel.org/stable/c/2310f5336f32eac9ada2d59b965d578efe25c4bf","https://git.kernel.org/stable/c/56acf415772ee7e10e448b371f52b249aa2d0f7b","https://git.kernel.org/stable/c/5bc6d0da4a32fe34a9960de577e0b7de3454de0c","https://git.kernel.org/stable/c/9b79d59e6b2b515eb9a22bc469ef7b8f0904fc73","https://git.kernel.org/stable/c/b7c7c400de85d915e0da7c2c363553a801c47349","https://git.kernel.org/stable/c/c472b55cc0bc3df805db6a14f50a084884cf18ee","https://git.kernel.org/stable/c/da498e02c92e6d82df8001438dd583b90c570815"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56726
|
Medium |
fixed |
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.c
Add error pointer check after calling otx2_mbox_get_rsp(). |
["https://git.kernel.org/stable/c/41f39f4c67253f802809310be6846ff408c3c758","https://git.kernel.org/stable/c/54abcec092616a4d01195355eb5d6036fb8fe363","https://git.kernel.org/stable/c/856ad633e11869729be698df2287ecfe6ec31f27","https://git.kernel.org/stable/c/a374e7e79fbdd7574bd89344447b0d4b91ba9801","https://git.kernel.org/stable/c/ac9183023b6a9c09467516abd8aab04f9a2f9564","https://git.kernel.org/stable/c/c5a6c5af434671aea739a5a41c849819144f02c9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56728
|
Medium |
fixed |
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c
Add error pointer check after calling otx2_mbox_get_rsp(). |
["https://git.kernel.org/stable/c/05a6ce174c0c724e5914e1e5efd826bab8f382b4","https://git.kernel.org/stable/c/2db2194727b1f49a5096c1c3981adef1b7638733","https://git.kernel.org/stable/c/55c41b97001a09bb490ffa2e667e251d75d15ab1","https://git.kernel.org/stable/c/5ff9de1f2712cbca53da2e37d831eea7ffcb43b6","https://git.kernel.org/stable/c/6cda142cee032b8fe65ee11f78721721c3988feb","https://git.kernel.org/stable/c/c0f64fd73b60aee85f88c270c9d714ead27a7b7a","https://git.kernel.org/stable/c/e26f8eac6bb20b20fdb8f7dc695711ebce4c7c5c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56754
|
Medium |
fixed |
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
crypto: caam - Fix the pointer passed to caam_qi_shutdown()
The type of the last parameter given to devm_add_action_or_reset() is
"struct caam_drv_private *", but in caam_qi_shutdown(), it is casted to
"struct device *".
Pass the correct parameter to devm_add_action_or_reset() so that the
resources are released as expected. |
["https://git.kernel.org/stable/c/1f8e2f597b918ca5827a5c6d00b819d064264d1c","https://git.kernel.org/stable/c/6187727e57aec122c8a99c464c74578c810cbe40","https://git.kernel.org/stable/c/66eddb8dcb61065c53098510165f14b54232bcc2","https://git.kernel.org/stable/c/84a185aea7b83f620699de0ea36907d588d89cf6","https://git.kernel.org/stable/c/ad39df0898d3f469776c19d99229be055cc2dcea","https://git.kernel.org/stable/c/ad980b04f51f7fb503530bd1cb328ba5e75a250e","https://git.kernel.org/stable/c/cc386170b3312fd7b5bc4a69a9f52d7f50814526"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56756
|
Medium |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
nvme-pci: fix freeing of the HMB descriptor table
The HMB descriptor table is sized to the maximum number of descriptors
that could be used for a given device, but __nvme_alloc_host_mem could
break out of the loop earlier on memory allocation failure and end up
using less descriptors than planned for, which leads to an incorrect
size passed to dma_free_coherent.
In practice this was not showing up because the number of descriptors
tends to be low and the dma coherent allocator always allocates and
frees at least a page. |
["https://git.kernel.org/stable/c/3c2fb1ca8086eb139b2a551358137525ae8e0d7a","https://git.kernel.org/stable/c/452f9ddd12bebc04cef741e8ba3806bf0e1fd015","https://git.kernel.org/stable/c/582d9ed999b004fb1d415ecbfa86d4d8df455269","https://git.kernel.org/stable/c/6d0f599db73b099aa724a12736369c4d4d92849d","https://git.kernel.org/stable/c/869cf50b9c9d1059f5223f79ef68fc0bc6210095","https://git.kernel.org/stable/c/ac22240540e0c5230d8c4138e3778420b712716a","https://git.kernel.org/stable/c/cee3bff51a35cab1c5d842d409a7b11caefe2386","https://git.kernel.org/stable/c/fb96d5cfa97a7363245b3dd523f475b04296d87b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56727
|
Medium |
fixed |
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c
Adding error pointer check after calling otx2_mbox_get_rsp(). |
["https://git.kernel.org/stable/c/8c9f8b35dc3d4ad8053a72bc0c5a7843591f6b75","https://git.kernel.org/stable/c/a479b3d7586e6f77f8337bbcac980eaf2d0a4029","https://git.kernel.org/stable/c/bd3110bc102ab6292656b8118be819faa0de8dd0","https://git.kernel.org/stable/c/c4eae7bac880edd88aaed6a8ec2997fa85e259c7","https://git.kernel.org/stable/c/e5e60f17d2462ef5c13db4d1a54eef5778fd2295"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48849
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: bypass tiling flag check in virtual display case (v2)
vkms leverages common amdgpu framebuffer creation, and
also as it does not support FB modifier, there is no need
to check tiling flags when initing framebuffer when virtual
display is enabled.
This can fix below calltrace:
amdgpu 0000:00:08.0: GFX9+ requires FB check based on format modifier
WARNING: CPU: 0 PID: 1023 at drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:1150 amdgpu_display_framebuffer_init+0x8e7/0xb40 [amdgpu]
v2: check adev->enable_virtual_display instead as vkms can be
enabled in bare metal as well. |
["https://git.kernel.org/stable/c/cb29021be49858059138f75d6311a7c35a9379b2","https://git.kernel.org/stable/c/e2b993302f40c4eb714ecf896dd9e1c5be7d4cd7","https://git.kernel.org/stable/c/fcd1d79aa943fff4fbaa0cce1d576995a7960699","https://git.kernel.org/stable/c/cb29021be49858059138f75d6311a7c35a9379b2","https://git.kernel.org/stable/c/e2b993302f40c4eb714ecf896dd9e1c5be7d4cd7","https://git.kernel.org/stable/c/fcd1d79aa943fff4fbaa0cce1d576995a7960699"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21690
|
Medium |
fixed |
- 5.15.178
- 6.1.128
- 6.6.75
- 6.12.12
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: storvsc: Ratelimit warning logs to prevent VM denial of service
If there's a persistent error in the hypervisor, the SCSI warning for
failed I/O can flood the kernel log and max out CPU utilization,
preventing troubleshooting from the VM side. Ratelimit the warning so
it doesn't DoS the VM. |
["https://git.kernel.org/stable/c/01d1ebdab9ccb73c952e1666a8a80abd194dbc55","https://git.kernel.org/stable/c/088bde862f8d3d0fc52e40e66a0484a246837087","https://git.kernel.org/stable/c/182a4b7c731e95c08cb47f14b87a272b6ab2b2da","https://git.kernel.org/stable/c/81d4dd05c412ba04f9f6b85b718e6da833be290c","https://git.kernel.org/stable/c/d0f0af1bafef33b3e2aa8c3a4ef44db48df9b0ea","https://git.kernel.org/stable/c/d2138eab8cde61e0e6f62d0713e45202e8457d6d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48985
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: mana: Fix race on per-CQ variable napi work_done
After calling napi_complete_done(), the NAPIF_STATE_SCHED bit may be
cleared, and another CPU can start napi thread and access per-CQ variable,
cq->work_done. If the other thread (for example, from busy_poll) sets
it to a value >= budget, this thread will continue to run when it should
stop, and cause memory corruption and panic.
To fix this issue, save the per-CQ work_done variable in a local variable
before napi_complete_done(), so it won't be corrupted by a possible
concurrent thread after napi_complete_done().
Also, add a flag bit to advertise to the NIC firmware: the NAPI work_done
variable race is fixed, so the driver is able to reliably support features
like busy_poll. |
["https://git.kernel.org/stable/c/18010ff776fa42340efc428b3ea6d19b3e7c7b21","https://git.kernel.org/stable/c/6740d8572ccd1bca50d8a1ca2bedc333f50ed5f3","https://git.kernel.org/stable/c/fe50a9bbeb1f042e756c5cfa7708112c944368de"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42107
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ice: Don't process extts if PTP is disabled
The ice_ptp_extts_event() function can race with ice_ptp_release() and
result in a NULL pointer dereference which leads to a kernel panic.
Panic occurs because the ice_ptp_extts_event() function calls
ptp_clock_event() with a NULL pointer. The ice driver has already
released the PTP clock by the time the interrupt for the next external
timestamp event occurs.
To fix this, modify the ice_ptp_extts_event() function to check the
PTP state and bail early if PTP is not ready. |
["https://git.kernel.org/stable/c/1c4e524811918600683b1ea87a5e0fc2db64fa9b","https://git.kernel.org/stable/c/996422e3230e41468f652d754fefd1bdbcd4604e","https://git.kernel.org/stable/c/1c4e524811918600683b1ea87a5e0fc2db64fa9b","https://git.kernel.org/stable/c/996422e3230e41468f652d754fefd1bdbcd4604e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47679
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
vfs: fix race between evice_inodes() and find_inode()&iput()
Hi, all
Recently I noticed a bug[1] in btrfs, after digged it into
and I believe it'a race in vfs.
Let's assume there's a inode (ie ino 261) with i_count 1 is
called by iput(), and there's a concurrent thread calling
generic_shutdown_super().
cpu0: cpu1:
iput() // i_count is 1
->spin_lock(inode)
->dec i_count to 0
->iput_final() generic_shutdown_super()
->__inode_add_lru() ->evict_inodes()
// cause some reason[2] ->if (atomic_read(inode->i_count)) continue;
// return before // inode 261 passed the above check
// list_lru_add_obj() // and then schedule out
->spin_unlock()
// note here: the inode 261
// was still at sb list and hash list,
// and I_FREEING|I_WILL_FREE was not been set
btrfs_iget()
// after some function calls
->find_inode()
// found the above inode 261
->spin_lock(inode)
// check I_FREEING|I_WILL_FREE
// and passed
->__iget()
->spin_unlock(inode) // schedule back
->spin_lock(inode)
// check (I_NEW|I_FREEING|I_WILL_FREE) flags,
// passed and set I_FREEING
iput() ->spin_unlock(inode)
->spin_lock(inode) ->evict()
// dec i_count to 0
->iput_final()
->spin_unlock()
->evict()
Now, we have two threads simultaneously evicting
the same inode, which may trigger the BUG(inode->i_state & I_CLEAR)
statement both within clear_inode() and iput().
To fix the bug, recheck the inode->i_count after holding i_lock.
Because in the most scenarios, the first check is valid, and
the overhead of spin_lock() can be reduced.
If there is any misunderstanding, please let me know, thanks.
[1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/
[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()
return false when I reproduced the bug. |
["https://git.kernel.org/stable/c/0eed942bc65de1f93eca7bda51344290f9c573bb","https://git.kernel.org/stable/c/0f8a5b6d0dafa4f533ac82e98f8b812073a7c9d1","https://git.kernel.org/stable/c/3721a69403291e2514d13a7c3af50a006ea1153b","https://git.kernel.org/stable/c/47a68c75052a660e4c37de41e321582ec9496195","https://git.kernel.org/stable/c/489faddb1ae75b0e1a741fe5ca2542a2b5e794a5","https://git.kernel.org/stable/c/540fb13120c9eab3ef203f90c00c8e69f37449d1","https://git.kernel.org/stable/c/6c857fb12b9137fee574443385d53914356bbe11","https://git.kernel.org/stable/c/6cc13a80a26e6b48f78c725c01b91987d61563ef","https://git.kernel.org/stable/c/88b1afbf0f6b221f6c5bb66cc80cd3b38d696687"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48898
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer
There are 3 possible interrupt sources are handled by DP controller,
HPDstatus, Controller state changes and Aux read/write transaction.
At every irq, DP controller have to check isr status of every interrupt
sources and service the interrupt if its isr status bits shows interrupts
are pending. There is potential race condition may happen at current aux
isr handler implementation since it is always complete dp_aux_cmd_fifo_tx()
even irq is not for aux read or write transaction. This may cause aux read
transaction return premature if host aux data read is in the middle of
waiting for sink to complete transferring data to host while irq happen.
This will cause host's receiving buffer contains unexpected data. This
patch fixes this problem by checking aux isr and return immediately at
aux isr handler if there are no any isr status bits set.
Current there is a bug report regrading eDP edid corruption happen during
system booting up. After lengthy debugging to found that VIDEO_READY
interrupt was continuously firing during system booting up which cause
dp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data
from aux hardware buffer which is not yet contains complete data transfer
from sink. This cause edid corruption.
Follows are the signature at kernel logs when problem happen,
EDID has corrupt header
panel-simple-dp-aux aux-aea0000.edp: Couldn't identify panel via EDID
Changes in v2:
-- do complete if (ret == IRQ_HANDLED) ay dp-aux_isr()
-- add more commit text
Changes in v3:
-- add Stephen suggested
-- dp_aux_isr() return IRQ_XXX back to caller
-- dp_ctrl_isr() return IRQ_XXX back to caller
Changes in v4:
-- split into two patches
Changes in v5:
-- delete empty line between tags
Changes in v6:
-- remove extra "that" and fixed line more than 75 char at commit text
Patchwork: https://patchwork.freedesktop.org/patch/516121/ |
["https://git.kernel.org/stable/c/1cba0d150fa102439114a91b3e215909efc9f169","https://git.kernel.org/stable/c/785607e5e6fb52caf141e4580de40405565f04f1","https://git.kernel.org/stable/c/984ad875db804948c86ca9e1c2e784ae8252715a","https://git.kernel.org/stable/c/b7dcbca46db3c77fdb02c2a9d6239e5aa3b06a59"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48921
|
Medium |
fixed |
- 5.10.137
- 5.15
- 5.15.27
- 5.16.13
|
In the Linux kernel, the following vulnerability has been resolved:
sched/fair: Fix fault in reweight_entity
Syzbot found a GPF in reweight_entity. This has been bisected to
commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an invalid
sched_task_group")
There is a race between sched_post_fork() and setpriority(PRIO_PGRP)
within a thread group that causes a null-ptr-deref in
reweight_entity() in CFS. The scenario is that the main process spawns
number of new threads, which then call setpriority(PRIO_PGRP, 0, -20),
wait, and exit. For each of the new threads the copy_process() gets
invoked, which adds the new task_struct and calls sched_post_fork()
for it.
In the above scenario there is a possibility that
setpriority(PRIO_PGRP) and set_one_prio() will be called for a thread
in the group that is just being created by copy_process(), and for
which the sched_post_fork() has not been executed yet. This will
trigger a null pointer dereference in reweight_entity(), as it will
try to access the run queue pointer, which hasn't been set.
Before the mentioned change the cfs_rq pointer for the task has been
set in sched_fork(), which is called much earlier in copy_process(),
before the new task is added to the thread_group. Now it is done in
the sched_post_fork(), which is called after that. To fix the issue
the remove the update_load param from the update_load param() function
and call reweight_task() only if the task flag doesn't have the
TASK_NEW flag set. |
["https://git.kernel.org/stable/c/13765de8148f71fa795e0a6607de37c49ea5915a","https://git.kernel.org/stable/c/589a954daab5e18399860b6c8ffaeaf79844eb20","https://git.kernel.org/stable/c/8f317cd888059c59e2fa924bf4b0957cfa53f78e","https://git.kernel.org/stable/c/e0bcd6b5779352aed88f2e538a82a39f1a7715bb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56664
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix race between element replace and close()
Element replace (with a socket different from the one stored) may race
with socket's close() link popping & unlinking. __sock_map_delete()
unconditionally unrefs the (wrong) element:
// set map[0] = s0
map_update_elem(map, 0, s0)
// drop fd of s0
close(s0)
sock_map_close()
lock_sock(sk) (s0!)
sock_map_remove_links(sk)
link = sk_psock_link_pop()
sock_map_unlink(sk, link)
sock_map_delete_from_link
// replace map[0] with s1
map_update_elem(map, 0, s1)
sock_map_update_elem
(s1!) lock_sock(sk)
sock_map_update_common
psock = sk_psock(sk)
spin_lock(&stab->lock)
osk = stab->sks[idx]
sock_map_add_link(..., &stab->sks[idx])
sock_map_unref(osk, &stab->sks[idx])
psock = sk_psock(osk)
sk_psock_put(sk, psock)
if (refcount_dec_and_test(&psock))
sk_psock_drop(sk, psock)
spin_unlock(&stab->lock)
unlock_sock(sk)
__sock_map_delete
spin_lock(&stab->lock)
sk = *psk // s1 replaced s0; sk == s1
if (!sk_test || sk_test == sk) // sk_test (s0) != sk (s1); no branch
sk = xchg(psk, NULL)
if (sk)
sock_map_unref(sk, psk) // unref s1; sks[idx] will dangle
psock = sk_psock(sk)
sk_psock_put(sk, psock)
if (refcount_dec_and_test())
sk_psock_drop(sk, psock)
spin_unlock(&stab->lock)
release_sock(sk)
Then close(map) enqueues bpf_map_free_deferred, which finally calls
sock_map_free(). This results in some refcount_t warnings along with
a KASAN splat [1].
Fix __sock_map_delete(), do not allow sock_map_unref() on elements that
may have been replaced.
[1]:
BUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330
Write of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063
CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014
Workqueue: events_unbound bpf_map_free_deferred
Call Trace:
<TASK>
dump_stack_lvl+0x68/0x90
print_report+0x174/0x4f6
kasan_report+0xb9/0x190
kasan_check_range+0x10f/0x1e0
sock_map_free+0x10e/0x330
bpf_map_free_deferred+0x173/0x320
process_one_work+0x846/0x1420
worker_thread+0x5b3/0xf80
kthread+0x29e/0x360
ret_from_fork+0x2d/0x70
ret_from_fork_asm+0x1a/0x30
</TASK>
Allocated by task 1202:
kasan_save_stack+0x1e/0x40
kasan_save_track+0x10/0x30
__kasan_slab_alloc+0x85/0x90
kmem_cache_alloc_noprof+0x131/0x450
sk_prot_alloc+0x5b/0x220
sk_alloc+0x2c/0x870
unix_create1+0x88/0x8a0
unix_create+0xc5/0x180
__sock_create+0x241/0x650
__sys_socketpair+0x1ce/0x420
__x64_sys_socketpair+0x92/0x100
do_syscall_64+0x93/0x180
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 46:
kasan_save_stack+0x1e/0x40
kasan_save_track+0x10/0x30
kasan_save_free_info+0x37/0x60
__kasan_slab_free+0x4b/0x70
kmem_cache_free+0x1a1/0x590
__sk_destruct+0x388/0x5a0
sk_psock_destroy+0x73e/0xa50
process_one_work+0x846/0x1420
worker_thread+0x5b3/0xf80
kthread+0x29e/0x360
ret_from_fork+0x2d/0x70
ret_from_fork_asm+0x1a/0x30
The bu
---truncated--- |
["https://git.kernel.org/stable/c/6deb9e85dc9a2ba4414b91c1b5b00b8415910890","https://git.kernel.org/stable/c/b015f19fedd2e12283a8450dd0aefce49ec57015","https://git.kernel.org/stable/c/b79a0d1e9a374d1b376933a354c4fcd01fce0365","https://git.kernel.org/stable/c/bf2318e288f636a882eea39f7e1015623629f168","https://git.kernel.org/stable/c/ed1fc5d76b81a4d681211333c026202cad4d5649","https://git.kernel.org/stable/c/fdb2cd8957ac51f84c9e742ba866087944bb834b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-2959
|
High |
fixed |
- 5.10.120
- 5.15.45
- 5.17.13
- 5.18.2
|
A race condition was found in the Linux kernel's watch queue due to a missing lock in pipe_resize_ring(). The specific flaw exists within the handling of pipe buffers. The issue results from the lack of proper locking when performing operations on an object. This flaw allows a local user to crash the system or escalate their privileges on the system. |
["https://github.com/torvalds/linux/commit/189b0ddc245139af81198d1a3637cac74f96e13a","https://security.netapp.com/advisory/ntap-20230214-0005/","https://www.zerodayinitiative.com/advisories/ZDI-22-1165/","https://github.com/torvalds/linux/commit/189b0ddc245139af81198d1a3637cac74f96e13a","https://security.netapp.com/advisory/ntap-20230214-0005/","https://www.zerodayinitiative.com/advisories/ZDI-22-1165/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-26490
|
High |
|
N/A
|
st21nfca_connectivity_event_received in drivers/nfc/st21nfca/se.c in the Linux kernel through 5.16.12 has EVT_TRANSACTION buffer overflows because of untrusted length parameters. |
["https://github.com/torvalds/linux/commit/4fbcc1a4cb20fe26ad0225679c536c80f1648221","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/BG4J46EMFPDD5QHYXDUI3PJCZQ7HQAZR/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/C5AUUDGSDLGYU7SZSK4PFAN22NISQZBT/","https://security.netapp.com/advisory/ntap-20220429-0004/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173","https://github.com/torvalds/linux/commit/4fbcc1a4cb20fe26ad0225679c536c80f1648221","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/BG4J46EMFPDD5QHYXDUI3PJCZQ7HQAZR/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/C5AUUDGSDLGYU7SZSK4PFAN22NISQZBT/","https://security.netapp.com/advisory/ntap-20220429-0004/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52515
|
High |
fixed |
- 5.10.199
- 5.15.136
- 6.1.57
- 6.5.7
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srp: Do not call scsi_done() from srp_abort()
After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler
callback, it performs one of the following actions:
* Call scsi_queue_insert().
* Call scsi_finish_command().
* Call scsi_eh_scmd_add().
Hence, SCSI abort handlers must not call scsi_done(). Otherwise all
the above actions would trigger a use-after-free. Hence remove the
scsi_done() call from srp_abort(). Keep the srp_free_req() call
before returning SUCCESS because we may not see the command again if
SUCCESS is returned. |
["https://git.kernel.org/stable/c/05a10b316adaac1f322007ca9a0383b410d759cc","https://git.kernel.org/stable/c/26788a5b48d9d5cd3283d777d238631c8cd7495a","https://git.kernel.org/stable/c/2b298f9181582270d5e95774e5a6c7a7fb5b1206","https://git.kernel.org/stable/c/b9bdffb3f9aaeff8379c83f5449c6b42cb71c2b5","https://git.kernel.org/stable/c/e193b7955dfad68035b983a0011f4ef3590c85eb","https://git.kernel.org/stable/c/05a10b316adaac1f322007ca9a0383b410d759cc","https://git.kernel.org/stable/c/26788a5b48d9d5cd3283d777d238631c8cd7495a","https://git.kernel.org/stable/c/2b298f9181582270d5e95774e5a6c7a7fb5b1206","https://git.kernel.org/stable/c/b9bdffb3f9aaeff8379c83f5449c6b42cb71c2b5","https://git.kernel.org/stable/c/e193b7955dfad68035b983a0011f4ef3590c85eb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21756
|
High |
fixed |
- 5.10.235
- 5.15.179
- 6.1.131
- 6.6.79
- 6.12.16
- 6.13.4
|
In the Linux kernel, the following vulnerability has been resolved:
vsock: Keep the binding until socket destruction
Preserve sockets bindings; this includes both resulting from an explicit
bind() and those implicitly bound through autobind during connect().
Prevents socket unbinding during a transport reassignment, which fixes a
use-after-free:
1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2)
2. transport->release() calls vsock_remove_bound() without checking if
sk was bound and moved to bound list (refcnt=1)
3. vsock_bind() assumes sk is in unbound list and before
__vsock_insert_bound(vsock_bound_sockets()) calls
__vsock_remove_bound() which does:
list_del_init(&vsk->bound_table); // nop
sock_put(&vsk->sk); // refcnt=0
BUG: KASAN: slab-use-after-free in __vsock_bind+0x62e/0x730
Read of size 4 at addr ffff88816b46a74c by task a.out/2057
dump_stack_lvl+0x68/0x90
print_report+0x174/0x4f6
kasan_report+0xb9/0x190
__vsock_bind+0x62e/0x730
vsock_bind+0x97/0xe0
__sys_bind+0x154/0x1f0
__x64_sys_bind+0x6e/0xb0
do_syscall_64+0x93/0x1b0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Allocated by task 2057:
kasan_save_stack+0x1e/0x40
kasan_save_track+0x10/0x30
__kasan_slab_alloc+0x85/0x90
kmem_cache_alloc_noprof+0x131/0x450
sk_prot_alloc+0x5b/0x220
sk_alloc+0x2c/0x870
__vsock_create.constprop.0+0x2e/0xb60
vsock_create+0xe4/0x420
__sock_create+0x241/0x650
__sys_socket+0xf2/0x1a0
__x64_sys_socket+0x6e/0xb0
do_syscall_64+0x93/0x1b0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 2057:
kasan_save_stack+0x1e/0x40
kasan_save_track+0x10/0x30
kasan_save_free_info+0x37/0x60
__kasan_slab_free+0x4b/0x70
kmem_cache_free+0x1a1/0x590
__sk_destruct+0x388/0x5a0
__vsock_bind+0x5e1/0x730
vsock_bind+0x97/0xe0
__sys_bind+0x154/0x1f0
__x64_sys_bind+0x6e/0xb0
do_syscall_64+0x93/0x1b0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 7 PID: 2057 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150
RIP: 0010:refcount_warn_saturate+0xce/0x150
__vsock_bind+0x66d/0x730
vsock_bind+0x97/0xe0
__sys_bind+0x154/0x1f0
__x64_sys_bind+0x6e/0xb0
do_syscall_64+0x93/0x1b0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
refcount_t: underflow; use-after-free.
WARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150
RIP: 0010:refcount_warn_saturate+0xee/0x150
vsock_remove_bound+0x187/0x1e0
__vsock_release+0x383/0x4a0
vsock_release+0x90/0x120
__sock_release+0xa3/0x250
sock_close+0x14/0x20
__fput+0x359/0xa80
task_work_run+0x107/0x1d0
do_exit+0x847/0x2560
do_group_exit+0xb8/0x250
__x64_sys_exit_group+0x3a/0x50
x64_sys_call+0xfec/0x14f0
do_syscall_64+0x93/0x1b0
entry_SYSCALL_64_after_hwframe+0x76/0x7e |
["https://git.kernel.org/stable/c/3f43540166128951cc1be7ab1ce6b7f05c670d8b","https://git.kernel.org/stable/c/42b33381e5e1f2b967dc4fb4221ddb9aaf10d197","https://git.kernel.org/stable/c/645ce25aa0e67895b11d89f27bb86c9d444c40f8","https://git.kernel.org/stable/c/b1afd40321f1c243cffbcf40ea7ca41aca87fa5e","https://git.kernel.org/stable/c/e48fcb403c2d0e574c19683f09399ab4cf67809c","https://git.kernel.org/stable/c/e7754d564579a5db9c5c9f74228df5d6dd6f1173","https://git.kernel.org/stable/c/fcdd2242c0231032fc84e1404315c245ae56322a","https://github.com/hoefler02/CVE-2025-21756/blob/main/x.c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-26606
|
High |
fixed |
|
In the Linux kernel 6.0.8, there is a use-after-free in ntfs_trim_fs in fs/ntfs3/bitmap.c. |
["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=557d19675a470bb0a98beccec38c5dc3735c20fa","https://lkml.org/lkml/2023/2/20/860","https://security.netapp.com/advisory/ntap-20230316-0010/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=557d19675a470bb0a98beccec38c5dc3735c20fa","https://lkml.org/lkml/2023/2/20/860","https://security.netapp.com/advisory/ntap-20230316-0010/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53141
|
High |
fixed |
- 4.19.325
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: add missing range check in bitmap_ip_uadt
When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists,
the values of ip and ip_to are slightly swapped. Therefore, the range check
for ip should be done later, but this part is missing and it seems that the
vulnerability occurs.
So we should add missing range checks and remove unnecessary range checks. |
["https://git.kernel.org/stable/c/15794835378ed56fb9bacc6a5dd3b9f33520604e","https://git.kernel.org/stable/c/2e151b8ca31607d14fddc4ad0f14da0893e1a7c7","https://git.kernel.org/stable/c/35f56c554eb1b56b77b3cf197a6b00922d49033d","https://git.kernel.org/stable/c/3c20b5948f119ae61ee35ad8584d666020c91581","https://git.kernel.org/stable/c/591efa494a1cf649f50a35def649c43ae984cd03","https://git.kernel.org/stable/c/78b0f2028f1043227a8eb0c41944027fc6a04596","https://git.kernel.org/stable/c/7ffef5e5d5eeecd9687204a5ec2d863752aafb7e","https://git.kernel.org/stable/c/856023ef032d824309abd5c747241dffa33aae8c","https://git.kernel.org/stable/c/e67471437ae9083fa73fa67eee1573fec1b7c8cf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-22056
|
High |
fixed |
- 5.10.236
- 5.15.180
- 6.1.134
- 6.6.87
- 6.12.23
- 6.13.11
- 6.14.2
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_tunnel: fix geneve_opt type confusion addition
When handling multiple NFTA_TUNNEL_KEY_OPTS_GENEVE attributes, the
parsing logic should place every geneve_opt structure one by one
compactly. Hence, when deciding the next geneve_opt position, the
pointer addition should be in units of char *.
However, the current implementation erroneously does type conversion
before the addition, which will lead to heap out-of-bounds write.
[ 6.989857] ==================================================================
[ 6.990293] BUG: KASAN: slab-out-of-bounds in nft_tunnel_obj_init+0x977/0xa70
[ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178
[ 6.991162]
[ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1
[ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
[ 6.992281] Call Trace:
[ 6.992423] <TASK>
[ 6.992586] dump_stack_lvl+0x44/0x5c
[ 6.992801] print_report+0x184/0x4be
[ 6.993790] kasan_report+0xc5/0x100
[ 6.994252] kasan_check_range+0xf3/0x1a0
[ 6.994486] memcpy+0x38/0x60
[ 6.994692] nft_tunnel_obj_init+0x977/0xa70
[ 6.995677] nft_obj_init+0x10c/0x1b0
[ 6.995891] nf_tables_newobj+0x585/0x950
[ 6.996922] nfnetlink_rcv_batch+0xdf9/0x1020
[ 6.998997] nfnetlink_rcv+0x1df/0x220
[ 6.999537] netlink_unicast+0x395/0x530
[ 7.000771] netlink_sendmsg+0x3d0/0x6d0
[ 7.001462] __sock_sendmsg+0x99/0xa0
[ 7.001707] ____sys_sendmsg+0x409/0x450
[ 7.002391] ___sys_sendmsg+0xfd/0x170
[ 7.003145] __sys_sendmsg+0xea/0x170
[ 7.004359] do_syscall_64+0x5e/0x90
[ 7.005817] entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[ 7.006127] RIP: 0033:0x7ec756d4e407
[ 7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf
[ 7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIG_RAX: 000000000000002e
[ 7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407
[ 7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003
[ 7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000
[ 7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000
[ 7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8
Fix this bug with correct pointer addition and conversion in parse
and dump code. |
["https://git.kernel.org/stable/c/0a93a710d6df334b828ea064c6d39fda34f901dc","https://git.kernel.org/stable/c/1b755d8eb1ace3870789d48fbd94f386ad6e30be","https://git.kernel.org/stable/c/28d88ee1e1cc8ac2d79aeb112717b97c5c833d43","https://git.kernel.org/stable/c/31d49eb436f2da61280508d7adf8c9b473b967aa","https://git.kernel.org/stable/c/446d94898c560ed2f61e26ae445858a4c4830762","https://git.kernel.org/stable/c/708e268acb3a446ad2a8a3d2e9bd41cc23660cd6","https://git.kernel.org/stable/c/a263d31c8c92e5919d41af57d9479cfb66323782","https://git.kernel.org/stable/c/ca2adfc03cd6273f0b589fe65afc6f75e0fe116e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-28866
|
Medium |
|
N/A
|
In the Linux kernel through 6.2.8, net/bluetooth/hci_sync.c allows out-of-bounds access because amp_init1[] and amp_init2[] are supposed to have an intentionally invalid element, but do not. |
["https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=95084403f8c070ccf5d7cbe72352519c1798a40a","https://lore.kernel.org/lkml/20230321015018.1759683-1-iam%40sung-woo.kim/","https://patchwork.kernel.org/project/bluetooth/patch/20230322232543.3079578-1-luiz.dentz%40gmail.com","https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=95084403f8c070ccf5d7cbe72352519c1798a40a","https://lore.kernel.org/lkml/20230321015018.1759683-1-iam%40sung-woo.kim/","https://patchwork.kernel.org/project/bluetooth/patch/20230322232543.3079578-1-luiz.dentz%40gmail.com"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52629
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
sh: push-switch: Reorder cleanup operations to avoid use-after-free bug
The original code puts flush_work() before timer_shutdown_sync()
in switch_drv_remove(). Although we use flush_work() to stop
the worker, it could be rescheduled in switch_timer(). As a result,
a use-after-free bug can occur. The details are shown below:
(cpu 0) | (cpu 1)
switch_drv_remove() |
flush_work() |
... | switch_timer // timer
| schedule_work(&psw->work)
timer_shutdown_sync() |
... | switch_work_handler // worker
kfree(psw) // free |
| psw->state = 0 // use
This patch puts timer_shutdown_sync() before flush_work() to
mitigate the bugs. As a result, the worker and timer will be
stopped safely before the deallocate operations. |
["https://git.kernel.org/stable/c/246f80a0b17f8f582b2c0996db02998239057c65","https://git.kernel.org/stable/c/610dbd8ac271aa36080aac50b928d700ee3fe4de","https://git.kernel.org/stable/c/246f80a0b17f8f582b2c0996db02998239057c65","https://git.kernel.org/stable/c/610dbd8ac271aa36080aac50b928d700ee3fe4de"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1872
|
High |
fixed |
|
A use-after-free vulnerability in the Linux Kernel io_uring system can be exploited to achieve local privilege escalation.
The io_file_get_fixed function lacks the presence of ctx->uring_lock which can lead to a Use-After-Free vulnerability due a race condition with fixed files getting unregistered.
We recommend upgrading past commit da24142b1ef9fd5d36b76e36bab328a5b27523e8. |
["http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y\u0026id=08681391b84da27133deefaaddefd0acfa90c2be","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y\u0026id=da24142b1ef9fd5d36b76e36bab328a5b27523e8","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://security.netapp.com/advisory/ntap-20230601-0002/","http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y\u0026id=08681391b84da27133deefaaddefd0acfa90c2be","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y\u0026id=da24142b1ef9fd5d36b76e36bab328a5b27523e8","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://security.netapp.com/advisory/ntap-20230601-0002/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50156
|
Medium |
fixed |
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
drm/msm: Avoid NULL dereference in msm_disp_state_print_regs()
If the allocation in msm_disp_state_dump_regs() failed then
`block->state` can be NULL. The msm_disp_state_print_regs() function
_does_ have code to try to handle it with:
if (*reg)
dump_addr = *reg;
...but since "dump_addr" is initialized to NULL the above is actually
a noop. The code then goes on to dereference `dump_addr`.
Make the function print "Registers not stored" when it sees a NULL to
solve this. Since we're touching the code, fix
msm_disp_state_print_regs() not to pointlessly take a double-pointer
and properly mark the pointer as `const`.
Patchwork: https://patchwork.freedesktop.org/patch/619657/ |
["https://git.kernel.org/stable/c/293f53263266bc4340d777268ab4328a97f041fa","https://git.kernel.org/stable/c/42cf045086feae77b212f0f66e742b91a5b566b7","https://git.kernel.org/stable/c/563aa81fd66a4e7e6e551a0e02bcc23957cafe2f","https://git.kernel.org/stable/c/e8e9f2a12a6214080c8ea83220a596f6e1dedc6c","https://git.kernel.org/stable/c/f7ad916273483748582d97cfa31054ccb19224f3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50160
|
Medium |
fixed |
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: hda/cs8409: Fix possible NULL dereference
If snd_hda_gen_add_kctl fails to allocate memory and returns NULL, then
NULL pointer dereference will occur in the next line.
Since dolphin_fixups function is a hda_fixup function which is not supposed
to return any errors, add simple check before dereference, ignore the fail.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/21dc97d5086fdabbe278786bb0a03cbf2e26c793","https://git.kernel.org/stable/c/4e19aca8db696b6ba4dd8c73657405e15c695f14","https://git.kernel.org/stable/c/8971fd61210d75fd2af225621cd2fcc87eb1847c","https://git.kernel.org/stable/c/a5dd71a8b849626f42d08a5e73d382f2016fc7bc","https://git.kernel.org/stable/c/c9bd4a82b4ed32c6d1c90500a52063e6e341517f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50162
|
Medium |
fixed |
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: devmap: provide rxq after redirect
rxq contains a pointer to the device from where
the redirect happened. Currently, the BPF program
that was executed after a redirect via BPF_MAP_TYPE_DEVMAP*
does not have it set.
This is particularly bad since accessing ingress_ifindex, e.g.
SEC("xdp")
int prog(struct xdp_md *pkt)
{
return bpf_redirect_map(&dev_redirect_map, 0, 0);
}
SEC("xdp/devmap")
int prog_after_redirect(struct xdp_md *pkt)
{
bpf_printk("ifindex %i", pkt->ingress_ifindex);
return XDP_PASS;
}
depends on access to rxq, so a NULL pointer gets dereferenced:
<1>[ 574.475170] BUG: kernel NULL pointer dereference, address: 0000000000000000
<1>[ 574.475188] #PF: supervisor read access in kernel mode
<1>[ 574.475194] #PF: error_code(0x0000) - not-present page
<6>[ 574.475199] PGD 0 P4D 0
<4>[ 574.475207] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
<4>[ 574.475217] CPU: 4 UID: 0 PID: 217 Comm: kworker/4:1 Not tainted 6.11.0-rc5-reduced-00859-g780801200300 #23
<4>[ 574.475226] Hardware name: Intel(R) Client Systems NUC13ANHi7/NUC13ANBi7, BIOS ANRPL357.0026.2023.0314.1458 03/14/2023
<4>[ 574.475231] Workqueue: mld mld_ifc_work
<4>[ 574.475247] RIP: 0010:bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c
<4>[ 574.475257] Code: cc cc cc cc cc cc cc 80 00 00 00 cc cc cc cc cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 66 90 55 48 89 e5 f3 0f 1e fa 48 8b 57 20 <48> 8b 52 00 8b 92 e0 00 00 00 48 bf f8 a6 d5 c4 5d a0 ff ff be 0b
<4>[ 574.475263] RSP: 0018:ffffa62440280c98 EFLAGS: 00010206
<4>[ 574.475269] RAX: ffffa62440280cd8 RBX: 0000000000000001 RCX: 0000000000000000
<4>[ 574.475274] RDX: 0000000000000000 RSI: ffffa62440549048 RDI: ffffa62440280ce0
<4>[ 574.475278] RBP: ffffa62440280c98 R08: 0000000000000002 R09: 0000000000000001
<4>[ 574.475281] R10: ffffa05dc8b98000 R11: ffffa05f577fca40 R12: ffffa05dcab24000
<4>[ 574.475285] R13: ffffa62440280ce0 R14: ffffa62440549048 R15: ffffa62440549000
<4>[ 574.475289] FS: 0000000000000000(0000) GS:ffffa05f4f700000(0000) knlGS:0000000000000000
<4>[ 574.475294] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[ 574.475298] CR2: 0000000000000000 CR3: 000000025522e000 CR4: 0000000000f50ef0
<4>[ 574.475303] PKRU: 55555554
<4>[ 574.475306] Call Trace:
<4>[ 574.475313] <IRQ>
<4>[ 574.475318] ? __die+0x23/0x70
<4>[ 574.475329] ? page_fault_oops+0x180/0x4c0
<4>[ 574.475339] ? skb_pp_cow_data+0x34c/0x490
<4>[ 574.475346] ? kmem_cache_free+0x257/0x280
<4>[ 574.475357] ? exc_page_fault+0x67/0x150
<4>[ 574.475368] ? asm_exc_page_fault+0x26/0x30
<4>[ 574.475381] ? bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c
<4>[ 574.475386] bq_xmit_all+0x158/0x420
<4>[ 574.475397] __dev_flush+0x30/0x90
<4>[ 574.475407] veth_poll+0x216/0x250 [veth]
<4>[ 574.475421] __napi_poll+0x28/0x1c0
<4>[ 574.475430] net_rx_action+0x32d/0x3a0
<4>[ 574.475441] handle_softirqs+0xcb/0x2c0
<4>[ 574.475451] do_softirq+0x40/0x60
<4>[ 574.475458] </IRQ>
<4>[ 574.475461] <TASK>
<4>[ 574.475464] __local_bh_enable_ip+0x66/0x70
<4>[ 574.475471] __dev_queue_xmit+0x268/0xe40
<4>[ 574.475480] ? selinux_ip_postroute+0x213/0x420
<4>[ 574.475491] ? alloc_skb_with_frags+0x4a/0x1d0
<4>[ 574.475502] ip6_finish_output2+0x2be/0x640
<4>[ 574.475512] ? nf_hook_slow+0x42/0xf0
<4>[ 574.475521] ip6_finish_output+0x194/0x300
<4>[ 574.475529] ? __pfx_ip6_finish_output+0x10/0x10
<4>[ 574.475538] mld_sendpack+0x17c/0x240
<4>[ 574.475548] mld_ifc_work+0x192/0x410
<4>[ 574.475557] process_one_work+0x15d/0x380
<4>[ 574.475566] worker_thread+0x29d/0x3a0
<4>[ 574.475573] ? __pfx_worker_thread+0x10/0x10
<4>[ 574.475580] ? __pfx_worker_thread+0x10/0x10
<4>[ 574.475587] kthread+0xcd/0x100
<4>[ 574.475597] ? __pfx_kthread+0x10/0x10
<4>[ 574.475606] ret_from_fork+0x31/0x50
<4>[ 574.475615] ? __pfx_kthread+0x10/0x10
<4>[ 574.475623] ret_from_fork_asm+0x1a/0x
---truncated--- |
["https://git.kernel.org/stable/c/49454f09936a9a96edfb047156889879cb4001eb","https://git.kernel.org/stable/c/9167d1c274a336e4763eeb3f3f9cb763c55df5aa","https://git.kernel.org/stable/c/a778fbe087c19f4ece5f5fc14173328f070c3803","https://git.kernel.org/stable/c/ca9984c5f0ab3690d98b13937b2485a978c8dd73","https://git.kernel.org/stable/c/fe068afb868660fe683a8391c6c17ecbe2254922"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50163
|
Medium |
fixed |
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Make sure internal and UAPI bpf_redirect flags don't overlap
The bpf_redirect_info is shared between the SKB and XDP redirect paths,
and the two paths use the same numeric flag values in the ri->flags
field (specifically, BPF_F_BROADCAST == BPF_F_NEXTHOP). This means that
if skb bpf_redirect_neigh() is used with a non-NULL params argument and,
subsequently, an XDP redirect is performed using the same
bpf_redirect_info struct, the XDP path will get confused and end up
crashing, which syzbot managed to trigger.
With the stack-allocated bpf_redirect_info, the structure is no longer
shared between the SKB and XDP paths, so the crash doesn't happen
anymore. However, different code paths using identically-numbered flag
values in the same struct field still seems like a bit of a mess, so
this patch cleans that up by moving the flag definitions together and
redefining the three flags in BPF_F_REDIRECT_INTERNAL to not overlap
with the flags used for XDP. It also adds a BUILD_BUG_ON() check to make
sure the overlap is not re-introduced by mistake. |
["https://git.kernel.org/stable/c/09d88791c7cd888d5195c84733caf9183dcfbd16","https://git.kernel.org/stable/c/0fca5ed4be8e8bfbfb9bd97845af596bab7192d3","https://git.kernel.org/stable/c/314dbee9fe4f5cee36435465de52c988d7caa466","https://git.kernel.org/stable/c/4e1e428533845d48828bd3875c0e92e8565b9962","https://git.kernel.org/stable/c/cec288e05ceac9a0d3a3a1fd279534b11844c826"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50182
|
Medium |
fixed |
- 5.15.169
- 6.1.113
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
secretmem: disable memfd_secret() if arch cannot set direct map
Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This
is the case for example on some arm64 configurations, where marking 4k
PTEs in the direct map not present can only be done if the direct map is
set up at 4k granularity in the first place (as ARM's break-before-make
semantics do not easily allow breaking apart large/gigantic pages).
More precisely, on arm64 systems with !can_set_direct_map(),
set_direct_map_invalid_noflush() is a no-op, however it returns success
(0) instead of an error. This means that memfd_secret will seemingly
"work" (e.g. syscall succeeds, you can mmap the fd and fault in pages),
but it does not actually achieve its goal of removing its memory from the
direct map.
Note that with this patch, memfd_secret() will start erroring on systems
where can_set_direct_map() returns false (arm64 with
CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and
CONFIG_KFENCE=n), but that still seems better than the current silent
failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most
arm64 systems actually have a working memfd_secret() and aren't be
affected.
From going through the iterations of the original memfd_secret patch
series, it seems that disabling the syscall in these scenarios was the
intended behavior [1] (preferred over having
set_direct_map_invalid_noflush return an error as that would result in
SIGBUSes at page-fault time), however the check for it got dropped between
v16 [2] and v17 [3], when secretmem moved away from CMA allocations.
[1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/
[2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t
[3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/ |
["https://git.kernel.org/stable/c/532b53cebe58f34ce1c0f34d866f5c0e335c53c6","https://git.kernel.org/stable/c/5ea0b7af38754d2b45ead9257bca47e84662e926","https://git.kernel.org/stable/c/757786abe4547eb3d9d0e8350a63bdb0f9824af2","https://git.kernel.org/stable/c/7caf966390e6e4ebf42775df54e7ee1f280ce677","https://git.kernel.org/stable/c/d0ae6ffa1aeb297aef89f49cfb894a83c329ebad"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50189
|
Medium |
fixed |
- 5.15.168
- 6.1.113
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
HID: amd_sfh: Switch to device-managed dmam_alloc_coherent()
Using the device-managed version allows to simplify clean-up in probe()
error path.
Additionally, this device-managed ensures proper cleanup, which helps to
resolve memory errors, page faults, btrfs going read-only, and btrfs
disk corruption. |
["https://git.kernel.org/stable/c/1c3b4c90479aa0375ec98fe1a802993ff96a5f47","https://git.kernel.org/stable/c/4cd9c5a0fcadc39a05c978a01e15e0d1edc4be93","https://git.kernel.org/stable/c/8c6ad37e5882073cab84901a31da9cb22f316276","https://git.kernel.org/stable/c/9dfee956f53eea96d93ef1e13ab4ce020f4c58b3","https://git.kernel.org/stable/c/c56f9ecb7fb6a3a90079c19eb4c8daf3bbf514b3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56692
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on node blkaddr in truncate_node()
syzbot reports a f2fs bug as below:
------------[ cut here ]------------
kernel BUG at fs/f2fs/segment.c:2534!
RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534
Call Trace:
truncate_node+0x1ae/0x8c0 fs/f2fs/node.c:909
f2fs_remove_inode_page+0x5c2/0x870 fs/f2fs/node.c:1288
f2fs_evict_inode+0x879/0x15c0 fs/f2fs/inode.c:856
evict+0x4e8/0x9b0 fs/inode.c:723
f2fs_handle_failed_inode+0x271/0x2e0 fs/f2fs/inode.c:986
f2fs_create+0x357/0x530 fs/f2fs/namei.c:394
lookup_open fs/namei.c:3595 [inline]
open_last_lookups fs/namei.c:3694 [inline]
path_openat+0x1c03/0x3590 fs/namei.c:3930
do_filp_open+0x235/0x490 fs/namei.c:3960
do_sys_openat2+0x13e/0x1d0 fs/open.c:1415
do_sys_open fs/open.c:1430 [inline]
__do_sys_openat fs/open.c:1446 [inline]
__se_sys_openat fs/open.c:1441 [inline]
__x64_sys_openat+0x247/0x2a0 fs/open.c:1441
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534
The root cause is: on a fuzzed image, blkaddr in nat entry may be
corrupted, then it will cause system panic when using it in
f2fs_invalidate_blocks(), to avoid this, let's add sanity check on
nat blkaddr in truncate_node(). |
["https://git.kernel.org/stable/c/0a5c8b3fbf6200f1c66062d307c9a52084917788","https://git.kernel.org/stable/c/27d6e7eff07f8cce8e83b162d8f21a07458c860d","https://git.kernel.org/stable/c/6babe00ccd34fc65b78ef8b99754e32b4385f23d","https://git.kernel.org/stable/c/c1077078ce4589b5e5387f6b0aaa0d4534b9eb57"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56718
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net/smc: protect link down work from execute after lgr freed
link down work may be scheduled before lgr freed but execute
after lgr freed, which may result in crash. So it is need to
hold a reference before shedule link down work, and put the
reference after work executed or canceled.
The relevant crash call stack as follows:
list_del corruption. prev->next should be ffffb638c9c0fe20,
but was 0000000000000000
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:51!
invalid opcode: 0000 [#1] SMP NOPTI
CPU: 6 PID: 978112 Comm: kworker/6:119 Kdump: loaded Tainted: G #1
Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 2221b89 04/01/2014
Workqueue: events smc_link_down_work [smc]
RIP: 0010:__list_del_entry_valid.cold+0x31/0x47
RSP: 0018:ffffb638c9c0fdd8 EFLAGS: 00010086
RAX: 0000000000000054 RBX: ffff942fb75e5128 RCX: 0000000000000000
RDX: ffff943520930aa0 RSI: ffff94352091fc80 RDI: ffff94352091fc80
RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb638c9c0fc38
R10: ffffb638c9c0fc30 R11: ffffffffa015eb28 R12: 0000000000000002
R13: ffffb638c9c0fe20 R14: 0000000000000001 R15: ffff942f9cd051c0
FS: 0000000000000000(0000) GS:ffff943520900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4f25214000 CR3: 000000025fbae004 CR4: 00000000007706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
rwsem_down_write_slowpath+0x17e/0x470
smc_link_down_work+0x3c/0x60 [smc]
process_one_work+0x1ac/0x350
worker_thread+0x49/0x2f0
? rescuer_thread+0x360/0x360
kthread+0x118/0x140
? __kthread_bind_mask+0x60/0x60
ret_from_fork+0x1f/0x30 |
["https://git.kernel.org/stable/c/2627c3e8646932dfc7b9722c88c2e1ffcf7a9fb2","https://git.kernel.org/stable/c/2b33eb8f1b3e8c2f87cfdbc8cc117f6bdfabc6ec","https://git.kernel.org/stable/c/841b1824750d3b8d1dc0a96b14db4418b952abbc","https://git.kernel.org/stable/c/bec2f52866d511e94c1c37cd962e4382b1b1a299"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1249
|
Medium |
fixed |
|
A use-after-free flaw was found in the Linux kernel’s core dump subsystem. This flaw allows a local user to crash the system. Only if patch 390031c94211 ("coredump: Use the vma snapshot in fill_files_note") not applied yet, then kernel could be affected. |
["http://packetstormsecurity.com/files/171912/CentOS-Stream-9-Missing-Kernel-Security-Fix.html","https://patchwork.kernel.org/project/linux-fsdevel/patch/87iltzn3nd.fsf_-_%40email.froward.int.ebiederm.org/","http://packetstormsecurity.com/files/171912/CentOS-Stream-9-Missing-Kernel-Security-Fix.html","https://patchwork.kernel.org/project/linux-fsdevel/patch/87iltzn3nd.fsf_-_%40email.froward.int.ebiederm.org/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48920
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: get rid of warning on transaction commit when using flushoncommit
When using the flushoncommit mount option, during almost every transaction
commit we trigger a warning from __writeback_inodes_sb_nr():
$ cat fs/fs-writeback.c:
(...)
static void __writeback_inodes_sb_nr(struct super_block *sb, ...
{
(...)
WARN_ON(!rwsem_is_locked(&sb->s_umount));
(...)
}
(...)
The trace produced in dmesg looks like the following:
[947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3
[947.481623] Modules linked in: nfsd nls_cp437 cifs asn1_decoder cifs_arc4 fscache cifs_md4 ipmi_ssif
[947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186
[947.497969] RIP: 0010:__writeback_inodes_sb_nr+0x7e/0xb3
[947.502097] Code: 24 10 4c 89 44 24 18 c6 (...)
[947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246
[947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000
[947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50
[947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000
[947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488
[947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460
[947.553621] FS: 0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000
[947.560537] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0
[947.571072] Call Trace:
[947.572354] <TASK>
[947.573266] btrfs_commit_transaction+0x1f1/0x998
[947.576785] ? start_transaction+0x3ab/0x44e
[947.579867] ? schedule_timeout+0x8a/0xdd
[947.582716] transaction_kthread+0xe9/0x156
[947.585721] ? btrfs_cleanup_transaction.isra.0+0x407/0x407
[947.590104] kthread+0x131/0x139
[947.592168] ? set_kthread_struct+0x32/0x32
[947.595174] ret_from_fork+0x22/0x30
[947.597561] </TASK>
[947.598553] ---[ end trace 644721052755541c ]---
This is because we started using writeback_inodes_sb() to flush delalloc
when committing a transaction (when using -o flushoncommit), in order to
avoid deadlocks with filesystem freeze operations. This change was made
by commit ce8ea7cc6eb313 ("btrfs: don't call btrfs_start_delalloc_roots
in flushoncommit"). After that change we started producing that warning,
and every now and then a user reports this since the warning happens too
often, it spams dmesg/syslog, and a user is unsure if this reflects any
problem that might compromise the filesystem's reliability.
We can not just lock the sb->s_umount semaphore before calling
writeback_inodes_sb(), because that would at least deadlock with
filesystem freezing, since at fs/super.c:freeze_super() sync_filesystem()
is called while we are holding that semaphore in write mode, and that can
trigger a transaction commit, resulting in a deadlock. It would also
trigger the same type of deadlock in the unmount path. Possibly, it could
also introduce some other locking dependencies that lockdep would report.
To fix this call try_to_writeback_inodes_sb() instead of
writeback_inodes_sb(), because that will try to read lock sb->s_umount
and then will only call writeback_inodes_sb() if it was able to lock it.
This is fine because the cases where it can't read lock sb->s_umount
are during a filesystem unmount or during a filesystem freeze - in those
cases sb->s_umount is write locked and sync_filesystem() is called, which
calls writeback_inodes_sb(). In other words, in all cases where we can't
take a read lock on sb->s_umount, writeback is already being triggered
elsewhere.
An alternative would be to call btrfs_start_delalloc_roots() with a
number of pages different from LONG_MAX, for example matching the number
of delalloc bytes we currently have, in
---truncated--- |
["https://git.kernel.org/stable/c/850a77c999b81dd2724efd2684068d6f90db8c16","https://git.kernel.org/stable/c/a0f0cf8341e34e5d2265bfd3a7ad68342da1e2aa","https://git.kernel.org/stable/c/e4d044dbffcd570351f21c747fc77ff90aed7f2e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-44957
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
xen: privcmd: Switch from mutex to spinlock for irqfds
irqfd_wakeup() gets EPOLLHUP, when it is called by
eventfd_release() by way of wake_up_poll(&ctx->wqh, EPOLLHUP), which
gets called under spin_lock_irqsave(). We can't use a mutex here as it
will lead to a deadlock.
Fix it by switching over to a spin lock. |
["https://git.kernel.org/stable/c/1c682593096a487fd9aebc079a307ff7a6d054a3","https://git.kernel.org/stable/c/49f2a5da6785b2dbde93e291cae037662440346e","https://git.kernel.org/stable/c/c2775ae4d9227729f8ca9ee2a068f62a00d5ea9c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47671
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
USB: usbtmc: prevent kernel-usb-infoleak
The syzbot reported a kernel-usb-infoleak in usbtmc_write,
we need to clear the structure before filling fields. |
["https://git.kernel.org/stable/c/0c927dfc0b9bd177f7ab6ee59ef0c4ea06c110a7","https://git.kernel.org/stable/c/16e0ab9ed3ae7d19ca8ee718ba4e09d5c0f909ca","https://git.kernel.org/stable/c/51297ef7ad7824ad577337f273cd092e81a9fa08","https://git.kernel.org/stable/c/625fa77151f00c1bd00d34d60d6f2e710b3f9aad","https://git.kernel.org/stable/c/6c7fc36da021b13c34c572a26ba336cd102418f8","https://git.kernel.org/stable/c/ba6269e187aa1b1f20faf3c458831a0d6350304b","https://git.kernel.org/stable/c/e872738e670ddd63e19f22d0d784f0bdf26ecba5","https://git.kernel.org/stable/c/fa652318887da530f2f9dbd9b0ea4a087d05ee12"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47734
|
Medium |
fixed |
- 5.15.168
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave()
syzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce
this[1], one bond device (bond1) has xdpdrv, which increases
bpf_master_redirect_enabled_key. Another bond device (bond0) which is
unsupported by XDP but its slave (veth3) has xdpgeneric that returns
XDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect().
To reduce unnecessary warnings and improve log management, we need to
delete the WARN_ON_ONCE() and add ratelimit to the netdev_err().
[1] Steps to reproduce:
# Needs tx_xdp with return XDP_TX;
ip l add veth0 type veth peer veth1
ip l add veth3 type veth peer veth4
ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP
ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default
ip l set veth0 master bond1
ip l set bond1 up
# Increases bpf_master_redirect_enabled_key
ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx
ip l set veth3 master bond0
ip l set bond0 up
ip l set veth4 up
# Triggers WARN_ON_ONCE() from the xdp_master_redirect()
ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx |
["https://git.kernel.org/stable/c/0cbfd45fbcf0cb26d85c981b91c62fe73cdee01c","https://git.kernel.org/stable/c/57b5fba55c6f8b1d83312a34bd656166fcd95658","https://git.kernel.org/stable/c/6b64197b4bf1a5703a8b105367baf20f1e627a75","https://git.kernel.org/stable/c/72e2c0825a480e19ee999cee9d018850d38c82b9","https://git.kernel.org/stable/c/c1be35e774f8ed415e01209fddd963c5a74e8e9f","https://git.kernel.org/stable/c/ccd3e6ff05e5236d1b9535f23f3e6622e0bb32b8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50096
|
Medium |
fixed |
- 5.4.285
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error
The `nouveau_dmem_copy_one` function ensures that the copy push command is
sent to the device firmware but does not track whether it was executed
successfully.
In the case of a copy error (e.g., firmware or hardware failure), the
copy push command will be sent via the firmware channel, and
`nouveau_dmem_copy_one` will likely report success, leading to the
`migrate_to_ram` function returning a dirty HIGH_USER page to the user.
This can result in a security vulnerability, as a HIGH_USER page that may
contain sensitive or corrupted data could be returned to the user.
To prevent this vulnerability, we allocate a zero page. Thus, in case of
an error, a non-dirty (zero) page will be returned to the user. |
["https://git.kernel.org/stable/c/614bfb2050982d23d53d0d51c4079dba0437c883","https://git.kernel.org/stable/c/697e3ddcf1f8b68bd531fc34eead27c000bdf3e1","https://git.kernel.org/stable/c/73f75d2b5aee5a735cf64b8ab4543d5c20dbbdd9","https://git.kernel.org/stable/c/835745a377a4519decd1a36d6b926e369b3033e2","https://git.kernel.org/stable/c/8c3de9282dde21ce3c1bf1bde3166a4510547aa9","https://git.kernel.org/stable/c/ab4d113b6718b076046018292f821d5aa4b844f8","https://git.kernel.org/stable/c/fd9bb7e996bab9b9049fffe3f3d3b50dee191d27"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50178
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request()
Use raw_smp_processor_id() instead of plain smp_processor_id() in
do_service_request(), otherwise we may get some errors with the driver
enabled:
BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/208
caller is loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq] |
["https://git.kernel.org/stable/c/2b7ec33e534f7a10033a5cf07794acf48b182bbe","https://git.kernel.org/stable/c/2f78e4a6d2702ac03c2bf2ed3a0e344e1fa9f967"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53050
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/hdcp: Add encoder check in hdcp2_get_capability
Add encoder check in intel_hdcp2_get_capability to avoid
null pointer error. |
["https://git.kernel.org/stable/c/5b89dcf23575eb5bb95ce8d672cbc2232c2eb096","https://git.kernel.org/stable/c/d34f4f058edf1235c103ca9c921dc54820d14d40"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53051
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/hdcp: Add encoder check in intel_hdcp_get_capability
Sometimes during hotplug scenario or suspend/resume scenario encoder is
not always initialized when intel_hdcp_get_capability add
a check to avoid kernel null pointer dereference. |
["https://git.kernel.org/stable/c/31b42af516afa1e184d1a9f9dd4096c54044269a","https://git.kernel.org/stable/c/4912e8fb3c37fb2dedf48d9c18bbbecd70e720f8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53084
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/imagination: Break an object reference loop
When remaining resources are being cleaned up on driver close,
outstanding VM mappings may result in resources being leaked, due
to an object reference loop, as shown below, with each object (or
set of objects) referencing the object below it:
PVR GEM Object
GPU scheduler "finished" fence
GPU scheduler “scheduled” fence
PVR driver “done” fence
PVR Context
PVR VM Context
PVR VM Mappings
PVR GEM Object
The reference that the PVR VM Context has on the VM mappings is a
soft one, in the sense that the freeing of outstanding VM mappings
is done as part of VM context destruction; no reference counts are
involved, as is the case for all the other references in the loop.
To break the reference loop during cleanup, free the outstanding
VM mappings before destroying the PVR Context associated with the
VM context. |
["https://git.kernel.org/stable/c/b04ce1e718bd55302b52d05d6873e233cb3ec7a1","https://git.kernel.org/stable/c/cb86db12b290ed07d05df00d99fa150bb123e80e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53114
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client
A number of Zen4 client SoCs advertise the ability to use virtualized
VMLOAD/VMSAVE, but using these instructions is reported to be a cause
of a random host reboot.
These instructions aren't intended to be advertised on Zen4 client
so clear the capability. |
["https://git.kernel.org/stable/c/00c713f84f477a85e524f34aad8fbd11a1c051f0","https://git.kernel.org/stable/c/a5ca1dc46a6b610dd4627d8b633d6c84f9724ef0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-39728
|
Medium |
fixed |
- 5.10.236
- 5.15.180
- 6.1.134
- 6.6.87
- 6.12.23
- 6.13.11
- 6.14.2
|
In the Linux kernel, the following vulnerability has been resolved:
clk: samsung: Fix UBSAN panic in samsung_clk_init()
With UBSAN_ARRAY_BOUNDS=y, I'm hitting the below panic due to
dereferencing `ctx->clk_data.hws` before setting
`ctx->clk_data.num = nr_clks`. Move that up to fix the crash.
UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP
<snip>
Call trace:
samsung_clk_init+0x110/0x124 (P)
samsung_clk_init+0x48/0x124 (L)
samsung_cmu_register_one+0x3c/0xa0
exynos_arm64_register_cmu+0x54/0x64
__gs101_cmu_top_of_clk_init_declare+0x28/0x60
... |
["https://git.kernel.org/stable/c/00307934eb94aaa0a99addfb37b9fe206f945004","https://git.kernel.org/stable/c/0fef48f4a70e45a93e73c39023c3a6ea624714d6","https://git.kernel.org/stable/c/157de9e48007a20c65d02fc0229a16f38134a72d","https://git.kernel.org/stable/c/24307866e0ac0a5ddb462e766ceda5e27a6fbbe3","https://git.kernel.org/stable/c/4d29a6dcb51e346595a15b49693eeb728925ca43","https://git.kernel.org/stable/c/a1500b98cd81a32fdfb9bc63c33bb9f0c2a0a1bf","https://git.kernel.org/stable/c/d19d7345a7bcdb083b65568a11b11adffe0687af","https://git.kernel.org/stable/c/d974e177369c034984cece9d7d4fada9f8b9c740"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-2153
|
Medium |
fixed |
|
A flaw was found in the Linux kernel’s KVM when attempting to set a SynIC IRQ. This issue makes it possible for a misbehaving VMM to write to SYNIC/STIMER MSRs, causing a NULL pointer dereference. This flaw allows an unprivileged local attacker on the host to issue specific ioctl calls, causing a kernel oops condition that results in a denial of service. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2069736","https://github.com/torvalds/linux/commit/00b5f37189d24ac3ed46cb7f11742094778c46ce","https://github.com/torvalds/linux/commit/7ec37d1cbe17d8189d9562178d8b29167fe1c31a","https://github.com/torvalds/linux/commit/b1e34d325397a33d97d845e312d7cf2a8b646b44","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://www.openwall.com/lists/oss-security/2022/06/22/1","https://bugzilla.redhat.com/show_bug.cgi?id=2069736","https://github.com/torvalds/linux/commit/00b5f37189d24ac3ed46cb7f11742094778c46ce","https://github.com/torvalds/linux/commit/7ec37d1cbe17d8189d9562178d8b29167fe1c31a","https://github.com/torvalds/linux/commit/b1e34d325397a33d97d845e312d7cf2a8b646b44","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://www.openwall.com/lists/oss-security/2022/06/22/1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50191
|
Medium |
fixed |
- 5.15.168
- 6.1.113
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: don't set SB_RDONLY after filesystem errors
When the filesystem is mounted with errors=remount-ro, we were setting
SB_RDONLY flag to stop all filesystem modifications. We knew this misses
proper locking (sb->s_umount) and does not go through proper filesystem
remount procedure but it has been the way this worked since early ext2
days and it was good enough for catastrophic situation damage
mitigation. Recently, syzbot has found a way (see link) to trigger
warnings in filesystem freezing because the code got confused by
SB_RDONLY changing under its hands. Since these days we set
EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all
filesystem modifications, modifying SB_RDONLY shouldn't be needed. So
stop doing that. |
["https://git.kernel.org/stable/c/4061e07f040a091f694f461b86a26cf95ae66439","https://git.kernel.org/stable/c/58c0648e4c773f5b54f0cb63bc8c7c6bf52719a9","https://git.kernel.org/stable/c/d3476f3dad4ad68ae5f6b008ea6591d1520da5d8","https://git.kernel.org/stable/c/ee77c388469116565e009eaa704a60bc78489e09","https://git.kernel.org/stable/c/fbb177bc1d6487cd3e9b50ae0be2781b7297980d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50196
|
Medium |
fixed |
- 5.15.169
- 6.1.114
- 6.6.58
- 6.11.5
|
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: ocelot: fix system hang on level based interrupts
The current implementation only calls chained_irq_enter() and
chained_irq_exit() if it detects pending interrupts.
```
for (i = 0; i < info->stride; i++) {
uregmap_read(info->map, id_reg + 4 * i, ®);
if (!reg)
continue;
chained_irq_enter(parent_chip, desc);
```
However, in case of GPIO pin configured in level mode and the parent
controller configured in edge mode, GPIO interrupt might be lowered by the
hardware. In the result, if the interrupt is short enough, the parent
interrupt is still pending while the GPIO interrupt is cleared;
chained_irq_enter() never gets called and the system hangs trying to
service the parent interrupt.
Moving chained_irq_enter() and chained_irq_exit() outside the for loop
ensures that they are called even when GPIO interrupt is lowered by the
hardware.
The similar code with chained_irq_enter() / chained_irq_exit() functions
wrapping interrupt checking loop may be found in many other drivers:
```
grep -r -A 10 chained_irq_enter drivers/pinctrl
``` |
["https://git.kernel.org/stable/c/20728e86289ab463b99b7ab4425515bd26aba417","https://git.kernel.org/stable/c/4a81800ef05bea5a9896f199677f7b7f5020776a","https://git.kernel.org/stable/c/655f5d4662b958122b260be05aa6dfdf8768efe6","https://git.kernel.org/stable/c/93b8ddc54507a227087c60a0013ed833b6ae7d3c","https://git.kernel.org/stable/c/dcbe9954634807ec54e22bde278b5b269f921381"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53146
|
Medium |
fixed |
- 4.19.325
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Prevent a potential integer overflow
If the tag length is >= U32_MAX - 3 then the "length + 4" addition
can result in an integer overflow. Address this by splitting the
decoding into several steps so that decode_cb_compound4res() does
not have to perform arithmetic on the unsafe length value. |
["https://git.kernel.org/stable/c/084f797dbc7e52209a4ab6dbc7f0109268754eb9","https://git.kernel.org/stable/c/3c5f545c9a1f8a1869246f6f3ae8c17289d6a841","https://git.kernel.org/stable/c/745f7ce5a95e783ba62fe774325829466aec2aa8","https://git.kernel.org/stable/c/7f33b92e5b18e904a481e6e208486da43e4dc841","https://git.kernel.org/stable/c/842f1c27a1aef5367e535f9e85c8c3b06352151a","https://git.kernel.org/stable/c/90adbae9dd158da8331d9fdd32077bd1af04f553","https://git.kernel.org/stable/c/ccd3394f9a7200d6b088553bf38e688620cd27af","https://git.kernel.org/stable/c/dde654cad08fdaac370febb161ec41eb58e9d2a2","https://git.kernel.org/stable/c/de53c5305184ca1333b87e695d329d1502d694ce"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56739
|
Medium |
fixed |
- 4.19.325
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
rtc: check if __rtc_read_time was successful in rtc_timer_do_work()
If the __rtc_read_time call fails,, the struct rtc_time tm; may contain
uninitialized data, or an illegal date/time read from the RTC hardware.
When calling rtc_tm_to_ktime later, the result may be a very large value
(possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue,
they will continually expire, may causing kernel softlockup. |
["https://git.kernel.org/stable/c/0d68e8514d9040108ff7d1b37ca71096674b6efe","https://git.kernel.org/stable/c/246f621d363988e7040f4546d20203dc713fa3e1","https://git.kernel.org/stable/c/39ad0a1ae17b54509cd9e93dcd8cec16e7c12d3f","https://git.kernel.org/stable/c/44b3257ff705d63d5f00ef8ed314a0eeb7ec37f2","https://git.kernel.org/stable/c/a1f0b4af90cc18b10261ecde56c6a56b22c75bd1","https://git.kernel.org/stable/c/dd4b1cbcc916fad5d10c2662b62def9f05e453d4","https://git.kernel.org/stable/c/e77bce0a8c3989b4173c36f4195122bca8f4a3e1","https://git.kernel.org/stable/c/e8ba8a2bc4f60a1065f23d6a0e7cbea945a0f40d","https://git.kernel.org/stable/c/fde56535505dde3336df438e949ef4742b6d6d6e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48979
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: fix array index out of bound error in DCN32 DML
[Why&How]
LinkCapacitySupport array is indexed with the number of voltage states and
not the number of max DPPs. Fix the error by changing the array
declaration to use the correct (larger) array size of total number of
voltage states. |
["https://git.kernel.org/stable/c/3d8a298b2e83b98042e6ec726e934f535b23e6aa","https://git.kernel.org/stable/c/aeffc8fb2174f017a10df114bc312f899904dc68"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50091
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
dm vdo: don't refer to dedupe_context after releasing it
Clear the dedupe_context pointer in a data_vio whenever ownership of
the context is lost, so that vdo can't examine it accidentally. |
["https://git.kernel.org/stable/c/0808ebf2f80b962e75741a41ced372a7116f1e26","https://git.kernel.org/stable/c/63ef073084c67878d7a92e15ad055172da3f05a3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-4382
|
Medium |
|
N/A
|
A use-after-free flaw caused by a race among the superblock operations in the gadgetfs Linux driver was found. It could be triggered by yanking out a device that is running the gadgetfs side. |
["https://www.openwall.com/lists/oss-security/2022/12/14/5","https://www.openwall.com/lists/oss-security/2022/12/14/5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3202
|
High |
fixed |
- 4.9.311
- 4.14.276
- 4.19.238
- 5.4.189
- 5.10.111
- 5.15.34
- 5.16.20
- 5.17.3
|
A NULL pointer dereference flaw in diFree in fs/jfs/inode.c in Journaled File System (JFS)in the Linux kernel. This could allow a local attacker to crash the system or leak kernel internal information. |
["https://github.com/torvalds/linux/commit/a53046291020ec41e09181396c1e829287b48d47","https://security.netapp.com/advisory/ntap-20221228-0007/","https://github.com/torvalds/linux/commit/a53046291020ec41e09181396c1e829287b48d47","https://security.netapp.com/advisory/ntap-20221228-0007/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48866
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
HID: hid-thrustmaster: fix OOB read in thrustmaster_interrupts
Syzbot reported an slab-out-of-bounds Read in thrustmaster_probe() bug.
The root case is in missing validation check of actual number of endpoints.
Code should not blindly access usb_host_interface::endpoint array, since
it may contain less endpoints than code expects.
Fix it by adding missing validaion check and print an error if
number of endpoints do not match expected number |
["https://git.kernel.org/stable/c/3ffbe85cda7f523dad896bae08cecd8db8b555ab","https://git.kernel.org/stable/c/56185434e1e50acecee56d8f5850135009b87947","https://git.kernel.org/stable/c/fc3ef2e3297b3c0e2006b5d7b3d66965e3392036","https://git.kernel.org/stable/c/3ffbe85cda7f523dad896bae08cecd8db8b555ab","https://git.kernel.org/stable/c/56185434e1e50acecee56d8f5850135009b87947","https://git.kernel.org/stable/c/fc3ef2e3297b3c0e2006b5d7b3d66965e3392036"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-33743
|
High |
|
N/A
|
network backend may cause Linux netfront to use freed SKBs While adding logic to support XDP (eXpress Data Path), a code label was moved in a way allowing for SKBs having references (pointers) retained for further processing to nevertheless be freed. |
["http://www.openwall.com/lists/oss-security/2022/07/05/5","http://xenbits.xen.org/xsa/advisory-405.html","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-405.txt","http://www.openwall.com/lists/oss-security/2022/07/05/5","http://xenbits.xen.org/xsa/advisory-405.html","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-405.txt"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-26544
|
High |
fixed |
|
In the Linux kernel 6.0.8, there is a use-after-free in run_unpack in fs/ntfs3/run.c, related to a difference between NTFS sector size and media sector size. |
["https://bugzilla.suse.com/show_bug.cgi?id=1208697","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=887bfc546097fbe8071dac13b2fef73b77920899","https://lkml.org/lkml/2023/2/20/128","https://security.netapp.com/advisory/ntap-20230316-0010/","https://bugzilla.suse.com/show_bug.cgi?id=1208697","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=887bfc546097fbe8071dac13b2fef73b77920899","https://lkml.org/lkml/2023/2/20/128","https://security.netapp.com/advisory/ntap-20230316-0010/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49290
|
High |
fixed |
- 4.5
- 4.9.309
- 4.14.274
- 4.19.237
- 5.4.188
- 5.10.109
- 5.15.32
- 5.16.18
- 5.17.1
|
In the Linux kernel, the following vulnerability has been resolved:
mac80211: fix potential double free on mesh join
While commit 6a01afcf8468 ("mac80211: mesh: Free ie data when leaving
mesh") fixed a memory leak on mesh leave / teardown it introduced a
potential memory corruption caused by a double free when rejoining the
mesh:
ieee80211_leave_mesh()
-> kfree(sdata->u.mesh.ie);
...
ieee80211_join_mesh()
-> copy_mesh_setup()
-> old_ie = ifmsh->ie;
-> kfree(old_ie);
This double free / kernel panics can be reproduced by using wpa_supplicant
with an encrypted mesh (if set up without encryption via "iw" then
ifmsh->ie is always NULL, which avoids this issue). And then calling:
$ iw dev mesh0 mesh leave
$ iw dev mesh0 mesh join my-mesh
Note that typically these commands are not used / working when using
wpa_supplicant. And it seems that wpa_supplicant or wpa_cli are going
through a NETDEV_DOWN/NETDEV_UP cycle between a mesh leave and mesh join
where the NETDEV_UP resets the mesh.ie to NULL via a memcpy of
default_mesh_setup in cfg80211_netdev_notifier_call, which then avoids
the memory corruption, too.
The issue was first observed in an application which was not using
wpa_supplicant but "Senf" instead, which implements its own calls to
nl80211.
Fixing the issue by removing the kfree()'ing of the mesh IE in the mesh
join function and leaving it solely up to the mesh leave to free the
mesh IE. |
["https://git.kernel.org/stable/c/12e407a8ef17623823fd0c066fbd7f103953d28d","https://git.kernel.org/stable/c/273ebddc5fda2967492cb0b6cdd7d81cfb821b76","https://git.kernel.org/stable/c/3bbd0000d012f92aec423b224784fbf0f7bf40f8","https://git.kernel.org/stable/c/46bb87d40683337757a2f902fcd4244b32bb4e86","https://git.kernel.org/stable/c/4a2d4496e15ea5bb5c8e83b94ca8ca7fb045e7d3","https://git.kernel.org/stable/c/582d8c60c0c053684f7138875e8150d5749ffc17","https://git.kernel.org/stable/c/5d3ff9542a40ce034416bca03864709540a36016","https://git.kernel.org/stable/c/615716af8644813355e014314a0bc1e961250f5a","https://git.kernel.org/stable/c/c1d9c3628ef0a0ca197595d0f9e01cd3b5dda186"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48424
|
High |
fixed |
|
In the Linux kernel before 6.1.3, fs/ntfs3/inode.c does not validate the attribute name offset. An unhandled page fault may occur. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.3","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4f1dc7d9756e66f3f876839ea174df2e656b7f79","https://security.netapp.com/advisory/ntap-20230505-0002/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.3","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4f1dc7d9756e66f3f876839ea174df2e656b7f79","https://security.netapp.com/advisory/ntap-20230505-0002/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-53023
|
High |
fixed |
- 4.14.305
- 4.19.272
- 5.4.231
- 5.10.166
- 5.15.91
- 6.1.9
|
In the Linux kernel, the following vulnerability has been resolved:
net: nfc: Fix use-after-free in local_cleanup()
Fix a use-after-free that occurs in kfree_skb() called from
local_cleanup(). This could happen when killing nfc daemon (e.g. neard)
after detaching an nfc device.
When detaching an nfc device, local_cleanup() called from
nfc_llcp_unregister_device() frees local->rx_pending and decreases
local->ref by kref_put() in nfc_llcp_local_put().
In the terminating process, nfc daemon releases all sockets and it leads
to decreasing local->ref. After the last release of local->ref,
local_cleanup() called from local_release() frees local->rx_pending
again, which leads to the bug.
Setting local->rx_pending to NULL in local_cleanup() could prevent
use-after-free when local_cleanup() is called twice.
Found by a modified version of syzkaller.
BUG: KASAN: use-after-free in kfree_skb()
Call Trace:
dump_stack_lvl (lib/dump_stack.c:106)
print_address_description.constprop.0.cold (mm/kasan/report.c:306)
kasan_check_range (mm/kasan/generic.c:189)
kfree_skb (net/core/skbuff.c:955)
local_cleanup (net/nfc/llcp_core.c:159)
nfc_llcp_local_put.part.0 (net/nfc/llcp_core.c:172)
nfc_llcp_local_put (net/nfc/llcp_core.c:181)
llcp_sock_destruct (net/nfc/llcp_sock.c:959)
__sk_destruct (net/core/sock.c:2133)
sk_destruct (net/core/sock.c:2181)
__sk_free (net/core/sock.c:2192)
sk_free (net/core/sock.c:2203)
llcp_sock_release (net/nfc/llcp_sock.c:646)
__sock_release (net/socket.c:650)
sock_close (net/socket.c:1365)
__fput (fs/file_table.c:306)
task_work_run (kernel/task_work.c:179)
ptrace_notify (kernel/signal.c:2354)
syscall_exit_to_user_mode_prepare (kernel/entry/common.c:278)
syscall_exit_to_user_mode (kernel/entry/common.c:296)
do_syscall_64 (arch/x86/entry/common.c:86)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:106)
Allocated by task 4719:
kasan_save_stack (mm/kasan/common.c:45)
__kasan_slab_alloc (mm/kasan/common.c:325)
slab_post_alloc_hook (mm/slab.h:766)
kmem_cache_alloc_node (mm/slub.c:3497)
__alloc_skb (net/core/skbuff.c:552)
pn533_recv_response (drivers/nfc/pn533/usb.c:65)
__usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1671)
usb_giveback_urb_bh (drivers/usb/core/hcd.c:1704)
tasklet_action_common.isra.0 (kernel/softirq.c:797)
__do_softirq (kernel/softirq.c:571)
Freed by task 1901:
kasan_save_stack (mm/kasan/common.c:45)
kasan_set_track (mm/kasan/common.c:52)
kasan_save_free_info (mm/kasan/genericdd.c:518)
__kasan_slab_free (mm/kasan/common.c:236)
kmem_cache_free (mm/slub.c:3809)
kfree_skbmem (net/core/skbuff.c:874)
kfree_skb (net/core/skbuff.c:931)
local_cleanup (net/nfc/llcp_core.c:159)
nfc_llcp_unregister_device (net/nfc/llcp_core.c:1617)
nfc_unregister_device (net/nfc/core.c:1179)
pn53x_unregister_nfc (drivers/nfc/pn533/pn533.c:2846)
pn533_usb_disconnect (drivers/nfc/pn533/usb.c:579)
usb_unbind_interface (drivers/usb/core/driver.c:458)
device_release_driver_internal (drivers/base/dd.c:1279)
bus_remove_device (drivers/base/bus.c:529)
device_del (drivers/base/core.c:3665)
usb_disable_device (drivers/usb/core/message.c:1420)
usb_disconnect (drivers/usb/core.c:2261)
hub_event (drivers/usb/core/hub.c:5833)
process_one_work (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:212 include/trace/events/workqueue.h:108 kernel/workqueue.c:2281)
worker_thread (include/linux/list.h:282 kernel/workqueue.c:2423)
kthread (kernel/kthread.c:319)
ret_from_fork (arch/x86/entry/entry_64.S:301) |
["https://git.kernel.org/stable/c/4bb4db7f3187c6e3de6b229ffc87cdb30a2d22b6","https://git.kernel.org/stable/c/54f7be61584b8ec4c6df405f479495b9397bae4a","https://git.kernel.org/stable/c/7f129927feaf7c10b1c38bbce630172e9a08c834","https://git.kernel.org/stable/c/a59cdbda3714e11aa3ab579132864c4c8c6d54f9","https://git.kernel.org/stable/c/ad1baab3a5c03692d22ce446f38596a126377f6a","https://git.kernel.org/stable/c/b09ae26f08aaf2d85f96ea7f90ddd3387f62216f","https://git.kernel.org/stable/c/d3605282ec3502ec8847915eb2cf1f340493ff79"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-37838
|
High |
fixed |
- 6.1.135
- 6.6.88
- 6.12.24
- 6.13.12
- 6.14.3
|
In the Linux kernel, the following vulnerability has been resolved:
HSI: ssi_protocol: Fix use after free vulnerability in ssi_protocol Driver Due to Race Condition
In the ssi_protocol_probe() function, &ssi->work is bound with
ssip_xmit_work(), In ssip_pn_setup(), the ssip_pn_xmit() function
within the ssip_pn_ops structure is capable of starting the
work.
If we remove the module which will call ssi_protocol_remove()
to make a cleanup, it will free ssi through kfree(ssi),
while the work mentioned above will be used. The sequence
of operations that may lead to a UAF bug is as follows:
CPU0 CPU1
| ssip_xmit_work
ssi_protocol_remove |
kfree(ssi); |
| struct hsi_client *cl = ssi->cl;
| // use ssi
Fix it by ensuring that the work is canceled before proceeding
with the cleanup in ssi_protocol_remove(). |
["https://git.kernel.org/stable/c/4a8c29beb8a02b5a0a9d77d608aa14b6f88a6b86","https://git.kernel.org/stable/c/4b4194c9a7a8f92db39e8e86c85f4fb12ebbec4f","https://git.kernel.org/stable/c/58eb29dba712ab0f13af59ca2fe545f5ce360e78","https://git.kernel.org/stable/c/72972552d0d0bfeb2dec5daf343a19018db36ffa","https://git.kernel.org/stable/c/834e602d0cc7c743bfce734fad4a46cefc0f9ab1","https://git.kernel.org/stable/c/ae5a6a0b425e8f76a9f0677e50796e494e89b088","https://git.kernel.org/stable/c/d03abc1c2b21324550fa71e12d53e7d3498e0af6","https://git.kernel.org/stable/c/d58493832e284f066e559b8da5ab20c15a2801d3","https://git.kernel.org/stable/c/e3f88665a78045fe35c7669d2926b8d97b892c11"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48651
|
High |
fixed |
- 4.9.330
- 4.14.295
- 4.19.260
- 5.4.215
- 5.10.146
- 5.15.71
- 5.19.12
|
In the Linux kernel, the following vulnerability has been resolved:
ipvlan: Fix out-of-bound bugs caused by unset skb->mac_header
If an AF_PACKET socket is used to send packets through ipvlan and the
default xmit function of the AF_PACKET socket is changed from
dev_queue_xmit() to packet_direct_xmit() via setsockopt() with the option
name of PACKET_QDISC_BYPASS, the skb->mac_header may not be reset and
remains as the initial value of 65535, this may trigger slab-out-of-bounds
bugs as following:
=================================================================
UG: KASAN: slab-out-of-bounds in ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan]
PU: 2 PID: 1768 Comm: raw_send Kdump: loaded Not tainted 6.0.0-rc4+ #6
ardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33
all Trace:
print_address_description.constprop.0+0x1d/0x160
print_report.cold+0x4f/0x112
kasan_report+0xa3/0x130
ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan]
ipvlan_start_xmit+0x29/0xa0 [ipvlan]
__dev_direct_xmit+0x2e2/0x380
packet_direct_xmit+0x22/0x60
packet_snd+0x7c9/0xc40
sock_sendmsg+0x9a/0xa0
__sys_sendto+0x18a/0x230
__x64_sys_sendto+0x74/0x90
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
The root cause is:
1. packet_snd() only reset skb->mac_header when sock->type is SOCK_RAW
and skb->protocol is not specified as in packet_parse_headers()
2. packet_direct_xmit() doesn't reset skb->mac_header as dev_queue_xmit()
In this case, skb->mac_header is 65535 when ipvlan_xmit_mode_l2() is
called. So when ipvlan_xmit_mode_l2() gets mac header with eth_hdr() which
use "skb->head + skb->mac_header", out-of-bound access occurs.
This patch replaces eth_hdr() with skb_eth_hdr() in ipvlan_xmit_mode_l2()
and reset mac header in multicast to solve this out-of-bound bug. |
["https://git.kernel.org/stable/c/25efdbe5fe542c3063d1948cc4e98abcb57621ca","https://git.kernel.org/stable/c/346e94aa4a99378592c46d6a34c72703a32bd5be","https://git.kernel.org/stable/c/81225b2ea161af48e093f58e8dfee6d705b16af4","https://git.kernel.org/stable/c/8d06006c7eb75587d986da46c48ba9274f94e8e7","https://git.kernel.org/stable/c/ab4a733874ead120691e8038272d22f8444d3638","https://git.kernel.org/stable/c/b583e6b25bf9321c91154f6c78d2173ef12c4241","https://git.kernel.org/stable/c/bffcdade259c05ab3436b5fab711612093c275ef","https://git.kernel.org/stable/c/e2b46cd5796f083e452fbc624f65b80328b0c1a4","https://git.kernel.org/stable/c/25efdbe5fe542c3063d1948cc4e98abcb57621ca","https://git.kernel.org/stable/c/346e94aa4a99378592c46d6a34c72703a32bd5be","https://git.kernel.org/stable/c/81225b2ea161af48e093f58e8dfee6d705b16af4","https://git.kernel.org/stable/c/8d06006c7eb75587d986da46c48ba9274f94e8e7","https://git.kernel.org/stable/c/ab4a733874ead120691e8038272d22f8444d3638","https://git.kernel.org/stable/c/b583e6b25bf9321c91154f6c78d2173ef12c4241","https://git.kernel.org/stable/c/bffcdade259c05ab3436b5fab711612093c275ef","https://git.kernel.org/stable/c/e2b46cd5796f083e452fbc624f65b80328b0c1a4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48842
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ice: Fix race condition during interface enslave
Commit 5dbbbd01cbba83 ("ice: Avoid RTNL lock when re-creating
auxiliary device") changes a process of re-creation of aux device
so ice_plug_aux_dev() is called from ice_service_task() context.
This unfortunately opens a race window that can result in dead-lock
when interface has left LAG and immediately enters LAG again.
Reproducer:
```
#!/bin/sh
ip link add lag0 type bond mode 1 miimon 100
ip link set lag0
for n in {1..10}; do
echo Cycle: $n
ip link set ens7f0 master lag0
sleep 1
ip link set ens7f0 nomaster
done
```
This results in:
[20976.208697] Workqueue: ice ice_service_task [ice]
[20976.213422] Call Trace:
[20976.215871] __schedule+0x2d1/0x830
[20976.219364] schedule+0x35/0xa0
[20976.222510] schedule_preempt_disabled+0xa/0x10
[20976.227043] __mutex_lock.isra.7+0x310/0x420
[20976.235071] enum_all_gids_of_dev_cb+0x1c/0x100 [ib_core]
[20976.251215] ib_enum_roce_netdev+0xa4/0xe0 [ib_core]
[20976.256192] ib_cache_setup_one+0x33/0xa0 [ib_core]
[20976.261079] ib_register_device+0x40d/0x580 [ib_core]
[20976.266139] irdma_ib_register_device+0x129/0x250 [irdma]
[20976.281409] irdma_probe+0x2c1/0x360 [irdma]
[20976.285691] auxiliary_bus_probe+0x45/0x70
[20976.289790] really_probe+0x1f2/0x480
[20976.298509] driver_probe_device+0x49/0xc0
[20976.302609] bus_for_each_drv+0x79/0xc0
[20976.306448] __device_attach+0xdc/0x160
[20976.310286] bus_probe_device+0x9d/0xb0
[20976.314128] device_add+0x43c/0x890
[20976.321287] __auxiliary_device_add+0x43/0x60
[20976.325644] ice_plug_aux_dev+0xb2/0x100 [ice]
[20976.330109] ice_service_task+0xd0c/0xed0 [ice]
[20976.342591] process_one_work+0x1a7/0x360
[20976.350536] worker_thread+0x30/0x390
[20976.358128] kthread+0x10a/0x120
[20976.365547] ret_from_fork+0x1f/0x40
...
[20976.438030] task:ip state:D stack: 0 pid:213658 ppid:213627 flags:0x00004084
[20976.446469] Call Trace:
[20976.448921] __schedule+0x2d1/0x830
[20976.452414] schedule+0x35/0xa0
[20976.455559] schedule_preempt_disabled+0xa/0x10
[20976.460090] __mutex_lock.isra.7+0x310/0x420
[20976.464364] device_del+0x36/0x3c0
[20976.467772] ice_unplug_aux_dev+0x1a/0x40 [ice]
[20976.472313] ice_lag_event_handler+0x2a2/0x520 [ice]
[20976.477288] notifier_call_chain+0x47/0x70
[20976.481386] __netdev_upper_dev_link+0x18b/0x280
[20976.489845] bond_enslave+0xe05/0x1790 [bonding]
[20976.494475] do_setlink+0x336/0xf50
[20976.502517] __rtnl_newlink+0x529/0x8b0
[20976.543441] rtnl_newlink+0x43/0x60
[20976.546934] rtnetlink_rcv_msg+0x2b1/0x360
[20976.559238] netlink_rcv_skb+0x4c/0x120
[20976.563079] netlink_unicast+0x196/0x230
[20976.567005] netlink_sendmsg+0x204/0x3d0
[20976.570930] sock_sendmsg+0x4c/0x50
[20976.574423] ____sys_sendmsg+0x1eb/0x250
[20976.586807] ___sys_sendmsg+0x7c/0xc0
[20976.606353] __sys_sendmsg+0x57/0xa0
[20976.609930] do_syscall_64+0x5b/0x1a0
[20976.613598] entry_SYSCALL_64_after_hwframe+0x65/0xca
1. Command 'ip link ... set nomaster' causes that ice_plug_aux_dev()
is called from ice_service_task() context, aux device is created
and associated device->lock is taken.
2. Command 'ip link ... set master...' calls ice's notifier under
RTNL lock and that notifier calls ice_unplug_aux_dev(). That
function tries to take aux device->lock but this is already taken
by ice_plug_aux_dev() in step 1
3. Later ice_plug_aux_dev() tries to take RTNL lock but this is already
taken in step 2
4. Dead-lock
The patch fixes this issue by following changes:
- Bit ICE_FLAG_PLUG_AUX_DEV is kept to be set during ice_plug_aux_dev()
call in ice_service_task()
- The bit is checked in ice_clear_rdma_cap() and only if it is not set
then ice_unplug_aux_dev() is called. If it is set (in other words
plugging of aux device was requested and ice_plug_aux_dev() is
potentially running) then the function only clears the
---truncated--- |
["https://git.kernel.org/stable/c/5cb1ebdbc4342b1c2ce89516e19808d64417bdbc","https://git.kernel.org/stable/c/a9bbacc53d1f5ed8febbfdf31401d20e005f49ef","https://git.kernel.org/stable/c/e1014fc5572375658fa421531cedb6e084f477dc","https://git.kernel.org/stable/c/5cb1ebdbc4342b1c2ce89516e19808d64417bdbc","https://git.kernel.org/stable/c/a9bbacc53d1f5ed8febbfdf31401d20e005f49ef","https://git.kernel.org/stable/c/e1014fc5572375658fa421531cedb6e084f477dc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53210
|
Medium |
fixed |
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()
Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount
(skb->users) and iucv_sock_recvmsg() does not decrement skb refcount
at exit.
This results in skb memory leak in skb_queue_purge() and WARN_ON in
iucv_sock_destruct() during socket close. To fix this decrease
skb refcount by one if MSG_PEEK is set in order to prevent memory
leak and WARN_ON.
WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv]
CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1
Hardware name: IBM 3931 A01 704 (z/VM 7.3.0)
Call Trace:
[<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv]
[<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv]
[<001587c704117a32>] __sk_destruct+0x52/0x550
[<001587c704104a54>] __sock_release+0xa4/0x230
[<001587c704104c0c>] sock_close+0x2c/0x40
[<001587c702c5f5a8>] __fput+0x2e8/0x970
[<001587c7024148c4>] task_work_run+0x1c4/0x2c0
[<001587c7023b0716>] do_exit+0x996/0x1050
[<001587c7023b13aa>] do_group_exit+0x13a/0x360
[<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60
[<001587c7022bccca>] do_syscall+0x27a/0x380
[<001587c7049a6a0c>] __do_syscall+0x9c/0x160
[<001587c7049ce8a8>] system_call+0x70/0x98
Last Breaking-Event-Address:
[<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 [af_iucv] |
["https://git.kernel.org/stable/c/42251c2d1ef1cb0822638bebb87ad9120c759673","https://git.kernel.org/stable/c/783c2c6e61c5a04eb8baea598753d5fa174dbe85","https://git.kernel.org/stable/c/934326aef7ac4652f81c69d18bf44eebaefc39c3","https://git.kernel.org/stable/c/9f603e66e1c59c1d25e60eb0636cb307d190782e","https://git.kernel.org/stable/c/ebaf81317e42aa990ad20b113cfe3a7b20d4e937"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56588
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: hisi_sas: Create all dump files during debugfs initialization
For the current debugfs of hisi_sas, after user triggers dump, the
driver allocate memory space to save the register information and create
debugfs files to display the saved information. In this process, the
debugfs files created after each dump.
Therefore, when the dump is triggered while the driver is unbind, the
following hang occurs:
[67840.853907] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0
[67840.862947] Mem abort info:
[67840.865855] ESR = 0x0000000096000004
[67840.869713] EC = 0x25: DABT (current EL), IL = 32 bits
[67840.875125] SET = 0, FnV = 0
[67840.878291] EA = 0, S1PTW = 0
[67840.881545] FSC = 0x04: level 0 translation fault
[67840.886528] Data abort info:
[67840.889524] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[67840.895117] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[67840.900284] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[67840.905709] user pgtable: 4k pages, 48-bit VAs, pgdp=0000002803a1f000
[67840.912263] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000
[67840.919177] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
[67840.996435] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[67841.003628] pc : down_write+0x30/0x98
[67841.007546] lr : start_creating.part.0+0x60/0x198
[67841.012495] sp : ffff8000b979ba20
[67841.016046] x29: ffff8000b979ba20 x28: 0000000000000010 x27: 0000000000024b40
[67841.023412] x26: 0000000000000012 x25: ffff20202b355ae8 x24: ffff20202b35a8c8
[67841.030779] x23: ffffa36877928208 x22: ffffa368b4972240 x21: ffff8000b979bb18
[67841.038147] x20: ffff00281dc1e3c0 x19: fffffffffffffffe x18: 0000000000000020
[67841.045515] x17: 0000000000000000 x16: ffffa368b128a530 x15: ffffffffffffffff
[67841.052888] x14: ffff8000b979bc18 x13: ffffffffffffffff x12: ffff8000b979bb18
[67841.060263] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa368b1289b18
[67841.067640] x8 : 0000000000000012 x7 : 0000000000000000 x6 : 00000000000003a9
[67841.075014] x5 : 0000000000000000 x4 : ffff002818c5cb00 x3 : 0000000000000001
[67841.082388] x2 : 0000000000000000 x1 : ffff002818c5cb00 x0 : 00000000000000a0
[67841.089759] Call trace:
[67841.092456] down_write+0x30/0x98
[67841.096017] start_creating.part.0+0x60/0x198
[67841.100613] debugfs_create_dir+0x48/0x1f8
[67841.104950] debugfs_create_files_v3_hw+0x88/0x348 [hisi_sas_v3_hw]
[67841.111447] debugfs_snapshot_regs_v3_hw+0x708/0x798 [hisi_sas_v3_hw]
[67841.118111] debugfs_trigger_dump_v3_hw_write+0x9c/0x120 [hisi_sas_v3_hw]
[67841.125115] full_proxy_write+0x68/0xc8
[67841.129175] vfs_write+0xd8/0x3f0
[67841.132708] ksys_write+0x70/0x108
[67841.136317] __arm64_sys_write+0x24/0x38
[67841.140440] invoke_syscall+0x50/0x128
[67841.144385] el0_svc_common.constprop.0+0xc8/0xf0
[67841.149273] do_el0_svc+0x24/0x38
[67841.152773] el0_svc+0x38/0xd8
[67841.156009] el0t_64_sync_handler+0xc0/0xc8
[67841.160361] el0t_64_sync+0x1a4/0x1a8
[67841.164189] Code: b9000882 d2800002 d2800023 f9800011 (c85ffc05)
[67841.170443] ---[ end trace 0000000000000000 ]---
To fix this issue, create all directories and files during debugfs
initialization. In this way, the driver only needs to allocate memory
space to save information each time the user triggers dumping. |
["https://git.kernel.org/stable/c/6c55f99123075e5429850b41b06f7dfffcb708eb","https://git.kernel.org/stable/c/7c8c50c9855a9e1b0d1e3680e5ad839002a9deb5","https://git.kernel.org/stable/c/9f564f15f88490b484e02442dc4c4b11640ea172"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48955
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: thunderbolt: fix memory leak in tbnet_open()
When tb_ring_alloc_rx() failed in tbnet_open(), ida that allocated in
tb_xdomain_alloc_out_hopid() is not released. Add
tb_xdomain_release_out_hopid() to the error path to release ida. |
["https://git.kernel.org/stable/c/b9274dbe399952a8175db2e1ee148b7c9ba2b538","https://git.kernel.org/stable/c/ed14e5903638f6eb868e3e2b4e610985e6a6c876","https://git.kernel.org/stable/c/ed6e955f3b7e0e622c080f4bcb5427a5e1af4c2a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48957
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
dpaa2-switch: Fix memory leak in dpaa2_switch_acl_entry_add() and dpaa2_switch_acl_entry_remove()
The cmd_buff needs to be freed when error happened in
dpaa2_switch_acl_entry_add() and dpaa2_switch_acl_entry_remove(). |
["https://git.kernel.org/stable/c/4fad22a1281c500f15b172c9d261eff347ca634b","https://git.kernel.org/stable/c/54d830e24247fa8361b016dd2069362866f45cb6","https://git.kernel.org/stable/c/785ee7a82297e1512d9061aae91699212ed65796"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48965
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
gpio/rockchip: fix refcount leak in rockchip_gpiolib_register()
The node returned by of_get_parent() with refcount incremented,
of_node_put() needs be called when finish using it. So add it in the
end of of_pinctrl_get(). |
["https://git.kernel.org/stable/c/033c79b7ee8a7bf1c1a13ac3addc91184425cbae","https://git.kernel.org/stable/c/5cb8f1a784fd6115be58282fe15105572319d8be","https://git.kernel.org/stable/c/63ff545af73f759d1bd04198af8ed8577fb739fc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48968
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: Fix potential memory leak in otx2_init_tc()
In otx2_init_tc(), if rhashtable_init() failed, it does not free
tc->tc_entries_bitmap which is allocated in otx2_tc_alloc_ent_bitmap(). |
["https://git.kernel.org/stable/c/db5ec358cf4ef0ab382ee733d05f018e8bef9462","https://git.kernel.org/stable/c/eefd8953a74822cb72006632b9ee9dd95f92c146","https://git.kernel.org/stable/c/fbf33f5ac76f2cdb47ad9763f620026d5cfa57ce"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53161
|
Medium |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
EDAC/bluefield: Fix potential integer overflow
The 64-bit argument for the "get DIMM info" SMC call consists of mem_ctrl_idx
left-shifted 16 bits and OR-ed with DIMM index. With mem_ctrl_idx defined as
32-bits wide the left-shift operation truncates the upper 16 bits of
information during the calculation of the SMC argument.
The mem_ctrl_idx stack variable must be defined as 64-bits wide to prevent any
potential integer overflow, i.e. loss of data from upper 16 bits. |
["https://git.kernel.org/stable/c/000930193fe5eb79ce5563ee2e9ddb0c6e4e1bb5","https://git.kernel.org/stable/c/1fe774a93b46bb029b8f6fa9d1f25affa53f06c6","https://git.kernel.org/stable/c/4ad7033de109d0fec99086f352f58a3412e378b8","https://git.kernel.org/stable/c/578ca89b04680145d41011e7cec8806fefbb59e7","https://git.kernel.org/stable/c/8cc31cfa36ff37aff399b72faa2ded58110112ae","https://git.kernel.org/stable/c/ac6ebb9edcdb7077e841862c402697c4c48a7c0a","https://git.kernel.org/stable/c/e0269ea7a628fdeddd65b92fe29c09655dbb80b9","https://git.kernel.org/stable/c/fdb90006184aa84c7b4e09144ed0936d4e1891a7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53180
|
Medium |
fixed |
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: Add sanity NULL check for the default mmap fault handler
A driver might allow the mmap access before initializing its
runtime->dma_area properly. Add a proper NULL check before passing to
virt_to_page() for avoiding a panic. |
["https://git.kernel.org/stable/c/0c4c9bf5eab7bee6b606f2abb0993e933b5831a0","https://git.kernel.org/stable/c/832efbb74b1578e3737d593a204d42af8bd1b81b","https://git.kernel.org/stable/c/8799f4332a9fd812eadfbc32fc5104d6292f754f","https://git.kernel.org/stable/c/bc200027ee92fba84f1826494735ed675f3aa911","https://git.kernel.org/stable/c/d2913a07d9037fe7aed4b7e680684163eaed6bc4","https://git.kernel.org/stable/c/f0ce9e24eff1678c16276f9717f26a78202506a2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53215
|
Medium |
fixed |
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init()
There's issue as follows:
RPC: Registered rdma transport module.
RPC: Registered rdma backchannel transport module.
RPC: Unregistered rdma transport module.
RPC: Unregistered rdma backchannel transport module.
BUG: unable to handle page fault for address: fffffbfff80c609a
PGD 123fee067 P4D 123fee067 PUD 123fea067 PMD 10c624067 PTE 0
Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI
RIP: 0010:percpu_counter_destroy_many+0xf7/0x2a0
Call Trace:
<TASK>
__die+0x1f/0x70
page_fault_oops+0x2cd/0x860
spurious_kernel_fault+0x36/0x450
do_kern_addr_fault+0xca/0x100
exc_page_fault+0x128/0x150
asm_exc_page_fault+0x26/0x30
percpu_counter_destroy_many+0xf7/0x2a0
mmdrop+0x209/0x350
finish_task_switch.isra.0+0x481/0x840
schedule_tail+0xe/0xd0
ret_from_fork+0x23/0x80
ret_from_fork_asm+0x1a/0x30
</TASK>
If register_sysctl() return NULL, then svc_rdma_proc_cleanup() will not
destroy the percpu counters which init in svc_rdma_proc_init().
If CONFIG_HOTPLUG_CPU is enabled, residual nodes may be in the
'percpu_counters' list. The above issue may occur once the module is
removed. If the CONFIG_HOTPLUG_CPU configuration is not enabled, memory
leakage occurs.
To solve above issue just destroy all percpu counters when
register_sysctl() return NULL. |
["https://git.kernel.org/stable/c/1c9a99c89e45b22eb556fd2f3f729f2683f247d5","https://git.kernel.org/stable/c/20322edcbad82a60321a8615a99ca73a9611115f","https://git.kernel.org/stable/c/94d2d6d398706ab7218a26d61e12919c4b498e09","https://git.kernel.org/stable/c/a12c897adf40b6e2b4a56e6912380c31bd7b2479","https://git.kernel.org/stable/c/ce89e742a4c12b20f09a43fec1b21db33f2166cd","https://git.kernel.org/stable/c/ebf47215d46992caea660ec01cd618005d9e687a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56567
|
Medium |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.12.4
|
In the Linux kernel, the following vulnerability has been resolved:
ad7780: fix division by zero in ad7780_write_raw()
In the ad7780_write_raw() , val2 can be zero, which might lead to a
division by zero error in DIV_ROUND_CLOSEST(). The ad7780_write_raw()
is based on iio_info's write_raw. While val is explicitly declared that
can be zero (in read mode), val2 is not specified to be non-zero. |
["https://git.kernel.org/stable/c/022e13518ba6cc1b4fdd291f49e4f57b2d5718e0","https://git.kernel.org/stable/c/18fb33df1de83a014d7f784089f9b124facc157f","https://git.kernel.org/stable/c/68e79b848196a0b0ec006009cc69da1f835d1ae8","https://git.kernel.org/stable/c/7e3a8ea3d1ada7f707de5d9d504774b4191eab66","https://git.kernel.org/stable/c/afc1e3c00b3f5f0b4f1bc3e974fb9803cb938a90","https://git.kernel.org/stable/c/c174b53e95adf2eece2afc56cd9798374919f99a","https://git.kernel.org/stable/c/f25a9f1df1f6738acf1fa05595fb6060a2c08ff1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56569
|
Medium |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.12.4
|
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix regression with module command in stack_trace_filter
When executing the following command:
# echo "write*:mod:ext3" > /sys/kernel/tracing/stack_trace_filter
The current mod command causes a null pointer dereference. While commit
0f17976568b3f ("ftrace: Fix regression with module command in stack_trace_filter")
has addressed part of the issue, it left a corner case unhandled, which still
results in a kernel crash. |
["https://git.kernel.org/stable/c/19cacabdd5a8487ae566cbecb4d03bcb038a067e","https://git.kernel.org/stable/c/43ca32ce12888fb0eeb2d74dfc558dea60d3473e","https://git.kernel.org/stable/c/45af52e7d3b8560f21d139b3759735eead8b1653","https://git.kernel.org/stable/c/5dabb7af57bc72308a6e2e81a5dd756eef283803","https://git.kernel.org/stable/c/7ae27880de3482e063fcc1f72d9a298d0d391407","https://git.kernel.org/stable/c/885109aa0c70639527dd6a65c82e63c9ac055e3d","https://git.kernel.org/stable/c/8a92dc4df89c50bdb26667419ea70e0abbce456e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56574
|
Medium |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.12.4
|
In the Linux kernel, the following vulnerability has been resolved:
media: ts2020: fix null-ptr-deref in ts2020_probe()
KASAN reported a null-ptr-deref issue when executing the following
command:
# echo ts2020 0x20 > /sys/bus/i2c/devices/i2c-0/new_device
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)
RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020]
RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809
RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010
RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6
R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790
R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001
FS: 00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
ts2020_probe+0xad/0xe10 [ts2020]
i2c_device_probe+0x421/0xb40
really_probe+0x266/0x850
...
The cause of the problem is that when using sysfs to dynamically register
an i2c device, there is no platform data, but the probe process of ts2020
needs to use platform data, resulting in a null pointer being accessed.
Solve this problem by adding checks to platform data. |
["https://git.kernel.org/stable/c/4a058b34b52ed3feb1f3ff6fd26aefeeeed20cba","https://git.kernel.org/stable/c/5a53f97cd5977911850b695add057f9965c1a2d6","https://git.kernel.org/stable/c/901070571bc191d1d8d7a1379bc5ba9446200999","https://git.kernel.org/stable/c/a2ed3b780f34e4a6403064208bc2c99d1ed85026","https://git.kernel.org/stable/c/b6208d1567f929105011bcdfd738f59a6bdc1088","https://git.kernel.org/stable/c/ced1c04e82e3ecc246b921b9733f0df0866aa50d","https://git.kernel.org/stable/c/dc03866b5f4aa2668946f8384a1e5286ae53bbaa"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56587
|
Medium |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
leds: class: Protect brightness_show() with led_cdev->led_access mutex
There is NULL pointer issue observed if from Process A where hid device
being added which results in adding a led_cdev addition and later a
another call to access of led_cdev attribute from Process B can result
in NULL pointer issue.
Use mutex led_cdev->led_access to protect access to led->cdev and its
attribute inside brightness_show() and max_brightness_show() and also
update the comment for mutex that it should be used to protect the led
class device fields.
Process A Process B
kthread+0x114
worker_thread+0x244
process_scheduled_works+0x248
uhid_device_add_worker+0x24
hid_add_device+0x120
device_add+0x268
bus_probe_device+0x94
device_initial_probe+0x14
__device_attach+0xfc
bus_for_each_drv+0x10c
__device_attach_driver+0x14c
driver_probe_device+0x3c
__driver_probe_device+0xa0
really_probe+0x190
hid_device_probe+0x130
ps_probe+0x990
ps_led_register+0x94
devm_led_classdev_register_ext+0x58
led_classdev_register_ext+0x1f8
device_create_with_groups+0x48
device_create_groups_vargs+0xc8
device_add+0x244
kobject_uevent+0x14
kobject_uevent_env[jt]+0x224
mutex_unlock[jt]+0xc4
__mutex_unlock_slowpath+0xd4
wake_up_q+0x70
try_to_wake_up[jt]+0x48c
preempt_schedule_common+0x28
__schedule+0x628
__switch_to+0x174
el0t_64_sync+0x1a8/0x1ac
el0t_64_sync_handler+0x68/0xbc
el0_svc+0x38/0x68
do_el0_svc+0x1c/0x28
el0_svc_common+0x80/0xe0
invoke_syscall+0x58/0x114
__arm64_sys_read+0x1c/0x2c
ksys_read+0x78/0xe8
vfs_read+0x1e0/0x2c8
kernfs_fop_read_iter+0x68/0x1b4
seq_read_iter+0x158/0x4ec
kernfs_seq_show+0x44/0x54
sysfs_kf_seq_show+0xb4/0x130
dev_attr_show+0x38/0x74
brightness_show+0x20/0x4c
dualshock4_led_get_brightness+0xc/0x74
[ 3313.874295][ T4013] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060
[ 3313.874301][ T4013] Mem abort info:
[ 3313.874303][ T4013] ESR = 0x0000000096000006
[ 3313.874305][ T4013] EC = 0x25: DABT (current EL), IL = 32 bits
[ 3313.874307][ T4013] SET = 0, FnV = 0
[ 3313.874309][ T4013] EA = 0, S1PTW = 0
[ 3313.874311][ T4013] FSC = 0x06: level 2 translation fault
[ 3313.874313][ T4013] Data abort info:
[ 3313.874314][ T4013] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
[ 3313.874316][ T4013] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 3313.874318][ T4013] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 3313.874320][ T4013] user pgtable: 4k pages, 39-bit VAs, pgdp=00000008f2b0a000
..
[ 3313.874332][ T4013] Dumping ftrace buffer:
[ 3313.874334][ T4013] (ftrace buffer empty)
..
..
[ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader
[ 3313.874648][ T4013] pc : dualshock4_led_get_brightness+0xc/0x74
[ 3313.874653][ T4013] lr : led_update_brightness+0x38/0x60
[ 3313.874656][ T4013] sp : ffffffc0b910bbd0
..
..
[ 3313.874685][ T4013] Call trace:
[ 3313.874687][ T4013] dualshock4_led_get_brightness+0xc/0x74
[ 3313.874690][ T4013] brightness_show+0x20/0x4c
[ 3313.874692][ T4013] dev_attr_show+0x38/0x74
[ 3313.874696][ T4013] sysfs_kf_seq_show+0xb4/0x130
[ 3313.874700][ T4013] kernfs_seq_show+0x44/0x54
[ 3313.874703][ T4013] seq_read_iter+0x158/0x4ec
[ 3313.874705][ T4013] kernfs_fop_read_iter+0x68/0x1b4
[ 3313.874708][ T4013] vfs_read+0x1e0/0x2c8
[ 3313.874711][ T4013] ksys_read+0x78/0xe8
[ 3313.874714][ T4013] __arm64_sys_read+0x1c/0x2c
[ 3313.874718][ T4013] invoke_syscall+0x58/0x114
[ 3313.874721][ T4013] el0_svc_common+0x80/0xe0
[ 3313.874724][ T4013] do_el0_svc+0x1c/0x28
[ 3313.874727][ T4013] el0_svc+0x38/0x68
[ 3313.874730][ T4013] el0t_64_sync_handler+0x68/0xbc
[ 3313.874732][ T4013] el0t_64_sync+0x1a8/0x1ac |
["https://git.kernel.org/stable/c/4ca7cd938725a4050dcd62ae9472e931d603118d","https://git.kernel.org/stable/c/50d9f68e4adf86901cbab1bd5b91f710aa9141b9","https://git.kernel.org/stable/c/84b42d5b5fcd767c9b7f30b0b32065ed949fe804","https://git.kernel.org/stable/c/b8283d52ed15c02bb2eb9b1b8644dcc34f8e98f1","https://git.kernel.org/stable/c/bb4a6236a430cfc3713f470f3a969f39d6d4ca25","https://git.kernel.org/stable/c/ddcfc5708da9972ac23a9121b3d819b0a53d6f21","https://git.kernel.org/stable/c/f6d6fb563e4be245a17bc4261a4b294e8bf8a31e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56593
|
Medium |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()
This patch fixes a NULL pointer dereference bug in brcmfmac that occurs
when a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBs
are sent from the pkt queue.
The problem is the number of entries in the pre-allocated sgtable, it is
nents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) >> 4 + 1.
Given the default [rt]xglom_size=32 it's actually 35 which is too small.
Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKB
is added for each original SKB if tailroom isn't enough to hold tail_pad.
At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop"
in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next return
NULL and this causes the oops.
The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handle
the worst-case.
Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464
additional bytes of memory. |
["https://git.kernel.org/stable/c/07c020c6d14d29e5a3ea4e4576b8ecf956a80834","https://git.kernel.org/stable/c/342f87d263462c2670b77ea9a32074cab2ac6fa1","https://git.kernel.org/stable/c/34941321b516bd7c6103bd01287d71a1804d19d3","https://git.kernel.org/stable/c/67a25ea28f8ec1da8894f2f115d01d3becf67dc7","https://git.kernel.org/stable/c/7522d7d745d13fbeff3350fe6aa56c8dae263571","https://git.kernel.org/stable/c/857282b819cbaa0675aaab1e7542e2c0579f52d7","https://git.kernel.org/stable/c/dfb3f9d3f602602de208da7bdcc0f6d5ee74af68"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56629
|
Medium |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
HID: wacom: fix when get product name maybe null pointer
Due to incorrect dev->product reporting by certain devices, null
pointer dereferences occur when dev->product is empty, leading to
potential system crashes.
This issue was found on EXCELSIOR DL37-D05 device with
Loongson-LS3A6000-7A2000-DL37 motherboard.
Kernel logs:
[ 56.470885] usb 4-3: new full-speed USB device number 4 using ohci-pci
[ 56.671638] usb 4-3: string descriptor 0 read error: -22
[ 56.671644] usb 4-3: New USB device found, idVendor=056a, idProduct=0374, bcdDevice= 1.07
[ 56.671647] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 56.678839] hid-generic 0003:056A:0374.0004: hiddev0,hidraw3: USB HID v1.10 Device [HID 056a:0374] on usb-0000:00:05.0-3/input0
[ 56.697719] CPU 2 Unable to handle kernel paging request at virtual address 0000000000000000, era == 90000000066e35c8, ra == ffff800004f98a80
[ 56.697732] Oops[#1]:
[ 56.697734] CPU: 2 PID: 2742 Comm: (udev-worker) Tainted: G OE 6.6.0-loong64-desktop #25.00.2000.015
[ 56.697737] Hardware name: Inspur CE520L2/C09901N000000000, BIOS 2.09.00 10/11/2024
[ 56.697739] pc 90000000066e35c8 ra ffff800004f98a80 tp 9000000125478000 sp 900000012547b8a0
[ 56.697741] a0 0000000000000000 a1 ffff800004818b28 a2 0000000000000000 a3 0000000000000000
[ 56.697743] a4 900000012547b8f0 a5 0000000000000000 a6 0000000000000000 a7 0000000000000000
[ 56.697745] t0 ffff800004818b2d t1 0000000000000000 t2 0000000000000003 t3 0000000000000005
[ 56.697747] t4 0000000000000000 t5 0000000000000000 t6 0000000000000000 t7 0000000000000000
[ 56.697748] t8 0000000000000000 u0 0000000000000000 s9 0000000000000000 s0 900000011aa48028
[ 56.697750] s1 0000000000000000 s2 0000000000000000 s3 ffff800004818e80 s4 ffff800004810000
[ 56.697751] s5 90000001000b98d0 s6 ffff800004811f88 s7 ffff800005470440 s8 0000000000000000
[ 56.697753] ra: ffff800004f98a80 wacom_update_name+0xe0/0x300 [wacom]
[ 56.697802] ERA: 90000000066e35c8 strstr+0x28/0x120
[ 56.697806] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
[ 56.697816] PRMD: 0000000c (PPLV0 +PIE +PWE)
[ 56.697821] EUEN: 00000000 (-FPE -SXE -ASXE -BTE)
[ 56.697827] ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
[ 56.697831] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
[ 56.697835] BADV: 0000000000000000
[ 56.697836] PRID: 0014d000 (Loongson-64bit, Loongson-3A6000)
[ 56.697838] Modules linked in: wacom(+) bnep bluetooth rfkill qrtr nls_iso8859_1 nls_cp437 snd_hda_codec_conexant snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore input_leds mousedev led_class joydev deepin_netmonitor(OE) fuse nfnetlink dmi_sysfs ip_tables x_tables overlay amdgpu amdxcp drm_exec gpu_sched drm_buddy radeon drm_suballoc_helper i2c_algo_bit drm_ttm_helper r8169 ttm drm_display_helper spi_loongson_pci xhci_pci cec xhci_pci_renesas spi_loongson_core hid_generic realtek gpio_loongson_64bit
[ 56.697887] Process (udev-worker) (pid: 2742, threadinfo=00000000aee0d8b4, task=00000000a9eff1f3)
[ 56.697890] Stack : 0000000000000000 ffff800004817e00 0000000000000000 0000251c00000000
[ 56.697896] 0000000000000000 00000011fffffffd 0000000000000000 0000000000000000
[ 56.697901] 0000000000000000 1b67a968695184b9 0000000000000000 90000001000b98d0
[ 56.697906] 90000001000bb8d0 900000011aa48028 0000000000000000 ffff800004f9d74c
[ 56.697911] 90000001000ba000 ffff800004f9ce58 0000000000000000 ffff800005470440
[ 56.697916] ffff800004811f88 90000001000b98d0 9000000100da2aa8 90000001000bb8d0
[ 56.697921] 0000000000000000 90000001000ba000 900000011aa48028 ffff800004f9d74c
[ 56.697926] ffff8000054704e8 90000001000bb8b8 90000001000ba000 0000000000000000
[ 56.697931] 90000001000bb8d0
---truncated--- |
["https://git.kernel.org/stable/c/2cd323c55bd3f356bf23ae1b4c20100abcdc29d6","https://git.kernel.org/stable/c/2ed3e3a3ac06af8a6391c3d6a7791b7967d7d43a","https://git.kernel.org/stable/c/5912a921289edb34d40aeab32ea6d52d41e75fed","https://git.kernel.org/stable/c/59548215b76be98cf3422eea9a67d6ea578aca3d","https://git.kernel.org/stable/c/a7f0509556fa2f9789639dbcee9eed46e471ccef","https://git.kernel.org/stable/c/d031eef3cc2e3bf524509e38fb898e5335c85c96","https://git.kernel.org/stable/c/e689bc6697a7fcebd4a945ab0b1e1112c76024d8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56648
|
Medium |
fixed |
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
net: hsr: avoid potential out-of-bound access in fill_frame_info()
syzbot is able to feed a packet with 14 bytes, pretending
it is a vlan one.
Since fill_frame_info() is relying on skb->mac_len already,
extend the check to cover this case.
BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline]
BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724
fill_frame_info net/hsr/hsr_forward.c:709 [inline]
hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724
hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235
__netdev_start_xmit include/linux/netdevice.h:5002 [inline]
netdev_start_xmit include/linux/netdevice.h:5011 [inline]
xmit_one net/core/dev.c:3590 [inline]
dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606
__dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434
dev_queue_xmit include/linux/netdevice.h:3168 [inline]
packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276
packet_snd net/packet/af_packet.c:3146 [inline]
packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178
sock_sendmsg_nosec net/socket.c:711 [inline]
__sock_sendmsg+0x30f/0x380 net/socket.c:726
__sys_sendto+0x594/0x750 net/socket.c:2197
__do_sys_sendto net/socket.c:2204 [inline]
__se_sys_sendto net/socket.c:2200 [inline]
__x64_sys_sendto+0x125/0x1d0 net/socket.c:2200
x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at:
slab_post_alloc_hook mm/slub.c:4091 [inline]
slab_alloc_node mm/slub.c:4134 [inline]
kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587
__alloc_skb+0x363/0x7b0 net/core/skbuff.c:678
alloc_skb include/linux/skbuff.h:1323 [inline]
alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612
sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881
packet_alloc_skb net/packet/af_packet.c:2995 [inline]
packet_snd net/packet/af_packet.c:3089 [inline]
packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178
sock_sendmsg_nosec net/socket.c:711 [inline]
__sock_sendmsg+0x30f/0x380 net/socket.c:726
__sys_sendto+0x594/0x750 net/socket.c:2197
__do_sys_sendto net/socket.c:2204 [inline]
__se_sys_sendto net/socket.c:2200 [inline]
__x64_sys_sendto+0x125/0x1d0 net/socket.c:2200
x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f |
["https://git.kernel.org/stable/c/3c215663b3e27a3b08cefcaea623ff54c70c8035","https://git.kernel.org/stable/c/6bb5c8ebc99f0671dbd3c9408ebaf935c3951186","https://git.kernel.org/stable/c/7ea527fbd7b94d0bee64a0a7e98279bcc654b322","https://git.kernel.org/stable/c/aa632691c722a123e47ccd05a3afdd5f87a36061","https://git.kernel.org/stable/c/b9653d19e556c6afd035602927a93d100a0d7644","https://git.kernel.org/stable/c/c6e778901d0055356c4fb223058364cae731494a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56659
|
Medium |
fixed |
- 5.4.288
- 5.10.232
- 5.15.175
- 6.1.121
- 6.6.67
- 6.12.6
|
In the Linux kernel, the following vulnerability has been resolved:
net: lapb: increase LAPB_HEADER_LEN
It is unclear if net/lapb code is supposed to be ready for 8021q.
We can at least avoid crashes like the following :
skbuff: skb_under_panic: text:ffffffff8aabe1f6 len:24 put:20 head:ffff88802824a400 data:ffff88802824a3fe tail:0x16 end:0x140 dev:nr0.2
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:206 !
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 1 UID: 0 PID: 5508 Comm: dhcpcd Not tainted 6.12.0-rc7-syzkaller-00144-g66418447d27b #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024
RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]
RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216
Code: 0d 8d 48 c7 c6 2e 9e 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 1a 6f 37 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3
RSP: 0018:ffffc90002ddf638 EFLAGS: 00010282
RAX: 0000000000000086 RBX: dffffc0000000000 RCX: 7a24750e538ff600
RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000
RBP: ffff888034a86650 R08: ffffffff8174b13c R09: 1ffff920005bbe60
R10: dffffc0000000000 R11: fffff520005bbe61 R12: 0000000000000140
R13: ffff88802824a400 R14: ffff88802824a3fe R15: 0000000000000016
FS: 00007f2a5990d740(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000110c2631fd CR3: 0000000029504000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
skb_push+0xe5/0x100 net/core/skbuff.c:2636
nr_header+0x36/0x320 net/netrom/nr_dev.c:69
dev_hard_header include/linux/netdevice.h:3148 [inline]
vlan_dev_hard_header+0x359/0x480 net/8021q/vlan_dev.c:83
dev_hard_header include/linux/netdevice.h:3148 [inline]
lapbeth_data_transmit+0x1f6/0x2a0 drivers/net/wan/lapbether.c:257
lapb_data_transmit+0x91/0xb0 net/lapb/lapb_iface.c:447
lapb_transmit_buffer+0x168/0x1f0 net/lapb/lapb_out.c:149
lapb_establish_data_link+0x84/0xd0
lapb_device_event+0x4e0/0x670
notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93
__dev_notify_flags+0x207/0x400
dev_change_flags+0xf0/0x1a0 net/core/dev.c:8922
devinet_ioctl+0xa4e/0x1aa0 net/ipv4/devinet.c:1188
inet_ioctl+0x3d7/0x4f0 net/ipv4/af_inet.c:1003
sock_do_ioctl+0x158/0x460 net/socket.c:1227
sock_ioctl+0x626/0x8e0 net/socket.c:1346
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 |
["https://git.kernel.org/stable/c/03e661b5e7aa1124f24054df9ab2ee5cb2178973","https://git.kernel.org/stable/c/2b351355bbd50ae25d096785b6eb31998d2bf765","https://git.kernel.org/stable/c/3aa2ef7ffd0451e8f81c249d2a2a68283c6bc700","https://git.kernel.org/stable/c/76d856f03d0290cf5392364ecdf74c15ee16b8fd","https://git.kernel.org/stable/c/a6d75ecee2bf828ac6a1b52724aba0a977e4eaf4","https://git.kernel.org/stable/c/c21c7c1c00bcc60cf752ec491bdfd47693f4d3c7","https://git.kernel.org/stable/c/f0949199651bc87c5ed2c12a7323f441f1af6fe9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56670
|
Medium |
fixed |
- 5.4.288
- 5.10.232
- 5.15.175
- 6.1.121
- 6.6.67
- 6.12.6
|
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointer
Considering that in some extreme cases,
when u_serial driver is accessed by multiple threads,
Thread A is executing the open operation and calling the gs_open,
Thread B is executing the disconnect operation and calling the
gserial_disconnect function,The port->port_usb pointer will be set to NULL.
E.g.
Thread A Thread B
gs_open() gadget_unbind_driver()
gs_start_io() composite_disconnect()
gs_start_rx() gserial_disconnect()
... ...
spin_unlock(&port->port_lock)
status = usb_ep_queue() spin_lock(&port->port_lock)
spin_lock(&port->port_lock) port->port_usb = NULL
gs_free_requests(port->port_usb->in) spin_unlock(&port->port_lock)
Crash
This causes thread A to access a null pointer (port->port_usb is null)
when calling the gs_free_requests function, causing a crash.
If port_usb is NULL, the release request will be skipped as it
will be done by gserial_disconnect.
So add a null pointer check to gs_start_io before attempting
to access the value of the pointer port->port_usb.
Call trace:
gs_start_io+0x164/0x25c
gs_open+0x108/0x13c
tty_open+0x314/0x638
chrdev_open+0x1b8/0x258
do_dentry_open+0x2c4/0x700
vfs_open+0x2c/0x3c
path_openat+0xa64/0xc60
do_filp_open+0xb8/0x164
do_sys_openat2+0x84/0xf0
__arm64_sys_openat+0x70/0x9c
invoke_syscall+0x58/0x114
el0_svc_common+0x80/0xe0
do_el0_svc+0x1c/0x28
el0_svc+0x38/0x68 |
["https://git.kernel.org/stable/c/1247e1df086aa6c17ab53cd1bedce70dd7132765","https://git.kernel.org/stable/c/28b3c03a6790de1f6f2683919ad657840f0f0f58","https://git.kernel.org/stable/c/4cfbca86f6a8b801f3254e0e3c8f2b1d2d64be2b","https://git.kernel.org/stable/c/4efdfdc32d8d6307f968cd99f1db64468471bab1","https://git.kernel.org/stable/c/8ca07a3d18f39b1669927ef536e485787e856df6","https://git.kernel.org/stable/c/c83213b6649d22656b3a4e92544ceeea8a2c6c07","https://git.kernel.org/stable/c/dd6b0ca6025f64ccb465a6a3460c5b0307ed9c44"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56720
|
Medium |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Several fixes to bpf_msg_pop_data
Several fixes to bpf_msg_pop_data,
1. In sk_msg_shift_left, we should put_page
2. if (len == 0), return early is better
3. pop the entire sk_msg (last == msg->sg.size) should be supported
4. Fix for the value of variable "a"
5. In sk_msg_shift_left, after shifting, i has already pointed to the next
element. Addtional sk_msg_iter_var_next may result in BUG. |
["https://git.kernel.org/stable/c/275a9f3ef8fabb0cb282a62b9e164dedba7284c5","https://git.kernel.org/stable/c/5d609ba262475db450ba69b8e8a557bd768ac07a","https://git.kernel.org/stable/c/785180bed9879680d8e5c5e1b54c8ae8d948f4c8","https://git.kernel.org/stable/c/98c7ea7d11f2588e8197db042e0291e4ac8f8346","https://git.kernel.org/stable/c/d26d977633d1d0b8bf9407278189bd0a8d973323","https://git.kernel.org/stable/c/d3f5763b3062514a234114e97bbde74d8d702449","https://git.kernel.org/stable/c/e1f54c61c4c9a5244eb8159dce60d248f7d97b32","https://git.kernel.org/stable/c/f58d3aa457e77a3d9b3df2ab081dcf9950f6029f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56723
|
Medium |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices
While design wise the idea of converting the driver to use
the hierarchy of the IRQ chips is correct, the implementation
has (inherited) flaws. This was unveiled when platform_get_irq()
had started WARN() on IRQ 0 that is supposed to be a Linux
IRQ number (also known as vIRQ).
Rework the driver to respect IRQ domain when creating each MFD
device separately, as the domain is not the same for all of them. |
["https://git.kernel.org/stable/c/0350d783ab888cb1cb48ced36cc28b372723f1a4","https://git.kernel.org/stable/c/61d590d7076b50b6ebdea1f3b83bb041c01fc482","https://git.kernel.org/stable/c/6ea17c03edc7ed0aabb1431eb26e2f94849af68a","https://git.kernel.org/stable/c/7ba45b8bc62e64da524d45532107ae93eb33c93c","https://git.kernel.org/stable/c/897713c9d24f6ec394585abfcf259a6e5cad22c8","https://git.kernel.org/stable/c/b3d45c19bcffb9a9a821df759f60be39d88c19f4","https://git.kernel.org/stable/c/bb6642d4b3136359b5b620049f76515876e6127e","https://git.kernel.org/stable/c/d4cc78bd6a25accb7ae2ac9fc445d1e1deda4a62"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56575
|
Medium |
fixed |
- 5.15.174
- 6.1.120
- 6.6.64
- 6.12.4
|
In the Linux kernel, the following vulnerability has been resolved:
media: imx-jpeg: Ensure power suppliers be suspended before detach them
The power suppliers are always requested to suspend asynchronously,
dev_pm_domain_detach() requires the caller to ensure proper
synchronization of this function with power management callbacks.
otherwise the detach may led to kernel panic, like below:
[ 1457.107934] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000040
[ 1457.116777] Mem abort info:
[ 1457.119589] ESR = 0x0000000096000004
[ 1457.123358] EC = 0x25: DABT (current EL), IL = 32 bits
[ 1457.128692] SET = 0, FnV = 0
[ 1457.131764] EA = 0, S1PTW = 0
[ 1457.134920] FSC = 0x04: level 0 translation fault
[ 1457.139812] Data abort info:
[ 1457.142707] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 1457.148196] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 1457.153256] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 1457.158563] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001138b6000
[ 1457.165000] [0000000000000040] pgd=0000000000000000, p4d=0000000000000000
[ 1457.171792] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
[ 1457.178045] Modules linked in: v4l2_jpeg wave6_vpu_ctrl(-) [last unloaded: mxc_jpeg_encdec]
[ 1457.186383] CPU: 0 PID: 51938 Comm: kworker/0:3 Not tainted 6.6.36-gd23d64eea511 #66
[ 1457.194112] Hardware name: NXP i.MX95 19X19 board (DT)
[ 1457.199236] Workqueue: pm pm_runtime_work
[ 1457.203247] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1457.210188] pc : genpd_runtime_suspend+0x20/0x290
[ 1457.214886] lr : __rpm_callback+0x48/0x1d8
[ 1457.218968] sp : ffff80008250bc50
[ 1457.222270] x29: ffff80008250bc50 x28: 0000000000000000 x27: 0000000000000000
[ 1457.229394] x26: 0000000000000000 x25: 0000000000000008 x24: 00000000000f4240
[ 1457.236518] x23: 0000000000000000 x22: ffff00008590f0e4 x21: 0000000000000008
[ 1457.243642] x20: ffff80008099c434 x19: ffff00008590f000 x18: ffffffffffffffff
[ 1457.250766] x17: 5300326563697665 x16: 645f676e696c6f6f x15: 63343a6d726f6674
[ 1457.257890] x14: 0000000000000004 x13: 00000000000003a4 x12: 0000000000000002
[ 1457.265014] x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff80008250bbb0
[ 1457.272138] x8 : ffff000092937200 x7 : ffff0003fdf6af80 x6 : 0000000000000000
[ 1457.279262] x5 : 00000000410fd050 x4 : 0000000000200000 x3 : 0000000000000000
[ 1457.286386] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00008590f000
[ 1457.293510] Call trace:
[ 1457.295946] genpd_runtime_suspend+0x20/0x290
[ 1457.300296] __rpm_callback+0x48/0x1d8
[ 1457.304038] rpm_callback+0x6c/0x78
[ 1457.307515] rpm_suspend+0x10c/0x570
[ 1457.311077] pm_runtime_work+0xc4/0xc8
[ 1457.314813] process_one_work+0x138/0x248
[ 1457.318816] worker_thread+0x320/0x438
[ 1457.322552] kthread+0x110/0x114
[ 1457.325767] ret_from_fork+0x10/0x20 |
["https://git.kernel.org/stable/c/12914fd765ba4f9d6a9a50439e8dd2e9f91423f2","https://git.kernel.org/stable/c/2f86d104539fab9181ea7b5721f40e7b92a8bf67","https://git.kernel.org/stable/c/b7a830bbc25da0f641e3ef2bac3b1766b2777a8b","https://git.kernel.org/stable/c/f3c4e088ec01cae45931a18ddf7cae0f4d72e1c5","https://git.kernel.org/stable/c/fd0af4cd35da0eb550ef682b71cda70a4e36f6b9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56578
|
Medium |
fixed |
- 5.15.174
- 6.1.120
- 6.6.64
- 6.12.4
|
In the Linux kernel, the following vulnerability has been resolved:
media: imx-jpeg: Set video drvdata before register video device
The video drvdata should be set before the video device is registered,
otherwise video_drvdata() may return NULL in the open() file ops, and led
to oops. |
["https://git.kernel.org/stable/c/5ade59d28eade49194eb09765afdeb0ba717c39a","https://git.kernel.org/stable/c/68efeff2f7fccdfedc55f92e92be32997127d16e","https://git.kernel.org/stable/c/b88556e82dc18cb708744d062770853a2d5095b2","https://git.kernel.org/stable/c/d2b7ecc26bd5406d5ba927be1748aa99c568696c","https://git.kernel.org/stable/c/f68bb1210fbea252552d97242757f69a219e942b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56622
|
Medium |
fixed |
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: sysfs: Prevent div by zero
Prevent a division by 0 when monitoring is not enabled. |
["https://git.kernel.org/stable/c/0069928727c2e95ca26c738fbe6e4b241aeaaf08","https://git.kernel.org/stable/c/7b21233e5f72d10f08310689f993c1dbdfde9f2c","https://git.kernel.org/stable/c/87bf3ea841a5d77beae6bb85af36b2b3848407ee","https://git.kernel.org/stable/c/9c191055c7abea4912fdb83cb9b261732b25a0c8","https://git.kernel.org/stable/c/eb48e9fc0028bed94a40a9352d065909f19e333c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56722
|
Medium |
fixed |
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix cpu stuck caused by printings during reset
During reset, cmd to destroy resources such as qp, cq, and mr may fail,
and error logs will be printed. When a large number of resources are
destroyed, there will be lots of printings, and it may lead to a cpu
stuck.
Delete some unnecessary printings and replace other printing functions
in these paths with the ratelimited version. |
["https://git.kernel.org/stable/c/31c6fe9b79ed42440094f2367897aea0c0ce96ec","https://git.kernel.org/stable/c/323275ac2ff15b2b7b3eac391ae5d8c5a3c3a999","https://git.kernel.org/stable/c/a0e4c78770faa0d56d47391476fe1d827e72eded","https://git.kernel.org/stable/c/b4ba31e5aaffbda9b22d9a35c40b16dc39e475a6","https://git.kernel.org/stable/c/e2e64f9c42c717beb459ab209ec1c4baa73d3760"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49970
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Implement bounds check for stream encoder creation in DCN401
'stream_enc_regs' array is an array of dcn10_stream_enc_registers
structures. The array is initialized with four elements, corresponding
to the four calls to stream_enc_regs() in the array initializer. This
means that valid indices for this array are 0, 1, 2, and 3.
The error message 'stream_enc_regs' 4 <= 5 below, is indicating that
there is an attempt to access this array with an index of 5, which is
out of bounds. This could lead to undefined behavior
Here, eng_id is used as an index to access the stream_enc_regs array. If
eng_id is 5, this would result in an out-of-bounds access on the
stream_enc_regs array.
Thus fixing Buffer overflow error in dcn401_stream_encoder_create
Found by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c:1209 dcn401_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5 |
["https://git.kernel.org/stable/c/b219b46ad42df1dea9258788bcfea37181f3ccb2","https://git.kernel.org/stable/c/bdf606810210e8e07a0cdf1af3c467291363b295"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56544
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
udmabuf: change folios array from kmalloc to kvmalloc
When PAGE_SIZE 4096, MAX_PAGE_ORDER 10, 64bit machine,
page_alloc only support 4MB.
If above this, trigger this warn and return NULL.
udmabuf can change size limit, if change it to 3072(3GB), and then alloc
3GB udmabuf, will fail create.
[ 4080.876581] ------------[ cut here ]------------
[ 4080.876843] WARNING: CPU: 3 PID: 2015 at mm/page_alloc.c:4556 __alloc_pages+0x2c8/0x350
[ 4080.878839] RIP: 0010:__alloc_pages+0x2c8/0x350
[ 4080.879470] Call Trace:
[ 4080.879473] <TASK>
[ 4080.879473] ? __alloc_pages+0x2c8/0x350
[ 4080.879475] ? __warn.cold+0x8e/0xe8
[ 4080.880647] ? __alloc_pages+0x2c8/0x350
[ 4080.880909] ? report_bug+0xff/0x140
[ 4080.881175] ? handle_bug+0x3c/0x80
[ 4080.881556] ? exc_invalid_op+0x17/0x70
[ 4080.881559] ? asm_exc_invalid_op+0x1a/0x20
[ 4080.882077] ? udmabuf_create+0x131/0x400
Because MAX_PAGE_ORDER, kmalloc can max alloc 4096 * (1 << 10), 4MB
memory, each array entry is pointer(8byte), so can save 524288 pages(2GB).
Further more, costly order(order 3) may not be guaranteed that it can be
applied for, due to fragmentation.
This patch change udmabuf array use kvmalloc_array, this can fallback
alloc into vmalloc, which can guarantee allocation for any size and does
not affect the performance of kmalloc allocations. |
["https://git.kernel.org/stable/c/1c0844c6184e658064e14c4335885785ad3bf84b","https://git.kernel.org/stable/c/2acc6192aa8570661ed37868c02c03002b1dc290","https://git.kernel.org/stable/c/85bb72397cb63649fe493c96e27e1d0e4ed2ff63"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48982
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix crash when replugging CSR fake controllers
It seems fake CSR 5.0 clones can cause the suspend notifier to be
registered twice causing the following kernel panic:
[ 71.986122] Call Trace:
[ 71.986124] <TASK>
[ 71.986125] blocking_notifier_chain_register+0x33/0x60
[ 71.986130] hci_register_dev+0x316/0x3d0 [bluetooth 99b5497ea3d09708fa1366c1dc03288bf3cca8da]
[ 71.986154] btusb_probe+0x979/0xd85 [btusb e1e0605a4f4c01984a4b9c8ac58c3666ae287477]
[ 71.986159] ? __pm_runtime_set_status+0x1a9/0x300
[ 71.986162] ? ktime_get_mono_fast_ns+0x3e/0x90
[ 71.986167] usb_probe_interface+0xe3/0x2b0
[ 71.986171] really_probe+0xdb/0x380
[ 71.986174] ? pm_runtime_barrier+0x54/0x90
[ 71.986177] __driver_probe_device+0x78/0x170
[ 71.986180] driver_probe_device+0x1f/0x90
[ 71.986183] __device_attach_driver+0x89/0x110
[ 71.986186] ? driver_allows_async_probing+0x70/0x70
[ 71.986189] bus_for_each_drv+0x8c/0xe0
[ 71.986192] __device_attach+0xb2/0x1e0
[ 71.986195] bus_probe_device+0x92/0xb0
[ 71.986198] device_add+0x422/0x9a0
[ 71.986201] ? sysfs_merge_group+0xd4/0x110
[ 71.986205] usb_set_configuration+0x57a/0x820
[ 71.986208] usb_generic_driver_probe+0x4f/0x70
[ 71.986211] usb_probe_device+0x3a/0x110
[ 71.986213] really_probe+0xdb/0x380
[ 71.986216] ? pm_runtime_barrier+0x54/0x90
[ 71.986219] __driver_probe_device+0x78/0x170
[ 71.986221] driver_probe_device+0x1f/0x90
[ 71.986224] __device_attach_driver+0x89/0x110
[ 71.986227] ? driver_allows_async_probing+0x70/0x70
[ 71.986230] bus_for_each_drv+0x8c/0xe0
[ 71.986232] __device_attach+0xb2/0x1e0
[ 71.986235] bus_probe_device+0x92/0xb0
[ 71.986237] device_add+0x422/0x9a0
[ 71.986239] ? _dev_info+0x7d/0x98
[ 71.986242] ? blake2s_update+0x4c/0xc0
[ 71.986246] usb_new_device.cold+0x148/0x36d
[ 71.986250] hub_event+0xa8a/0x1910
[ 71.986255] process_one_work+0x1c4/0x380
[ 71.986259] worker_thread+0x51/0x390
[ 71.986262] ? rescuer_thread+0x3b0/0x3b0
[ 71.986264] kthread+0xdb/0x110
[ 71.986266] ? kthread_complete_and_exit+0x20/0x20
[ 71.986268] ret_from_fork+0x1f/0x30
[ 71.986273] </TASK>
[ 71.986274] ---[ end trace 0000000000000000 ]---
[ 71.986284] btusb: probe of 2-1.6:1.0 failed with error -17 |
["https://git.kernel.org/stable/c/549b46f8130effccf168293270bb3b1d5da529cc","https://git.kernel.org/stable/c/a49894a5ac3656f1a4f0f6b110460060e8026bf8","https://git.kernel.org/stable/c/b5ca338751ad4783ec8d37b5d99c3e37b7813e59","https://git.kernel.org/stable/c/dc8fa6570deadb70c3fb74d7cd8ce38849feaed0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50108
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too
Stuart Hayhurst has found that both at bootup and fullscreen VA-API video
is leading to black screens for around 1 second and kernel WARNING [1] traces
when calling dmub_psr_enable() with Parade 08-01 TCON.
These symptoms all go away with PSR-SU disabled for this TCON, so disable
it for now while DMUB traces [2] from the failure can be analyzed and the failure
state properly root caused.
(cherry picked from commit afb634a6823d8d9db23c5fb04f79c5549349628b) |
["https://git.kernel.org/stable/c/5660bcc4dd533005248577d5042f1c48cce2b443","https://git.kernel.org/stable/c/ba1959f71117b27f3099ee789e0815360b4081dd","https://git.kernel.org/stable/c/c79e0a18e4b301401bb745702830be9041cfbf04","https://git.kernel.org/stable/c/fc6afa07b5e251148fb37600ee06e1a7007178c3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57807
|
Medium |
fixed |
- 5.4.289
- 5.10.233
- 5.15.176
- 6.1.123
- 6.6.69
- 6.12.8
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: megaraid_sas: Fix for a potential deadlock
This fixes a 'possible circular locking dependency detected' warning
CPU0 CPU1
---- ----
lock(&instance->reset_mutex);
lock(&shost->scan_mutex);
lock(&instance->reset_mutex);
lock(&shost->scan_mutex);
Fix this by temporarily releasing the reset_mutex. |
["https://git.kernel.org/stable/c/3c654998a3e8167a58b6c6fede545fe400a4b554","https://git.kernel.org/stable/c/466ca39dbf5d0ba71c16b15c27478a9c7d4022a8","https://git.kernel.org/stable/c/50740f4dc78b41dec7c8e39772619d5ba841ddd7","https://git.kernel.org/stable/c/78afb9bfad00c4aa58a424111d7edbcab9452f2b","https://git.kernel.org/stable/c/edadc693bfcc0f1ea08b8fa041c9361fd042410d","https://git.kernel.org/stable/c/f36d024bd15ed356a80dda3ddc46d0a62aa55815","https://git.kernel.org/stable/c/f50783148ec98a1d38b87422e2ceaf2380b7b606"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-22063
|
Medium |
fixed |
- 5.4.292
- 5.10.236
- 5.15.180
- 6.1.134
- 6.6.87
- 6.12.23
- 6.13.11
- 6.14.2
|
In the Linux kernel, the following vulnerability has been resolved:
netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets
When calling netlbl_conn_setattr(), addr->sa_family is used
to determine the function behavior. If sk is an IPv4 socket,
but the connect function is called with an IPv6 address,
the function calipso_sock_setattr() is triggered.
Inside this function, the following code is executed:
sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL;
Since sk is an IPv4 socket, pinet6 is NULL, leading to a
null pointer dereference.
This patch fixes the issue by checking if inet6_sk(sk)
returns a NULL pointer before accessing pinet6. |
["https://git.kernel.org/stable/c/078aabd567de3d63d37d7673f714e309d369e6e2","https://git.kernel.org/stable/c/172a8a996a337206970467e871dd995ac07640b1","https://git.kernel.org/stable/c/1927d0bcd5b81e80971bf6b8eba267508bd1c78b","https://git.kernel.org/stable/c/1ad9166cab6a0f5c0b10344a97bdf749ae11dcbf","https://git.kernel.org/stable/c/1e38f7a6cdd68377f8a4189b2fbaec14a6dd5152","https://git.kernel.org/stable/c/3ba9cf69de50e8abed32b448616c313baa4c5712","https://git.kernel.org/stable/c/797e5371cf55463b4530bab3fef5f27f7c6657a8","https://git.kernel.org/stable/c/9fe3839588db7519030377b7dee3f165e654f6c5","https://git.kernel.org/stable/c/a7e89541d05b98c79a51c0f95df020f8e82b62ed"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-23136
|
Medium |
fixed |
- 5.4.292
- 5.10.236
- 5.15.180
- 6.1.134
- 6.6.87
- 6.12.23
- 6.13.11
- 6.14.2
|
In the Linux kernel, the following vulnerability has been resolved:
thermal: int340x: Add NULL check for adev
Not all devices have an ACPI companion fwnode, so adev might be NULL.
This is similar to the commit cd2fd6eab480
("platform/x86: int3472: Check for adev == NULL").
Add a check for adev not being set and return -ENODEV in that case to
avoid a possible NULL pointer deref in int3402_thermal_probe().
Note, under the same directory, int3400_thermal_probe() has such a
check.
[ rjw: Subject edit, added Fixes: ] |
["https://git.kernel.org/stable/c/0c49f12c77b77a706fd41370c11910635e491845","https://git.kernel.org/stable/c/2542a3f70e563a9e70e7ded314286535a3321bdb","https://git.kernel.org/stable/c/3155d5261b518776d1b807d9d922669991bbee56","https://git.kernel.org/stable/c/6a810c462f099353e908c70619638884cb82229c","https://git.kernel.org/stable/c/8e8f1ddf4186731649df8bc9646017369eb19186","https://git.kernel.org/stable/c/953d28a4f459fcbde2d08f51aeca19d6b0f179f3","https://git.kernel.org/stable/c/ac2eb7378319e3836cdf3a2c15a0bdf04c50e81d","https://git.kernel.org/stable/c/bc7b5f782d28942dbdfda70df30ce132694a06de","https://git.kernel.org/stable/c/d0d21c8e44216fa9afdb3809edf213f3c0a8c060"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46777
|
Medium |
fixed |
- 4.19.322
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
udf: Avoid excessive partition lengths
Avoid mounting filesystems where the partition would overflow the
32-bits used for block number. Also refuse to mount filesystems where
the partition length is so large we cannot safely index bits in a
block bitmap. |
["https://git.kernel.org/stable/c/0173999123082280cf904bd640015951f194a294","https://git.kernel.org/stable/c/1497a4484cdb2cf6c37960d788fb6ba67567bdb7","https://git.kernel.org/stable/c/2ddf831451357c6da4b64645eb797c93c1c054d1","https://git.kernel.org/stable/c/551966371e17912564bc387fbeb2ac13077c3db1","https://git.kernel.org/stable/c/925fd8ee80d5348a5e965548e5484d164d19221d","https://git.kernel.org/stable/c/a56330761950cb83de1dfb348479f20c56c95f90","https://git.kernel.org/stable/c/c0c23130d38e8bc28e9ef581443de9b1fc749966","https://git.kernel.org/stable/c/ebbe26fd54a9621994bc16b14f2ba8f84c089693"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53221
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix null-ptr-deref in f2fs_submit_page_bio()
There's issue as follows when concurrently installing the f2fs.ko
module and mounting the f2fs file system:
KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
RIP: 0010:__bio_alloc+0x2fb/0x6c0 [f2fs]
Call Trace:
<TASK>
f2fs_submit_page_bio+0x126/0x8b0 [f2fs]
__get_meta_page+0x1d4/0x920 [f2fs]
get_checkpoint_version.constprop.0+0x2b/0x3c0 [f2fs]
validate_checkpoint+0xac/0x290 [f2fs]
f2fs_get_valid_checkpoint+0x207/0x950 [f2fs]
f2fs_fill_super+0x1007/0x39b0 [f2fs]
mount_bdev+0x183/0x250
legacy_get_tree+0xf4/0x1e0
vfs_get_tree+0x88/0x340
do_new_mount+0x283/0x5e0
path_mount+0x2b2/0x15b0
__x64_sys_mount+0x1fe/0x270
do_syscall_64+0x5f/0x170
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Above issue happens as the biset of the f2fs file system is not
initialized before register "f2fs_fs_type".
To address above issue just register "f2fs_fs_type" at the last in
init_f2fs_fs(). Ensure that all f2fs file system resources are
initialized. |
["https://git.kernel.org/stable/c/32f5e291b7677495f98246eec573767430321c08","https://git.kernel.org/stable/c/8dddc12d03248755d9f709bc1eb9e3ea2bf1b322","https://git.kernel.org/stable/c/9e11b1d5fda972f6be60ab732976a7c8e064cd56","https://git.kernel.org/stable/c/b7d0a97b28083084ebdd8e5c6bccd12e6ec18faa"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-33744
|
Medium |
|
N/A
|
Arm guests can cause Dom0 DoS via PV devices When mapping pages of guests on Arm, dom0 is using an rbtree to keep track of the foreign mappings. Updating of that rbtree is not always done completely with the related lock held, resulting in a small race window, which can be used by unprivileged guests via PV devices to cause inconsistencies of the rbtree. These inconsistencies can lead to Denial of Service (DoS) of dom0, e.g. by causing crashes or the inability to perform further mappings of other guests' memory pages. |
["http://www.openwall.com/lists/oss-security/2022/07/05/4","http://xenbits.xen.org/xsa/advisory-406.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-406.txt","http://www.openwall.com/lists/oss-security/2022/07/05/4","http://xenbits.xen.org/xsa/advisory-406.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-406.txt"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1206
|
Medium |
fixed |
|
A hash collision flaw was found in the IPv6 connection lookup table in the Linux kernel’s IPv6 functionality when a user makes a new kind of SYN flood attack. A user located in the local network or with a high bandwidth connection can increase the CPU usage of the server that accepts IPV6 connections up to 95%. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2175903","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230929-0006/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492","https://bugzilla.redhat.com/show_bug.cgi?id=2175903","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230929-0006/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56748
|
Medium |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()
Hook "qed_ops->common->sb_init = qed_sb_init" does not release the DMA
memory sb_virt when it fails. Add dma_free_coherent() to free it. This
is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb(). |
["https://git.kernel.org/stable/c/0e04bd5a11dffe8c1c0e4c9fc79f7d3cd6182dd5","https://git.kernel.org/stable/c/64654bf5efb3f748e6fc41227adda689618ce9c4","https://git.kernel.org/stable/c/78a169dc69fbdaf114c40e2d56955bf6bd4fc3c0","https://git.kernel.org/stable/c/7c1832287b21ff68c4e3625e63cc7619edf5908b","https://git.kernel.org/stable/c/97384449ddfc07f12ca75f510eb070020d7abb34","https://git.kernel.org/stable/c/a56777a3ef5b35e24a20c4418bcf88bad033807a","https://git.kernel.org/stable/c/b514f45e0fe18d763a1afc34401b1585333cb329","https://git.kernel.org/stable/c/c62c30429db3eb4ced35c7fcf6f04a61ce3a01bb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53052
|
Medium |
fixed |
- 5.10.230
- 5.15.172
- 6.1.116
- 6.6.60
- 6.11.7
|
In the Linux kernel, the following vulnerability has been resolved:
io_uring/rw: fix missing NOWAIT check for O_DIRECT start write
When io_uring starts a write, it'll call kiocb_start_write() to bump the
super block rwsem, preventing any freezes from happening while that
write is in-flight. The freeze side will grab that rwsem for writing,
excluding any new writers from happening and waiting for existing writes
to finish. But io_uring unconditionally uses kiocb_start_write(), which
will block if someone is currently attempting to freeze the mount point.
This causes a deadlock where freeze is waiting for previous writes to
complete, but the previous writes cannot complete, as the task that is
supposed to complete them is blocked waiting on starting a new write.
This results in the following stuck trace showing that dependency with
the write blocked starting a new write:
task:fio state:D stack:0 pid:886 tgid:886 ppid:876
Call trace:
__switch_to+0x1d8/0x348
__schedule+0x8e8/0x2248
schedule+0x110/0x3f0
percpu_rwsem_wait+0x1e8/0x3f8
__percpu_down_read+0xe8/0x500
io_write+0xbb8/0xff8
io_issue_sqe+0x10c/0x1020
io_submit_sqes+0x614/0x2110
__arm64_sys_io_uring_enter+0x524/0x1038
invoke_syscall+0x74/0x268
el0_svc_common.constprop.0+0x160/0x238
do_el0_svc+0x44/0x60
el0_svc+0x44/0xb0
el0t_64_sync_handler+0x118/0x128
el0t_64_sync+0x168/0x170
INFO: task fsfreeze:7364 blocked for more than 15 seconds.
Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963
with the attempting freezer stuck trying to grab the rwsem:
task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995
Call trace:
__switch_to+0x1d8/0x348
__schedule+0x8e8/0x2248
schedule+0x110/0x3f0
percpu_down_write+0x2b0/0x680
freeze_super+0x248/0x8a8
do_vfs_ioctl+0x149c/0x1b18
__arm64_sys_ioctl+0xd0/0x1a0
invoke_syscall+0x74/0x268
el0_svc_common.constprop.0+0x160/0x238
do_el0_svc+0x44/0x60
el0_svc+0x44/0xb0
el0t_64_sync_handler+0x118/0x128
el0t_64_sync+0x168/0x170
Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a
blocking grab of the super block rwsem if it isn't set. For normal issue
where IOCB_NOWAIT would always be set, this returns -EAGAIN which will
have io_uring core issue a blocking attempt of the write. That will in
turn also get completions run, ensuring forward progress.
Since freezing requires CAP_SYS_ADMIN in the first place, this isn't
something that can be triggered by a regular user. |
["https://git.kernel.org/stable/c/003d2996964c03dfd34860500428f4cdf1f5879e","https://git.kernel.org/stable/c/1d60d74e852647255bd8e76f5a22dc42531e4389","https://git.kernel.org/stable/c/26b8c48f369b7591f5679e0b90612f4862a32929","https://git.kernel.org/stable/c/485d9232112b17f389b29497ff41b97b3189546b","https://git.kernel.org/stable/c/4e24041ba86d50aaa4c792ae2c88ed01b3d96243","https://git.kernel.org/stable/c/9e8debb8e51354b201db494689198078ec2c1e75"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56627
|
High |
fixed |
- 5.15.176
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix Out-of-Bounds Read in ksmbd_vfs_stream_read
An offset from client could be a negative value, It could lead
to an out-of-bounds read from the stream_buf.
Note that this issue is coming when setting
'vfs objects = streams_xattr parameter' in ksmbd.conf. |
["https://git.kernel.org/stable/c/27de4295522e9a33e4a3fc72f7b8193df9eebe41","https://git.kernel.org/stable/c/6bd1bf0e8c42f10a9a9679a4c103a9032d30594d","https://git.kernel.org/stable/c/81eed631935f2c52cdaf6691c6d48e0b06e8ad73","https://git.kernel.org/stable/c/de4d790dcf53be41736239d7ee63849a16ff5d10","https://git.kernel.org/stable/c/fc342cf86e2dc4d2edb0fc2ff5e28b6c7845adb9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-37785
|
High |
fixed |
- 5.10.236
- 5.15.180
- 6.1.134
- 6.6.87
- 6.12.23
- 6.13.11
- 6.14.2
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix OOB read when checking dotdot dir
Mounting a corrupted filesystem with directory which contains '.' dir
entry with rec_len == block size results in out-of-bounds read (later
on, when the corrupted directory is removed).
ext4_empty_dir() assumes every ext4 directory contains at least '.'
and '..' as directory entries in the first data block. It first loads
the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry()
and then uses its rec_len member to compute the location of '..' dir
entry (in ext4_next_entry). It assumes the '..' dir entry fits into the
same data block.
If the rec_len of '.' is precisely one block (4KB), it slips through the
sanity checks (it is considered the last directory entry in the data
block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the
memory slot allocated to the data block. The following call to
ext4_check_dir_entry() on new value of de then dereferences this pointer
which results in out-of-bounds mem access.
Fix this by extending __ext4_check_dir_entry() to check for '.' dir
entries that reach the end of data block. Make sure to ignore the phony
dir entries for checksum (by checking name_len for non-zero).
Note: This is reported by KASAN as use-after-free in case another
structure was recently freed from the slot past the bound, but it is
really an OOB read.
This issue was found by syzkaller tool.
Call Trace:
[ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710
[ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375
[ 38.595158]
[ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1
[ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
[ 38.595304] Call Trace:
[ 38.595308] <TASK>
[ 38.595311] dump_stack_lvl+0xa7/0xd0
[ 38.595325] print_address_description.constprop.0+0x2c/0x3f0
[ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710
[ 38.595349] print_report+0xaa/0x250
[ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710
[ 38.595368] ? kasan_addr_to_slab+0x9/0x90
[ 38.595378] kasan_report+0xab/0xe0
[ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710
[ 38.595400] __ext4_check_dir_entry+0x67e/0x710
[ 38.595410] ext4_empty_dir+0x465/0x990
[ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10
[ 38.595432] ext4_rmdir.part.0+0x29a/0xd10
[ 38.595441] ? __dquot_initialize+0x2a7/0xbf0
[ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10
[ 38.595464] ? __pfx___dquot_initialize+0x10/0x10
[ 38.595478] ? down_write+0xdb/0x140
[ 38.595487] ? __pfx_down_write+0x10/0x10
[ 38.595497] ext4_rmdir+0xee/0x140
[ 38.595506] vfs_rmdir+0x209/0x670
[ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190
[ 38.595529] do_rmdir+0x363/0x3c0
[ 38.595537] ? __pfx_do_rmdir+0x10/0x10
[ 38.595544] ? strncpy_from_user+0x1ff/0x2e0
[ 38.595561] __x64_sys_unlinkat+0xf0/0x130
[ 38.595570] do_syscall_64+0x5b/0x180
[ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e |
["https://git.kernel.org/stable/c/14da7dbecb430e35b5889da8dae7bef33173b351","https://git.kernel.org/stable/c/52a5509ab19a5d3afe301165d9b5787bba34d842","https://git.kernel.org/stable/c/53bc45da8d8da92ec07877f5922b130562eb4b00","https://git.kernel.org/stable/c/89503e5eae64637d0fa2218912b54660effe7d93","https://git.kernel.org/stable/c/ac28c5684c1cdab650a7e5065b19e91577d37a4b","https://git.kernel.org/stable/c/b47584c556444cf7acb66b26a62cbc348eb92b78","https://git.kernel.org/stable/c/b7531a4f99c3887439d778afaf418d1a01a5f01b","https://git.kernel.org/stable/c/d5e206778e96e8667d3bde695ad372c296dc9353","https://git.kernel.org/stable/c/e47f472a664d70a3d104a6c2a035cdff55a719b4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47738
|
Low |
fixed |
- 5.11
- 5.13
- 5.14
- 6.1.113
- 6.6.54
- 6.10.13
- 6.11.2
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: don't use rate mask for offchannel TX either
Like the commit ab9177d83c04 ("wifi: mac80211: don't use rate mask for
scanning"), ignore incorrect settings to avoid no supported rate warning
reported by syzbot.
The syzbot did bisect and found cause is commit 9df66d5b9f45 ("cfg80211:
fix default HE tx bitrate mask in 2G band"), which however corrects
bitmask of HE MCS and recognizes correctly settings of empty legacy rate
plus HE MCS rate instead of returning -EINVAL.
As suggestions [1], follow the change of SCAN TX to consider this case of
offchannel TX as well.
[1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024 |
["https://git.kernel.org/stable/c/3565ef215101ffadb5fe5394c70b1fca51376b25","https://git.kernel.org/stable/c/43897111481b679508711d3ca881c4c6593e9247","https://git.kernel.org/stable/c/aafca50e71dc8f3192a5bfb325135a7908f3ef9e","https://git.kernel.org/stable/c/d54455a3a965feb547711aff7afd2ca5deadb99c","https://git.kernel.org/stable/c/e7a7ef9a0742dbd0818d5b15fba2c5313ace765b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4389
|
High |
fixed |
|
A flaw was found in btrfs_get_root_ref in fs/btrfs/disk-io.c in the btrfs filesystem in the Linux Kernel due to a double decrement of the reference count. This issue may allow a local attacker with user privilege to crash the system or may lead to leaked internal kernel information. |
["https://access.redhat.com/security/cve/CVE-2023-4389","https://bugzilla.redhat.com/show_bug.cgi?id=2219271","https://patchwork.kernel.org/project/linux-btrfs/patch/20220324134454.15192-1-baijiaju1990@gmail.com/","https://access.redhat.com/security/cve/CVE-2023-4389","https://bugzilla.redhat.com/show_bug.cgi?id=2219271","https://patchwork.kernel.org/project/linux-btrfs/patch/20220324134454.15192-1-baijiaju1990@gmail.com/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50135
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
nvme-pci: fix race condition between reset and nvme_dev_disable()
nvme_dev_disable() modifies the dev->online_queues field, therefore
nvme_pci_update_nr_queues() should avoid racing against it, otherwise
we could end up passing invalid values to blk_mq_update_nr_hw_queues().
WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347
pci_irq_get_affinity+0x187/0x210
Workqueue: nvme-reset-wq nvme_reset_work [nvme]
RIP: 0010:pci_irq_get_affinity+0x187/0x210
Call Trace:
<TASK>
? blk_mq_pci_map_queues+0x87/0x3c0
? pci_irq_get_affinity+0x187/0x210
blk_mq_pci_map_queues+0x87/0x3c0
nvme_pci_map_queues+0x189/0x460 [nvme]
blk_mq_update_nr_hw_queues+0x2a/0x40
nvme_reset_work+0x1be/0x2a0 [nvme]
Fix the bug by locking the shutdown_lock mutex before using
dev->online_queues. Give up if nvme_dev_disable() is running or if
it has been executed already. |
["https://git.kernel.org/stable/c/26bc0a81f64ce00fc4342c38eeb2eddaad084dd2","https://git.kernel.org/stable/c/4ed32cc0939b64e3d7b48c8c0d63ea038775f304","https://git.kernel.org/stable/c/b33e49a5f254474b33ce98fd45dd0ffdc247a0be"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46787
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
userfaultfd: fix checks for huge PMDs
Patch series "userfaultfd: fix races around pmd_trans_huge() check", v2.
The pmd_trans_huge() code in mfill_atomic() is wrong in three different
ways depending on kernel version:
1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit
the right two race windows) - I've tested this in a kernel build with
some extra mdelay() calls. See the commit message for a description
of the race scenario.
On older kernels (before 6.5), I think the same bug can even
theoretically lead to accessing transhuge page contents as a page table
if you hit the right 5 narrow race windows (I haven't tested this case).
2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for
detecting PMDs that don't point to page tables.
On older kernels (before 6.5), you'd just have to win a single fairly
wide race to hit this.
I've tested this on 6.1 stable by racing migration (with a mdelay()
patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86
VM, that causes a kernel oops in ptlock_ptr().
3. On newer kernels (>=6.5), for shmem mappings, khugepaged is allowed
to yank page tables out from under us (though I haven't tested that),
so I think the BUG_ON() checks in mfill_atomic() are just wrong.
I decided to write two separate fixes for these (one fix for bugs 1+2, one
fix for bug 3), so that the first fix can be backported to kernels
affected by bugs 1+2.
This patch (of 2):
This fixes two issues.
I discovered that the following race can occur:
mfill_atomic other thread
============ ============
<zap PMD>
pmdp_get_lockless() [reads none pmd]
<bail if trans_huge>
<if none:>
<pagefault creates transhuge zeropage>
__pte_alloc [no-op]
<zap PMD>
<bail if pmd_trans_huge(*dst_pmd)>
BUG_ON(pmd_none(*dst_pmd))
I have experimentally verified this in a kernel with extra mdelay() calls;
the BUG_ON(pmd_none(*dst_pmd)) triggers.
On kernels newer than commit 0d940a9b270b ("mm/pgtable: allow
pte_offset_map[_lock]() to fail"), this can't lead to anything worse than
a BUG_ON(), since the page table access helpers are actually designed to
deal with page tables concurrently disappearing; but on older kernels
(<=6.4), I think we could probably theoretically race past the two
BUG_ON() checks and end up treating a hugepage as a page table.
The second issue is that, as Qi Zheng pointed out, there are other types
of huge PMDs that pmd_trans_huge() can't catch: devmap PMDs and swap PMDs
(in particular, migration PMDs).
On <=6.4, this is worse than the first issue: If mfill_atomic() runs on a
PMD that contains a migration entry (which just requires winning a single,
fairly wide race), it will pass the PMD to pte_offset_map_lock(), which
assumes that the PMD points to a page table.
Breakage follows: First, the kernel tries to take the PTE lock (which will
crash or maybe worse if there is no "struct page" for the address bits in
the migration entry PMD - I think at least on X86 there usually is no
corresponding "struct page" thanks to the PTE inversion mitigation, amd64
looks different).
If that didn't crash, the kernel would next try to write a PTE into what
it wrongly thinks is a page table.
As part of fixing these issues, get rid of the check for pmd_trans_huge()
before __pte_alloc() - that's redundant, we're going to have to check for
that after the __pte_alloc() anyway.
Backport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels. |
["https://git.kernel.org/stable/c/3c6b4bcf37845c9359aed926324bed66bdd2448d","https://git.kernel.org/stable/c/71c186efc1b2cf1aeabfeff3b9bd5ac4c5ac14d8","https://git.kernel.org/stable/c/98cc18b1b71e23fe81a5194ed432b20c2d81a01a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50277
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
dm: fix a crash if blk_alloc_disk fails
If blk_alloc_disk fails, the variable md->disk is set to an error value.
cleanup_mapped_device will see that md->disk is non-NULL and it will
attempt to access it, causing a crash on this statement
"md->disk->private_data = NULL;". |
["https://git.kernel.org/stable/c/d7aec2a06730b774a97caaf48cbbc58330a85829","https://git.kernel.org/stable/c/fed13a5478680614ba97fc87e71f16e2e197912e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53100
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
nvme: tcp: avoid race between queue_lock lock and destroy
Commit 76d54bf20cdc ("nvme-tcp: don't access released socket during
error recovery") added a mutex_lock() call for the queue->queue_lock
in nvme_tcp_get_address(). However, the mutex_lock() races with
mutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below.
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220
Modules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs]
CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:__mutex_lock+0xcf0/0x1220
Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1
RSP: 0018:ffff88811305f760 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001
RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341
R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000
R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058
FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
? __warn.cold+0x5b/0x1af
? __mutex_lock+0xcf0/0x1220
? report_bug+0x1ec/0x390
? handle_bug+0x3c/0x80
? exc_invalid_op+0x13/0x40
? asm_exc_invalid_op+0x16/0x20
? __mutex_lock+0xcf0/0x1220
? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]
? __pfx___mutex_lock+0x10/0x10
? __lock_acquire+0xd6a/0x59e0
? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]
nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]
? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp]
nvme_sysfs_show_address+0x81/0xc0 [nvme_core]
dev_attr_show+0x42/0x80
? __asan_memset+0x1f/0x40
sysfs_kf_seq_show+0x1f0/0x370
seq_read_iter+0x2cb/0x1130
? rw_verify_area+0x3b1/0x590
? __mutex_lock+0x433/0x1220
vfs_read+0x6a6/0xa20
? lockdep_hardirqs_on+0x78/0x100
? __pfx_vfs_read+0x10/0x10
ksys_read+0xf7/0x1d0
? __pfx_ksys_read+0x10/0x10
? __x64_sys_openat+0x105/0x1d0
do_syscall_64+0x93/0x180
? lockdep_hardirqs_on_prepare+0x16d/0x400
? do_syscall_64+0x9f/0x180
? lockdep_hardirqs_on+0x78/0x100
? do_syscall_64+0x9f/0x180
? __pfx_ksys_read+0x10/0x10
? lockdep_hardirqs_on_prepare+0x16d/0x400
? do_syscall_64+0x9f/0x180
? lockdep_hardirqs_on+0x78/0x100
? do_syscall_64+0x9f/0x180
? lockdep_hardirqs_on_prepare+0x16d/0x400
? do_syscall_64+0x9f/0x180
? lockdep_hardirqs_on+0x78/0x100
? do_syscall_64+0x9f/0x180
? lockdep_hardirqs_on_prepare+0x16d/0x400
? do_syscall_64+0x9f/0x180
? lockdep_hardirqs_on+0x78/0x100
? do_syscall_64+0x9f/0x180
? lockdep_hardirqs_on_prepare+0x16d/0x400
? do_syscall_64+0x9f/0x180
? lockdep_hardirqs_on+0x78/0x100
? do_syscall_64+0x9f/0x180
? do_syscall_64+0x9f/0x180
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7f9713f55cfa
Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4
---truncated--- |
["https://git.kernel.org/stable/c/4f946479b326a3cbb193f2b8368aed9269514c35","https://git.kernel.org/stable/c/782373ba27660ba7d330208cf5509ece6feb4545","https://git.kernel.org/stable/c/975cb1d2121511584695d0e47fdb90e6782da007","https://git.kernel.org/stable/c/e15cebc1b21856944b387f4abd03b66bd3d4f027"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3028
|
High |
fixed |
- 4.9.327
- 4.14.292
- 4.19.257
- 5.4.212
- 5.10.140
- 5.15.64
- 5.19.6
|
A race condition was found in the Linux kernel's IP framework for transforming packets (XFRM subsystem) when multiple calls to xfrm_probe_algs occurred simultaneously. This flaw could allow a local attacker to potentially trigger an out-of-bounds write or leak kernel heap memory by performing an out-of-bounds read and copying it into a socket. |
["https://github.com/torvalds/linux/commit/ba953a9d89a00c078b85f4b190bc1dde66fe16b5","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/F3MYP7WX4PNE6RCITVXA43CECBZT4CL6/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JKVA75UHKVOHNOEPCLUHTFGWCOOUBDM3/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PEQYVCNYUWB4CJ2YRAYNF2GGFQ7SUYC4/","https://lore.kernel.org/all/YtoWqEkKzvimzWS5%40gondor.apana.org.au/T/","https://security.netapp.com/advisory/ntap-20230214-0004/","https://github.com/torvalds/linux/commit/ba953a9d89a00c078b85f4b190bc1dde66fe16b5","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/F3MYP7WX4PNE6RCITVXA43CECBZT4CL6/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JKVA75UHKVOHNOEPCLUHTFGWCOOUBDM3/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PEQYVCNYUWB4CJ2YRAYNF2GGFQ7SUYC4/","https://lore.kernel.org/all/YtoWqEkKzvimzWS5%40gondor.apana.org.au/T/","https://security.netapp.com/advisory/ntap-20230214-0004/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-28466
|
High |
fixed |
- 5.10.177
- 5.15.105
- 6.1.20
- 6.2.7
|
do_tls_getsockopt in net/tls/tls_main.c in the Linux kernel through 6.2.6 lacks a lock_sock call, leading to a race condition (with a resultant use-after-free or NULL pointer dereference). |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=49c47cc21b5b7a3d8deb18fc57b0aa2ab1286962","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://security.netapp.com/advisory/ntap-20230427-0006/","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=49c47cc21b5b7a3d8deb18fc57b0aa2ab1286962","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://security.netapp.com/advisory/ntap-20230427-0006/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47141
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
pinmux: Use sequential access to access desc->pinmux data
When two client of the same gpio call pinctrl_select_state() for the
same functionality, we are seeing NULL pointer issue while accessing
desc->mux_owner.
Let's say two processes A, B executing in pin_request() for the same pin
and process A updates the desc->mux_usecount but not yet updated the
desc->mux_owner while process B see the desc->mux_usecount which got
updated by A path and further executes strcmp and while accessing
desc->mux_owner it crashes with NULL pointer.
Serialize the access to mux related setting with a mutex lock.
cpu0 (process A) cpu1(process B)
pinctrl_select_state() { pinctrl_select_state() {
pin_request() { pin_request() {
...
....
} else {
desc->mux_usecount++;
desc->mux_usecount && strcmp(desc->mux_owner, owner)) {
if (desc->mux_usecount > 1)
return 0;
desc->mux_owner = owner;
} } |
["https://git.kernel.org/stable/c/2da32aed4a97ca1d70fb8b77926f72f30ce5fb4b","https://git.kernel.org/stable/c/5a3e85c3c397c781393ea5fb2f45b1f60f8a4e6e","https://git.kernel.org/stable/c/c11e2ec9a780f54982a187ee10ffd1b810715c85"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-48875
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't take dev_replace rwsem on task already holding it
Running fstests btrfs/011 with MKFS_OPTIONS="-O rst" to force the usage of
the RAID stripe-tree, we get the following splat from lockdep:
BTRFS info (device sdd): dev_replace from /dev/sdd (devid 1) to /dev/sdb started
============================================
WARNING: possible recursive locking detected
6.11.0-rc3-btrfs-for-next #599 Not tainted
--------------------------------------------
btrfs/2326 is trying to acquire lock:
ffff88810f215c98 (&fs_info->dev_replace.rwsem){++++}-{3:3}, at: btrfs_map_block+0x39f/0x2250
but task is already holding lock:
ffff88810f215c98 (&fs_info->dev_replace.rwsem){++++}-{3:3}, at: btrfs_map_block+0x39f/0x2250
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&fs_info->dev_replace.rwsem);
lock(&fs_info->dev_replace.rwsem);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by btrfs/2326:
#0: ffff88810f215c98 (&fs_info->dev_replace.rwsem){++++}-{3:3}, at: btrfs_map_block+0x39f/0x2250
stack backtrace:
CPU: 1 UID: 0 PID: 2326 Comm: btrfs Not tainted 6.11.0-rc3-btrfs-for-next #599
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Call Trace:
<TASK>
dump_stack_lvl+0x5b/0x80
__lock_acquire+0x2798/0x69d0
? __pfx___lock_acquire+0x10/0x10
? __pfx___lock_acquire+0x10/0x10
lock_acquire+0x19d/0x4a0
? btrfs_map_block+0x39f/0x2250
? __pfx_lock_acquire+0x10/0x10
? find_held_lock+0x2d/0x110
? lock_is_held_type+0x8f/0x100
down_read+0x8e/0x440
? btrfs_map_block+0x39f/0x2250
? __pfx_down_read+0x10/0x10
? do_raw_read_unlock+0x44/0x70
? _raw_read_unlock+0x23/0x40
btrfs_map_block+0x39f/0x2250
? btrfs_dev_replace_by_ioctl+0xd69/0x1d00
? btrfs_bio_counter_inc_blocked+0xd9/0x2e0
? __kasan_slab_alloc+0x6e/0x70
? __pfx_btrfs_map_block+0x10/0x10
? __pfx_btrfs_bio_counter_inc_blocked+0x10/0x10
? kmem_cache_alloc_noprof+0x1f2/0x300
? mempool_alloc_noprof+0xed/0x2b0
btrfs_submit_chunk+0x28d/0x17e0
? __pfx_btrfs_submit_chunk+0x10/0x10
? bvec_alloc+0xd7/0x1b0
? bio_add_folio+0x171/0x270
? __pfx_bio_add_folio+0x10/0x10
? __kasan_check_read+0x20/0x20
btrfs_submit_bio+0x37/0x80
read_extent_buffer_pages+0x3df/0x6c0
btrfs_read_extent_buffer+0x13e/0x5f0
read_tree_block+0x81/0xe0
read_block_for_search+0x4bd/0x7a0
? __pfx_read_block_for_search+0x10/0x10
btrfs_search_slot+0x78d/0x2720
? __pfx_btrfs_search_slot+0x10/0x10
? lock_is_held_type+0x8f/0x100
? kasan_save_track+0x14/0x30
? __kasan_slab_alloc+0x6e/0x70
? kmem_cache_alloc_noprof+0x1f2/0x300
btrfs_get_raid_extent_offset+0x181/0x820
? __pfx_lock_acquire+0x10/0x10
? __pfx_btrfs_get_raid_extent_offset+0x10/0x10
? down_read+0x194/0x440
? __pfx_down_read+0x10/0x10
? do_raw_read_unlock+0x44/0x70
? _raw_read_unlock+0x23/0x40
btrfs_map_block+0x5b5/0x2250
? __pfx_btrfs_map_block+0x10/0x10
scrub_submit_initial_read+0x8fe/0x11b0
? __pfx_scrub_submit_initial_read+0x10/0x10
submit_initial_group_read+0x161/0x3a0
? lock_release+0x20e/0x710
? __pfx_submit_initial_group_read+0x10/0x10
? __pfx_lock_release+0x10/0x10
scrub_simple_mirror.isra.0+0x3eb/0x580
scrub_stripe+0xe4d/0x1440
? lock_release+0x20e/0x710
? __pfx_scrub_stripe+0x10/0x10
? __pfx_lock_release+0x10/0x10
? do_raw_read_unlock+0x44/0x70
? _raw_read_unlock+0x23/0x40
scrub_chunk+0x257/0x4a0
scrub_enumerate_chunks+0x64c/0xf70
? __mutex_unlock_slowpath+0x147/0x5f0
? __pfx_scrub_enumerate_chunks+0x10/0x10
? bit_wait_timeout+0xb0/0x170
? __up_read+0x189/0x700
? scrub_workers_get+0x231/0x300
? up_write+0x490/0x4f0
btrfs_scrub_dev+0x52e/0xcd0
? create_pending_snapshots+0x230/0x250
? __pfx_btrfs_scrub_dev+0x10/0x10
btrfs_dev_replace_by_ioctl+0xd69/0x1d00
? lock_acquire+0x19d/0x4a0
? __pfx_btrfs_dev_replace_by_ioctl+0x10/0x10
?
---truncated--- |
["https://git.kernel.org/stable/c/8cca35cb29f81eba3e96ec44dad8696c8a2f9138","https://git.kernel.org/stable/c/a2e99dcd7aafa9d474f7d9b0740b8f93c4e156c2","https://git.kernel.org/stable/c/a5bc4e030f50fdbb1fbc69acc1e0c5f57c79d044"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-54683
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: IDLETIMER: Fix for possible ABBA deadlock
Deletion of the last rule referencing a given idletimer may happen at
the same time as a read of its file in sysfs:
| ======================================================
| WARNING: possible circular locking dependency detected
| 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted
| ------------------------------------------------------
| iptables/3303 is trying to acquire lock:
| ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: __kernfs_remove+0x20
|
| but task is already holding lock:
| ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v]
|
| which lock already depends on the new lock.
A simple reproducer is:
| #!/bin/bash
|
| while true; do
| iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label "testme"
| iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label "testme"
| done &
| while true; do
| cat /sys/class/xt_idletimer/timers/testme >/dev/null
| done
Avoid this by freeing list_mutex right after deleting the element from
the list, then continuing with the teardown. |
["https://git.kernel.org/stable/c/45fe76573a2557f632e248cc141342233f422b9a","https://git.kernel.org/stable/c/8c2c8445cda8f59c38dec7dc10509bcb23ae26a0","https://git.kernel.org/stable/c/f36b01994d68ffc253c8296e2228dfe6e6431c03"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-58012
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: Intel: hda-dai: Ensure DAI widget is valid during params
Each cpu DAI should associate with a widget. However, the topology might
not create the right number of DAI widgets for aggregated amps. And it
will cause NULL pointer deference.
Check that the DAI widget associated with the CPU DAI is valid to prevent
NULL pointer deference due to missing DAI widgets in topologies with
aggregated amps. |
["https://git.kernel.org/stable/c/569922b82ca660f8b24e705f6cf674e6b1f99cc7","https://git.kernel.org/stable/c/789a2fbf0900982788408d3b0034e0e3f914fb3b","https://git.kernel.org/stable/c/e012a77e4d7632cf615ba9625b1600ed8985c3b5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48992
|
Medium |
fixed |
- 4.9.336
- 4.14.302
- 4.19.269
- 5.4.227
- 5.10.159
- 5.15.83
- 6.0.13
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: soc-pcm: Add NULL check in BE reparenting
Add NULL check in dpcm_be_reparent API, to handle
kernel NULL pointer dereference error.
The issue occurred in fuzzing test. |
["https://git.kernel.org/stable/c/0760acc2e6598ad4f7bd3662db2d907ef0838139","https://git.kernel.org/stable/c/34a9796bf0684bfd54e96a142560d560c21c983b","https://git.kernel.org/stable/c/9f74b9aa8d58c18927bb9b65dd5ba70a5fd61615","https://git.kernel.org/stable/c/d4dd21a79dbb862d2ebcf9ed90e646416009ff0d","https://git.kernel.org/stable/c/db8f91d424fe0ea6db337aca8bc05908bbce1498","https://git.kernel.org/stable/c/e7166d6821c15f3516bcac8ae3f155924da1908c","https://git.kernel.org/stable/c/f2ba66d8738584d124aff4e760ed1337f5f6dfb6","https://git.kernel.org/stable/c/f6f45e538328df9ce66aa61bafee1a5717c4b700"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48994
|
Medium |
fixed |
- 4.9.336
- 4.14.302
- 4.19.269
- 5.4.227
- 5.10.159
- 5.15.83
- 6.0.13
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed.
seq_copy_in_user() and seq_copy_in_kernel() did not have prototypes
matching snd_seq_dump_func_t. Adjust this and remove the casts. There
are not resulting binary output differences.
This was found as a result of Clang's new -Wcast-function-type-strict
flag, which is more sensitive than the simpler -Wcast-function-type,
which only checks for type width mismatches. |
["https://git.kernel.org/stable/c/05530ef7cf7c7d700f6753f058999b1b5099a026","https://git.kernel.org/stable/c/13ee8fb5410b740c8dd2867d3557c7662f7dda2d","https://git.kernel.org/stable/c/15c42ab8d43acb73e2eba361ad05822c0af0ecfa","https://git.kernel.org/stable/c/2f46e95bf344abc4e74f8158901d32a869e0adb6","https://git.kernel.org/stable/c/63badfed200219ca656968725f1a43df293ac936","https://git.kernel.org/stable/c/b38486e82ecb9f3046e0184205f6b61408fc40c9","https://git.kernel.org/stable/c/e385360705a0b346bdb57ce938249175d0613b8a","https://git.kernel.org/stable/c/fccd454129f6a0739651f7f58307cdb631fd6e89"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-52559
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/gem: prevent integer overflow in msm_ioctl_gem_submit()
The "submit->cmd[i].size" and "submit->cmd[i].offset" variables are u32
values that come from the user via the submit_lookup_cmds() function.
This addition could lead to an integer wrapping bug so use size_add()
to prevent that.
Patchwork: https://patchwork.freedesktop.org/patch/624696/ |
["https://git.kernel.org/stable/c/2b99b2c4621d13bd4374ef384e8f1fc188d0a5df","https://git.kernel.org/stable/c/2f1845e46c41ed500789d53dc45b383b7745c96c","https://git.kernel.org/stable/c/3a47f4b439beb98e955d501c609dfd12b7836d61","https://git.kernel.org/stable/c/e43a0f1327a1ee70754f8a0de6e0262cfa3e0b87"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21941
|
Medium |
fixed |
- 5.10.236
- 5.15.180
- 6.1.131
- 6.6.83
- 6.12.19
- 6.13.7
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix null check for pipe_ctx->plane_state in resource_build_scaling_params
Null pointer dereference issue could occur when pipe_ctx->plane_state
is null. The fix adds a check to ensure 'pipe_ctx->plane_state' is not
null before accessing. This prevents a null pointer dereference.
Found by code review.
(cherry picked from commit 63e6a77ccf239337baa9b1e7787cde9fa0462092) |
["https://git.kernel.org/stable/c/265422915416468ba91bffa56addbff45e18342a","https://git.kernel.org/stable/c/3748fad09d89e9a5290e1738fd6872a79f794743","https://git.kernel.org/stable/c/374c9faac5a763a05bc3f68ad9f73dab3c6aec90","https://git.kernel.org/stable/c/3b3c2be58d5275aa59d8b4810a59f173f2f5bac1","https://git.kernel.org/stable/c/c1e54752dc12e90305eb0475ca908f42f5b369ca","https://git.kernel.org/stable/c/e0345c3478f185ca840daac7f08a1fcd4ebec3e9","https://git.kernel.org/stable/c/f435192e00bc4d5d4134356b93212670ec47fa8d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21963
|
Medium |
fixed |
- 5.15.180
- 6.1.132
- 6.6.84
- 6.12.20
- 6.13.8
|
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix integer overflow while processing acdirmax mount option
User-provided mount parameter acdirmax of type u32 is intended to have
an upper limit, but before it is validated, the value is converted from
seconds to jiffies which can lead to an integer overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/0c26edf477e093cefc41637f5bccc102e1a77399","https://git.kernel.org/stable/c/2809a79bc64964ce02e0c5f2d6bd39b9d09bdb3c","https://git.kernel.org/stable/c/39d086bb3558da9640ef335f97453e01d32578a1","https://git.kernel.org/stable/c/5b29891f91dfb8758baf1e2217bef4b16b2b165b","https://git.kernel.org/stable/c/6124cbf73e3dea7591857dd63b8ccece28952afd","https://git.kernel.org/stable/c/9e438d0410a4002d24f420f2c28897ba2dc0af64"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21964
|
Medium |
fixed |
- 5.15.180
- 6.1.132
- 6.6.84
- 6.12.20
- 6.13.8
|
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix integer overflow while processing acregmax mount option
User-provided mount parameter acregmax of type u32 is intended to have
an upper limit, but before it is validated, the value is converted from
seconds to jiffies which can lead to an integer overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/0252c33cc943e9e48ddfafaa6b1eb72adb68a099","https://git.kernel.org/stable/c/5f500874ab9b3cc8c169c2ab49f00b838520b9c5","https://git.kernel.org/stable/c/7489161b1852390b4413d57f2457cd40b34da6cc","https://git.kernel.org/stable/c/833f2903eb8b70faca7967319e580e9ce69729fc","https://git.kernel.org/stable/c/a13351624a6af8d91398860b8c9d4cf6c8e63de5","https://git.kernel.org/stable/c/dd190168e60ac15408f074a1fe0ce36aff34027b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21981
|
Medium |
fixed |
- 6.1.132
- 6.6.84
- 6.12.20
- 6.13.8
|
In the Linux kernel, the following vulnerability has been resolved:
ice: fix memory leak in aRFS after reset
Fix aRFS (accelerated Receive Flow Steering) structures memory leak by
adding a checker to verify if aRFS memory is already allocated while
configuring VSI. aRFS objects are allocated in two cases:
- as part of VSI initialization (at probe), and
- as part of reset handling
However, VSI reconfiguration executed during reset involves memory
allocation one more time, without prior releasing already allocated
resources. This led to the memory leak with the following signature:
[root@os-delivery ~]# cat /sys/kernel/debug/kmemleak
unreferenced object 0xff3c1ca7252e6000 (size 8192):
comm "kworker/0:0", pid 8, jiffies 4296833052
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 0):
[<ffffffff991ec485>] __kmalloc_cache_noprof+0x275/0x340
[<ffffffffc0a6e06a>] ice_init_arfs+0x3a/0xe0 [ice]
[<ffffffffc09f1027>] ice_vsi_cfg_def+0x607/0x850 [ice]
[<ffffffffc09f244b>] ice_vsi_setup+0x5b/0x130 [ice]
[<ffffffffc09c2131>] ice_init+0x1c1/0x460 [ice]
[<ffffffffc09c64af>] ice_probe+0x2af/0x520 [ice]
[<ffffffff994fbcd3>] local_pci_probe+0x43/0xa0
[<ffffffff98f07103>] work_for_cpu_fn+0x13/0x20
[<ffffffff98f0b6d9>] process_one_work+0x179/0x390
[<ffffffff98f0c1e9>] worker_thread+0x239/0x340
[<ffffffff98f14abc>] kthread+0xcc/0x100
[<ffffffff98e45a6d>] ret_from_fork+0x2d/0x50
[<ffffffff98e083ba>] ret_from_fork_asm+0x1a/0x30
... |
["https://git.kernel.org/stable/c/23d97f18901ef5e4e264e3b1777fe65c760186b5","https://git.kernel.org/stable/c/3b27e6e10a32589fcd293b8933ab6de9387a460e","https://git.kernel.org/stable/c/5d30d256661fc11b6e73fac6c3783a702e1006a3","https://git.kernel.org/stable/c/78f3d64b30210c0e521c59357431aca14024cb79","https://git.kernel.org/stable/c/e6902101f34f098af59b0d1d8cf90c4124c02c6a","https://git.kernel.org/stable/c/ef2bc94059836a115430a6ad9d2838b0b34dc8f5","https://git.kernel.org/stable/c/fcbacc47d16306c87ad1b820b7a575f6e9eae58b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53157
|
Medium |
fixed |
- 4.19.325
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scpi: Check the DVFS OPP count returned by the firmware
Fix a kernel crash with the below call trace when the SCPI firmware
returns OPP count of zero.
dvfs_info.opp_count may be zero on some platforms during the reboot
test, and the kernel will crash after dereferencing the pointer to
kcalloc(info->count, sizeof(*opp), GFP_KERNEL).
| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028
| Mem abort info:
| ESR = 0x96000004
| Exception class = DABT (current EL), IL = 32 bits
| SET = 0, FnV = 0
| EA = 0, S1PTW = 0
| Data abort info:
| ISV = 0, ISS = 0x00000004
| CM = 0, WnR = 0
| user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c
| [0000000000000028] pgd=0000000000000000
| Internal error: Oops: 96000004 [#1] SMP
| scpi-hwmon: probe of PHYT000D:00 failed with error -110
| Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c)
| CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1
| Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS
| pstate: 60000005 (nZCv daif -PAN -UAO)
| pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi]
| lr : clk_register+0x438/0x720
| Call trace:
| scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi]
| devm_clk_hw_register+0x50/0xa0
| scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi]
| scpi_clocks_probe+0x528/0x70c [clk_scpi]
| platform_drv_probe+0x58/0xa8
| really_probe+0x260/0x3d0
| driver_probe_device+0x12c/0x148
| device_driver_attach+0x74/0x98
| __driver_attach+0xb4/0xe8
| bus_for_each_dev+0x88/0xe0
| driver_attach+0x30/0x40
| bus_add_driver+0x178/0x2b0
| driver_register+0x64/0x118
| __platform_driver_register+0x54/0x60
| scpi_clocks_driver_init+0x24/0x1000 [clk_scpi]
| do_one_initcall+0x54/0x220
| do_init_module+0x54/0x1c8
| load_module+0x14a4/0x1668
| __se_sys_finit_module+0xf8/0x110
| __arm64_sys_finit_module+0x24/0x30
| el0_svc_common+0x78/0x170
| el0_svc_handler+0x38/0x78
| el0_svc+0x8/0x340
| Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820)
| ---[ end trace 06feb22469d89fa8 ]---
| Kernel panic - not syncing: Fatal exception
| SMP: stopping secondary CPUs
| Kernel Offset: disabled
| CPU features: 0x10,a0002008
| Memory Limit: none |
["https://git.kernel.org/stable/c/025067eeb945aa17c7dd483a63960125b7efb577","https://git.kernel.org/stable/c/06258e57fee253f4046d3a6a86d7fde09f596eac","https://git.kernel.org/stable/c/109aa654f85c5141e813b2cd1bd36d90be678407","https://git.kernel.org/stable/c/12e2c520a0a4202575e4a45ea41f06a8e9aa3417","https://git.kernel.org/stable/c/2a5b8de6fcb944f9af0c5fcb30bb0c039705e051","https://git.kernel.org/stable/c/380c0e1d96f3b522f3170c18ee5e0f1a28fec5d6","https://git.kernel.org/stable/c/8be4e51f3ecfb0915e3510b600c4cce0dc68a383","https://git.kernel.org/stable/c/9beaff47bcea5eec7d4ead98f5043057161fd71a","https://git.kernel.org/stable/c/dfc9c2aa7f04f7db7e7225a5e118a24bf1c3b325"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53217
|
Medium |
fixed |
- 4.19.325
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Prevent NULL dereference in nfsd4_process_cb_update()
@ses is initialized to NULL. If __nfsd4_find_backchannel() finds no
available backchannel session, setup_callback_client() will try to
dereference @ses and segfault. |
["https://git.kernel.org/stable/c/03178cd8f67227015debb700123987fe96275cd1","https://git.kernel.org/stable/c/0c3b0e326f838787d229314d4de83af9c53347e8","https://git.kernel.org/stable/c/1e02c641c3a43c88cecc08402000418e15578d38","https://git.kernel.org/stable/c/4a4ffc1aa9d618e41ad9151f40966e402e58a5a2","https://git.kernel.org/stable/c/752a75811f27300fe8131b0a1efc91960f6f88e7","https://git.kernel.org/stable/c/c5d90f9302742985a5078e42ac38de42c364c44a","https://git.kernel.org/stable/c/cac1405e3ff6685a438e910ad719e0cf06af90ee","https://git.kernel.org/stable/c/d9a0d1f6e15859ea7a86a327f28491e23deaaa62","https://git.kernel.org/stable/c/eb51733ae5fc73d95bd857d5da26f9f65b202a79"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21891
|
Medium |
fixed |
- 6.1.130
- 6.6.81
- 6.12.18
- 6.13.6
|
In the Linux kernel, the following vulnerability has been resolved:
ipvlan: ensure network headers are in skb linear part
syzbot found that ipvlan_process_v6_outbound() was assuming
the IPv6 network header isis present in skb->head [1]
Add the needed pskb_network_may_pull() calls for both
IPv4 and IPv6 handlers.
[1]
BUG: KMSAN: uninit-value in __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47
__ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47
ipv6_addr_type include/net/ipv6.h:555 [inline]
ip6_route_output_flags_noref net/ipv6/route.c:2616 [inline]
ip6_route_output_flags+0x51/0x720 net/ipv6/route.c:2651
ip6_route_output include/net/ip6_route.h:93 [inline]
ipvlan_route_v6_outbound+0x24e/0x520 drivers/net/ipvlan/ipvlan_core.c:476
ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:491 [inline]
ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:541 [inline]
ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:605 [inline]
ipvlan_queue_xmit+0xd72/0x1780 drivers/net/ipvlan/ipvlan_core.c:671
ipvlan_start_xmit+0x5b/0x210 drivers/net/ipvlan/ipvlan_main.c:223
__netdev_start_xmit include/linux/netdevice.h:5150 [inline]
netdev_start_xmit include/linux/netdevice.h:5159 [inline]
xmit_one net/core/dev.c:3735 [inline]
dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3751
sch_direct_xmit+0x399/0xd40 net/sched/sch_generic.c:343
qdisc_restart net/sched/sch_generic.c:408 [inline]
__qdisc_run+0x14da/0x35d0 net/sched/sch_generic.c:416
qdisc_run+0x141/0x4d0 include/net/pkt_sched.h:127
net_tx_action+0x78b/0x940 net/core/dev.c:5484
handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561
__do_softirq+0x14/0x1a kernel/softirq.c:595
do_softirq+0x9a/0x100 kernel/softirq.c:462
__local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389
local_bh_enable include/linux/bottom_half.h:33 [inline]
rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]
__dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4611
dev_queue_xmit include/linux/netdevice.h:3311 [inline]
packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276
packet_snd net/packet/af_packet.c:3132 [inline]
packet_sendmsg+0x93e0/0xa7e0 net/packet/af_packet.c:3164
sock_sendmsg_nosec net/socket.c:718 [inline] |
["https://git.kernel.org/stable/c/27843ce6ba3d3122b65066550fe33fb8839f8aef","https://git.kernel.org/stable/c/4ec48f812804f370f622e0874e6dd8fcc58241cd","https://git.kernel.org/stable/c/5353fd89663c48f56bdff975c562cfe78b1a2e4c","https://git.kernel.org/stable/c/5b8dea8d1612dc7151d2457d7d2e6a69820309bf","https://git.kernel.org/stable/c/e2a4f76a2d8a44816ecd25bcbdb47b786d621974"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50298
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: enetc: allocate vf_state during PF probes
In the previous implementation, vf_state is allocated memory only when VF
is enabled. However, net_device_ops::ndo_set_vf_mac() may be called before
VF is enabled to configure the MAC address of VF. If this is the case,
enetc_pf_set_vf_mac() will access vf_state, resulting in access to a null
pointer. The simplified error log is as follows.
root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89
[ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004
[ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy
[ 173.641973] lr : do_setlink+0x4a8/0xec8
[ 173.732292] Call trace:
[ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80
[ 173.738847] __rtnl_newlink+0x530/0x89c
[ 173.742692] rtnl_newlink+0x50/0x7c
[ 173.746189] rtnetlink_rcv_msg+0x128/0x390
[ 173.750298] netlink_rcv_skb+0x60/0x130
[ 173.754145] rtnetlink_rcv+0x18/0x24
[ 173.757731] netlink_unicast+0x318/0x380
[ 173.761665] netlink_sendmsg+0x17c/0x3c8 |
["https://git.kernel.org/stable/c/7eb923f8d4819737c07d6a8d0daef0a4d7f99e0c","https://git.kernel.org/stable/c/e15c5506dd39885cd047f811a64240e2e8ab401b","https://git.kernel.org/stable/c/ef0edfbe9eeed1fccad7cb705648af5222664944"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53091
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx
As the introduction of the support for vsock and unix sockets in sockmap,
tls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK.
vsock and af_unix sockets have vsock_sock and unix_sock instead of
inet_connection_sock. For these sockets, tls_get_ctx may return an invalid
pointer and cause page fault in function tls_sw_ctx_rx.
BUG: unable to handle page fault for address: 0000000000040030
Workqueue: vsock-loopback vsock_loopback_work
RIP: 0010:sk_psock_strp_data_ready+0x23/0x60
Call Trace:
? __die+0x81/0xc3
? no_context+0x194/0x350
? do_page_fault+0x30/0x110
? async_page_fault+0x3e/0x50
? sk_psock_strp_data_ready+0x23/0x60
virtio_transport_recv_pkt+0x750/0x800
? update_load_avg+0x7e/0x620
vsock_loopback_work+0xd0/0x100
process_one_work+0x1a7/0x360
worker_thread+0x30/0x390
? create_worker+0x1a0/0x1a0
kthread+0x112/0x130
? __kthread_cancel_work+0x40/0x40
ret_from_fork+0x1f/0x40
v2:
- Add IS_ICSK check
v3:
- Update the commits in Fixes |
["https://git.kernel.org/stable/c/44d0469f79bd3d0b3433732877358df7dc6b17b1","https://git.kernel.org/stable/c/6781cfa93a6a1b7f5be6819a5a2dd8f30f47ca26","https://git.kernel.org/stable/c/a078a480ff3f43d74d8a024ae10c3c7daf6db149"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-35978
|
Medium |
fixed |
- 4.19.313
- 5.4.275
- 5.10.216
- 5.15.156
- 6.1.87
- 6.6.28
- 6.8.7
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix memory leak in hci_req_sync_complete()
In 'hci_req_sync_complete()', always free the previous sync
request state before assigning reference to a new one. |
["https://git.kernel.org/stable/c/45d355a926ab40f3ae7bc0b0a00cb0e3e8a5a810","https://git.kernel.org/stable/c/4beab84fbb50df3be1d8f8a976e6fe882ca65cb2","https://git.kernel.org/stable/c/66fab1e120b39f8f47a94186ddee36006fc02ca8","https://git.kernel.org/stable/c/75193678cce993aa959e7764b6df2f599886dd06","https://git.kernel.org/stable/c/8478394f76c748862ef179a16f651f752bdafaf0","https://git.kernel.org/stable/c/89a32741f4217856066c198a4a7267bcdd1edd67","https://git.kernel.org/stable/c/9ab5e44b9bac946bd49fd63264a08cd1ea494e76","https://git.kernel.org/stable/c/e4cb8382fff6706436b66eafd9c0ee857ff0a9f5","https://git.kernel.org/stable/c/45d355a926ab40f3ae7bc0b0a00cb0e3e8a5a810","https://git.kernel.org/stable/c/4beab84fbb50df3be1d8f8a976e6fe882ca65cb2","https://git.kernel.org/stable/c/66fab1e120b39f8f47a94186ddee36006fc02ca8","https://git.kernel.org/stable/c/75193678cce993aa959e7764b6df2f599886dd06","https://git.kernel.org/stable/c/8478394f76c748862ef179a16f651f752bdafaf0","https://git.kernel.org/stable/c/89a32741f4217856066c198a4a7267bcdd1edd67","https://git.kernel.org/stable/c/9ab5e44b9bac946bd49fd63264a08cd1ea494e76","https://git.kernel.org/stable/c/e4cb8382fff6706436b66eafd9c0ee857ff0a9f5","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3611
|
High |
fixed |
- 4.14.322
- 4.19.291
- 5.4.253
- 5.10.188
- 5.15.121
- 6.1.40
- 6.4.5
|
An out-of-bounds write vulnerability in the Linux kernel's net/sched: sch_qfq component can be exploited to achieve local privilege escalation.
The qfq_change_agg() function in net/sched/sch_qfq.c allows an out-of-bounds write because lmax is updated according to packet sizes without bounds checks.
We recommend upgrading past commit 3e337087c3b5805fe0b8a46ba622a962880b5d64. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e337087c3b5805fe0b8a46ba622a962880b5d64","https://kernel.dance/3e337087c3b5805fe0b8a46ba622a962880b5d64","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230908-0002/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e337087c3b5805fe0b8a46ba622a962880b5d64","https://kernel.dance/3e337087c3b5805fe0b8a46ba622a962880b5d64","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230908-0002/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49840
|
High |
fixed |
- 4.14.300
- 4.19.267
- 5.4.225
- 5.10.156
- 5.15.80
- 6.0.10
|
In the Linux kernel, the following vulnerability has been resolved:
bpf, test_run: Fix alignment problem in bpf_prog_test_run_skb()
We got a syzkaller problem because of aarch64 alignment fault
if KFENCE enabled. When the size from user bpf program is an odd
number, like 399, 407, etc, it will cause the struct skb_shared_info's
unaligned access. As seen below:
BUG: KFENCE: use-after-free read in __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032
Use-after-free read at 0xffff6254fffac077 (in kfence-#213):
__lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline]
arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline]
arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [inline]
atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline]
__skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032
skb_clone+0xf4/0x214 net/core/skbuff.c:1481
____bpf_clone_redirect net/core/filter.c:2433 [inline]
bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420
bpf_prog_d3839dd9068ceb51+0x80/0x330
bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline]
bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53
bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594
bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline]
__do_sys_bpf kernel/bpf/syscall.c:4441 [inline]
__se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381
kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, size=407, cache=kmalloc-512
allocated by task 15074 on cpu 0 at 1342.585390s:
kmalloc include/linux/slab.h:568 [inline]
kzalloc include/linux/slab.h:675 [inline]
bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191
bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512
bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline]
__do_sys_bpf kernel/bpf/syscall.c:4441 [inline]
__se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381
__arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381
To fix the problem, we adjust @size so that (@size + @hearoom) is a
multiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_info
is aligned to a cache line. |
["https://git.kernel.org/stable/c/047824a730699c6c66df43306b80f700c9dfc2fd","https://git.kernel.org/stable/c/1b597f2d6a55e9f549989913860ad5170da04964","https://git.kernel.org/stable/c/730fb1ef974a13915bc7651364d8b3318891cd70","https://git.kernel.org/stable/c/7a704dbfd3735304e261f2787c52fbc7c3884736","https://git.kernel.org/stable/c/d3fd203f36d46aa29600a72d57a1b61af80e4a25","https://git.kernel.org/stable/c/e60f37a1d379c821c17b08f366412dce9ef3d99f","https://git.kernel.org/stable/c/eaa8edd86514afac9deb9bf9a5053e74f37edf40"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49842
|
High |
fixed |
- 4.9.334
- 4.14.300
- 4.19.267
- 5.4.225
- 5.10.156
- 5.15.80
- 6.0.10
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: core: Fix use-after-free in snd_soc_exit()
KASAN reports a use-after-free:
BUG: KASAN: use-after-free in device_del+0xb5b/0xc60
Read of size 8 at addr ffff888008655050 by task rmmod/387
CPU: 2 PID: 387 Comm: rmmod
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Call Trace:
<TASK>
dump_stack_lvl+0x79/0x9a
print_report+0x17f/0x47b
kasan_report+0xbb/0xf0
device_del+0xb5b/0xc60
platform_device_del.part.0+0x24/0x200
platform_device_unregister+0x2e/0x40
snd_soc_exit+0xa/0x22 [snd_soc_core]
__do_sys_delete_module.constprop.0+0x34f/0x5b0
do_syscall_64+0x3a/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
...
</TASK>
It's bacause in snd_soc_init(), snd_soc_util_init() is possble to fail,
but its ret is ignored, which makes soc_dummy_dev unregistered twice.
snd_soc_init()
snd_soc_util_init()
platform_device_register_simple(soc_dummy_dev)
platform_driver_register() # fail
platform_device_unregister(soc_dummy_dev)
platform_driver_register() # success
...
snd_soc_exit()
snd_soc_util_exit()
# soc_dummy_dev will be unregistered for second time
To fix it, handle error and stop snd_soc_init() when util_init() fail.
Also clean debugfs when util_init() or driver_register() fail. |
["https://git.kernel.org/stable/c/2ec3f558db343b045a7c7419cdbaec266b8ac1a7","https://git.kernel.org/stable/c/34eee4189bcebbd5f6a2ff25ef0cb893ad33d51e","https://git.kernel.org/stable/c/41fad4f712e081acdfde8b59847f9f66eaf407a0","https://git.kernel.org/stable/c/6ec27c53886c8963729885bcf2dd996eba2767a7","https://git.kernel.org/stable/c/8d21554ec7680e9585fb852d933203c3db60dad1","https://git.kernel.org/stable/c/90bbdf30a51e42378cb23a312005a022794b8e1e","https://git.kernel.org/stable/c/a3365e62239dc064019a244bde5686ac18527c22","https://git.kernel.org/stable/c/c5674bd073c0fd9f620ca550c5ff08d0d429bdd9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49846
|
High |
fixed |
- 4.9.334
- 4.14.300
- 4.19.267
- 5.4.225
- 5.10.155
- 5.15.79
- 6.0.9
|
In the Linux kernel, the following vulnerability has been resolved:
udf: Fix a slab-out-of-bounds write bug in udf_find_entry()
Syzbot reported a slab-out-of-bounds Write bug:
loop0: detected capacity change from 0 to 2048
==================================================================
BUG: KASAN: slab-out-of-bounds in udf_find_entry+0x8a5/0x14f0
fs/udf/namei.c:253
Write of size 105 at addr ffff8880123ff896 by task syz-executor323/3610
CPU: 0 PID: 3610 Comm: syz-executor323 Not tainted
6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0
Hardware name: Google Compute Engine/Google Compute Engine, BIOS
Google 10/11/2022
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
print_address_description+0x74/0x340 mm/kasan/report.c:284
print_report+0x107/0x1f0 mm/kasan/report.c:395
kasan_report+0xcd/0x100 mm/kasan/report.c:495
kasan_check_range+0x2a7/0x2e0 mm/kasan/generic.c:189
memcpy+0x3c/0x60 mm/kasan/shadow.c:66
udf_find_entry+0x8a5/0x14f0 fs/udf/namei.c:253
udf_lookup+0xef/0x340 fs/udf/namei.c:309
lookup_open fs/namei.c:3391 [inline]
open_last_lookups fs/namei.c:3481 [inline]
path_openat+0x10e6/0x2df0 fs/namei.c:3710
do_filp_open+0x264/0x4f0 fs/namei.c:3740
do_sys_openat2+0x124/0x4e0 fs/open.c:1310
do_sys_open fs/open.c:1326 [inline]
__do_sys_creat fs/open.c:1402 [inline]
__se_sys_creat fs/open.c:1396 [inline]
__x64_sys_creat+0x11f/0x160 fs/open.c:1396
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7ffab0d164d9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89
f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffe1a7e6bb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000055
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffab0d164d9
RDX: 00007ffab0d164d9 RSI: 0000000000000000 RDI: 0000000020000180
RBP: 00007ffab0cd5a10 R08: 0000000000000000 R09: 0000000000000000
R10: 00005555573552c0 R11: 0000000000000246 R12: 00007ffab0cd5aa0
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
</TASK>
Allocated by task 3610:
kasan_save_stack mm/kasan/common.c:45 [inline]
kasan_set_track+0x3d/0x60 mm/kasan/common.c:52
____kasan_kmalloc mm/kasan/common.c:371 [inline]
__kasan_kmalloc+0x97/0xb0 mm/kasan/common.c:380
kmalloc include/linux/slab.h:576 [inline]
udf_find_entry+0x7b6/0x14f0 fs/udf/namei.c:243
udf_lookup+0xef/0x340 fs/udf/namei.c:309
lookup_open fs/namei.c:3391 [inline]
open_last_lookups fs/namei.c:3481 [inline]
path_openat+0x10e6/0x2df0 fs/namei.c:3710
do_filp_open+0x264/0x4f0 fs/namei.c:3740
do_sys_openat2+0x124/0x4e0 fs/open.c:1310
do_sys_open fs/open.c:1326 [inline]
__do_sys_creat fs/open.c:1402 [inline]
__se_sys_creat fs/open.c:1396 [inline]
__x64_sys_creat+0x11f/0x160 fs/open.c:1396
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
The buggy address belongs to the object at ffff8880123ff800
which belongs to the cache kmalloc-256 of size 256
The buggy address is located 150 bytes inside of
256-byte region [ffff8880123ff800, ffff8880123ff900)
The buggy address belongs to the physical page:
page:ffffea000048ff80 refcount:1 mapcount:0 mapping:0000000000000000
index:0x0 pfn:0x123fe
head:ffffea000048ff80 order:1 compound_mapcount:0 compound_pincount:0
flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000010200 ffffea00004b8500 dead000000000003 ffff888012041b40
raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x0(),
pid 1, tgid 1 (swapper/0), ts 1841222404, free_ts 0
create_dummy_stack mm/page_owner.c:
---truncated--- |
["https://git.kernel.org/stable/c/03f9582a6a2ebd25a440896475c968428c4b63e7","https://git.kernel.org/stable/c/583fdd98d94acba1e7225e5cc29063aef0741030","https://git.kernel.org/stable/c/7a6051d734f1ed0031e2216f9a538621235c11a4","https://git.kernel.org/stable/c/ac79001b8e603226fab17240a79cb9ef679d3cd9","https://git.kernel.org/stable/c/c736ed8541605e3a25075bb1cbf8f38cb3083238","https://git.kernel.org/stable/c/c8af247de385ce49afabc3bf1cf4fd455c94bfe8","https://git.kernel.org/stable/c/d8971f410739a864c537e0ac29344a7b6c450232","https://git.kernel.org/stable/c/f1517721c408631f09d54c743aa70cb07fd3eebd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49921
|
High |
fixed |
- 4.5
- 4.9.333
- 4.14.299
- 4.19.265
- 5.4.224
- 5.10.154
- 5.15.78
- 6.0.8
|
In the Linux kernel, the following vulnerability has been resolved:
net: sched: Fix use after free in red_enqueue()
We can't use "skb" again after passing it to qdisc_enqueue(). This is
basically identical to commit 2f09707d0c97 ("sch_sfb: Also store skb
len before calling child enqueue"). |
["https://git.kernel.org/stable/c/170e5317042c302777ed6d59fdb84af9b0219d4e","https://git.kernel.org/stable/c/52e0429471976785c155bfbf51d80990c6cd46e2","https://git.kernel.org/stable/c/5960b9081baca85cc7dcb14aec1de85999ea9d36","https://git.kernel.org/stable/c/795afe0b9bb6c915f0299a8e309936519be01619","https://git.kernel.org/stable/c/8bdc2acd420c6f3dd1f1c78750ec989f02a1e2b9","https://git.kernel.org/stable/c/a238cdcf2bdc72207c74375fc8be13ee549ca9db","https://git.kernel.org/stable/c/e877f8fa49fbccc63cb2df2e9179bddc695b825a","https://git.kernel.org/stable/c/fc4b50adb400ee5ec527a04073174e8e73a139fa"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21999
|
High |
fixed |
- 6.1.132
- 6.6.85
- 6.12.21
- 6.13.9
|
In the Linux kernel, the following vulnerability has been resolved:
proc: fix UAF in proc_get_inode()
Fix race between rmmod and /proc/XXX's inode instantiation.
The bug is that pde->proc_ops don't belong to /proc, it belongs to a
module, therefore dereferencing it after /proc entry has been registered
is a bug unless use_pde/unuse_pde() pair has been used.
use_pde/unuse_pde can be avoided (2 atomic ops!) because pde->proc_ops
never changes so information necessary for inode instantiation can be
saved _before_ proc_register() in PDE itself and used later, avoiding
pde->proc_ops->... dereference.
rmmod lookup
sys_delete_module
proc_lookup_de
pde_get(de);
proc_get_inode(dir->i_sb, de);
mod->exit()
proc_remove
remove_proc_subtree
proc_entry_rundown(de);
free_module(mod);
if (S_ISREG(inode->i_mode))
if (de->proc_ops->proc_read_iter)
--> As module is already freed, will trigger UAF
BUG: unable to handle page fault for address: fffffbfff80a702b
PGD 817fc4067 P4D 817fc4067 PUD 817fc0067 PMD 102ef4067 PTE 0
Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 26 UID: 0 PID: 2667 Comm: ls Tainted: G
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:proc_get_inode+0x302/0x6e0
RSP: 0018:ffff88811c837998 EFLAGS: 00010a06
RAX: dffffc0000000000 RBX: ffffffffc0538140 RCX: 0000000000000007
RDX: 1ffffffff80a702b RSI: 0000000000000001 RDI: ffffffffc0538158
RBP: ffff8881299a6000 R08: 0000000067bbe1e5 R09: 1ffff11023906f20
R10: ffffffffb560ca07 R11: ffffffffb2b43a58 R12: ffff888105bb78f0
R13: ffff888100518048 R14: ffff8881299a6004 R15: 0000000000000001
FS: 00007f95b9686840(0000) GS:ffff8883af100000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff80a702b CR3: 0000000117dd2000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
proc_lookup_de+0x11f/0x2e0
__lookup_slow+0x188/0x350
walk_component+0x2ab/0x4f0
path_lookupat+0x120/0x660
filename_lookup+0x1ce/0x560
vfs_statx+0xac/0x150
__do_sys_newstat+0x96/0x110
do_syscall_64+0x5f/0x170
entry_SYSCALL_64_after_hwframe+0x76/0x7e
[adobriyan@gmail.com: don't do 2 atomic ops on the common path] |
["https://git.kernel.org/stable/c/4b0b8445b6fd41e6f62ac90547a0ea9d348de3fa","https://git.kernel.org/stable/c/63b53198aff2e4e6c5866a4ff73c7891f958ffa4","https://git.kernel.org/stable/c/64dc7c68e040251d9ec6e989acb69f8f6ae4a10b","https://git.kernel.org/stable/c/654b33ada4ab5e926cd9c570196fefa7bec7c1df","https://git.kernel.org/stable/c/966f331403dc3ed04ff64eaf3930cf1267965e53","https://git.kernel.org/stable/c/eda279586e571b05dff44d48e05f8977ad05855d","https://git.kernel.org/stable/c/ede3e8ac90ae106f0b29cd759aadebc1568f1308"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-22004
|
High |
fixed |
- 6.1.132
- 6.6.85
- 6.12.21
- 6.13.9
|
In the Linux kernel, the following vulnerability has been resolved:
net: atm: fix use after free in lec_send()
The ->send() operation frees skb so save the length before calling
->send() to avoid a use after free. |
["https://git.kernel.org/stable/c/326223182e4703cde99fdbd36d07d0b3de9980fb","https://git.kernel.org/stable/c/50e288097c2c6e5f374ae079394436fc29d1e88e","https://git.kernel.org/stable/c/51e8be9578a2e74f9983d8fd8de8cafed191f30c","https://git.kernel.org/stable/c/82d9084a97892de1ee4881eb5c17911fcd9be6f6","https://git.kernel.org/stable/c/8cd90c7db08f32829bfa1b5b2b11fbc542afbab7","https://git.kernel.org/stable/c/9566f6ee13b17a15d0a47667ad1b1893c539f730","https://git.kernel.org/stable/c/f3009d0d6ab78053117f8857b921a8237f4d17b3","https://git.kernel.org/stable/c/f3271f7548385e0096739965961c7cbf7e6b4762"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49892
|
High |
fixed |
- 4.2
- 4.5
- 4.10
- 5.10.154
- 5.15.78
- 6.0.8
|
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix use-after-free for dynamic ftrace_ops
KASAN reported a use-after-free with ftrace ops [1]. It was found from
vmcore that perf had registered two ops with the same content
successively, both dynamic. After unregistering the second ops, a
use-after-free occurred.
In ftrace_shutdown(), when the second ops is unregistered, the
FTRACE_UPDATE_CALLS command is not set because there is another enabled
ops with the same content. Also, both ops are dynamic and the ftrace
callback function is ftrace_ops_list_func, so the
FTRACE_UPDATE_TRACE_FUNC command will not be set. Eventually the value
of 'command' will be 0 and ftrace_shutdown() will skip the rcu
synchronization.
However, ftrace may be activated. When the ops is released, another CPU
may be accessing the ops. Add the missing synchronization to fix this
problem.
[1]
BUG: KASAN: use-after-free in __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline]
BUG: KASAN: use-after-free in ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049
Read of size 8 at addr ffff56551965bbc8 by task syz-executor.2/14468
CPU: 1 PID: 14468 Comm: syz-executor.2 Not tainted 5.10.0 #7
Hardware name: linux,dummy-virt (DT)
Call trace:
dump_backtrace+0x0/0x40c arch/arm64/kernel/stacktrace.c:132
show_stack+0x30/0x40 arch/arm64/kernel/stacktrace.c:196
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b4/0x248 lib/dump_stack.c:118
print_address_description.constprop.0+0x28/0x48c mm/kasan/report.c:387
__kasan_report mm/kasan/report.c:547 [inline]
kasan_report+0x118/0x210 mm/kasan/report.c:564
check_memory_region_inline mm/kasan/generic.c:187 [inline]
__asan_load8+0x98/0xc0 mm/kasan/generic.c:253
__ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline]
ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049
ftrace_graph_call+0x0/0x4
__might_sleep+0x8/0x100 include/linux/perf_event.h:1170
__might_fault mm/memory.c:5183 [inline]
__might_fault+0x58/0x70 mm/memory.c:5171
do_strncpy_from_user lib/strncpy_from_user.c:41 [inline]
strncpy_from_user+0x1f4/0x4b0 lib/strncpy_from_user.c:139
getname_flags+0xb0/0x31c fs/namei.c:149
getname+0x2c/0x40 fs/namei.c:209
[...]
Allocated by task 14445:
kasan_save_stack+0x24/0x50 mm/kasan/common.c:48
kasan_set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc mm/kasan/common.c:479 [inline]
__kasan_kmalloc.constprop.0+0x110/0x13c mm/kasan/common.c:449
kasan_kmalloc+0xc/0x14 mm/kasan/common.c:493
kmem_cache_alloc_trace+0x440/0x924 mm/slub.c:2950
kmalloc include/linux/slab.h:563 [inline]
kzalloc include/linux/slab.h:675 [inline]
perf_event_alloc.part.0+0xb4/0x1350 kernel/events/core.c:11230
perf_event_alloc kernel/events/core.c:11733 [inline]
__do_sys_perf_event_open kernel/events/core.c:11831 [inline]
__se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723
__arm64_sys_perf_event_open+0x6c/0x80 kernel/events/core.c:11723
[...]
Freed by task 14445:
kasan_save_stack+0x24/0x50 mm/kasan/common.c:48
kasan_set_track+0x24/0x34 mm/kasan/common.c:56
kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:358
__kasan_slab_free.part.0+0x11c/0x1b0 mm/kasan/common.c:437
__kasan_slab_free mm/kasan/common.c:445 [inline]
kasan_slab_free+0x2c/0x40 mm/kasan/common.c:446
slab_free_hook mm/slub.c:1569 [inline]
slab_free_freelist_hook mm/slub.c:1608 [inline]
slab_free mm/slub.c:3179 [inline]
kfree+0x12c/0xc10 mm/slub.c:4176
perf_event_alloc.part.0+0xa0c/0x1350 kernel/events/core.c:11434
perf_event_alloc kernel/events/core.c:11733 [inline]
__do_sys_perf_event_open kernel/events/core.c:11831 [inline]
__se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723
[...] |
["https://git.kernel.org/stable/c/0e792b89e6800cd9cb4757a76a96f7ef3e8b6294","https://git.kernel.org/stable/c/88561a66777e7a2fe06638c6dcb22a9fae0b6733","https://git.kernel.org/stable/c/cc1b9961a0ceb70f6ca4e2f4b8bb71c87c7a495c","https://git.kernel.org/stable/c/ea5f2fd4640ecbb9df969bf8bb27733ae2183169"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-53003
|
High |
fixed |
- 5.4.231
- 5.10.166
- 5.15.91
- 6.1.9
|
In the Linux kernel, the following vulnerability has been resolved:
EDAC/qcom: Do not pass llcc_driv_data as edac_device_ctl_info's pvt_info
The memory for llcc_driv_data is allocated by the LLCC driver. But when
it is passed as the private driver info to the EDAC core, it will get freed
during the qcom_edac driver release. So when the qcom_edac driver gets probed
again, it will try to use the freed data leading to the use-after-free bug.
Hence, do not pass llcc_driv_data as pvt_info but rather reference it
using the platform_data pointer in the qcom_edac driver. |
["https://git.kernel.org/stable/c/66e10d5f399629ef7877304d9ba2b35d0474e7eb","https://git.kernel.org/stable/c/6f0351d0c311951b8b3064db91e61841e85b2b96","https://git.kernel.org/stable/c/76d9ebb7f0bc10fbc78b6d576751552edf743968","https://git.kernel.org/stable/c/977c6ba624f24ae20cf0faee871257a39348d4a9","https://git.kernel.org/stable/c/bff5243bd32661cf9ce66f6d9210fc8f89bda145"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21915
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
cdx: Fix possible UAF error in driver_override_show()
Fixed a possible UAF problem in driver_override_show() in drivers/cdx/cdx.c
This function driver_override_show() is part of DEVICE_ATTR_RW, which
includes both driver_override_show() and driver_override_store().
These functions can be executed concurrently in sysfs.
The driver_override_store() function uses driver_set_override() to
update the driver_override value, and driver_set_override() internally
locks the device (device_lock(dev)). If driver_override_show() reads
cdx_dev->driver_override without locking, it could potentially access
a freed pointer if driver_override_store() frees the string
concurrently. This could lead to printing a kernel address, which is a
security risk since DEVICE_ATTR can be read by all users.
Additionally, a similar pattern is used in drivers/amba/bus.c, as well
as many other bus drivers, where device_lock() is taken in the show
function, and it has been working without issues.
This potential bug was detected by our experimental static analysis
tool, which analyzes locking APIs and paired functions to identify
data races and atomicity violations. |
["https://git.kernel.org/stable/c/0439d541aa8d3444ad41c39e39eb71acb57acde3","https://git.kernel.org/stable/c/8473135f89c0949436a22adb05b8cece2fb3da91","https://git.kernel.org/stable/c/91d44c1afc61a2fec37a9c7a3485368309391e0b","https://git.kernel.org/stable/c/d7b339bbc887bcfc1a5b620bfc70c6fbb8f733bf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21967
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in ksmbd_free_work_struct
->interim_entry of ksmbd_work could be deleted after oplock is freed.
We don't need to manage it with linked list. The interim request could be
immediately sent whenever a oplock break wait is needed. |
["https://git.kernel.org/stable/c/62746ae3f5414244a96293e3b017be637b641280","https://git.kernel.org/stable/c/bb39ed47065455604729404729d9116868638d31","https://git.kernel.org/stable/c/eb51f6f59d19b92f6fe84d3873f958495ab32f0a","https://git.kernel.org/stable/c/fb776765bfc21d5e4ed03bb3d4406c2b86ff1ac3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21969
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix slab-use-after-free Read in l2cap_send_cmd
After the hci sync command releases l2cap_conn, the hci receive data work
queue references the released l2cap_conn when sending to the upper layer.
Add hci dev lock to the hci receive data work queue to synchronize the two.
[1]
BUG: KASAN: slab-use-after-free in l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954
Read of size 8 at addr ffff8880271a4000 by task kworker/u9:2/5837
CPU: 0 UID: 0 PID: 5837 Comm: kworker/u9:2 Not tainted 6.13.0-rc5-syzkaller-00163-gab75170520d4 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Workqueue: hci1 hci_rx_work
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0x169/0x550 mm/kasan/report.c:489
kasan_report+0x143/0x180 mm/kasan/report.c:602
l2cap_build_cmd net/bluetooth/l2cap_core.c:2964 [inline]
l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954
l2cap_sig_send_rej net/bluetooth/l2cap_core.c:5502 [inline]
l2cap_sig_channel net/bluetooth/l2cap_core.c:5538 [inline]
l2cap_recv_frame+0x221f/0x10db0 net/bluetooth/l2cap_core.c:6817
hci_acldata_packet net/bluetooth/hci_core.c:3797 [inline]
hci_rx_work+0x508/0xdb0 net/bluetooth/hci_core.c:4040
process_one_work kernel/workqueue.c:3229 [inline]
process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310
worker_thread+0x870/0xd30 kernel/workqueue.c:3391
kthread+0x2f0/0x390 kernel/kthread.c:389
ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
</TASK>
Allocated by task 5837:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
__kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394
kasan_kmalloc include/linux/kasan.h:260 [inline]
__kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329
kmalloc_noprof include/linux/slab.h:901 [inline]
kzalloc_noprof include/linux/slab.h:1037 [inline]
l2cap_conn_add+0xa9/0x8e0 net/bluetooth/l2cap_core.c:6860
l2cap_connect_cfm+0x115/0x1090 net/bluetooth/l2cap_core.c:7239
hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline]
hci_remote_features_evt+0x68e/0xac0 net/bluetooth/hci_event.c:3726
hci_event_func net/bluetooth/hci_event.c:7473 [inline]
hci_event_packet+0xac2/0x1540 net/bluetooth/hci_event.c:7525
hci_rx_work+0x3f3/0xdb0 net/bluetooth/hci_core.c:4035
process_one_work kernel/workqueue.c:3229 [inline]
process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310
worker_thread+0x870/0xd30 kernel/workqueue.c:3391
kthread+0x2f0/0x390 kernel/kthread.c:389
ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
Freed by task 54:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582
poison_slab_object mm/kasan/common.c:247 [inline]
__kasan_slab_free+0x59/0x70 mm/kasan/common.c:264
kasan_slab_free include/linux/kasan.h:233 [inline]
slab_free_hook mm/slub.c:2353 [inline]
slab_free mm/slub.c:4613 [inline]
kfree+0x196/0x430 mm/slub.c:4761
l2cap_connect_cfm+0xcc/0x1090 net/bluetooth/l2cap_core.c:7235
hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline]
hci_conn_failed+0x287/0x400 net/bluetooth/hci_conn.c:1266
hci_abort_conn_sync+0x56c/0x11f0 net/bluetooth/hci_sync.c:5603
hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332
process_one_work kernel/workqueue.c:3229 [inline]
process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310
worker_thread+0x870/0xd30 kernel/workqueue.c:3391
kthread+0x2f0/0x390 kernel/kthread.c:389
ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr
---truncated--- |
["https://git.kernel.org/stable/c/7790a79c6fce8d5d552bc64f5c82819f719e4f28","https://git.kernel.org/stable/c/b4f82f9ed43aefa79bec2504ae8c29be0c0f5d1d","https://git.kernel.org/stable/c/c96cce853542b3b13da3738f35ef1be8cfcc9d1d","https://git.kernel.org/stable/c/f8094625a591eeb0b75b1bd9e713fac1d93f5ca9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52603
|
High |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
UBSAN: array-index-out-of-bounds in dtSplitRoot
Syzkaller reported the following issue:
oop0: detected capacity change from 0 to 32768
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9
index -2 is out of range for type 'struct dtslot [128]'
CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
ubsan_epilogue lib/ubsan.c:151 [inline]
__ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283
dtSplitRoot+0x8d8/0x1900 fs/jfs/jfs_dtree.c:1971
dtSplitUp fs/jfs/jfs_dtree.c:985 [inline]
dtInsert+0x1189/0x6b80 fs/jfs/jfs_dtree.c:863
jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270
vfs_mkdir+0x3b3/0x590 fs/namei.c:4013
do_mkdirat+0x279/0x550 fs/namei.c:4038
__do_sys_mkdirat fs/namei.c:4053 [inline]
__se_sys_mkdirat fs/namei.c:4051 [inline]
__x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fcdc0113fd9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffeb8bc67d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000102
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9
RDX: 0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003
RBP: 00007fcdc00d37a0 R08: 0000000000000000 R09: 00007fcdc00d37a0
R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000
R13: 0000000000000000 R14: 00083878000000f8 R15: 0000000000000000
</TASK>
The issue is caused when the value of fsi becomes less than -1.
The check to break the loop when fsi value becomes -1 is present
but syzbot was able to produce value less than -1 which cause the error.
This patch simply add the change for the values less than 0.
The patch is tested via syzbot. |
["https://git.kernel.org/stable/c/27e56f59bab5ddafbcfe69ad7a4a6ea1279c1b16","https://git.kernel.org/stable/c/6e2902ecc77e9760a9fc447f56d598383e2372d2","https://git.kernel.org/stable/c/7aa33854477d9c346f5560a1a1fcb3fe7783e2a8","https://git.kernel.org/stable/c/e30b52a2ea3d1e0aaee68096957cf90a2f4ec5af","https://git.kernel.org/stable/c/e4cbc857d75d4e22a1f75446e7480b1f305d8d60","https://git.kernel.org/stable/c/e4ce01c25ccbea02a09a5291c21749b1fc358e39","https://git.kernel.org/stable/c/edff092a59260bf0b0a2eba219cb3da6372c2f9f","https://git.kernel.org/stable/c/fd3486a893778770557649fe28afa5e463d4ed07","https://git.kernel.org/stable/c/27e56f59bab5ddafbcfe69ad7a4a6ea1279c1b16","https://git.kernel.org/stable/c/6e2902ecc77e9760a9fc447f56d598383e2372d2","https://git.kernel.org/stable/c/7aa33854477d9c346f5560a1a1fcb3fe7783e2a8","https://git.kernel.org/stable/c/e30b52a2ea3d1e0aaee68096957cf90a2f4ec5af","https://git.kernel.org/stable/c/e4cbc857d75d4e22a1f75446e7480b1f305d8d60","https://git.kernel.org/stable/c/e4ce01c25ccbea02a09a5291c21749b1fc358e39","https://git.kernel.org/stable/c/edff092a59260bf0b0a2eba219cb3da6372c2f9f","https://git.kernel.org/stable/c/fd3486a893778770557649fe28afa5e463d4ed07","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21968
|
High |
fixed |
- 5.10.236
- 5.15.180
- 6.1.132
- 6.6.84
- 6.12.20
- 6.13.8
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix slab-use-after-free on hdcp_work
[Why]
A slab-use-after-free is reported when HDCP is destroyed but the
property_validate_dwork queue is still running.
[How]
Cancel the delayed work when destroying workqueue.
(cherry picked from commit 725a04ba5a95e89c89633d4322430cfbca7ce128) |
["https://git.kernel.org/stable/c/06acfdef370ae018dad9592369e2d2fd9a40c09e","https://git.kernel.org/stable/c/1397715b011bcdc6ad91b17df7acaee301e89db5","https://git.kernel.org/stable/c/378b361e2e30e9729f9a7676f7926868d14f4326","https://git.kernel.org/stable/c/4964dbc4191ab436877a5e3ecd9c67a4e50b7c36","https://git.kernel.org/stable/c/93d701064e56788663d7c5918fbe5e060d5df587","https://git.kernel.org/stable/c/bac7b8b1a3f1a86eeec85835af106cbdc2b9d9f7","https://git.kernel.org/stable/c/e65e7bea220c3ce8c4c793b4ba35557f4994ab2b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21945
|
High |
fixed |
- 6.1.131
- 6.6.83
- 6.12.19
- 6.13.7
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in smb2_lock
If smb_lock->zero_len has value, ->llist of smb_lock is not delete and
flock is old one. It will cause use-after-free on error handling
routine. |
["https://git.kernel.org/stable/c/410ce35a2ed6d0e114132bba29af49b69880c8c7","https://git.kernel.org/stable/c/636e021646cf9b52ddfea7c809b018e91f2188cb","https://git.kernel.org/stable/c/84d2d1641b71dec326e8736a749b7ee76a9599fc","https://git.kernel.org/stable/c/8573571060ca466cbef2c6f03306b2cc7b883506","https://git.kernel.org/stable/c/a0609097fd10d618aed4864038393dd75131289e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4004
|
High |
fixed |
- 5.10.188
- 5.15.123
- 6.1.42
- 6.4.7
|
A use-after-free flaw was found in the Linux kernel's netfilter in the way a user triggers the nft_pipapo_remove function with the element, without a NFT_SET_EXT_KEY_END. This issue could allow a local user to crash the system or potentially escalate their privileges on the system. |
["https://access.redhat.com/errata/RHSA-2023:4961","https://access.redhat.com/errata/RHSA-2023:4962","https://access.redhat.com/errata/RHSA-2023:4967","https://access.redhat.com/errata/RHSA-2023:5069","https://access.redhat.com/errata/RHSA-2023:5091","https://access.redhat.com/errata/RHSA-2023:5093","https://access.redhat.com/errata/RHSA-2023:5221","https://access.redhat.com/errata/RHSA-2023:5244","https://access.redhat.com/errata/RHSA-2023:5255","https://access.redhat.com/errata/RHSA-2023:5548","https://access.redhat.com/errata/RHSA-2023:5627","https://access.redhat.com/errata/RHSA-2023:7382","https://access.redhat.com/errata/RHSA-2023:7389","https://access.redhat.com/errata/RHSA-2023:7411","https://access.redhat.com/errata/RHSA-2023:7417","https://access.redhat.com/errata/RHSA-2023:7431","https://access.redhat.com/errata/RHSA-2023:7434","https://access.redhat.com/security/cve/CVE-2023-4004","https://bugzilla.redhat.com/show_bug.cgi?id=2225275","https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230719190824.21196-1-fw@strlen.de/","http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://access.redhat.com/errata/RHSA-2023:4961","https://access.redhat.com/errata/RHSA-2023:4962","https://access.redhat.com/errata/RHSA-2023:4967","https://access.redhat.com/errata/RHSA-2023:5069","https://access.redhat.com/errata/RHSA-2023:5091","https://access.redhat.com/errata/RHSA-2023:5093","https://access.redhat.com/errata/RHSA-2023:5221","https://access.redhat.com/errata/RHSA-2023:5244","https://access.redhat.com/errata/RHSA-2023:5255","https://access.redhat.com/errata/RHSA-2023:5548","https://access.redhat.com/errata/RHSA-2023:5627","https://access.redhat.com/errata/RHSA-2023:7382","https://access.redhat.com/errata/RHSA-2023:7389","https://access.redhat.com/errata/RHSA-2023:7411","https://access.redhat.com/errata/RHSA-2023:7417","https://access.redhat.com/errata/RHSA-2023:7431","https://access.redhat.com/errata/RHSA-2023:7434","https://access.redhat.com/security/cve/CVE-2023-4004","https://bugzilla.redhat.com/show_bug.cgi?id=2225275","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230719190824.21196-1-fw@strlen.de/","https://security.netapp.com/advisory/ntap-20231027-0001/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-4139
|
High |
fixed |
- 5.4.226
- 5.10.157
- 5.15.81
- 6.0.11
|
An incorrect TLB flush issue was found in the Linux kernel’s GPU i915 kernel driver, potentially leading to random memory corruption or data leaks. This flaw could allow a local user to crash the system or escalate their privileges on the system. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2147572","https://security.netapp.com/advisory/ntap-20230309-0004/","https://www.openwall.com/lists/oss-security/2022/11/30/1","https://bugzilla.redhat.com/show_bug.cgi?id=2147572","https://security.netapp.com/advisory/ntap-20230309-0004/","https://www.openwall.com/lists/oss-security/2022/11/30/1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49888
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
arm64: entry: avoid kprobe recursion
The cortex_a76_erratum_1463225_debug_handler() function is called when
handling debug exceptions (and synchronous exceptions from BRK
instructions), and so is called when a probed function executes. If the
compiler does not inline cortex_a76_erratum_1463225_debug_handler(), it
can be probed.
If cortex_a76_erratum_1463225_debug_handler() is probed, any debug
exception or software breakpoint exception will result in recursive
exceptions leading to a stack overflow. This can be triggered with the
ftrace multiple_probes selftest, and as per the example splat below.
This is a regression caused by commit:
6459b8469753e9fe ("arm64: entry: consolidate Cortex-A76 erratum 1463225 workaround")
... which removed the NOKPROBE_SYMBOL() annotation associated with the
function.
My intent was that cortex_a76_erratum_1463225_debug_handler() would be
inlined into its caller, el1_dbg(), which is marked noinstr and cannot
be probed. Mark cortex_a76_erratum_1463225_debug_handler() as
__always_inline to ensure this.
Example splat prior to this patch (with recursive entries elided):
| # echo p cortex_a76_erratum_1463225_debug_handler > /sys/kernel/debug/tracing/kprobe_events
| # echo p do_el0_svc >> /sys/kernel/debug/tracing/kprobe_events
| # echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable
| Insufficient stack space to handle exception!
| ESR: 0x0000000096000047 -- DABT (current EL)
| FAR: 0xffff800009cefff0
| Task stack: [0xffff800009cf0000..0xffff800009cf4000]
| IRQ stack: [0xffff800008000000..0xffff800008004000]
| Overflow stack: [0xffff00007fbc00f0..0xffff00007fbc10f0]
| CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2
| Hardware name: linux,dummy-virt (DT)
| pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
| pc : arm64_enter_el1_dbg+0x4/0x20
| lr : el1_dbg+0x24/0x5c
| sp : ffff800009cf0000
| x29: ffff800009cf0000 x28: ffff000002c74740 x27: 0000000000000000
| x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
| x23: 00000000604003c5 x22: ffff80000801745c x21: 0000aaaac95ac068
| x20: 00000000f2000004 x19: ffff800009cf0040 x18: 0000000000000000
| x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
| x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
| x11: 0000000000000010 x10: ffff800008c87190 x9 : ffff800008ca00d0
| x8 : 000000000000003c x7 : 0000000000000000 x6 : 0000000000000000
| x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000043a4
| x2 : 00000000f2000004 x1 : 00000000f2000004 x0 : ffff800009cf0040
| Kernel panic - not syncing: kernel stack overflow
| CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2
| Hardware name: linux,dummy-virt (DT)
| Call trace:
| dump_backtrace+0xe4/0x104
| show_stack+0x18/0x4c
| dump_stack_lvl+0x64/0x7c
| dump_stack+0x18/0x38
| panic+0x14c/0x338
| test_taint+0x0/0x2c
| panic_bad_stack+0x104/0x118
| handle_bad_stack+0x34/0x48
| __bad_stack+0x78/0x7c
| arm64_enter_el1_dbg+0x4/0x20
| el1h_64_sync_handler+0x40/0x98
| el1h_64_sync+0x64/0x68
| cortex_a76_erratum_1463225_debug_handler+0x0/0x34
...
| el1h_64_sync_handler+0x40/0x98
| el1h_64_sync+0x64/0x68
| cortex_a76_erratum_1463225_debug_handler+0x0/0x34
...
| el1h_64_sync_handler+0x40/0x98
| el1h_64_sync+0x64/0x68
| cortex_a76_erratum_1463225_debug_handler+0x0/0x34
| el1h_64_sync_handler+0x40/0x98
| el1h_64_sync+0x64/0x68
| do_el0_svc+0x0/0x28
| el0t_64_sync_handler+0x84/0xf0
| el0t_64_sync+0x18c/0x190
| Kernel Offset: disabled
| CPU features: 0x0080,00005021,19001080
| Memory Limit: none
| ---[ end Kernel panic - not syncing: kernel stack overflow ]---
With this patch, cortex_a76_erratum_1463225_debug_handler() is inlined
into el1_dbg(), and el1_dbg() cannot be probed:
| # echo p cortex_a76_erratum_1463225_debug_handler > /sys/kernel/debug/tracing/kprobe_events
| sh: write error: No such file or directory
| # grep -w cortex_a76_errat
---truncated--- |
["https://git.kernel.org/stable/c/024f4b2e1f874934943eb2d3d288ebc52c79f55c","https://git.kernel.org/stable/c/71d6c33fe223255f4416a01514da2c0bc3e283e7","https://git.kernel.org/stable/c/db66629d43b2d12cb43b004a4ca6be1d03228e97"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52975
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: iscsi_tcp: Fix UAF during logout when accessing the shost ipaddress
Bug report and analysis from Ding Hui.
During iSCSI session logout, if another task accesses the shost ipaddress
attr, we can get a KASAN UAF report like this:
[ 276.942144] BUG: KASAN: use-after-free in _raw_spin_lock_bh+0x78/0xe0
[ 276.942535] Write of size 4 at addr ffff8881053b45b8 by task cat/4088
[ 276.943511] CPU: 2 PID: 4088 Comm: cat Tainted: G E 6.1.0-rc8+ #3
[ 276.943997] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
[ 276.944470] Call Trace:
[ 276.944943] <TASK>
[ 276.945397] dump_stack_lvl+0x34/0x48
[ 276.945887] print_address_description.constprop.0+0x86/0x1e7
[ 276.946421] print_report+0x36/0x4f
[ 276.947358] kasan_report+0xad/0x130
[ 276.948234] kasan_check_range+0x35/0x1c0
[ 276.948674] _raw_spin_lock_bh+0x78/0xe0
[ 276.949989] iscsi_sw_tcp_host_get_param+0xad/0x2e0 [iscsi_tcp]
[ 276.951765] show_host_param_ISCSI_HOST_PARAM_IPADDRESS+0xe9/0x130 [scsi_transport_iscsi]
[ 276.952185] dev_attr_show+0x3f/0x80
[ 276.953005] sysfs_kf_seq_show+0x1fb/0x3e0
[ 276.953401] seq_read_iter+0x402/0x1020
[ 276.954260] vfs_read+0x532/0x7b0
[ 276.955113] ksys_read+0xed/0x1c0
[ 276.955952] do_syscall_64+0x38/0x90
[ 276.956347] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 276.956769] RIP: 0033:0x7f5d3a679222
[ 276.957161] Code: c0 e9 b2 fe ff ff 50 48 8d 3d 32 c0 0b 00 e8 a5 fe 01 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24
[ 276.958009] RSP: 002b:00007ffc864d16a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[ 276.958431] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5d3a679222
[ 276.958857] RDX: 0000000000020000 RSI: 00007f5d3a4fe000 RDI: 0000000000000003
[ 276.959281] RBP: 00007f5d3a4fe000 R08: 00000000ffffffff R09: 0000000000000000
[ 276.959682] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000020000
[ 276.960126] R13: 0000000000000003 R14: 0000000000000000 R15: 0000557a26dada58
[ 276.960536] </TASK>
[ 276.961357] Allocated by task 2209:
[ 276.961756] kasan_save_stack+0x1e/0x40
[ 276.962170] kasan_set_track+0x21/0x30
[ 276.962557] __kasan_kmalloc+0x7e/0x90
[ 276.962923] __kmalloc+0x5b/0x140
[ 276.963308] iscsi_alloc_session+0x28/0x840 [scsi_transport_iscsi]
[ 276.963712] iscsi_session_setup+0xda/0xba0 [libiscsi]
[ 276.964078] iscsi_sw_tcp_session_create+0x1fd/0x330 [iscsi_tcp]
[ 276.964431] iscsi_if_create_session.isra.0+0x50/0x260 [scsi_transport_iscsi]
[ 276.964793] iscsi_if_recv_msg+0xc5a/0x2660 [scsi_transport_iscsi]
[ 276.965153] iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi]
[ 276.965546] netlink_unicast+0x4d5/0x7b0
[ 276.965905] netlink_sendmsg+0x78d/0xc30
[ 276.966236] sock_sendmsg+0xe5/0x120
[ 276.966576] ____sys_sendmsg+0x5fe/0x860
[ 276.966923] ___sys_sendmsg+0xe0/0x170
[ 276.967300] __sys_sendmsg+0xc8/0x170
[ 276.967666] do_syscall_64+0x38/0x90
[ 276.968028] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 276.968773] Freed by task 2209:
[ 276.969111] kasan_save_stack+0x1e/0x40
[ 276.969449] kasan_set_track+0x21/0x30
[ 276.969789] kasan_save_free_info+0x2a/0x50
[ 276.970146] __kasan_slab_free+0x106/0x190
[ 276.970470] __kmem_cache_free+0x133/0x270
[ 276.970816] device_release+0x98/0x210
[ 276.971145] kobject_cleanup+0x101/0x360
[ 276.971462] iscsi_session_teardown+0x3fb/0x530 [libiscsi]
[ 276.971775] iscsi_sw_tcp_session_destroy+0xd8/0x130 [iscsi_tcp]
[ 276.972143] iscsi_if_recv_msg+0x1bf1/0x2660 [scsi_transport_iscsi]
[ 276.972485] iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi]
[ 276.972808] netlink_unicast+0x4d5/0x7b0
[ 276.973201] netlink_sendmsg+0x78d/0xc30
[ 276.973544] sock_sendmsg+0xe5/0x120
[ 276.973864] ____sys_sendmsg+0x5fe/0x860
[ 276.974248] ___sys_
---truncated--- |
["https://git.kernel.org/stable/c/17b738590b97fb3fc287289971d1519ff9b875a1","https://git.kernel.org/stable/c/6f1d64b13097e85abda0f91b5638000afc5f9a06","https://git.kernel.org/stable/c/8859687f5b242c0b057461df0a9ff51d5500783b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50073
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: Fix use-after-free in gsm_cleanup_mux
BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0
drivers/tty/n_gsm.c:3160 [n_gsm]
Read of size 8 at addr ffff88815fe99c00 by task poc/3379
CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56
Hardware name: VMware, Inc. VMware Virtual Platform/440BX
Desktop Reference Platform, BIOS 6.00 11/12/2020
Call Trace:
<TASK>
gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]
__pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm]
__pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389
update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500
__pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846
__rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161
gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]
_raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107
__pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm]
ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195
ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79
__pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338
__pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805
tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818
Allocated by task 65:
gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm]
gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm]
gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm]
gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm]
tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391
tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39
flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445
process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229
worker_thread+0x3dc/0x950 kernel/workqueue.c:3391
kthread+0x2a3/0x370 kernel/kthread.c:389
ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257
Freed by task 3367:
kfree+0x126/0x420 mm/slub.c:4580
gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]
gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]
tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818
[Analysis]
gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux
can be freed by multi threads through ioctl,which leads
to the occurrence of uaf. Protect it by gsm tx lock. |
["https://git.kernel.org/stable/c/0eec592c6a7460ba795d7de29f3dc95cb5422e62","https://git.kernel.org/stable/c/9462f4ca56e7d2430fdb6dcc8498244acbfc4489","https://git.kernel.org/stable/c/bf171b5e86e41de4c1cf32fb7aefa275c3d7de49","https://git.kernel.org/stable/c/c29f192e0d44cc1cbaf698fa1ff198f63556691a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52483
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mctp: perform route lookups under a RCU read-side lock
Our current route lookups (mctp_route_lookup and mctp_route_lookup_null)
traverse the net's route list without the RCU read lock held. This means
the route lookup is subject to preemption, resulting in an potential
grace period expiry, and so an eventual kfree() while we still have the
route pointer.
Add the proper read-side critical section locks around the route
lookups, preventing premption and a possible parallel kfree.
The remaining net->mctp.routes accesses are already under a
rcu_read_lock, or protected by the RTNL for updates.
Based on an analysis from Sili Luo <rootlab@huawei.com>, where
introducing a delay in the route lookup could cause a UAF on
simultaneous sendmsg() and route deletion. |
["https://git.kernel.org/stable/c/1db0724a01b558feb1ecae551782add1951a114a","https://git.kernel.org/stable/c/2405f64a95a7a094eb24cba9bcfaffd1ea264de4","https://git.kernel.org/stable/c/5093bbfc10ab6636b32728e35813cbd79feb063c","https://git.kernel.org/stable/c/6c52b12159049046483fdb0c411a0a1869c41a67","https://git.kernel.org/stable/c/1db0724a01b558feb1ecae551782add1951a114a","https://git.kernel.org/stable/c/2405f64a95a7a094eb24cba9bcfaffd1ea264de4","https://git.kernel.org/stable/c/5093bbfc10ab6636b32728e35813cbd79feb063c","https://git.kernel.org/stable/c/6c52b12159049046483fdb0c411a0a1869c41a67"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-4095
|
High |
fixed |
- 4.9.328
- 4.14.293
- 4.19.258
- 5.4.213
- 5.10.142
- 5.15.66
- 5.19.8
|
A use-after-free flaw was found in Linux kernel before 5.19.2. This issue occurs in cmd_hdl_filter in drivers/staging/rtl8712/rtl8712_cmd.c, allowing an attacker to launch a local denial of service attack and gain escalation of privileges. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c53b3dcb9942b8ed7f81ee3921c4085d87070c73","https://security.netapp.com/advisory/ntap-20230420-0005/","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c53b3dcb9942b8ed7f81ee3921c4085d87070c73","https://security.netapp.com/advisory/ntap-20230420-0005/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52624
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Wake DMCUB before executing GPINT commands
[Why]
DMCUB can be in idle when we attempt to interface with the HW through
the GPINT mailbox resulting in a system hang.
[How]
Add dc_wake_and_execute_gpint() to wrap the wake, execute, sleep
sequence.
If the GPINT executes successfully then DMCUB will be put back into
sleep after the optional response is returned.
It functions similar to the inbox command interface. |
["https://git.kernel.org/stable/c/2ef98c6d753a744e333b7e34b9cf687040fba57d","https://git.kernel.org/stable/c/e5ffd1263dd5b44929c676171802e7b6af483f21","https://git.kernel.org/stable/c/2ef98c6d753a744e333b7e34b9cf687040fba57d","https://git.kernel.org/stable/c/e5ffd1263dd5b44929c676171802e7b6af483f21"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48423
|
High |
fixed |
|
In the Linux kernel before 6.1.3, fs/ntfs3/record.c does not validate resident attribute names. An out-of-bounds write may occur. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.3","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=54e45702b648b7c0000e90b3e9b890e367e16ea8","https://security.netapp.com/advisory/ntap-20230505-0003/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.3","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=54e45702b648b7c0000e90b3e9b890e367e16ea8","https://security.netapp.com/advisory/ntap-20230505-0003/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-22020
|
High |
fixed |
- 5.4.292
- 5.10.236
- 5.15.180
- 6.1.133
- 6.6.86
- 6.12.22
- 6.13.10
- 6.14.1
|
In the Linux kernel, the following vulnerability has been resolved:
memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove
This fixes the following crash:
==================================================================
BUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]
Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241
CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1
Tainted: [E]=UNSIGNED_MODULE
Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024
Workqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms]
Call Trace:
<TASK>
dump_stack_lvl+0x51/0x70
print_address_description.constprop.0+0x27/0x320
? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]
print_report+0x3e/0x70
kasan_report+0xab/0xe0
? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]
rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]
? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms]
? __pfx___schedule+0x10/0x10
? kick_pool+0x3b/0x270
process_one_work+0x357/0x660
worker_thread+0x390/0x4c0
? __pfx_worker_thread+0x10/0x10
kthread+0x190/0x1d0
? __pfx_kthread+0x10/0x10
ret_from_fork+0x2d/0x50
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
Allocated by task 161446:
kasan_save_stack+0x20/0x40
kasan_save_track+0x10/0x30
__kasan_kmalloc+0x7b/0x90
__kmalloc_noprof+0x1a7/0x470
memstick_alloc_host+0x1f/0xe0 [memstick]
rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms]
platform_probe+0x60/0xe0
call_driver_probe+0x35/0x120
really_probe+0x123/0x410
__driver_probe_device+0xc7/0x1e0
driver_probe_device+0x49/0xf0
__device_attach_driver+0xc6/0x160
bus_for_each_drv+0xe4/0x160
__device_attach+0x13a/0x2b0
bus_probe_device+0xbd/0xd0
device_add+0x4a5/0x760
platform_device_add+0x189/0x370
mfd_add_device+0x587/0x5e0
mfd_add_devices+0xb1/0x130
rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb]
usb_probe_interface+0x15c/0x460
call_driver_probe+0x35/0x120
really_probe+0x123/0x410
__driver_probe_device+0xc7/0x1e0
driver_probe_device+0x49/0xf0
__device_attach_driver+0xc6/0x160
bus_for_each_drv+0xe4/0x160
__device_attach+0x13a/0x2b0
rebind_marked_interfaces.isra.0+0xcc/0x110
usb_reset_device+0x352/0x410
usbdev_do_ioctl+0xe5c/0x1860
usbdev_ioctl+0xa/0x20
__x64_sys_ioctl+0xc5/0xf0
do_syscall_64+0x59/0x170
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 161506:
kasan_save_stack+0x20/0x40
kasan_save_track+0x10/0x30
kasan_save_free_info+0x36/0x60
__kasan_slab_free+0x34/0x50
kfree+0x1fd/0x3b0
device_release+0x56/0xf0
kobject_cleanup+0x73/0x1c0
rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms]
platform_remove+0x2f/0x50
device_release_driver_internal+0x24b/0x2e0
bus_remove_device+0x124/0x1d0
device_del+0x239/0x530
platform_device_del.part.0+0x19/0xe0
platform_device_unregister+0x1c/0x40
mfd_remove_devices_fn+0x167/0x170
device_for_each_child_reverse+0xc9/0x130
mfd_remove_devices+0x6e/0xa0
rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb]
usb_unbind_interface+0xf3/0x3f0
device_release_driver_internal+0x24b/0x2e0
proc_disconnect_claim+0x13d/0x220
usbdev_do_ioctl+0xb5e/0x1860
usbdev_ioctl+0xa/0x20
__x64_sys_ioctl+0xc5/0xf0
do_syscall_64+0x59/0x170
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Last potentially related work creation:
kasan_save_stack+0x20/0x40
kasan_record_aux_stack+0x85/0x90
insert_work+0x29/0x100
__queue_work+0x34a/0x540
call_timer_fn+0x2a/0x160
expire_timers+0x5f/0x1f0
__run_timer_base.part.0+0x1b6/0x1e0
run_timer_softirq+0x8b/0xe0
handle_softirqs+0xf9/0x360
__irq_exit_rcu+0x114/0x130
sysvec_apic_timer_interrupt+0x72/0x90
asm_sysvec_apic_timer_interrupt+0x16/0x20
Second to last potentially related work creation:
kasan_save_stack+0x20/0x40
kasan_record_aux_stack+0x85/0x90
insert_work+0x29/0x100
__queue_work+0x34a/0x540
call_timer_fn+0x2a/0x160
expire_timers+0x5f/0x1f0
__run_timer_base.part.0+0x1b6/0x1e0
run_timer_softirq+0x8b/0xe0
handle_softirqs+0xf9/0x
---truncated--- |
["https://git.kernel.org/stable/c/0067cb7d7e7c277e91a0887a3c24e71462379469","https://git.kernel.org/stable/c/31f0eaed6914333f42501fc7e0f6830879f5ef2d","https://git.kernel.org/stable/c/4676741a3464b300b486e70585c3c9b692be1632","https://git.kernel.org/stable/c/52d942a5302eefb3b7a3bfee310a5a33feeedc21","https://git.kernel.org/stable/c/6186fb2cd36317277a8423687982140a7f3f7841","https://git.kernel.org/stable/c/75123adf204f997e11bbddee48408c284f51c050","https://git.kernel.org/stable/c/914c5e5bfceb9878f3056eaf4d1c88f2cbe0a185","https://git.kernel.org/stable/c/9dfaf4d723c62bda8d9d1340e2e78acf0c190439","https://git.kernel.org/stable/c/b094e8e3988e02e8cef7a756c8d2cea9c12509ab"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52935
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mm/khugepaged: fix ->anon_vma race
If an ->anon_vma is attached to the VMA, collapse_and_free_pmd() requires
it to be locked.
Page table traversal is allowed under any one of the mmap lock, the
anon_vma lock (if the VMA is associated with an anon_vma), and the
mapping lock (if the VMA is associated with a mapping); and so to be
able to remove page tables, we must hold all three of them.
retract_page_tables() bails out if an ->anon_vma is attached, but does
this check before holding the mmap lock (as the comment above the check
explains).
If we racily merged an existing ->anon_vma (shared with a child
process) from a neighboring VMA, subsequent rmap traversals on pages
belonging to the child will be able to see the page tables that we are
concurrently removing while assuming that nothing else can access them.
Repeat the ->anon_vma check once we hold the mmap lock to ensure that
there really is no concurrent page table access.
Hitting this bug causes a lockdep warning in collapse_and_free_pmd(),
in the line "lockdep_assert_held_write(&vma->anon_vma->root->rwsem)".
It can also lead to use-after-free access. |
["https://git.kernel.org/stable/c/023f47a8250c6bdb4aebe744db4bf7f73414028b","https://git.kernel.org/stable/c/acb08187b5a83cdb9ac4112fae9e18cf983b0128"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-5090
|
Medium |
|
N/A
|
A flaw was found in KVM. An improper check in svm_set_x2apic_msr_interception() may allow direct access to host x2apic msrs when the guest resets its apic, potentially leading to a denial of service condition. |
["https://access.redhat.com/errata/RHSA-2024:2758","https://access.redhat.com/errata/RHSA-2024:3854","https://access.redhat.com/errata/RHSA-2024:3855","https://access.redhat.com/errata/RHSA-2024:4211","https://access.redhat.com/errata/RHSA-2024:4352","https://access.redhat.com/security/cve/CVE-2023-5090","https://bugzilla.redhat.com/show_bug.cgi?id=2248122","https://access.redhat.com/errata/RHSA-2024:3854","https://access.redhat.com/errata/RHSA-2024:3855","https://access.redhat.com/errata/RHSA-2024:4211","https://access.redhat.com/errata/RHSA-2024:4352","https://access.redhat.com/security/cve/CVE-2023-5090","https://bugzilla.redhat.com/show_bug.cgi?id=2248122"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56747
|
Medium |
fixed |
- 4.19.325
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()
Hook "qedi_ops->common->sb_init = qed_sb_init" does not release the DMA
memory sb_virt when it fails. Add dma_free_coherent() to free it. This
is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb(). |
["https://git.kernel.org/stable/c/10a6fc486ac40a410f0fb84cc15161238eccd20a","https://git.kernel.org/stable/c/20b775cf274cfbfa3da871a1108877e17b8b19e1","https://git.kernel.org/stable/c/4e48e5b26b3edc0e1dd329201ffc924a7a1f9337","https://git.kernel.org/stable/c/95bbdca4999bc59a72ebab01663d421d6ce5775d","https://git.kernel.org/stable/c/a4d2011cbe039b25024831427b60ab91ee247066","https://git.kernel.org/stable/c/b778b5240485106abf665eb509cc01779ed0cb00","https://git.kernel.org/stable/c/bb8b45883eb072adba297922b67d1467082ac880","https://git.kernel.org/stable/c/cfc76acaf2c4b43d1e140f1e4cbde15adb540bc5","https://git.kernel.org/stable/c/eaf92fad1f21be63427920c12f22227e5f757424"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3303
|
Medium |
fixed |
|
A race condition flaw was found in the Linux kernel sound subsystem due to improper locking. It could lead to a NULL pointer dereference while handling the SNDCTL_DSP_SYNC ioctl. A privileged local user (root or member of the audio group) could use this flaw to crash the system, resulting in a denial of service condition |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8423f0b6d513b259fdab9c9bf4aaa6188d054c2d","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/all/CAFcO6XN7JDM4xSXGhtusQfS2mSBcx50VJKwQpCq=WeLt57aaZA%40mail.gmail.com/","https://www.debian.org/security/2022/dsa-5257","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8423f0b6d513b259fdab9c9bf4aaa6188d054c2d","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/all/CAFcO6XN7JDM4xSXGhtusQfS2mSBcx50VJKwQpCq=WeLt57aaZA%40mail.gmail.com/","https://www.debian.org/security/2022/dsa-5257"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47660
|
Medium |
fixed |
- 5.10.226
- 5.15.167
- 6.1.109
- 6.6.50
- 6.10.9
|
In the Linux kernel, the following vulnerability has been resolved:
fsnotify: clear PARENT_WATCHED flags lazily
In some setups directories can have many (usually negative) dentries.
Hence __fsnotify_update_child_dentry_flags() function can take a
significant amount of time. Since the bulk of this function happens
under inode->i_lock this causes a significant contention on the lock
when we remove the watch from the directory as the
__fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask()
races with __fsnotify_update_child_dentry_flags() calls from
__fsnotify_parent() happening on children. This can lead upto softlockup
reports reported by users.
Fix the problem by calling fsnotify_update_children_dentry_flags() to
set PARENT_WATCHED flags only when parent starts watching children.
When parent stops watching children, clear false positive PARENT_WATCHED
flags lazily in __fsnotify_parent() for each accessed child. |
["https://git.kernel.org/stable/c/172e422ffea20a89bfdc672741c1aad6fbb5044e","https://git.kernel.org/stable/c/3f3ef1d9f66b93913ce2171120d9226b55acd41d","https://git.kernel.org/stable/c/7ef1d2e240c32b1f337a37232d037b07e3919e1a","https://git.kernel.org/stable/c/d8c42405fc3507cc43ba7e4986a773c3fc633f6e","https://git.kernel.org/stable/c/f9a48bc3dd9099935751458a5bbbea4b7c28abc8","https://git.kernel.org/stable/c/fc1b1e135c3f72382f792e6c319fc088d5523ad5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47668
|
Medium |
fixed |
- 5.4.284
- 5.10.226
- 5.15.167
- 6.1.110
- 6.6.51
- 6.10.10
|
In the Linux kernel, the following vulnerability has been resolved:
lib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc()
If we need to increase the tree depth, allocate a new node, and then
race with another thread that increased the tree depth before us, we'll
still have a preallocated node that might be used later.
If we then use that node for a new non-root node, it'll still have a
pointer to the old root instead of being zeroed - fix this by zeroing it
in the cmpxchg failure path. |
["https://git.kernel.org/stable/c/0f078f8ca93b28a34e20bd050f12cd4efeee7c0f","https://git.kernel.org/stable/c/0f27f4f445390cb7f73d4209cb2bf32834dc53da","https://git.kernel.org/stable/c/99418ec776a39609f50934720419e0b464ca2283","https://git.kernel.org/stable/c/ad5ee9feebc2eb8cfc76ed74a2d6e55343b0e169","https://git.kernel.org/stable/c/b2f11c6f3e1fc60742673b8675c95b78447f3dae","https://git.kernel.org/stable/c/d942e855324a60107025c116245095632476613e","https://git.kernel.org/stable/c/ebeff038744c498a036e7a92eb8e433ae0a386d7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-25012
|
Medium |
|
N/A
|
The Linux kernel through 6.1.9 has a Use-After-Free in bigben_remove in drivers/hid/hid-bigbenff.c via a crafted USB device because the LED controllers remain registered for too long. |
["http://www.openwall.com/lists/oss-security/2023/02/02/1","http://www.openwall.com/lists/oss-security/2023/11/05/1","https://bugzilla.suse.com/show_bug.cgi?id=1207560","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=27d2a2fd844ec7da70d19fabb482304fd1e0595b","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=76ca8da989c7d97a7f76c75d475fe95a584439d7","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9fefb6201c4f8dd9f58c581b2a66e5cde2895ea2","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lore.kernel.org/all/20230125-hid-unregister-leds-v1-1-9a5192dcef16%40diag.uniroma1.it/","https://seclists.org/oss-sec/2023/q1/53","http://www.openwall.com/lists/oss-security/2023/02/02/1","http://www.openwall.com/lists/oss-security/2023/11/05/1","https://bugzilla.suse.com/show_bug.cgi?id=1207560","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=27d2a2fd844ec7da70d19fabb482304fd1e0595b","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=76ca8da989c7d97a7f76c75d475fe95a584439d7","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9fefb6201c4f8dd9f58c581b2a66e5cde2895ea2","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lore.kernel.org/all/20230125-hid-unregister-leds-v1-1-9a5192dcef16%40diag.uniroma1.it/","https://seclists.org/oss-sec/2023/q1/53"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21689
|
Medium |
fixed |
- 5.4.290
- 5.10.234
- 5.15.178
- 6.1.128
- 6.6.75
- 6.12.12
|
In the Linux kernel, the following vulnerability has been resolved:
USB: serial: quatech2: fix null-ptr-deref in qt2_process_read_urb()
This patch addresses a null-ptr-deref in qt2_process_read_urb() due to
an incorrect bounds check in the following:
if (newport > serial->num_ports) {
dev_err(&port->dev,
"%s - port change to invalid port: %i\n",
__func__, newport);
break;
}
The condition doesn't account for the valid range of the serial->port
buffer, which is from 0 to serial->num_ports - 1. When newport is equal
to serial->num_ports, the assignment of "port" in the
following code is out-of-bounds and NULL:
serial_priv->current_port = newport;
port = serial->port[serial_priv->current_port];
The fix checks if newport is greater than or equal to serial->num_ports
indicating it is out-of-bounds. |
["https://git.kernel.org/stable/c/4b9b41fabcd38990f69ef0cee9c631d954a2b530","https://git.kernel.org/stable/c/575a5adf48b06a2980c9eeffedf699ed5534fade","https://git.kernel.org/stable/c/6068dcff7f19e9fa6fa23ee03453ad6a40fa4efe","https://git.kernel.org/stable/c/6377838560c03b36e1153a42ef727533def9b68f","https://git.kernel.org/stable/c/8542b33622571f54dfc2a267fce378b6e3840b8b","https://git.kernel.org/stable/c/94770cf7c5124f0268d481886829dc2beecc4507","https://git.kernel.org/stable/c/f371471708c7d997f763b0e70565026eb67cc470","https://git.kernel.org/stable/c/fa4c7472469d97c4707698b4c0e098f8cfc2bf22"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21697
|
Medium |
fixed |
- 5.4.290
- 5.10.234
- 5.15.177
- 6.1.127
- 6.6.74
- 6.12.11
|
In the Linux kernel, the following vulnerability has been resolved:
drm/v3d: Ensure job pointer is set to NULL after job completion
After a job completes, the corresponding pointer in the device must
be set to NULL. Failing to do so triggers a warning when unloading
the driver, as it appears the job is still active. To prevent this,
assign the job pointer to NULL after completing the job, indicating
the job has finished. |
["https://git.kernel.org/stable/c/14e0a874488e79086340ba8e2d238cb9596b68a8","https://git.kernel.org/stable/c/1bd6303d08c85072ce40ac01a767ab67195105bd","https://git.kernel.org/stable/c/2a1c88f7ca5c12dff6fa6787492ac910bb9e4407","https://git.kernel.org/stable/c/63195bae1cbf78f1d392b1bc9ae4b03c82d0ebf3","https://git.kernel.org/stable/c/a34050f70e7955a359874dff1a912a748724a140","https://git.kernel.org/stable/c/b22467b1ae104073dcb11aa78562a331cd7fb0e0","https://git.kernel.org/stable/c/e4b5ccd392b92300a2b341705cc4805681094e49"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21699
|
Medium |
fixed |
- 5.4.290
- 5.10.234
- 5.15.178
- 6.1.128
- 6.6.75
- 6.12.12
|
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Truncate address space when flipping GFS2_DIF_JDATA flag
Truncate an inode's address space when flipping the GFS2_DIF_JDATA flag:
depending on that flag, the pages in the address space will either use
buffer heads or iomap_folio_state structs, and we cannot mix the two. |
["https://git.kernel.org/stable/c/2a40a140e11fec699e128170ccaa98b6b82cb503","https://git.kernel.org/stable/c/2b0bd5051ad1c1e9ef4879f18e15a7712c974f3e","https://git.kernel.org/stable/c/4516febe325342555bb09ca5b396fb816d655821","https://git.kernel.org/stable/c/4dd57d1f0e9844311c635a7fb39abce4f2ac5a61","https://git.kernel.org/stable/c/4e3ded34f3f3c9d7ed2aac7be8cf51153646574a","https://git.kernel.org/stable/c/5bb1fd0855bb0abc7d97e44758d6ffed7882d2d0","https://git.kernel.org/stable/c/7c9d9223802fbed4dee1ae301661bf346964c9d2","https://git.kernel.org/stable/c/8c41abc11aa8438c9ed2d973f97e66674c0355df"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-47631
|
Medium |
fixed |
- 4.9.311
- 4.14.276
- 4.19.239
- 5.4.190
- 5.10.112
- 5.15.35
- 5.17.4
|
In the Linux kernel, the following vulnerability has been resolved:
ARM: davinci: da850-evm: Avoid NULL pointer dereference
With newer versions of GCC, there is a panic in da850_evm_config_emac()
when booting multi_v5_defconfig in QEMU under the palmetto-bmc machine:
Unable to handle kernel NULL pointer dereference at virtual address 00000020
pgd = (ptrval)
[00000020] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 5.15.0 #1
Hardware name: Generic DT based system
PC is at da850_evm_config_emac+0x1c/0x120
LR is at do_one_initcall+0x50/0x1e0
The emac_pdata pointer in soc_info is NULL because davinci_soc_info only
gets populated on davinci machines but da850_evm_config_emac() is called
on all machines via device_initcall().
Move the rmii_en assignment below the machine check so that it is only
dereferenced when running on a supported SoC. |
["https://git.kernel.org/stable/c/0940795c6834fbe7705acc5c3d4b2f7a5f67527a","https://git.kernel.org/stable/c/0a312ec66a03133d28570f07bc52749ccfef54da","https://git.kernel.org/stable/c/83a1cde5c74bfb44b49cb2a940d044bb2380f4ea","https://git.kernel.org/stable/c/89931d4762572aaee6edbe5673d41f8082de110f","https://git.kernel.org/stable/c/a12b356d45cbb6e8a1b718d1436b3d6239a862f3","https://git.kernel.org/stable/c/c06f476e5b74bcabb8c4a2fba55864a37e62843b","https://git.kernel.org/stable/c/c5628533a3ece64235d04fe11ec44d2be99e423d","https://git.kernel.org/stable/c/c64e2ed5cc376e137e572babfd2edc38b2cfb61b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-47638
|
Medium |
fixed |
- 4.14.276
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
ubifs: rename_whiteout: Fix double free for whiteout_ui->data
'whiteout_ui->data' will be freed twice if space budget fail for
rename whiteout operation as following process:
rename_whiteout
dev = kmalloc
whiteout_ui->data = dev
kfree(whiteout_ui->data) // Free first time
iput(whiteout)
ubifs_free_inode
kfree(ui->data) // Double free!
KASAN reports:
==================================================================
BUG: KASAN: double-free or invalid-free in ubifs_free_inode+0x4f/0x70
Call Trace:
kfree+0x117/0x490
ubifs_free_inode+0x4f/0x70 [ubifs]
i_callback+0x30/0x60
rcu_do_batch+0x366/0xac0
__do_softirq+0x133/0x57f
Allocated by task 1506:
kmem_cache_alloc_trace+0x3c2/0x7a0
do_rename+0x9b7/0x1150 [ubifs]
ubifs_rename+0x106/0x1f0 [ubifs]
do_syscall_64+0x35/0x80
Freed by task 1506:
kfree+0x117/0x490
do_rename.cold+0x53/0x8a [ubifs]
ubifs_rename+0x106/0x1f0 [ubifs]
do_syscall_64+0x35/0x80
The buggy address belongs to the object at ffff88810238bed8 which
belongs to the cache kmalloc-8 of size 8
==================================================================
Let ubifs_free_inode() free 'whiteout_ui->data'. BTW, delete unused
assignment 'whiteout_ui->data_len = 0', process 'ubifs_evict_inode()
-> ubifs_jnl_delete_inode() -> ubifs_jnl_write_inode()' doesn't need it
(because 'inc_nlink(whiteout)' won't be excuted by 'goto out_release',
and the nlink of whiteout inode is 0). |
["https://git.kernel.org/stable/c/14276d38c89a170363e90b6ac0a53c3cf61b87fc","https://git.kernel.org/stable/c/2ad07009c459e56ebdcc089d850d664660fdb742","https://git.kernel.org/stable/c/2b3236ecf96db7af5836e1366ce39ace8ce832fa","https://git.kernel.org/stable/c/40a8f0d5e7b3999f096570edab71c345da812e3e","https://git.kernel.org/stable/c/6d7a158a7363c1f6604aa47ae1a280a5c65123dd","https://git.kernel.org/stable/c/8b3c7be16f3f4dfd6e15ac651484e59d3fa36274","https://git.kernel.org/stable/c/a90e2dbe66d2647ff95a0442ad2e86482d977fd8","https://git.kernel.org/stable/c/b9a937f096e608b3368c1abc920d4d640ba2c94f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-47651
|
Medium |
fixed |
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: rpmpd: Check for null return of devm_kcalloc
Because of the possible failure of the allocation, data->domains might
be NULL pointer and will cause the dereference of the NULL pointer
later.
Therefore, it might be better to check it and directly return -ENOMEM
without releasing data manually if fails, because the comment of the
devm_kmalloc() says "Memory allocated with this function is
automatically freed on driver detach.". |
["https://git.kernel.org/stable/c/31b5124d742969ea8bf7a1360596f548ca23e770","https://git.kernel.org/stable/c/5a811126d38f9767a20cc271b34db7c8efc5a46c","https://git.kernel.org/stable/c/724376c30af5a57686b223dbcd6188e07d2a1de2","https://git.kernel.org/stable/c/755dbc3d73789ac9f0017c729abf5e4b153bf799","https://git.kernel.org/stable/c/84b89fa877ad576e9ee8130f412cfd592f274508","https://git.kernel.org/stable/c/b5d6eba71997b6d661935d2b15094ac7f9f6132d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49055
|
Medium |
fixed |
- 4.9.311
- 4.14.276
- 4.19.239
- 5.4.190
- 5.10.112
- 5.15.35
- 5.17.4
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Check for potential null return of kmalloc_array()
As the kmalloc_array() may return null, the 'event_waiters[i].wait' would lead to null-pointer dereference.
Therefore, it is better to check the return value of kmalloc_array() to avoid this confusion. |
["https://git.kernel.org/stable/c/0a692c625e373fef692ffbc7fc41f8a025f01cb7","https://git.kernel.org/stable/c/1d7a5aae884ca727d41c7ed15d4c82fdb67c040c","https://git.kernel.org/stable/c/32cf90a521dcc0f136db7ee5ba32bfe5f79e460e","https://git.kernel.org/stable/c/40bf32dbfef866c83a3e74800b81d79e52b6d20b","https://git.kernel.org/stable/c/94869bb0de69a812f70231b0eb480bb2f7ae73a6","https://git.kernel.org/stable/c/c7a268b33882d5feaafd29c1734456f41ba41396","https://git.kernel.org/stable/c/ebbb7bb9e80305820dc2328a371c1b35679f2667","https://git.kernel.org/stable/c/f2658d5966bcee8c3eb487875f459756d4f7cdfc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49117
|
Medium |
fixed |
- 5.4.189
- 5.10.111
- 5.15.34
- 5.16.20
- 5.17.3
|
In the Linux kernel, the following vulnerability has been resolved:
mips: ralink: fix a refcount leak in ill_acc_of_setup()
of_node_put(np) needs to be called when pdev == NULL. |
["https://git.kernel.org/stable/c/060a485df4ec1183d543317511cb4caa43468b5d","https://git.kernel.org/stable/c/142ae7d4f21524acfe073e5a3da5667aa85eb970","https://git.kernel.org/stable/c/4a0a1436053b17e50b7c88858fb0824326641793","https://git.kernel.org/stable/c/5fb47ca3490813d3884d8ad0b2ce511aa3537551","https://git.kernel.org/stable/c/8d7f7ef7980f287ace1c15f2ac03d6754e12f071","https://git.kernel.org/stable/c/c74c755daed551b9aceb8388159180861474bdfe"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49137
|
Medium |
fixed |
- 4.19.238
- 5.4.189
- 5.10.111
- 5.15.34
- 5.16.20
- 5.17.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj
This issue takes place in an error path in
amdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls into
default case, the function simply returns -EINVAL, forgetting to
decrement the reference count of a dma_fence obj, which is bumped
earlier by amdgpu_cs_get_fence(). This may result in reference count
leaks.
Fix it by decreasing the refcount of specific object before returning
the error code. |
["https://git.kernel.org/stable/c/3edd8646cb7c11b57c90e026bda6f21076223f5b","https://git.kernel.org/stable/c/4009f104b02b223d1a11d74b36b1cc083bc37028","https://git.kernel.org/stable/c/72d77ddb2224ebc00648f4f78f8a9a259dccbdf7","https://git.kernel.org/stable/c/927beb05aaa429c883cc0ec6adc48964b187e291","https://git.kernel.org/stable/c/b6d1f7d97c81ebaf2cda9c4c943ee2e484fffdcf","https://git.kernel.org/stable/c/bc2d5c0775c839e2b072884f4ee6a93ba410f107","https://git.kernel.org/stable/c/dfced44f122c500004a48ecc8db516bb6a295a1b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49206
|
Medium |
fixed |
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix memory leak in error flow for subscribe event routine
In case the second xa_insert() fails, the obj_event is not released. Fix
the error unwind flow to free that memory to avoid a memory leak. |
["https://git.kernel.org/stable/c/0174a89663a5ef83617da15bf24c0af2f62b6c7f","https://git.kernel.org/stable/c/087f9c3f2309ed183f7e4b85ae57121d8663224d","https://git.kernel.org/stable/c/414b4e8738484379f18d6c4e780787c80dbf8a2c","https://git.kernel.org/stable/c/8dd392e352d3269938fea32061a74655a613f929","https://git.kernel.org/stable/c/c98d903ff9e79c210beddea4e6bc15ac38e25aa5","https://git.kernel.org/stable/c/d66498507801fd9a20307a15a0814a0a016c3cde"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49209
|
Medium |
fixed |
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full
If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc()
returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial
memory has been alloced by sk_msg_alloc(), that is, msg_tx->sg.size is
greater than osize after sk_msg_alloc(), memleak occurs. To fix we use
sk_msg_trim() to release the allocated memory, then goto wait for memory.
Other call paths of sk_msg_alloc() have the similar issue, such as
tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(),
as Cong Wang suggested.
This issue can cause the following info:
WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0
Call Trace:
<TASK>
inet_csk_destroy_sock+0x55/0x110
__tcp_close+0x279/0x470
tcp_close+0x1f/0x60
inet_release+0x3f/0x80
__sock_release+0x3d/0xb0
sock_close+0x11/0x20
__fput+0x92/0x250
task_work_run+0x6a/0xa0
do_exit+0x33b/0xb60
do_group_exit+0x2f/0xa0
get_signal+0xb6/0x950
arch_do_signal_or_restart+0xac/0x2a0
exit_to_user_mode_prepare+0xa9/0x200
syscall_exit_to_user_mode+0x12/0x30
do_syscall_64+0x46/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
</TASK>
WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260
Call Trace:
<TASK>
__sk_destruct+0x24/0x1f0
sk_psock_destroy+0x19b/0x1c0
process_one_work+0x1b3/0x3c0
kthread+0xe6/0x110
ret_from_fork+0x22/0x30
</TASK> |
["https://git.kernel.org/stable/c/6d03722c34d9603df325f67c6d30dc1b7b3c6067","https://git.kernel.org/stable/c/9c34e38c4a870eb30b13f42f5b44f42e9d19ccb8","https://git.kernel.org/stable/c/bec34a91eba3483e1830c02bdd36f8f968642047","https://git.kernel.org/stable/c/d0b85dfc6f01d26808e2576c6537c131b590e270","https://git.kernel.org/stable/c/de3a8d8fab0710186f7864ec812836d8d70da3c9","https://git.kernel.org/stable/c/f677328f05f52d535cbdc15cb04476db49477eb4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49212
|
Medium |
fixed |
- 4.14.276
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
mtd: rawnand: atmel: fix refcount issue in atmel_nand_controller_init
The reference counting issue happens in several error handling paths
on a refcounted object "nc->dmac". In these paths, the function simply
returns the error code, forgetting to balance the reference count of
"nc->dmac", increased earlier by dma_request_channel(), which may
cause refcount leaks.
Fix it by decrementing the refcount of specific object in those error
paths. |
["https://git.kernel.org/stable/c/0856bf27057561f42b37df111603cf5a0d040294","https://git.kernel.org/stable/c/8baea2b96fa90af8d0f937caf4cf2105ee094d93","https://git.kernel.org/stable/c/9843c9c98f26c6ad843260b19bfdaa2598f2ae1e","https://git.kernel.org/stable/c/9b08d211db4c447eb1a07df65e45e0aa772e0fa6","https://git.kernel.org/stable/c/a3587259ae553e41d1ce8c7435351a5d6b299a11","https://git.kernel.org/stable/c/f1694169f3674cdf7553aed06864254635679878","https://git.kernel.org/stable/c/fe0e2ce5c87e9c0b9485ff566362030aa55972cf","https://git.kernel.org/stable/c/fecbd4a317c95d73c849648c406bcf1b6a0ec1cf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49232
|
Medium |
fixed |
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix a NULL pointer dereference in amdgpu_dm_connector_add_common_modes()
In amdgpu_dm_connector_add_common_modes(), amdgpu_dm_create_common_mode()
is assigned to mode and is passed to drm_mode_probed_add() directly after
that. drm_mode_probed_add() passes &mode->head to list_add_tail(), and
there is a dereference of it in list_add_tail() without recoveries, which
could lead to NULL pointer dereference on failure of
amdgpu_dm_create_common_mode().
Fix this by adding a NULL check of mode.
This bug was found by a static analyzer.
Builds with 'make allyesconfig' show no new warnings,
and our static analyzer no longer warns about this code. |
["https://git.kernel.org/stable/c/19a7eba284790cfbba2945deb2363cf03ce41648","https://git.kernel.org/stable/c/2c729dec8c1e3e2892fde5ce8181553860914e74","https://git.kernel.org/stable/c/57f4ad5e286fe4599c8fc63cf89f85f9eec7f9c9","https://git.kernel.org/stable/c/588a70177df3b1777484267584ef38ab2ca899a2","https://git.kernel.org/stable/c/639b3b9def0a6a3f316a195d705d14113236e89c","https://git.kernel.org/stable/c/bdc7429708a0772d90c208975694f7c2133b1202","https://git.kernel.org/stable/c/f4eaa999fec78dec2a9c2d797438e05cbffb125b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49279
|
Medium |
fixed |
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
NFSD: prevent integer overflow on 32 bit systems
On a 32 bit system, the "len * sizeof(*p)" operation can have an
integer overflow. |
["https://git.kernel.org/stable/c/23a9dbbe0faf124fc4c139615633b9d12a3a89ef","https://git.kernel.org/stable/c/303cd6173dce0a28d26526c77814eb90a41bd898","https://git.kernel.org/stable/c/3a2789e8ccb4a3e2a631f6817a2d3bb98b8c4fd8","https://git.kernel.org/stable/c/79b1c54fc6ce09ee0d5fe088bb3de26ae2150e3c","https://git.kernel.org/stable/c/7af164fa2f1abc577d357d22d83a2f3490875d7e","https://git.kernel.org/stable/c/ce1aa09cc14ed625104acc2d487bd92b9a88efe2","https://git.kernel.org/stable/c/e4195d27306ea468a6dc3a27af6f586709951229"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49282
|
Medium |
fixed |
- 5.4.189
- 5.10.110
- 5.14
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: quota: fix loop condition at f2fs_quota_sync()
cnt should be passed to sb_has_quota_active() instead of type to check
active quota properly.
Moreover, when the type is -1, the compiler with enough inline knowledge
can discard sb_has_quota_active() check altogether, causing a NULL pointer
dereference at the following inode_lock(dqopt->files[cnt]):
[ 2.796010] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0
[ 2.796024] Mem abort info:
[ 2.796025] ESR = 0x96000005
[ 2.796028] EC = 0x25: DABT (current EL), IL = 32 bits
[ 2.796029] SET = 0, FnV = 0
[ 2.796031] EA = 0, S1PTW = 0
[ 2.796032] Data abort info:
[ 2.796034] ISV = 0, ISS = 0x00000005
[ 2.796035] CM = 0, WnR = 0
[ 2.796046] user pgtable: 4k pages, 39-bit VAs, pgdp=00000003370d1000
[ 2.796048] [00000000000000a0] pgd=0000000000000000, pud=0000000000000000
[ 2.796051] Internal error: Oops: 96000005 [#1] PREEMPT SMP
[ 2.796056] CPU: 7 PID: 640 Comm: f2fs_ckpt-259:7 Tainted: G S 5.4.179-arter97-r8-64666-g2f16e087f9d8 #1
[ 2.796057] Hardware name: Qualcomm Technologies, Inc. Lahaina MTP lemonadep (DT)
[ 2.796059] pstate: 80c00005 (Nzcv daif +PAN +UAO)
[ 2.796065] pc : down_write+0x28/0x70
[ 2.796070] lr : f2fs_quota_sync+0x100/0x294
[ 2.796071] sp : ffffffa3f48ffc30
[ 2.796073] x29: ffffffa3f48ffc30 x28: 0000000000000000
[ 2.796075] x27: ffffffa3f6d718b8 x26: ffffffa415fe9d80
[ 2.796077] x25: ffffffa3f7290048 x24: 0000000000000001
[ 2.796078] x23: 0000000000000000 x22: ffffffa3f7290000
[ 2.796080] x21: ffffffa3f72904a0 x20: ffffffa3f7290110
[ 2.796081] x19: ffffffa3f77a9800 x18: ffffffc020aae038
[ 2.796083] x17: ffffffa40e38e040 x16: ffffffa40e38e6d0
[ 2.796085] x15: ffffffa40e38e6cc x14: ffffffa40e38e6d0
[ 2.796086] x13: 00000000000004f6 x12: 00162c44ff493000
[ 2.796088] x11: 0000000000000400 x10: ffffffa40e38c948
[ 2.796090] x9 : 0000000000000000 x8 : 00000000000000a0
[ 2.796091] x7 : 0000000000000000 x6 : 0000d1060f00002a
[ 2.796093] x5 : ffffffa3f48ff718 x4 : 000000000000000d
[ 2.796094] x3 : 00000000060c0000 x2 : 0000000000000001
[ 2.796096] x1 : 0000000000000000 x0 : 00000000000000a0
[ 2.796098] Call trace:
[ 2.796100] down_write+0x28/0x70
[ 2.796102] f2fs_quota_sync+0x100/0x294
[ 2.796104] block_operations+0x120/0x204
[ 2.796106] f2fs_write_checkpoint+0x11c/0x520
[ 2.796107] __checkpoint_and_complete_reqs+0x7c/0xd34
[ 2.796109] issue_checkpoint_thread+0x6c/0xb8
[ 2.796112] kthread+0x138/0x414
[ 2.796114] ret_from_fork+0x10/0x18
[ 2.796117] Code: aa0803e0 aa1f03e1 52800022 aa0103e9 (c8e97d02)
[ 2.796120] ---[ end trace 96e942e8eb6a0b53 ]---
[ 2.800116] Kernel panic - not syncing: Fatal exception
[ 2.800120] SMP: stopping secondary CPUs |
["https://git.kernel.org/stable/c/680af5b824a52faa819167628665804a14f0e0df","https://git.kernel.org/stable/c/724469814d805820cd37ea789769dba94123ff1a","https://git.kernel.org/stable/c/e58ee6bd939b773675240f5d0f5b88a367c037c4","https://git.kernel.org/stable/c/e9ebf1e8fc50b6a9336f9aea1082d7845e568d0e","https://git.kernel.org/stable/c/f1d5946d47c0827bae39e1537959ce8d6f0224c5","https://git.kernel.org/stable/c/f9156db0987f1b426015d56505e2c58dee70c90d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49301
|
Medium |
fixed |
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8712: fix uninit-value in usb_read8() and friends
When r8712_usbctrl_vendorreq() returns negative, 'data' in
usb_read{8,16,32} will not be initialized.
BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:643 [inline]
BUG: KMSAN: uninit-value in string+0x4ec/0x6f0 lib/vsprintf.c:725
string_nocheck lib/vsprintf.c:643 [inline]
string+0x4ec/0x6f0 lib/vsprintf.c:725
vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806
va_format lib/vsprintf.c:1704 [inline]
pointer+0x18e6/0x1f70 lib/vsprintf.c:2443
vsnprintf+0x1a9b/0x3650 lib/vsprintf.c:2810
vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158
vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256
dev_vprintk_emit+0x5ef/0x6d0 drivers/base/core.c:4604
dev_printk_emit+0x1dd/0x21f drivers/base/core.c:4615
__dev_printk+0x3be/0x440 drivers/base/core.c:4627
_dev_info+0x1ea/0x22f drivers/base/core.c:4673
r871xu_drv_init+0x1929/0x3070 drivers/staging/rtl8712/usb_intf.c:401
usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396
really_probe+0x6c7/0x1350 drivers/base/dd.c:621
__driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752
driver_probe_device drivers/base/dd.c:782 [inline]
__device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899
bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427
__device_attach+0x593/0x8e0 drivers/base/dd.c:970
device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017
bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487
device_add+0x1fff/0x26e0 drivers/base/core.c:3405
usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170
usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238
usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293
really_probe+0x6c7/0x1350 drivers/base/dd.c:621
__driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752
driver_probe_device drivers/base/dd.c:782 [inline]
__device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899
bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427
__device_attach+0x593/0x8e0 drivers/base/dd.c:970
device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017
bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487
device_add+0x1fff/0x26e0 drivers/base/core.c:3405
usb_new_device+0x1b91/0x2950 drivers/usb/core/hub.c:2566
hub_port_connect drivers/usb/core/hub.c:5363 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5507 [inline]
port_event drivers/usb/core/hub.c:5665 [inline]
hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5747
process_one_work+0xdb6/0x1820 kernel/workqueue.c:2289
worker_thread+0x10d0/0x2240 kernel/workqueue.c:2436
kthread+0x3c7/0x500 kernel/kthread.c:376
ret_from_fork+0x1f/0x30
Local variable data created at:
usb_read8+0x5d/0x130 drivers/staging/rtl8712/usb_ops.c:33
r8712_read8+0xa5/0xd0 drivers/staging/rtl8712/rtl8712_io.c:29
KMSAN: uninit-value in r871xu_drv_init
https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8 |
["https://git.kernel.org/stable/c/33ef21d55418ab6a62a63fd550b2dbe297433372","https://git.kernel.org/stable/c/58762f1c63c75cbe1dc393eed3c9cf8e38310ca1","https://git.kernel.org/stable/c/95b0f54f8a898072a2810c05fab34d971f23a612","https://git.kernel.org/stable/c/d1b57669732d09da7e13ef86d058dab0cd57f6e0","https://git.kernel.org/stable/c/d7ed3c85da0b230bcdf5329acfe012ed093f3daa","https://git.kernel.org/stable/c/de075af8c404f7d59ed34df230aedd9f645fb846"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49318
|
Medium |
fixed |
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: remove WARN_ON in f2fs_is_valid_blkaddr
Syzbot triggers two WARNs in f2fs_is_valid_blkaddr and
__is_bitmap_valid. For example, in f2fs_is_valid_blkaddr,
if type is DATA_GENERIC_ENHANCE or DATA_GENERIC_ENHANCE_READ,
it invokes WARN_ON if blkaddr is not in the right range.
The call trace is as follows:
f2fs_get_node_info+0x45f/0x1070
read_node_page+0x577/0x1190
__get_node_page.part.0+0x9e/0x10e0
__get_node_page
f2fs_get_node_page+0x109/0x180
do_read_inode
f2fs_iget+0x2a5/0x58b0
f2fs_fill_super+0x3b39/0x7ca0
Fix these two WARNs by replacing WARN_ON with dump_stack. |
["https://git.kernel.org/stable/c/0a7a1fc7e71eecf2e5053a6c312c9f0dcbb9b8fd","https://git.kernel.org/stable/c/32bea51fe4c6e92c00403739f7547c89219bea88","https://git.kernel.org/stable/c/8c62c5e26345c34d199b4b8c8e69255ba3d0e751","https://git.kernel.org/stable/c/99c09b298e47ebbe345a6da9f268b32a6b0f4582","https://git.kernel.org/stable/c/cd6374af36cc548464d8c47a93fdba7303bb82a4","https://git.kernel.org/stable/c/dc2f78e2d4cc844a1458653d57ce1b54d4a29f21"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49321
|
Medium |
fixed |
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
xprtrdma: treat all calls not a bcall when bc_serv is NULL
When a rdma server returns a fault format reply, nfs v3 client may
treats it as a bcall when bc service is not exist.
The debug message at rpcrdma_bc_receive_call are,
[56579.837169] RPC: rpcrdma_bc_receive_call: callback XID
00000001, length=20
[56579.837174] RPC: rpcrdma_bc_receive_call: 00 00 00 01 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 04
After that, rpcrdma_bc_receive_call will meets NULL pointer as,
[ 226.057890] BUG: unable to handle kernel NULL pointer dereference at
00000000000000c8
...
[ 226.058704] RIP: 0010:_raw_spin_lock+0xc/0x20
...
[ 226.059732] Call Trace:
[ 226.059878] rpcrdma_bc_receive_call+0x138/0x327 [rpcrdma]
[ 226.060011] __ib_process_cq+0x89/0x170 [ib_core]
[ 226.060092] ib_cq_poll_work+0x26/0x80 [ib_core]
[ 226.060257] process_one_work+0x1a7/0x360
[ 226.060367] ? create_worker+0x1a0/0x1a0
[ 226.060440] worker_thread+0x30/0x390
[ 226.060500] ? create_worker+0x1a0/0x1a0
[ 226.060574] kthread+0x116/0x130
[ 226.060661] ? kthread_flush_work_fn+0x10/0x10
[ 226.060724] ret_from_fork+0x35/0x40
... |
["https://git.kernel.org/stable/c/11270e7ca268e8d61b5d9e5c3a54bd1550642c9c","https://git.kernel.org/stable/c/8dbae5affbdbf524b48000f9d357925bb001e5f4","https://git.kernel.org/stable/c/8e3943c50764dc7c5f25911970c3ff062ec1f18c","https://git.kernel.org/stable/c/90c4f73104016748533a5707ecd15930fbeff402","https://git.kernel.org/stable/c/91784f3d77b73885e1b2e6b59d3cbf0de0a1126a","https://git.kernel.org/stable/c/998d35a2aff4b81a1c784f3aa45cd3afff6814c1","https://git.kernel.org/stable/c/a3fc8051ee061e31db13e2fe011e8e0b71a7f815","https://git.kernel.org/stable/c/da99331fa62131a38a0947a8204c5208de7b0454"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49324
|
Medium |
fixed |
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
mips: cpc: Fix refcount leak in mips_cpc_default_phys_base
Add the missing of_node_put() to release the refcount incremented
by of_find_compatible_node(). |
["https://git.kernel.org/stable/c/1699ec1bfb59304a788901474f6bb003f7831b61","https://git.kernel.org/stable/c/4107fa700f314592850e2c64608f6ede4c077476","https://git.kernel.org/stable/c/8f843cdfc202caaa5d67db3395d893e56362e43a","https://git.kernel.org/stable/c/961ee8a6eeef4632a215d995d837b204f8c7c2d4","https://git.kernel.org/stable/c/aae6b4bb63c694bc91714412718f15468407fe51","https://git.kernel.org/stable/c/bed702566dcdb6ebe300bc0c62bf3600cf4d5874","https://git.kernel.org/stable/c/c667b3872a4c435a3f29d4e15971cd8c378b0043","https://git.kernel.org/stable/c/cc0aed22d33ced9e266c50bdf1cbe668c5acfdf8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49346
|
Medium |
fixed |
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: lantiq_gswip: Fix refcount leak in gswip_gphy_fw_list
Every iteration of for_each_available_child_of_node() decrements
the reference count of the previous node.
when breaking early from a for_each_available_child_of_node() loop,
we need to explicitly call of_node_put() on the gphy_fw_np.
Add missing of_node_put() to avoid refcount leak. |
["https://git.kernel.org/stable/c/0737e018a05e2aa352828c52bdeed3b02cff2930","https://git.kernel.org/stable/c/2e007ac6fa7c9c94ad84da075c5c504afad690a0","https://git.kernel.org/stable/c/32cd78c5610f02a929f63cac985e73692d05f33e","https://git.kernel.org/stable/c/54d6802c4d83fa8de7696cfec06f475d5fd92d27","https://git.kernel.org/stable/c/7c8df6fad43d9d5d77f281f794b2a93cd02fd1a9","https://git.kernel.org/stable/c/c2ae49a113a5344232f1ebb93bcf18bbd11e9c39"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49358
|
Medium |
fixed |
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: memleak flow rule from commit path
Abort path release flow rule object, however, commit path does not.
Update code to destroy these objects before releasing the transaction. |
["https://git.kernel.org/stable/c/330c0c6cd2150a2d7f47af16aa590078b0d2f736","https://git.kernel.org/stable/c/5b8d63489c3b701eb2a76f848ec94d8cbc9373b9","https://git.kernel.org/stable/c/80de9ea1f5b808a6601e91111fae601df2b26369","https://git.kernel.org/stable/c/9dd732e0bdf538b1b76dc7c157e2b5e560ff30d3","https://git.kernel.org/stable/c/ab9f34a30c23f656e76f4c5b83125a4e7b53c86e","https://git.kernel.org/stable/c/e33d9bd563e71f6c6528b96008d65524a459c4dc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49367
|
Medium |
fixed |
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: mv88e6xxx: Fix refcount leak in mv88e6xxx_mdios_register
of_get_child_by_name() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
mv88e6xxx_mdio_register() pass the device node to of_mdiobus_register().
We don't need the device node after it.
Add missing of_node_put() to avoid refcount leak. |
["https://git.kernel.org/stable/c/02ded5a173619b11728b8bf75a3fd995a2c1ff28","https://git.kernel.org/stable/c/42658e47f1abbbe592007d3ba303de466114d0bb","https://git.kernel.org/stable/c/86c3c5f8e4bd1325e24f6fba9017cade29933377","https://git.kernel.org/stable/c/8a1a1255152da4fb934290e7ababc66f24985520","https://git.kernel.org/stable/c/a101793994c0a14c70bb4e44c7fda597eeebba0a","https://git.kernel.org/stable/c/c1df9cb756e5a9ba1841648c44ee5d92306b9c65","https://git.kernel.org/stable/c/dc1cf8c6f9793546696fded437a5b4c84944c48b","https://git.kernel.org/stable/c/e0d763d0c7665c7897e4f5a0847ab0c82543345f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49373
|
Medium |
fixed |
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
watchdog: ts4800_wdt: Fix refcount leak in ts4800_wdt_probe
of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
Add missing of_node_put() in some error paths. |
["https://git.kernel.org/stable/c/5b110d940417942bc87d9e4bea6d4f24e05ed483","https://git.kernel.org/stable/c/5d24df3d690809952528e7a19a43d84bc5b99d44","https://git.kernel.org/stable/c/7a4afd8a003d6abf1f5d159c2bb67e6b7cbde253","https://git.kernel.org/stable/c/910b1cdf6c50ae8fb222e46657d04fb181577017","https://git.kernel.org/stable/c/91fa5aa53f68b85e779164b3127c7e23cad5c457","https://git.kernel.org/stable/c/f067b5286edfd83d2d3903e8578b561599d62539"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49374
|
Medium |
fixed |
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
tipc: check attribute length for bearer name
syzbot reported uninit-value:
=====================================================
BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:644 [inline]
BUG: KMSAN: uninit-value in string+0x4f9/0x6f0 lib/vsprintf.c:725
string_nocheck lib/vsprintf.c:644 [inline]
string+0x4f9/0x6f0 lib/vsprintf.c:725
vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806
vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158
vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256
vprintk_default+0x86/0xa0 kernel/printk/printk.c:2283
vprintk+0x15f/0x180 kernel/printk/printk_safe.c:50
_printk+0x18d/0x1cf kernel/printk/printk.c:2293
tipc_enable_bearer net/tipc/bearer.c:371 [inline]
__tipc_nl_bearer_enable+0x2022/0x22a0 net/tipc/bearer.c:1033
tipc_nl_bearer_enable+0x6c/0xb0 net/tipc/bearer.c:1042
genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]
- Do sanity check the attribute length for TIPC_NLA_BEARER_NAME.
- Do not use 'illegal name' in printing message. |
["https://git.kernel.org/stable/c/292be63c382ce20673ee61dff1ee9ed4a3dcaae7","https://git.kernel.org/stable/c/3af15272cde28fe5c8489174b8624e232c1775ec","https://git.kernel.org/stable/c/7f36f798f89bf32c0164049cb0e3fd1af613d0bb","https://git.kernel.org/stable/c/8b91d0dfc839e67708c905648cd0e7507a2263e5","https://git.kernel.org/stable/c/92a930fcf4250fe961f6238b99af0bc405799f39","https://git.kernel.org/stable/c/b8fac8e321044a9ac50f7185b4e9d91a7745e4b0","https://git.kernel.org/stable/c/f07670871f4d19e613740eebe210e7e9ea535973"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49382
|
Medium |
fixed |
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
soc: rockchip: Fix refcount leak in rockchip_grf_init
of_find_matching_node_and_match returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak. |
["https://git.kernel.org/stable/c/042571fe1d171773655ad706715ecc865913d9a4","https://git.kernel.org/stable/c/28133325526b92921f3269fdf97a20d90b92b217","https://git.kernel.org/stable/c/5b3e990f85eb034faa461e691e719e8ce9e2a3c8","https://git.kernel.org/stable/c/69a30b2ed620c2206cbbd1e9c112e4fc584e02bd","https://git.kernel.org/stable/c/8f64e84924604bb969ee1fbc4b8d7d09b9214889","https://git.kernel.org/stable/c/9b59588d8be91c96bfb0371e912ceb4f16315dbf","https://git.kernel.org/stable/c/aab25b669cb9fd3698c2631be4435f4fe92d9e59","https://git.kernel.org/stable/c/d5422f323858cad3ac3581075f9a3a5e0d41c0d8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49439
|
Medium |
fixed |
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
powerpc/fsl_rio: Fix refcount leak in fsl_rio_setup
of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak. |
["https://git.kernel.org/stable/c/46fd994763cf6884b88a2da712af918f3ed54d7b","https://git.kernel.org/stable/c/51e25fbf20c9152d84a34b7afac15a41fe5c9116","https://git.kernel.org/stable/c/5607a77a365df8c0fd5ff43ac424812b95775527","https://git.kernel.org/stable/c/5b8aa2ba38c010f47c965dd9bb5a8561813ed649","https://git.kernel.org/stable/c/7b668a59ddfb32727e39b06fdf52b28e58c684e0","https://git.kernel.org/stable/c/bcb6c4c5eb4836a21411dfe8247bf9951eb6e7c3","https://git.kernel.org/stable/c/c70dd353d37158e06bf8d450d4b31a7091609924","https://git.kernel.org/stable/c/fcee96924ba1596ca80a6770b2567ca546f9a482"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49451
|
Medium |
fixed |
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Fix list protocols enumeration in the base protocol
While enumerating protocols implemented by the SCMI platform using
BASE_DISCOVER_LIST_PROTOCOLS, the number of returned protocols is
currently validated in an improper way since the check employs a sum
between unsigned integers that could overflow and cause the check itself
to be silently bypassed if the returned value 'loop_num_ret' is big
enough.
Fix the validation avoiding the addition. |
["https://git.kernel.org/stable/c/1052f22e127d0c34c3387bb389424ba1c61491ff","https://git.kernel.org/stable/c/2ccfcd7a09c826516edcfe464b05071961aada3f","https://git.kernel.org/stable/c/444a2d27fe9867d0da4b28fc45b793f32e099ab8","https://git.kernel.org/stable/c/6e7978695f4a6cbd83616b5a702b77fa2087b247","https://git.kernel.org/stable/c/8009120e0354a67068e920eb10dce532391361d0","https://git.kernel.org/stable/c/98342148a8cd242855d7e257f298c966c96dba9f","https://git.kernel.org/stable/c/b0e4bafac8963c2d85ee18d3d01f393735acceec"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49459
|
Medium |
fixed |
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
thermal/drivers/broadcom: Fix potential NULL dereference in sr_thermal_probe
platform_get_resource() may return NULL, add proper check to
avoid potential NULL dereferencing. |
["https://git.kernel.org/stable/c/61621e042c22b47d1eadee617bdd26835294b425","https://git.kernel.org/stable/c/79098339ac2065f4b4352ef5921628970b6f47e6","https://git.kernel.org/stable/c/b3461ccaa5d2588568d865faee285512ad448049","https://git.kernel.org/stable/c/e20d136ec7d6f309989c447638365840d3424c8e","https://git.kernel.org/stable/c/ee9b6b02e8c140323ed46d6602d805ea735c7719","https://git.kernel.org/stable/c/ef1235c6514a58f274246cf4a2d5f4e40af539ce"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49462
|
Medium |
fixed |
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/a6xx: Fix refcount leak in a6xx_gpu_init
of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
a6xx_gmu_init() passes the node to of_find_device_by_node()
and of_dma_configure(), of_find_device_by_node() will takes its
reference, of_dma_configure() doesn't need the node after usage.
Add missing of_node_put() to avoid refcount leak. |
["https://git.kernel.org/stable/c/06907a374f1b74f8f2fb30720dc6df81331e4fb5","https://git.kernel.org/stable/c/48e82ce8cdb19c20a5020fa446b286d6a147450c","https://git.kernel.org/stable/c/65ddbc0d26824e2a5d6154d01d8cf39344900213","https://git.kernel.org/stable/c/6832e36f156ea35a6ed74bca72727806116effdd","https://git.kernel.org/stable/c/c56de483093d7ad0782327f95dda7da97bc4c315","https://git.kernel.org/stable/c/edff4c1af831d0c02e654eed9da7d74174de49d5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49467
|
Medium |
fixed |
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm: msm: fix possible memory leak in mdp5_crtc_cursor_set()
drm_gem_object_lookup will call drm_gem_object_get inside. So cursor_bo
needs to be put when msm_gem_get_and_pin_iova fails. |
["https://git.kernel.org/stable/c/33546183c16c7b9650682dc610bedd732d9c6919","https://git.kernel.org/stable/c/449374565f349d4233beec811d4286fdfe5de44b","https://git.kernel.org/stable/c/656aa3c51fc662064f17179b38ec3ce43af53bca","https://git.kernel.org/stable/c/947a844bb3ebff0f4736d244d792ce129f6700d7","https://git.kernel.org/stable/c/d544880482a5558ec06393b1b3d5dc9275b7a32b","https://git.kernel.org/stable/c/d63ffe3fb3f8327ca21cf91b6a14a2961bc629b4","https://git.kernel.org/stable/c/f8cd192752a1f613b14eee77783c6f0aebb49691"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49472
|
Medium |
fixed |
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
net: phy: micrel: Allow probing without .driver_data
Currently, if the .probe element is present in the phy_driver structure
and the .driver_data is not, a NULL pointer dereference happens.
Allow passing .probe without .driver_data by inserting NULL checks
for priv->type. |
["https://git.kernel.org/stable/c/143878e18001c5a61fcc7ae5c5240323753bb641","https://git.kernel.org/stable/c/1e5fbfc2a6f384e3195446c14bbd3bc298eb88c2","https://git.kernel.org/stable/c/660dfa033ccc9afb032015b6dc76e846bba42cfb","https://git.kernel.org/stable/c/7dcb404662839a4ed1a9703658fee979eb894ca4","https://git.kernel.org/stable/c/91e720b32cba25fa58eaa4c88fe957009cffe9f3","https://git.kernel.org/stable/c/abb5594ae2ba7b82cce85917cc6337ec5d774837","https://git.kernel.org/stable/c/bd219273b4e004a3f853da72e111fc8f81357501","https://git.kernel.org/stable/c/f2ef6f7539c68c6bd6c32323d8845ee102b7c450"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49486
|
Medium |
fixed |
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: fsl: Fix refcount leak in imx_sgtl5000_probe
of_find_i2c_device_by_node() takes a reference,
In error paths, we should call put_device() to drop
the reference to aviod refount leak. |
["https://git.kernel.org/stable/c/41cd312dfe980af869c3503b4d38e62ed20dd3b7","https://git.kernel.org/stable/c/4bfbbfdb3d761323127a67d7d765abe2f77d7b21","https://git.kernel.org/stable/c/7f75e9f629ef54a0845b43889d8ab9dd6e280dd5","https://git.kernel.org/stable/c/922bccdb1796a9e7b989f2bc6d9ada7b499a4329","https://git.kernel.org/stable/c/96fc3da6184af5687e153d420cd7dcdeefdd2f9a","https://git.kernel.org/stable/c/e84aaf23ca82753d765bf84d05295d9d9c5fed29"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49498
|
Medium |
fixed |
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: Check for null pointer of pointer substream before dereferencing it
Pointer substream is being dereferenced on the assignment of pointer card
before substream is being null checked with the macro PCM_RUNTIME_CHECK.
Although PCM_RUNTIME_CHECK calls BUG_ON, it still is useful to perform the
the pointer check before card is assigned. |
["https://git.kernel.org/stable/c/011b559be832194f992f73d6c0d5485f5925a10b","https://git.kernel.org/stable/c/1f2e28857be1e5c7db39bbc221332215fc5467e3","https://git.kernel.org/stable/c/7784d22f81a29df2ec57ca90d54f93a35cbcd1a2","https://git.kernel.org/stable/c/b2421a196cb0911ea95aec1050a0b830464c8fa6","https://git.kernel.org/stable/c/b41ef7ad9238c22aa2e142f5ce4ce1a1a0d48123","https://git.kernel.org/stable/c/f2c68c52898f623fe84518da4606538d193b0cca"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49517
|
Medium |
fixed |
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: mediatek: Fix missing of_node_put in mt2701_wm8960_machine_probe
This node pointer is returned by of_parse_phandle() with
refcount incremented in this function.
Calling of_node_put() to avoid the refcount leak. |
["https://git.kernel.org/stable/c/05654431a18fe24e5e46a375d98904134628a102","https://git.kernel.org/stable/c/318afb1442eeef089fe7f8a8297d97c0302ff6f6","https://git.kernel.org/stable/c/61a85a20e8df5e0a92cfe169c92425c7bae0753b","https://git.kernel.org/stable/c/9345122f5fb9f97a206f440f38bb656e53f46912","https://git.kernel.org/stable/c/94587aa17abf8b26f543d2b29c44abc21bc36836","https://git.kernel.org/stable/c/bc2afecaabd2a2c9f17e43b4793a30e3461bfb29","https://git.kernel.org/stable/c/c71494f5f2b444adfd992a7359a0d2a791642b39","https://git.kernel.org/stable/c/f279c49f17ce10866087ea6c0c57382158974b63"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49527
|
Medium |
fixed |
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi: avoid null dereference in deinit
If venus_probe fails at pm_runtime_put_sync the error handling first
calls hfi_destroy and afterwards hfi_core_deinit. As hfi_destroy sets
core->ops to NULL, hfi_core_deinit cannot call the core_deinit function
anymore.
Avoid this null pointer derefence by skipping the call when necessary. |
["https://git.kernel.org/stable/c/0ac84ab50712879eac3c1dd2598440652a85d3d0","https://git.kernel.org/stable/c/0ed5a643b1a4a46b9b7bfba5d468c10cc30e1359","https://git.kernel.org/stable/c/2533acb652359c9e097dfa33587896af782e8a91","https://git.kernel.org/stable/c/27ad46da44177a78a4a0cae6fe03906888c61aa1","https://git.kernel.org/stable/c/86594f6af867b5165d2ba7b5a71fae3a5961e56c","https://git.kernel.org/stable/c/9c385b961d4c378228e80f6abea8509cb67feab6","https://git.kernel.org/stable/c/a21d15dde21d7e8ae047eb8368677407db45d840","https://git.kernel.org/stable/c/b73ed0510bb8d9647cd8e8a4c4c8772bbe545c3a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49608
|
Medium |
fixed |
- 4.19.254
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: ralink: Check for null return of devm_kcalloc
Because of the possible failure of the allocation, data->domains might
be NULL pointer and will cause the dereference of the NULL pointer
later.
Therefore, it might be better to check it and directly return -ENOMEM
without releasing data manually if fails, because the comment of the
devm_kmalloc() says "Memory allocated with this function is
automatically freed on driver detach.". |
["https://git.kernel.org/stable/c/13596e6c9e541e90e5fc2c52b23f08b951370da9","https://git.kernel.org/stable/c/44016a85419ca0d4f1e4d0127b330f8e4e2a57d0","https://git.kernel.org/stable/c/5595d30c4dc27d939635c3188c68203b6ece1711","https://git.kernel.org/stable/c/5694b162f275fb9a9f89422701b2b963be11e496","https://git.kernel.org/stable/c/6194c021496addc11763d1ffa89ce5751889fe3c","https://git.kernel.org/stable/c/c3b821e8e406d5650e587b7ac624ac24e9b780a8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49609
|
Medium |
fixed |
- 4.9.325
- 4.14.290
- 4.19.254
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
power/reset: arm-versatile: Fix refcount leak in versatile_reboot_probe
of_find_matching_node_and_match() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak. |
["https://git.kernel.org/stable/c/493ceca3271316e74639c89ff8ac35883de64256","https://git.kernel.org/stable/c/49fa778ee044b00471dd9ccae5f6a121fffea1ac","https://git.kernel.org/stable/c/6689754b121bd487f99680280102b3a5cd7374af","https://git.kernel.org/stable/c/71ab83ac65e2d671552374123bf920c1d698335a","https://git.kernel.org/stable/c/78bdf732cf5d74d1c6ecda06830a91f80a4aef6f","https://git.kernel.org/stable/c/80192eff64eee9b3bc0594a47381937b94b9d65a","https://git.kernel.org/stable/c/a9ed3ad3a8d1dfbc829d86edb3236873a315db11","https://git.kernel.org/stable/c/b4d224eec96a18fa8959512cd9e5b6a50bd16a41"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49619
|
Medium |
fixed |
- 4.14.289
- 4.19.253
- 5.4.207
- 5.10.132
- 5.15.56
- 5.18.13
|
In the Linux kernel, the following vulnerability has been resolved:
net: sfp: fix memory leak in sfp_probe()
sfp_probe() allocates a memory chunk from sfp with sfp_alloc(). When
devm_add_action() fails, sfp is not freed, which leads to a memory leak.
We should use devm_add_action_or_reset() instead of devm_add_action(). |
["https://git.kernel.org/stable/c/0a18d802d65cf662644fd1d369c86d84a5630652","https://git.kernel.org/stable/c/1545bc727625ea6e8decd717e5d1e8cc704ccf8f","https://git.kernel.org/stable/c/204543581a2f26bb3b997a304c0bd06926ba7f15","https://git.kernel.org/stable/c/67dc32542a1fb7790d0853cf4a5cf859ac6a2002","https://git.kernel.org/stable/c/9ec5a97f327a89031fce6cfc3e95543c53936638","https://git.kernel.org/stable/c/ede990cfc42775bd0141e21f37ee365dcaeeb50f","https://git.kernel.org/stable/c/f22ddc8a5278d7fb6369a0aeb0d8775a0aefaaee"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49620
|
Medium |
fixed |
- 4.9.324
- 4.14.289
- 4.19.253
- 5.4.207
- 5.10.132
- 5.15.56
- 5.18.13
|
In the Linux kernel, the following vulnerability has been resolved:
net: tipc: fix possible refcount leak in tipc_sk_create()
Free sk in case tipc_sk_insert() fails. |
["https://git.kernel.org/stable/c/00aff3590fc0a73bddd3b743863c14e76fd35c0c","https://git.kernel.org/stable/c/3b2957fc09fe1ac7f07f40dd50dd5f93e3f3a7a2","https://git.kernel.org/stable/c/4919d82f7041157a421ca9bf39a78551d5ad8a1b","https://git.kernel.org/stable/c/638fa20b618b2bbcf86da71231624cc82121a036","https://git.kernel.org/stable/c/7bc9e7f70bc57d8f02ffea2a42094281effb15ef","https://git.kernel.org/stable/c/833ecd0eae76eadf81d6d747bb5bc992d1151867","https://git.kernel.org/stable/c/ef488669b2652bde5b6ee5a409a5b048a2a50db4","https://git.kernel.org/stable/c/efa78f2ae363428525fb4981bb63c555ee79f3c7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49621
|
Medium |
fixed |
- 4.9.324
- 4.14.289
- 4.19.253
- 5.4.207
- 5.10.132
- 5.15.56
- 5.18.13
|
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: pmac32-cpufreq: Fix refcount leak bug
In pmac_cpufreq_init_MacRISC3(), we need to add corresponding
of_node_put() for the three node pointers whose refcount have
been incremented by of_find_node_by_name(). |
["https://git.kernel.org/stable/c/37c16fc2cb13a13f3c0193bfc6f2edef7d7df7d7","https://git.kernel.org/stable/c/3ea9dbf7c2f436952bca331c6f5d72f75aca224e","https://git.kernel.org/stable/c/4513018d0bd739097570d26a7760551cba3deb56","https://git.kernel.org/stable/c/4585890ab2dbf455d80e254d3d859d4c1e357920","https://git.kernel.org/stable/c/4f242486bf46d314b2e3838cc64b56f008a3c4d7","https://git.kernel.org/stable/c/57289b6601fe78c09921599b042a0b430fb420ec","https://git.kernel.org/stable/c/8dda30f81c751b01cd71f2cfaeef26ad4393b1d1","https://git.kernel.org/stable/c/ccd7567d4b6cf187fdfa55f003a9e461ee629e36"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49648
|
Medium |
fixed |
- 4.19.253
- 5.4.207
- 5.10.132
- 5.15.56
- 5.18.13
|
In the Linux kernel, the following vulnerability has been resolved:
tracing/histograms: Fix memory leak problem
This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac.
As commit 46bbe5c671e0 ("tracing: fix double free") said, the
"double free" problem reported by clang static analyzer is:
> In parse_var_defs() if there is a problem allocating
> var_defs.expr, the earlier var_defs.name is freed.
> This free is duplicated by free_var_defs() which frees
> the rest of the list.
However, if there is a problem allocating N-th var_defs.expr:
+ in parse_var_defs(), the freed 'earlier var_defs.name' is
actually the N-th var_defs.name;
+ then in free_var_defs(), the names from 0th to (N-1)-th are freed;
IF ALLOCATING PROBLEM HAPPENED HERE!!! -+
\
|
0th 1th (N-1)-th N-th V
+-------------+-------------+-----+-------------+-----------
var_defs: | name | expr | name | expr | ... | name | expr | name | ///
+-------------+-------------+-----+-------------+-----------
These two frees don't act on same name, so there was no "double free"
problem before. Conversely, after that commit, we get a "memory leak"
problem because the above "N-th var_defs.name" is not freed.
If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th
var_defs.expr allocated, then execute on shell like:
$ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' > \
/sys/kernel/debug/tracing/events/kmem/kmalloc/trigger
Then kmemleak reports:
unreferenced object 0xffff8fb100ef3518 (size 8):
comm "bash", pid 196, jiffies 4295681690 (age 28.538s)
hex dump (first 8 bytes):
76 31 00 00 b1 8f ff ff v1......
backtrace:
[<0000000038fe4895>] kstrdup+0x2d/0x60
[<00000000c99c049a>] event_hist_trigger_parse+0x206f/0x20e0
[<00000000ae70d2cc>] trigger_process_regex+0xc0/0x110
[<0000000066737a4c>] event_trigger_write+0x75/0xd0
[<000000007341e40c>] vfs_write+0xbb/0x2a0
[<0000000087fde4c2>] ksys_write+0x59/0xd0
[<00000000581e9cdf>] do_syscall_64+0x3a/0x80
[<00000000cf3b065c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 |
["https://git.kernel.org/stable/c/22eeff55679d9e7c0f768c79bfbd83e2f8142d89","https://git.kernel.org/stable/c/4d453eb5e1eec89971aa5b3262857ee26cfdffd3","https://git.kernel.org/stable/c/78a1400c42ee11197eb1f0f85ba51df9a4fdfff0","https://git.kernel.org/stable/c/7edc3945bdce9c39198a10d6129377a5c53559c2","https://git.kernel.org/stable/c/eb622d5580b9e2ff694f62da6410618bd73853cb","https://git.kernel.org/stable/c/ecc6dec12c33aa92c086cd702af9f544ddaf3c75"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49649
|
Medium |
fixed |
- 4.9.324
- 4.14.289
- 4.19.253
- 5.4.207
- 5.10.132
- 5.15.56
- 5.18.13
|
In the Linux kernel, the following vulnerability has been resolved:
xen/netback: avoid entering xenvif_rx_next_skb() with an empty rx queue
xenvif_rx_next_skb() is expecting the rx queue not being empty, but
in case the loop in xenvif_rx_action() is doing multiple iterations,
the availability of another skb in the rx queue is not being checked.
This can lead to crashes:
[40072.537261] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080
[40072.537407] IP: xenvif_rx_skb+0x23/0x590 [xen_netback]
[40072.537534] PGD 0 P4D 0
[40072.537644] Oops: 0000 [#1] SMP NOPTI
[40072.537749] CPU: 0 PID: 12505 Comm: v1-c40247-q2-gu Not tainted 4.12.14-122.121-default #1 SLE12-SP5
[40072.537867] Hardware name: HP ProLiant DL580 Gen9/ProLiant DL580 Gen9, BIOS U17 11/23/2021
[40072.537999] task: ffff880433b38100 task.stack: ffffc90043d40000
[40072.538112] RIP: e030:xenvif_rx_skb+0x23/0x590 [xen_netback]
[40072.538217] RSP: e02b:ffffc90043d43de0 EFLAGS: 00010246
[40072.538319] RAX: 0000000000000000 RBX: ffffc90043cd7cd0 RCX: 00000000000000f7
[40072.538430] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffffc90043d43df8
[40072.538531] RBP: 000000000000003f R08: 000077ff80000000 R09: 0000000000000008
[40072.538644] R10: 0000000000007ff0 R11: 00000000000008f6 R12: ffffc90043ce2708
[40072.538745] R13: 0000000000000000 R14: ffffc90043d43ed0 R15: ffff88043ea748c0
[40072.538861] FS: 0000000000000000(0000) GS:ffff880484600000(0000) knlGS:0000000000000000
[40072.538988] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033
[40072.539088] CR2: 0000000000000080 CR3: 0000000407ac8000 CR4: 0000000000040660
[40072.539211] Call Trace:
[40072.539319] xenvif_rx_action+0x71/0x90 [xen_netback]
[40072.539429] xenvif_kthread_guest_rx+0x14a/0x29c [xen_netback]
Fix that by stopping the loop in case the rx queue becomes empty. |
["https://git.kernel.org/stable/c/5a071aefd6414af5a20321ab58a0557b81993687","https://git.kernel.org/stable/c/7425479d20f9e96f7c3ec8e8a93fe0d7478724cb","https://git.kernel.org/stable/c/94e8100678889ab428e68acadf042de723f094b9","https://git.kernel.org/stable/c/b99174ac57fe5d8867448c03b23828e63f24cb1c","https://git.kernel.org/stable/c/b9c32a6886af79d6e0ad87a7b01800ed079cdd02","https://git.kernel.org/stable/c/c0fcceb5f3f1ec197c014fe218c2f28108cacd27","https://git.kernel.org/stable/c/d5320c6a27aa975aff740f9cb481dcbde48f4348","https://git.kernel.org/stable/c/f0b5c819b062df8bf5f2acf4697e3871cb3722da"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49652
|
Medium |
fixed |
- 4.9.323
- 4.14.288
- 4.19.252
- 5.4.205
- 5.10.130
- 5.15.54
- 5.18.11
|
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocate
of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not needed anymore.
Add missing of_node_put() in to fix this. |
["https://git.kernel.org/stable/c/37147e22cd8dfc0412495cb361708836157a4486","https://git.kernel.org/stable/c/3bd66010398871807c1cebacee07d60ded1b1402","https://git.kernel.org/stable/c/452b9dfd7aca96befce22634fadb111737f22bbe","https://git.kernel.org/stable/c/61b4ef19c346dc21ab1d4f39f5c412e3037b2bdc","https://git.kernel.org/stable/c/b31ab132561c7f1b6459039152b8d09e44eb3565","https://git.kernel.org/stable/c/b5a817f8d62e9e13280928f3756e54854ae4962e","https://git.kernel.org/stable/c/c132fe78ad7b4ce8b5d49a501a15c29d08eeb23a","https://git.kernel.org/stable/c/cb9813d7eae917acd34436160a278b8b5d48ca53"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49656
|
Medium |
fixed |
- 4.19.252
- 5.4.205
- 5.10.130
- 5.15.54
- 5.18.11
|
In the Linux kernel, the following vulnerability has been resolved:
ARM: meson: Fix refcount leak in meson_smp_prepare_cpus
of_find_compatible_node() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak. |
["https://git.kernel.org/stable/c/2e1bcd33478ef44e63a45457055060b5fe4118ad","https://git.kernel.org/stable/c/34d2cd3fccced12b958b8848e3eff0ee4296764c","https://git.kernel.org/stable/c/3cf8ece9113242c10f83c7675ea4f4f67959ee43","https://git.kernel.org/stable/c/3d90607e7e6afa89768b0aaa915b58bd2b849276","https://git.kernel.org/stable/c/7208101ded1e9dcc52c8f0f8b16474211c871c1a","https://git.kernel.org/stable/c/c5fbf4f74c94fd60d5e9bf9f7f8268c3601562ca"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49677
|
Medium |
fixed |
- 4.9.321
- 4.14.286
- 4.19.250
- 5.4.202
- 5.10.127
- 5.15.51
- 5.18.8
|
In the Linux kernel, the following vulnerability has been resolved:
ARM: cns3xxx: Fix refcount leak in cns3xxx_init
of_find_compatible_node() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak. |
["https://git.kernel.org/stable/c/1ba904b6b16e08de5aed7c1349838d9cd0d178c5","https://git.kernel.org/stable/c/45bebbc8cea7d586a6216dc62814bdb380b9b29b","https://git.kernel.org/stable/c/68d4303bf59662b64bd555e2aa0518282d20aa4f","https://git.kernel.org/stable/c/b8b84e01ca94e2e1f5492353e9c24dab520b2e5b","https://git.kernel.org/stable/c/c980392af1473d6d5662f70d8089c8e6d85144a4","https://git.kernel.org/stable/c/d1359e4129ad43e43972a28838b87291c51de23d","https://git.kernel.org/stable/c/da3ee7cd2f15922ad88a7ca6deee2eafdc7cd214","https://git.kernel.org/stable/c/dc5170aae24e04068fd5ea125d06c0ab51f48a27"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49678
|
Medium |
fixed |
- 4.19.250
- 5.4.202
- 5.10.127
- 5.15.51
- 5.18.8
|
In the Linux kernel, the following vulnerability has been resolved:
soc: bcm: brcmstb: pm: pm-arm: Fix refcount leak in brcmstb_pm_probe
of_find_matching_node() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak.
In brcmstb_init_sram, it pass dn to of_address_to_resource(),
of_address_to_resource() will call of_find_device_by_node() to take
reference, so we should release the reference returned by
of_find_matching_node(). |
["https://git.kernel.org/stable/c/10ba9d499a9fd82ed40897e734ba19870a879407","https://git.kernel.org/stable/c/30bbfeb480ae8b5ee43199d72417b232590440c2","https://git.kernel.org/stable/c/37d838de369b07b596c19ff3662bf0293fdb09ee","https://git.kernel.org/stable/c/4f5877bdf7b593e988f1924f4c3df6523f80b39c","https://git.kernel.org/stable/c/734a4d15142bb4c8ecad2d8ec70d7564e78ae34d","https://git.kernel.org/stable/c/dcafd5463d8f20c4f90ddc138a5738adb99f74c8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49679
|
Medium |
fixed |
- 4.9.321
- 4.14.286
- 4.19.250
- 5.4.202
- 5.10.127
- 5.15.51
- 5.18.8
|
In the Linux kernel, the following vulnerability has been resolved:
ARM: Fix refcount leak in axxia_boot_secondary
of_find_compatible_node() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak. |
["https://git.kernel.org/stable/c/29ca9c4efacccdc15104a8d4bf10b5183fc92840","https://git.kernel.org/stable/c/3c19fe3f04f4f4e7a2b722c2fd3c98356fc1d72b","https://git.kernel.org/stable/c/44a5b3a073e5aaa5720929dba95b2725eb32bb65","https://git.kernel.org/stable/c/4d9c60e868f7cf8e09956e7d5bb44d807d712699","https://git.kernel.org/stable/c/71e12e5b02674459a24f16e965255d63b31fe049","https://git.kernel.org/stable/c/7c7ff68daa93d8c4cdea482da4f2429c0398fcde","https://git.kernel.org/stable/c/a9b76c232a1ce4cbf27862097f7eb634dcc779eb","https://git.kernel.org/stable/c/b385cb59aac8d61c29bc72ebf3d19a536914af96"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49680
|
Medium |
fixed |
- 4.9.321
- 4.14.286
- 4.19.250
- 5.4.202
- 5.10.127
- 5.15.51
- 5.18.8
|
In the Linux kernel, the following vulnerability has been resolved:
ARM: exynos: Fix refcount leak in exynos_map_pmu
of_find_matching_node() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak.
of_node_put() checks null pointer. |
["https://git.kernel.org/stable/c/31d09571bb071c20f6bdc0bb7ac1ef8dd2987c04","https://git.kernel.org/stable/c/545ae5cbae839ce39bfe09828e413f1c916082de","https://git.kernel.org/stable/c/68f28d52e6cbab8dcfa249cac4356d1d0573e868","https://git.kernel.org/stable/c/7571bcecf01b69f0d3ec60ca41ce5d4c75411a4a","https://git.kernel.org/stable/c/c4c79525042a4a7df96b73477feaf232fe44ae81","https://git.kernel.org/stable/c/d23f76018e17618559da9eea179d137362023f95","https://git.kernel.org/stable/c/f9b77a52937582a5b99a5a07e4ef1e2f48f87347","https://git.kernel.org/stable/c/fc354856e9fad9cd36e2ad28f9da70716025055a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49681
|
Medium |
fixed |
- 4.9.321
- 4.14.286
- 4.19.250
- 5.4.202
- 5.10.127
- 5.15.51
- 5.18.8
|
In the Linux kernel, the following vulnerability has been resolved:
xtensa: xtfpga: Fix refcount leak bug in setup
In machine_setup(), of_find_compatible_node() will return a node
pointer with refcount incremented. We should use of_node_put() when
it is not used anymore. |
["https://git.kernel.org/stable/c/0162451723178602c37f0555d235dfa17e486112","https://git.kernel.org/stable/c/0715d0e60052662c3f225342062f174dd721d1c7","https://git.kernel.org/stable/c/173940b3ae40114d4179c251a98ee039dc9cd5b3","https://git.kernel.org/stable/c/35d7e961be68732eb3acaeba81fb81ca16eafd05","https://git.kernel.org/stable/c/6c0839cf1b9e1b3c88da6af76794583cbfae8da3","https://git.kernel.org/stable/c/9b30c5c8884eda3f541229899671cebbad15979b","https://git.kernel.org/stable/c/a52972ee706b438302eb0350e61f378eb191e3d1","https://git.kernel.org/stable/c/b12d5c52f073a0420622aaf2f21b615cce8b36cc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49682
|
Medium |
fixed |
- 4.9.321
- 4.14.286
- 4.19.250
- 5.4.202
- 5.10.127
- 5.15.51
- 5.18.8
|
In the Linux kernel, the following vulnerability has been resolved:
xtensa: Fix refcount leak bug in time.c
In calibrate_ccount(), of_find_compatible_node() will return a node
pointer with refcount incremented. We should use of_node_put() when
it is not used anymore. |
["https://git.kernel.org/stable/c/0dcc1dd8a5dd9240639f1051dfaa2dffc9fbbde5","https://git.kernel.org/stable/c/0e403a383c14b63c86bd9df085b7e573e9caee64","https://git.kernel.org/stable/c/3e5eb904d9ba657308fc75a5de434b0e58dcb8d7","https://git.kernel.org/stable/c/7de4502af68f4f3932f450157f5483eb7b33cb74","https://git.kernel.org/stable/c/a0117dc956429f2ede17b323046e1968d1849150","https://git.kernel.org/stable/c/af0ff2da01521144bc11194f4c26485d7c9cee73","https://git.kernel.org/stable/c/e5234a9d64a976abd134a14710dcd5188158a7c5","https://git.kernel.org/stable/c/f1eaf4ba5372ad111f687a80c67e270708e14c23"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49707
|
Medium |
fixed |
- 4.9.320
- 4.14.285
- 4.19.249
- 5.4.200
- 5.10.124
- 5.15.49
- 5.18.6
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: add reserved GDT blocks check
We capture a NULL pointer issue when resizing a corrupt ext4 image which
is freshly clear resize_inode feature (not run e2fsck). It could be
simply reproduced by following steps. The problem is because of the
resize_inode feature was cleared, and it will convert the filesystem to
meta_bg mode in ext4_resize_fs(), but the es->s_reserved_gdt_blocks was
not reduced to zero, so could we mistakenly call reserve_backup_gdb()
and passing an uninitialized resize_inode to it when adding new group
descriptors.
mkfs.ext4 /dev/sda 3G
tune2fs -O ^resize_inode /dev/sda #forget to run requested e2fsck
mount /dev/sda /mnt
resize2fs /dev/sda 8G
========
BUG: kernel NULL pointer dereference, address: 0000000000000028
CPU: 19 PID: 3243 Comm: resize2fs Not tainted 5.18.0-rc7-00001-gfde086c5ebfd #748
...
RIP: 0010:ext4_flex_group_add+0xe08/0x2570
...
Call Trace:
<TASK>
ext4_resize_fs+0xbec/0x1660
__ext4_ioctl+0x1749/0x24e0
ext4_ioctl+0x12/0x20
__x64_sys_ioctl+0xa6/0x110
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f2dd739617b
========
The fix is simple, add a check in ext4_resize_begin() to make sure that
the es->s_reserved_gdt_blocks is zero when the resize_inode feature is
disabled. |
["https://git.kernel.org/stable/c/0dc2fca8e4f9ac4a40e8424a10163369cca0cc06","https://git.kernel.org/stable/c/33b1bba31f4c784d33d2c2517964bdccdc9204cd","https://git.kernel.org/stable/c/7c921328ac760bba780bdace41f4cd045f7f1405","https://git.kernel.org/stable/c/af75c481a2e45e70f62f5942c93695e95bf7bd21","https://git.kernel.org/stable/c/b55c3cd102a6f48b90e61c44f7f3dda8c290c694","https://git.kernel.org/stable/c/b9747263b13e5290ac4d63bec47e38f701303cad","https://git.kernel.org/stable/c/bfd004a1d3a062aac300523d406ac1f3e5f1a82c","https://git.kernel.org/stable/c/fba54289176702a7caac0b64738406775817f451"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49712
|
Medium |
fixed |
- 4.9.320
- 4.14.285
- 4.19.249
- 5.4.200
- 5.10.124
- 5.15.49
- 5.18.6
|
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: lpc32xx_udc: Fix refcount leak in lpc32xx_udc_probe
of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak.
of_node_put() will check NULL pointer. |
["https://git.kernel.org/stable/c/0ef6917c0524da5b88496b9706628ffef108b9bb","https://git.kernel.org/stable/c/2a598da14856ead80c726b38ba426c68637d9211","https://git.kernel.org/stable/c/46da1e4a8b6329479433b2a4056941dfdd7f3efd","https://git.kernel.org/stable/c/4757c9ade34178b351580133771f510b5ffcf9c8","https://git.kernel.org/stable/c/57901c658f77d9ea2e772f35cb38e47efb54c558","https://git.kernel.org/stable/c/727c82d003e0ec64411fd1257a9a57de4ad7a99a","https://git.kernel.org/stable/c/b75bddfcc18170ce8e3fb695a76ec2dec4ce0ea5","https://git.kernel.org/stable/c/d85e4e6284a91aa2d1ab004e9d84b9c09b4aa203"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49713
|
Medium |
fixed |
- 4.14.285
- 4.19.249
- 5.4.200
- 5.10.124
- 5.15.49
- 5.18.6
|
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc2: Fix memory leak in dwc2_hcd_init
usb_create_hcd will alloc memory for hcd, and we should
call usb_put_hcd to free it when platform_get_resource()
fails to prevent memory leak.
goto error2 label instead error1 to fix this. |
["https://git.kernel.org/stable/c/3755278f078460b021cd0384562977bf2039a57a","https://git.kernel.org/stable/c/52bfcedbfd5bf962dbdcb6e761f4d0dd3ba26dfd","https://git.kernel.org/stable/c/6506aff2dc2f7059aa3d45ee2e8639b25e87090f","https://git.kernel.org/stable/c/701d8ec01e0f229d4db6f43d3d64ee479120cbeb","https://git.kernel.org/stable/c/84e6d0af87e27bbc0db94f2e7323b34abe17b6e5","https://git.kernel.org/stable/c/981ee40649e5fd9550f82db1fbb3bfab037da346","https://git.kernel.org/stable/c/a44a8a762f7fe9ad3c065813d058e835a6180cb2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49715
|
Medium |
fixed |
- 4.19.249
- 5.4.200
- 5.10.124
- 5.15.49
- 5.18.6
|
In the Linux kernel, the following vulnerability has been resolved:
irqchip/gic-v3: Fix refcount leak in gic_populate_ppi_partitions
of_find_node_by_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak. |
["https://git.kernel.org/stable/c/506a88a5bf261d76a5214c0338a320f2214c67ac","https://git.kernel.org/stable/c/8d884c08eeb83142a7173cb46bcff0434ec42cf1","https://git.kernel.org/stable/c/c136c2924a59a399aa789858cfb320d481964fb7","https://git.kernel.org/stable/c/cc5984cf270b69d03f9f4b27063e535036c659e9","https://git.kernel.org/stable/c/e824482e2c5edacc961b7dd30a92fd47606c3036","https://git.kernel.org/stable/c/fa1ad9d4cc47ca2470cd904ad4519f05d7e43a2b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49719
|
Medium |
fixed |
- 4.9.320
- 4.14.285
- 4.19.249
- 5.4.200
- 5.10.124
- 5.15.49
- 5.18.6
|
In the Linux kernel, the following vulnerability has been resolved:
irqchip/gic/realview: Fix refcount leak in realview_gic_of_init
of_find_matching_node_and_match() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak. |
["https://git.kernel.org/stable/c/16b603cb8d34c2d917983918db1f88c8b831baaa","https://git.kernel.org/stable/c/486f68f85085d9b16ae097679b1486dcb1b6eb69","https://git.kernel.org/stable/c/56526c3883fc7a1f5898b1d40a02c8b8685a5d92","https://git.kernel.org/stable/c/5d38720661a4b9c87705c206a6081177ffb8ec1d","https://git.kernel.org/stable/c/87da903ce632d5689bef66d56ee5dae700d82104","https://git.kernel.org/stable/c/b634af84bc1edece4e63317b0ad95618dd3a8693","https://git.kernel.org/stable/c/e52a58b79f11755ea7e877015c4a1704303fa55f","https://git.kernel.org/stable/c/f4b98e314888cc51486421bcf6d52852452ea48b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49729
|
Medium |
fixed |
- 4.9.320
- 4.14.285
- 4.19.249
- 5.4.200
- 5.10.124
- 5.15.49
- 5.18.6
|
In the Linux kernel, the following vulnerability has been resolved:
nfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred
Similar to the handling of play_deferred in commit 19cfe912c37b
("Bluetooth: btusb: Fix memory leak in play_deferred"), we thought
a patch might be needed here as well.
Currently usb_submit_urb is called directly to submit deferred tx
urbs after unanchor them.
So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb
and cause memory leak.
Put those urbs in tx_anchor to avoid the leak, and also fix the error
handling. |
["https://git.kernel.org/stable/c/0eeec1a8b0cd38c47edeb042980a6aeacecf35ed","https://git.kernel.org/stable/c/1eb0afecfb9cd0f38424b82bd9aaa542310934ee","https://git.kernel.org/stable/c/3e7c7df6991ac349f2fa8540047757df666e610f","https://git.kernel.org/stable/c/3eadc560c1919b8193d17334145dad9a917960e4","https://git.kernel.org/stable/c/6616872cfe7f0474a22dd1f12699f95bcf81a54d","https://git.kernel.org/stable/c/6b4d8b44e7163a77fe942f5b80e1651c1b78c537","https://git.kernel.org/stable/c/8a4d480702b71184fabcf379b80bf7539716752e","https://git.kernel.org/stable/c/f21f908347712b8288ffe83b531b5e977042b29c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21814
|
Medium |
fixed |
- 6.1.129
- 6.6.78
- 6.12.14
- 6.13.3
|
In the Linux kernel, the following vulnerability has been resolved:
ptp: Ensure info->enable callback is always set
The ioctl and sysfs handlers unconditionally call the ->enable callback.
Not all drivers implement that callback, leading to NULL dereferences.
Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c.
Instead use a dummy callback if no better was specified by the driver. |
["https://git.kernel.org/stable/c/1334c64a5d1de6666e0c9f984db6745083df1eb4","https://git.kernel.org/stable/c/5d1041c76de656f9f8d5a192218039a9acf9bd00","https://git.kernel.org/stable/c/755caf4ee1c615ee5717862e427124370f46b1f3","https://git.kernel.org/stable/c/81846070cba17125a866e8023c01d3465b153339","https://git.kernel.org/stable/c/8441aea46445252df5d2eed6deb6d5246fc24002","https://git.kernel.org/stable/c/9df3a9284f39bfd51a9f72a6a165c79e2aa5066b","https://git.kernel.org/stable/c/fd53aa40e65f518453115b6f56183b0c201db26b","https://git.kernel.org/stable/c/fdc1e72487781dd7705bcbe30878bee7d5d1f3e8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-47644
|
Medium |
fixed |
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
media: staging: media: zoran: move videodev alloc
Move some code out of zr36057_init() and create new functions for handling
zr->video_dev. This permit to ease code reading and fix a zr->video_dev
memory leak. |
["https://git.kernel.org/stable/c/1e501ec38796f43e995731d1bcd4173cb1ccfce0","https://git.kernel.org/stable/c/82e3a496eb56da0b9f29fdc5b63cedb3289e91de","https://git.kernel.org/stable/c/bd01629315ffd5b63da91d0bd529a77d30e55028","https://git.kernel.org/stable/c/c1ba65100a359fe28cfe37e09e10c99f247cbf1e","https://git.kernel.org/stable/c/ff3357bffd9fb78f59762d8955afc7382a279079"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-47645
|
Medium |
fixed |
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
media: staging: media: zoran: calculate the right buffer number for zoran_reap_stat_com
On the case tmp_dcim=1, the index of buffer is miscalculated.
This generate a NULL pointer dereference later.
So let's fix the calcul and add a check to prevent this to reappear. |
["https://git.kernel.org/stable/c/20811bbe685ca3eddd34b0c750860427d7030910","https://git.kernel.org/stable/c/20db2ed1e2f9fcd417fa67853e5154f0c2537d6c","https://git.kernel.org/stable/c/7e76f3ed7ab2ae026c6ef9cc23096a7554af8c52","https://git.kernel.org/stable/c/bafec1a6ba4b187a7fcdcfce0faebdc623d4ef8e","https://git.kernel.org/stable/c/e3b86f4e558cea9eed71d894df2f19b10d60a207"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-47648
|
Medium |
fixed |
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
gpu: host1x: Fix a memory leak in 'host1x_remove()'
Add a missing 'host1x_channel_list_free()' call in the remove function,
as already done in the error handling path of the probe function. |
["https://git.kernel.org/stable/c/025c6643a81564f066d8381b9e2f4603e0f8438f","https://git.kernel.org/stable/c/5124a344983e1b9670dae7add0e4d00d589aabcd","https://git.kernel.org/stable/c/6bb107332db28a0e9256c2d36a0902b85307612c","https://git.kernel.org/stable/c/c06577a80485511b894cb688e881ef0bc2d1d296","https://git.kernel.org/stable/c/fe1ce680560d4f0049ffa0c687de17567421c1ec"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49060
|
Medium |
fixed |
- 5.4.190
- 5.10.112
- 5.15.35
- 5.17.4
|
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Fix NULL pointer dereference in smc_pnet_find_ib()
dev_name() was called with dev.parent as argument but without to
NULL-check it before.
Solve this by checking the pointer before the call to dev_name(). |
["https://git.kernel.org/stable/c/22025513ced3d599ee8b24169141c95cf2467a4a","https://git.kernel.org/stable/c/35b91e49bc80ca944a8679c3b139ddaf2f8eea0f","https://git.kernel.org/stable/c/3a523807f01455fe9a0c1a433f27cd4411ee400f","https://git.kernel.org/stable/c/a05f5e26cb8bb4d07e0595545fcad1bb406f0085","https://git.kernel.org/stable/c/d22f4f977236f97e01255a80bca2ea93a8094fc8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49061
|
Medium |
fixed |
- 5.4.190
- 5.10.112
- 5.15.35
- 5.17.4
|
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: stmmac: fix altr_tse_pcs function when using a fixed-link
When using a fixed-link, the altr_tse_pcs driver crashes
due to null-pointer dereference as no phy_device is provided to
tse_pcs_fix_mac_speed function. Fix this by adding a check for
phy_dev before calling the tse_pcs_fix_mac_speed() function.
Also clean up the tse_pcs_fix_mac_speed function a bit. There is
no need to check for splitter_base and sgmii_adapter_base
because the driver will fail if these 2 variables are not
derived from the device tree. |
["https://git.kernel.org/stable/c/08d5e3e954537931c8da7428034808d202e98299","https://git.kernel.org/stable/c/62a48383ebe2e159fd68425dd3e16d4c6bd6599a","https://git.kernel.org/stable/c/6c020f05253df04c3480b586fe188a3582740049","https://git.kernel.org/stable/c/7e59fdf9547c4f948d1d917ec7ffa5fb5ac53bdb","https://git.kernel.org/stable/c/a6aaa00324240967272b451bfa772547bd576ee6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49103
|
Medium |
fixed |
- 5.10.111
- 5.15.34
- 5.16.20
- 5.17.3
|
In the Linux kernel, the following vulnerability has been resolved:
NFSv4.2: fix reference count leaks in _nfs42_proc_copy_notify()
[You don't often get email from xiongx18@fudan.edu.cn. Learn why this is important at http://aka.ms/LearnAboutSenderIdentification.]
The reference counting issue happens in two error paths in the
function _nfs42_proc_copy_notify(). In both error paths, the function
simply returns the error code and forgets to balance the refcount of
object `ctx`, bumped by get_nfs_open_context() earlier, which may
cause refcount leaks.
Fix it by balancing refcount of the `ctx` object before the function
returns in both error paths. |
["https://git.kernel.org/stable/c/9b9feec97c1fc7dd9bb69f62c4905cddf1801599","https://git.kernel.org/stable/c/b37f482ba9f0e6382c188e3fccf6c4b2fdc938eb","https://git.kernel.org/stable/c/b7f114edd54326f730a754547e7cfb197b5bc132","https://git.kernel.org/stable/c/f46f632f9cfae4b2e3635fa58840a8ec584c42e3","https://git.kernel.org/stable/c/fb73bf6305f4eb8f0cf9a61ee874d55f019d6dc4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49104
|
Medium |
fixed |
- 5.10.111
- 5.15.34
- 5.16.20
- 5.17.3
|
In the Linux kernel, the following vulnerability has been resolved:
staging: vchiq_core: handle NULL result of find_service_by_handle
In case of an invalid handle the function find_servive_by_handle
returns NULL. So take care of this and avoid a NULL pointer dereference. |
["https://git.kernel.org/stable/c/04202f54dd8899e10f56a89c4c1ede0043fa22af","https://git.kernel.org/stable/c/3b424f6586a870b8d657c5e5419465bbe0e7b61f","https://git.kernel.org/stable/c/42f2142a337ee372455574809fc924580a7e51b2","https://git.kernel.org/stable/c/aa0b7296785312a4bfa8fac0ba8ad78698fd9fcf","https://git.kernel.org/stable/c/ca225857faf237234d2fffe5d1919467dfadd822"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49105
|
Medium |
fixed |
- 5.10.111
- 5.15.34
- 5.16.20
- 5.17.3
|
In the Linux kernel, the following vulnerability has been resolved:
staging: wfx: fix an error handling in wfx_init_common()
One error handler of wfx_init_common() return without calling
ieee80211_free_hw(hw), which may result in memory leak. And I add
one err label to unify the error handler, which is useful for the
subsequent changes. |
["https://git.kernel.org/stable/c/60f1d3c92dc1ef1026e5b917a329a7fa947da036","https://git.kernel.org/stable/c/86efcb524ae1889ae73f2a2f0bb7fff2ec757ab0","https://git.kernel.org/stable/c/93498c6e775ae91732a8109dba1bdcd324908f84","https://git.kernel.org/stable/c/9727912e906762a63c1a667c84731d3427653f88","https://git.kernel.org/stable/c/ab0fed1fa744173433cfd1dbaf9239f200ded650"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49107
|
Medium |
fixed |
- 5.10.111
- 5.15.34
- 5.16.20
- 5.17.3
|
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix memory leak in ceph_readdir when note_last_dentry returns error
Reset the last_readdir at the same time, and add a comment explaining
why we don't free last_readdir when dir_emit returns false. |
["https://git.kernel.org/stable/c/2fe82d3254029ef9ec4e7be890125d5ef4f537de","https://git.kernel.org/stable/c/7f740ede35132d3d5d19747cad56a511d21bb156","https://git.kernel.org/stable/c/e792575b902a3939ca482491ee9fb3a236f99640","https://git.kernel.org/stable/c/f4429786129648a8f4bb1e5faa143c4478cc5c4a","https://git.kernel.org/stable/c/f639d9867eea647005dc824e0e24f39ffc50d4e4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49113
|
Medium |
fixed |
- 5.10.111
- 5.15.34
- 5.16.20
- 5.17.3
|
In the Linux kernel, the following vulnerability has been resolved:
powerpc/secvar: fix refcount leak in format_show()
Refcount leak will happen when format_show returns failure in multiple
cases. Unified management of of_node_put can fix this problem. |
["https://git.kernel.org/stable/c/02222bf4f0a27f6eba66d1f597cdb5daadd51829","https://git.kernel.org/stable/c/2a71e3ecd829a82013cf095c55068c61d991e885","https://git.kernel.org/stable/c/c105ffb6b9744158e37e9f81f0f38861951d1c1f","https://git.kernel.org/stable/c/d05e4265d33af60b39606c20c731e3e719bfe3d6","https://git.kernel.org/stable/c/d601fd24e6964967f115f036a840f4f28488f63f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49115
|
Medium |
fixed |
- 5.10.111
- 5.15.34
- 5.16.20
- 5.17.3
|
In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: Fix misused goto label
Fix a misused goto label jump since that can result in a memory leak. |
["https://git.kernel.org/stable/c/70236a0d2d62b081d52076de22d8d017d6cbe99f","https://git.kernel.org/stable/c/7c657c0694ff690e361a13ce41c36b9dfb433ec8","https://git.kernel.org/stable/c/bf8d87c076f55b8b4dfdb6bc6c6b6dc0c2ccb487","https://git.kernel.org/stable/c/d3642fc64276b06446290f82fd45630aeaa4b007","https://git.kernel.org/stable/c/dc9d33b2d8d09e6478e8ef817a81cf26930acc3e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49116
|
Medium |
fixed |
- 5.10.111
- 5.15.34
- 5.16.20
- 5.17.3
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: use memset avoid memory leaks
Use memset to initialize structs to prevent memory leaks
in l2cap_ecred_connect |
["https://git.kernel.org/stable/c/42b6a39f439b6f37cc2024d91ce547d83290ff78","https://git.kernel.org/stable/c/9567d54e70ff58c2695c2cc2e53c86c67551d3e6","https://git.kernel.org/stable/c/d3715b2333e9a21692ba16ef8645eda584a9515d","https://git.kernel.org/stable/c/d588c183a971b85c775ad66da563ee6e8bc8158f","https://git.kernel.org/stable/c/e9e55acee9b7a737ec7f5161b94a78932a5514c8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49119
|
Medium |
fixed |
- 5.10.111
- 5.15.34
- 5.16.20
- 5.17.3
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: pm8001: Fix memory leak in pm8001_chip_fw_flash_update_req()
In pm8001_chip_fw_flash_update_build(), if
pm8001_chip_fw_flash_update_build() fails, the struct fw_control_ex
allocated must be freed. |
["https://git.kernel.org/stable/c/a25ed5f21f94f9ae4bcc8dd747e978668890c921","https://git.kernel.org/stable/c/d83574666bac4b1462e90df393fbed6c5f57d1a3","https://git.kernel.org/stable/c/e5ecdb01952f230921aa8163d8d7f4c97c925ed8","https://git.kernel.org/stable/c/f792a3629f4c4aa4c3703d66b43ce1edcc3ec09a","https://git.kernel.org/stable/c/fe5b8ea5583b5c3f6f68e06acba50387edf3b5d5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49130
|
Medium |
fixed |
- 5.10.111
- 5.15.34
- 5.16.20
- 5.17.3
|
In the Linux kernel, the following vulnerability has been resolved:
ath11k: mhi: use mhi_sync_power_up()
If amss.bin was missing ath11k would crash during 'rmmod ath11k_pci'. The
reason for that was that we were using mhi_async_power_up() which does not
check any errors. But mhi_sync_power_up() on the other hand does check for
errors so let's use that to fix the crash.
I was not able to find a reason why an async version was used.
ath11k_mhi_start() (which enables state ATH11K_MHI_POWER_ON) is called from
ath11k_hif_power_up(), which can sleep. So sync version should be safe to use
here.
[ 145.569731] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN PTI
[ 145.569789] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
[ 145.569843] CPU: 2 PID: 1628 Comm: rmmod Kdump: loaded Tainted: G W 5.16.0-wt-ath+ #567
[ 145.569898] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021
[ 145.569956] RIP: 0010:ath11k_hal_srng_access_begin+0xb5/0x2b0 [ath11k]
[ 145.570028] Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 ec 01 00 00 48 8b ab a8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 ea 48 c1 ea 03 <0f> b6 14 02 48 89 e8 83 e0 07 83 c0 03 45 85 ed 75 48 38 d0 7c 08
[ 145.570089] RSP: 0018:ffffc900025d7ac0 EFLAGS: 00010246
[ 145.570144] RAX: dffffc0000000000 RBX: ffff88814fca2dd8 RCX: 1ffffffff50cb455
[ 145.570196] RDX: 0000000000000000 RSI: ffff88814fca2dd8 RDI: ffff88814fca2e80
[ 145.570252] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffa8659497
[ 145.570329] R10: fffffbfff50cb292 R11: 0000000000000001 R12: ffff88814fca0000
[ 145.570410] R13: 0000000000000000 R14: ffff88814fca2798 R15: ffff88814fca2dd8
[ 145.570465] FS: 00007fa399988540(0000) GS:ffff888233e00000(0000) knlGS:0000000000000000
[ 145.570519] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 145.570571] CR2: 00007fa399b51421 CR3: 0000000137898002 CR4: 00000000003706e0
[ 145.570623] Call Trace:
[ 145.570675] <TASK>
[ 145.570727] ? ath11k_ce_tx_process_cb+0x34b/0x860 [ath11k]
[ 145.570797] ath11k_ce_tx_process_cb+0x356/0x860 [ath11k]
[ 145.570864] ? tasklet_init+0x150/0x150
[ 145.570919] ? ath11k_ce_alloc_pipes+0x280/0x280 [ath11k]
[ 145.570986] ? tasklet_clear_sched+0x42/0xe0
[ 145.571042] ? tasklet_kill+0xe9/0x1b0
[ 145.571095] ? tasklet_clear_sched+0xe0/0xe0
[ 145.571148] ? irq_has_action+0x120/0x120
[ 145.571202] ath11k_ce_cleanup_pipes+0x45a/0x580 [ath11k]
[ 145.571270] ? ath11k_pci_stop+0x10e/0x170 [ath11k_pci]
[ 145.571345] ath11k_core_stop+0x8a/0xc0 [ath11k]
[ 145.571434] ath11k_core_deinit+0x9e/0x150 [ath11k]
[ 145.571499] ath11k_pci_remove+0xd2/0x260 [ath11k_pci]
[ 145.571553] pci_device_remove+0x9a/0x1c0
[ 145.571605] __device_release_driver+0x332/0x660
[ 145.571659] driver_detach+0x1e7/0x2c0
[ 145.571712] bus_remove_driver+0xe2/0x2d0
[ 145.571772] pci_unregister_driver+0x21/0x250
[ 145.571826] __do_sys_delete_module+0x30a/0x4b0
[ 145.571879] ? free_module+0xac0/0xac0
[ 145.571933] ? lockdep_hardirqs_on_prepare.part.0+0x18c/0x370
[ 145.571986] ? syscall_enter_from_user_mode+0x1d/0x50
[ 145.572039] ? lockdep_hardirqs_on+0x79/0x100
[ 145.572097] do_syscall_64+0x3b/0x90
[ 145.572153] entry_SYSCALL_64_after_hwframe+0x44/0xae
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2 |
["https://git.kernel.org/stable/c/20d01a11efde2e05e47d5c66101f5c26eaca68e2","https://git.kernel.org/stable/c/339bd0b55ecdd0f7f341e9357c4cfde799de9418","https://git.kernel.org/stable/c/3df6d74aedfdca919cca475d15dfdbc8b05c9e5d","https://git.kernel.org/stable/c/3fd7d50384c3808b7f7fa135aa9bb5feb1cb9849","https://git.kernel.org/stable/c/646d533af2911be1184eaee8c900b7eb8ecc4396"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49131
|
Medium |
fixed |
- 5.10.111
- 5.15.34
- 5.16.20
- 5.17.3
|
In the Linux kernel, the following vulnerability has been resolved:
ath11k: fix kernel panic during unload/load ath11k modules
Call netif_napi_del() from ath11k_ahb_free_ext_irq() to fix
the following kernel panic when unload/load ath11k modules
for few iterations.
[ 971.201365] Unable to handle kernel paging request at virtual address 6d97a208
[ 971.204227] pgd = 594c2919
[ 971.211478] [6d97a208] *pgd=00000000
[ 971.214120] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 971.412024] CPU: 2 PID: 4435 Comm: insmod Not tainted 5.4.89 #0
[ 971.434256] Hardware name: Generic DT based system
[ 971.440165] PC is at napi_by_id+0x10/0x40
[ 971.445019] LR is at netif_napi_add+0x160/0x1dc
[ 971.743127] (napi_by_id) from [<807d89a0>] (netif_napi_add+0x160/0x1dc)
[ 971.751295] (netif_napi_add) from [<7f1209ac>] (ath11k_ahb_config_irq+0xf8/0x414 [ath11k_ahb])
[ 971.759164] (ath11k_ahb_config_irq [ath11k_ahb]) from [<7f12135c>] (ath11k_ahb_probe+0x40c/0x51c [ath11k_ahb])
[ 971.768567] (ath11k_ahb_probe [ath11k_ahb]) from [<80666864>] (platform_drv_probe+0x48/0x94)
[ 971.779670] (platform_drv_probe) from [<80664718>] (really_probe+0x1c8/0x450)
[ 971.789389] (really_probe) from [<80664cc4>] (driver_probe_device+0x15c/0x1b8)
[ 971.797547] (driver_probe_device) from [<80664f60>] (device_driver_attach+0x44/0x60)
[ 971.805795] (device_driver_attach) from [<806650a0>] (__driver_attach+0x124/0x140)
[ 971.814822] (__driver_attach) from [<80662adc>] (bus_for_each_dev+0x58/0xa4)
[ 971.823328] (bus_for_each_dev) from [<80663a2c>] (bus_add_driver+0xf0/0x1e8)
[ 971.831662] (bus_add_driver) from [<806658a4>] (driver_register+0xa8/0xf0)
[ 971.839822] (driver_register) from [<8030269c>] (do_one_initcall+0x78/0x1ac)
[ 971.847638] (do_one_initcall) from [<80392524>] (do_init_module+0x54/0x200)
[ 971.855968] (do_init_module) from [<803945b0>] (load_module+0x1e30/0x1ffc)
[ 971.864126] (load_module) from [<803948b0>] (sys_init_module+0x134/0x17c)
[ 971.871852] (sys_init_module) from [<80301000>] (ret_fast_syscall+0x0/0x50)
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.6.0.1-00760-QCAHKSWPL_SILICONZ-1 |
["https://git.kernel.org/stable/c/22b59cb965f79ee1accf83172441c9ca0ecb632a","https://git.kernel.org/stable/c/38e488db194dc16d2eb23c77c6a8c04ff583c40d","https://git.kernel.org/stable/c/699e8c87e5c406af0f0606f40eeebd248c51b702","https://git.kernel.org/stable/c/c4b7653af62a9a5efe2856183d1f987c5429758b","https://git.kernel.org/stable/c/c6a815f5abdf324108799829dd19ea62fef4bf95"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49139
|
Medium |
fixed |
- 5.4.231
- 5.10.167
- 5.15.92
- 5.17.3
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: fix null ptr deref on hci_sync_conn_complete_evt
This event is just specified for SCO and eSCO link types.
On the reception of a HCI_Synchronous_Connection_Complete for a BDADDR
of an existing LE connection, LE link type and a status that triggers the
second case of the packet processing a NULL pointer dereference happens,
as conn->link is NULL. |
["https://git.kernel.org/stable/c/0f9db1209f59844839175b5b907d3778cafde93d","https://git.kernel.org/stable/c/1c1291a84e94f6501644634c97544bb8291e9a1a","https://git.kernel.org/stable/c/3afee2118132e93e5f6fa636dfde86201a860ab3","https://git.kernel.org/stable/c/c1aa0dd52db4ce888be0bd820c3fa918d350ca0b","https://git.kernel.org/stable/c/f61c23e73dc653b957781066abfa8105c3fa3f5b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49144
|
Medium |
fixed |
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
io_uring: fix memory leak of uid in files registration
When there are no files for __io_sqe_files_scm() to process in the
range, it'll free everything and return. However, it forgets to put uid. |
["https://git.kernel.org/stable/c/0853bd6885c2f293d88aaa7f7f1702c959b31680","https://git.kernel.org/stable/c/7fa8b228c3f30060b9f4b24bb9aaaf41b0ae83fe","https://git.kernel.org/stable/c/b27de7011cb3ba14b047be2cee0ed8278368665b","https://git.kernel.org/stable/c/c86d18f4aa93e0e66cda0e55827cd03eea6bc5f8","https://git.kernel.org/stable/c/d6d7a517e81accf6ed22d55684baea763d2dbe43"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49148
|
Medium |
fixed |
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
watch_queue: Free the page array when watch_queue is dismantled
Commit 7ea1a0124b6d ("watch_queue: Free the alloc bitmap when the
watch_queue is torn down") took care of the bitmap, but not the page
array.
BUG: memory leak
unreferenced object 0xffff88810d9bc140 (size 32):
comm "syz-executor335", pid 3603, jiffies 4294946994 (age 12.840s)
hex dump (first 32 bytes):
40 a7 40 04 00 ea ff ff 00 00 00 00 00 00 00 00 @.@.............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
kmalloc_array include/linux/slab.h:621 [inline]
kcalloc include/linux/slab.h:652 [inline]
watch_queue_set_size+0x12f/0x2e0 kernel/watch_queue.c:251
pipe_ioctl+0x82/0x140 fs/pipe.c:632
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline] |
["https://git.kernel.org/stable/c/375cd2536494cfbcdda84ae8b3e35bf19d0250b9","https://git.kernel.org/stable/c/3963a5d1ff75585bddf0c3a918566a6be09d7520","https://git.kernel.org/stable/c/4913daecd04addb41bc96a9175a885e1c19862a8","https://git.kernel.org/stable/c/7169f60110915c8b53bffd43741fa020a75eb87a","https://git.kernel.org/stable/c/b490207017ba237d97b735b2aa66dc241ccd18f5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49153
|
Medium |
fixed |
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
wireguard: socket: free skb in send6 when ipv6 is disabled
I got a memory leak report:
unreferenced object 0xffff8881191fc040 (size 232):
comm "kworker/u17:0", pid 23193, jiffies 4295238848 (age 3464.870s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff814c3ef4>] slab_post_alloc_hook+0x84/0x3b0
[<ffffffff814c8977>] kmem_cache_alloc_node+0x167/0x340
[<ffffffff832974fb>] __alloc_skb+0x1db/0x200
[<ffffffff82612b5d>] wg_socket_send_buffer_to_peer+0x3d/0xc0
[<ffffffff8260e94a>] wg_packet_send_handshake_initiation+0xfa/0x110
[<ffffffff8260ec81>] wg_packet_handshake_send_worker+0x21/0x30
[<ffffffff8119c558>] process_one_work+0x2e8/0x770
[<ffffffff8119ca2a>] worker_thread+0x4a/0x4b0
[<ffffffff811a88e0>] kthread+0x120/0x160
[<ffffffff8100242f>] ret_from_fork+0x1f/0x30
In function wg_socket_send_buffer_as_reply_to_skb() or wg_socket_send_
buffer_to_peer(), the semantics of send6() is required to free skb. But
when CONFIG_IPV6 is disable, kfree_skb() is missing. This patch adds it
to fix this bug. |
["https://git.kernel.org/stable/c/096f9d35cac0a0c95ffafc00db84786b665a4837","https://git.kernel.org/stable/c/0b19bcb753dbfb74710d12bb2761ec5ed706c726","https://git.kernel.org/stable/c/402991a9771587acc2947cf6c4d689c5397f2258","https://git.kernel.org/stable/c/bbbf962d9460194993ee1943a793a0a0af4a7fbf","https://git.kernel.org/stable/c/ebcc492f4ba14bae54b898f1016a37b4282558d1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49190
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
kernel/resource: fix kfree() of bootmem memory again
Since commit ebff7d8f270d ("mem hotunplug: fix kfree() of bootmem
memory"), we could get a resource allocated during boot via
alloc_resource(). And it's required to release the resource using
free_resource(). Howerver, many people use kfree directly which will
result in kernel BUG. In order to fix this without fixing every call
site, just leak a couple of bytes in such corner case. |
["https://git.kernel.org/stable/c/0cbcc92917c5de80f15c24d033566539ad696892","https://git.kernel.org/stable/c/3379a60f6bb4afcd9c456e340ac525ae649d3ce7","https://git.kernel.org/stable/c/a9e88c2618d228d7a4e7e515cf30dc0d0d813f27","https://git.kernel.org/stable/c/ab86020070999e758ce2e60c4348f20bf7ddba56","https://git.kernel.org/stable/c/d7faa04a44a0c37ac3d222fa8e0bdcbfcee9c0c8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49210
|
Medium |
fixed |
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
MIPS: pgalloc: fix memory leak caused by pgd_free()
pgd page is freed by generic implementation pgd_free() since commit
f9cb654cb550 ("asm-generic: pgalloc: provide generic pgd_free()"),
however, there are scenarios that the system uses more than one page as
the pgd table, in such cases the generic implementation pgd_free() won't
be applicable anymore. For example, when PAGE_SIZE_4KB is enabled and
MIPS_VA_BITS_48 is not enabled in a 64bit system, the macro "PGD_ORDER"
will be set as "1", which will cause allocating two pages as the pgd
table. Well, at the same time, the generic implementation pgd_free()
just free one pgd page, which will result in the memory leak.
The memory leak can be easily detected by executing shell command:
"while true; do ls > /dev/null; grep MemFree /proc/meminfo; done" |
["https://git.kernel.org/stable/c/1bf0d78c8cc3cf615a6e7bf33ada70b73592f0a1","https://git.kernel.org/stable/c/2bc5bab9a763d520937e4f3fe8df51c6a1eceb97","https://git.kernel.org/stable/c/5a8501d34b261906e4c76ec9da679f2cb4d309ed","https://git.kernel.org/stable/c/d29cda15cab086d82d692de016f7249545d4b6b4","https://git.kernel.org/stable/c/fa3d44424579972cc7c4fac3d9cf227798ebdfa0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49211
|
Medium |
fixed |
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
mips: cdmm: Fix refcount leak in mips_cdmm_phys_base
The of_find_compatible_node() function returns a node pointer with
refcount incremented, We should use of_node_put() on it when done
Add the missing of_node_put() to release the refcount. |
["https://git.kernel.org/stable/c/4528668ca331f7ce5999b7746657b46db5b3b785","https://git.kernel.org/stable/c/4680c2ac9aabda82acd23ebbd1f900fb6a889cd3","https://git.kernel.org/stable/c/69155dc2e04777aa94207a73a8b10f12b8428a68","https://git.kernel.org/stable/c/721ab4be20d4448dd04c2cc8ed99cd4f3e45f765","https://git.kernel.org/stable/c/ef1728e3cb9e43f38ed10cde705a7ba2b4ad2d35"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49213
|
Medium |
fixed |
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
ath10k: Fix error handling in ath10k_setup_msa_resources
The device_node pointer is returned by of_parse_phandle() with refcount
incremented. We should use of_node_put() on it when done.
This function only calls of_node_put() in the regular path.
And it will cause refcount leak in error path. |
["https://git.kernel.org/stable/c/315772133a4b960859e4f5efe0e738e347188cdc","https://git.kernel.org/stable/c/32939187f254171a5666badc058bc3787fe454af","https://git.kernel.org/stable/c/4ed37d611ea5d222c3ecb3549e4c2d34b8f3c335","https://git.kernel.org/stable/c/74b1d41e1b6410eed5c76d00eedb262036e9eff5","https://git.kernel.org/stable/c/9747a78d5f758a5284751a10aee13c30d02bd5f1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49219
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: fix memory leak during D3hot to D0 transition
If 'vfio_pci_core_device::needs_pm_restore' is set (PCI device does
not have No_Soft_Reset bit set in its PMCSR config register), then
the current PCI state will be saved locally in
'vfio_pci_core_device::pm_save' during D0->D3hot transition and same
will be restored back during D3hot->D0 transition.
For saving the PCI state locally, pci_store_saved_state() is being
used and the pci_load_and_free_saved_state() will free the allocated
memory.
But for reset related IOCTLs, vfio driver calls PCI reset-related
API's which will internally change the PCI power state back to D0. So,
when the guest resumes, then it will get the current state as D0 and it
will skip the call to vfio_pci_set_power_state() for changing the
power state to D0 explicitly. In this case, the memory pointed by
'pm_save' will never be freed. In a malicious sequence, the state changing
to D3hot followed by VFIO_DEVICE_RESET/VFIO_DEVICE_PCI_HOT_RESET can be
run in a loop and it can cause an OOM situation.
This patch frees the earlier allocated memory first before overwriting
'pm_save' to prevent the mentioned memory leak. |
["https://git.kernel.org/stable/c/26ddd196e9eb264da8e1bdc4df8a94d62581c8b5","https://git.kernel.org/stable/c/4319f17fb8264ba39352b611dfa913a4d8c1d1a0","https://git.kernel.org/stable/c/c8a1f8bd586ee31020614b8d48b702ece3e2ae44","https://git.kernel.org/stable/c/da426ad86027b849b877d4628b277ffbbd2f5325","https://git.kernel.org/stable/c/eadf88ecf6ac7d6a9f47a76c6055d9a1987a8991"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49221
|
Medium |
fixed |
- 5.10.110
- 5.14
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dp: populate connector of struct dp_panel
DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose
and expect DP source return correct checksum. During drm edid read,
correct edid checksum is calculated and stored at
connector::real_edid_checksum.
The problem is struct dp_panel::connector never be assigned, instead the
connector is stored in struct msm_dp::connector. When we run compliance
testing test case 4.2.2.6 dp_panel_handle_sink_request() won't have a valid
edid set in struct dp_panel::edid so we'll try to use the connectors
real_edid_checksum and hit a NULL pointer dereference error because the
connector pointer is never assigned.
Changes in V2:
-- populate panel connector at msm_dp_modeset_init() instead of at dp_panel_read_sink_caps()
Changes in V3:
-- remove unhelpful kernel crash trace commit text
-- remove renaming dp_display parameter to dp
Changes in V4:
-- add more details to commit text
Changes in v10:
-- group into one series
Changes in v11:
-- drop drm/msm/dp: dp_link_parse_sink_count() return immediately if aux read
Signee-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com> |
["https://git.kernel.org/stable/c/104074ebc0c3f358dd1ee944fbcde92c6e5a21dd","https://git.kernel.org/stable/c/413c62697b61226a236c8b1f5cd64dcf42bcc12f","https://git.kernel.org/stable/c/5e602f5156910c7b19661699896cb6e3fb94fab9","https://git.kernel.org/stable/c/9525b8bcae8b99188990b56484799cf4b1b43786","https://git.kernel.org/stable/c/fbba600f432a360b42452fee79d1fb35d3aa8aeb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49239
|
Medium |
fixed |
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: codecs: wcd934x: Add missing of_node_put() in wcd934x_codec_parse_data
The device_node pointer is returned by of_parse_phandle() with refcount
incremented. We should use of_node_put() on it when done.
This is similar to commit 64b92de9603f
("ASoC: wcd9335: fix a leaked reference by adding missing of_node_put") |
["https://git.kernel.org/stable/c/1f24716e38220fc9e52e208d20591d2bc9b7f020","https://git.kernel.org/stable/c/2f44eca78cc6d4e1779eb95765ec79e433accab4","https://git.kernel.org/stable/c/9531a631379169d57756b2411178c6238655df88","https://git.kernel.org/stable/c/f3793eeb7b94a5eeed6f5c7a44bce403c6681a12","https://git.kernel.org/stable/c/f8e89d84ea83c51ba3ba97ff154f7aa679326760"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49241
|
Medium |
fixed |
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: atmel: Fix error handling in sam9x5_wm8731_driver_probe
The device_node pointer is returned by of_parse_phandle() with refcount
incremented. We should use of_node_put() on it when done.
This function only calls of_node_put() in the regular path.
And it will cause refcount leak in error path. |
["https://git.kernel.org/stable/c/14228225091a0854b1de23e5b4fe8bdeeca9683b","https://git.kernel.org/stable/c/740dc3e846537c3743da98bf106f376023fd085c","https://git.kernel.org/stable/c/90ac679aa6a01841da90ec5a4aaa4b5e0badddf0","https://git.kernel.org/stable/c/f43ad5dc43240289f4cf13c16cc506f4f7087931","https://git.kernel.org/stable/c/f589063b585ac6dd2081bde6c145411cf48d8d92"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49312
|
Medium |
fixed |
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8712: fix a potential memory leak in r871xu_drv_init()
In r871xu_drv_init(), if r8712_init_drv_sw() fails, then the memory
allocated by r8712_alloc_io_queue() in r8712_usb_dvobj_init() is not
properly released as there is no action will be performed by
r8712_usb_dvobj_deinit().
To properly release it, we should call r8712_free_io_queue() in
r8712_usb_dvobj_deinit().
Besides, in r871xu_dev_remove(), r8712_usb_dvobj_deinit() will be called
by r871x_dev_unload() under condition `padapter->bup` and
r8712_free_io_queue() is called by r8712_free_drv_sw().
However, r8712_usb_dvobj_deinit() does not rely on `padapter->bup` and
calling r8712_free_io_queue() in r8712_free_drv_sw() is negative for
better understading the code.
So I move r8712_usb_dvobj_deinit() into r871xu_dev_remove(), and remove
r8712_free_io_queue() from r8712_free_drv_sw(). |
["https://git.kernel.org/stable/c/205e039fead72e87ad2838f5e649a4c4834f648b","https://git.kernel.org/stable/c/5a89a92efc342dd7c44b6056da87debc598f9c73","https://git.kernel.org/stable/c/7288ff561de650d4139fab80e9cb0da9b5b32434","https://git.kernel.org/stable/c/8eb42d6d10f8fe509117859defddf9e72b4fa4d0","https://git.kernel.org/stable/c/a2882b8baad068d21c99fb2ab5a85a2bdbd5b834"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49319
|
Medium |
fixed |
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
iommu/arm-smmu-v3: check return value after calling platform_get_resource()
It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value. |
["https://git.kernel.org/stable/c/54c1e0e3bbcab2abe25b2874a43050ae5df87831","https://git.kernel.org/stable/c/54cf47da0c7532d151d76e5d63f5936191698c44","https://git.kernel.org/stable/c/b131fa8c1d2afd05d0b7598621114674289c2fbb","https://git.kernel.org/stable/c/db728a891f9177b044aaca89b678f6b5e24d5cc3","https://git.kernel.org/stable/c/fb0f1c5eb8d60b3e018ba7c87da249b52674ebe6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49376
|
Medium |
fixed |
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: sd: Fix potential NULL pointer dereference
If sd_probe() sees an early error before sdkp->device is initialized,
sd_zbc_release_disk() is called. This causes a NULL pointer dereference
when sd_is_zoned() is called inside that function. Avoid this by removing
the call to sd_zbc_release_disk() in sd_probe() error path.
This change is safe and does not result in zone information memory leakage
because the zone information for a zoned disk is allocated only when
sd_revalidate_disk() is called, at which point sdkp->disk_dev is fully set,
resulting in sd_disk_release() being called when needed to cleanup a disk
zone information using sd_zbc_release_disk(). |
["https://git.kernel.org/stable/c/05fbde3a77a4f1d62e4c4428f384288c1f1a0be5","https://git.kernel.org/stable/c/0fcb0b131cc90c8f523a293d84c58d0c7273c96f","https://git.kernel.org/stable/c/3733439593ad12f7b54ae35c273ea6f15d692de3","https://git.kernel.org/stable/c/78f8e96df06e2d04d82d4071c299b59d28744f47","https://git.kernel.org/stable/c/c1f0187025905e9981000d44a92e159468b561a8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49386
|
Medium |
fixed |
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: ti: am65-cpsw-nuss: Fix some refcount leaks
of_get_child_by_name() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
am65_cpsw_init_cpts() and am65_cpsw_nuss_probe() don't release
the refcount in error case.
Add missing of_node_put() to avoid refcount leak. |
["https://git.kernel.org/stable/c/2e44f21c384503562713b7d3b673c40bed20af3d","https://git.kernel.org/stable/c/5dd89d2fc438457811cbbec07999ce0d80051ff5","https://git.kernel.org/stable/c/78aca10a16f001c9f49f1cc4dadfee8d444bb173","https://git.kernel.org/stable/c/a4b7ef3b159805ba6be061d0cd2403d84b9b0063","https://git.kernel.org/stable/c/f7ba2cc57f404d2d9f26fb85bd3833d35a477829"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49445
|
Medium |
fixed |
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: renesas: core: Fix possible null-ptr-deref in sh_pfc_map_resources()
It will cause null-ptr-deref when using 'res', if platform_get_resource()
returns NULL, so move using 'res' after devm_ioremap_resource() that
will check it to avoid null-ptr-deref.
And use devm_platform_get_and_ioremap_resource() to simplify code. |
["https://git.kernel.org/stable/c/5376e3d904532e657fd7ca1a9b1ff3d351527b90","https://git.kernel.org/stable/c/5ed0519d425619b435150372cce2ffeec71581fa","https://git.kernel.org/stable/c/e3a1ad8fd0ac11f4fa1260c23b5db71a25473254","https://git.kernel.org/stable/c/f991879762392c19661af5b722578089a12b305f","https://git.kernel.org/stable/c/fb4f022b3ad1f3ff3cafdbc7d51896090ae17701"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49449
|
Medium |
fixed |
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: renesas: rzn1: Fix possible null-ptr-deref in sh_pfc_map_resources()
It will cause null-ptr-deref when using 'res', if platform_get_resource()
returns NULL, so move using 'res' after devm_ioremap_resource() that
will check it to avoid null-ptr-deref.
And use devm_platform_get_and_ioremap_resource() to simplify code. |
["https://git.kernel.org/stable/c/01f9e02e0f13df3fd291676dc80054e977be1601","https://git.kernel.org/stable/c/2f661477c2bb8068194dbba9738d05219f111c6e","https://git.kernel.org/stable/c/34c719b8fdfbd0c7c54cae56e6b0f16e9f8bf03e","https://git.kernel.org/stable/c/b646e0cfeb38bf5f1944fd548f1dfa9b129fa00c","https://git.kernel.org/stable/c/c16b59d445135c8026a04e388d8b2762feaa3b3b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49453
|
Medium |
fixed |
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
soc: ti: ti_sci_pm_domains: Check for null return of devm_kcalloc
The allocation funciton devm_kcalloc may fail and return a null pointer,
which would cause a null-pointer dereference later.
It might be better to check it and directly return -ENOMEM just like the
usage of devm_kcalloc in previous code. |
["https://git.kernel.org/stable/c/01ba41a359622ab256ce4d4f8b94c67165ae3daf","https://git.kernel.org/stable/c/05efc4591f80582b6fe53366b70b6a35a42fd255","https://git.kernel.org/stable/c/7cef9274fa1b8506949d74bc45aef072b890824a","https://git.kernel.org/stable/c/ba56291e297d28aa6eb82c5c1964fae2d7594746","https://git.kernel.org/stable/c/c4e188869406b47ac3350920bf165be303cb1c96"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49463
|
Medium |
fixed |
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
thermal/drivers/imx_sc_thermal: Fix refcount leak in imx_sc_thermal_probe
of_find_node_by_name() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak. |
["https://git.kernel.org/stable/c/09700c504d8e63faffd2a2235074e8c5d130cb8f","https://git.kernel.org/stable/c/0ec10303c10833c1bcba7a1bde2f297e494d5464","https://git.kernel.org/stable/c/3ade442ea5d3512a3c67984489ab4d8a6fb3b29f","https://git.kernel.org/stable/c/8bbf522a2c51ef939d0e8835e236bfcd252193af","https://git.kernel.org/stable/c/ec0925b731697db7cab5944a3e55d2d58bb3d075"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49473
|
Medium |
fixed |
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: ti: j721e-evm: Fix refcount leak in j721e_soc_probe_*
of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not needed anymore.
Add missing of_node_put() to avoid refcount leak. |
["https://git.kernel.org/stable/c/2a3966b950b37a6f10c5f9caee15b4cdcf5a7413","https://git.kernel.org/stable/c/510e879420b410d88c612aecc6ca15dc6fe77473","https://git.kernel.org/stable/c/554df0f70bff1ace6d2df2fcaddbc9b7bd509de2","https://git.kernel.org/stable/c/a34840c4eb3278a7c29c9c57a65ce7541c66f9f2","https://git.kernel.org/stable/c/d748ff8fbb3a5296bddd586445dc692b079cbe3d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49477
|
Medium |
fixed |
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: samsung: Fix refcount leak in aries_audio_probe
of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
If extcon_find_edev_by_node() fails, it doesn't call of_node_put()
Calling of_node_put() after extcon_find_edev_by_node() to fix this. |
["https://git.kernel.org/stable/c/46d1b310a2d571811c4e08041ce287babb60b86a","https://git.kernel.org/stable/c/70130bde3457d28c02c76b6cacc5d40a72dd6e17","https://git.kernel.org/stable/c/85d899f396622d3034643bf89615a78f9be7c91a","https://git.kernel.org/stable/c/bf4a9b2467b775717d0e9034ad916888e19713a3","https://git.kernel.org/stable/c/cacea459f95be22b3750f3b25b7a1c5897a68206"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49494
|
Medium |
fixed |
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
mtd: rawnand: cadence: fix possible null-ptr-deref in cadence_nand_dt_probe()
It will cause null-ptr-deref when using 'res', if platform_get_resource()
returns NULL, so move using 'res' after devm_ioremap_resource() that
will check it to avoid null-ptr-deref.
And use devm_platform_get_and_ioremap_resource() to simplify code. |
["https://git.kernel.org/stable/c/069af5e27c1b0f7677ef76d8d3102e503ca4f80b","https://git.kernel.org/stable/c/0cfee868b89ffa945f3d535ee5c985cb40c5a0f8","https://git.kernel.org/stable/c/13b60d3dc84b47307669edb66b633b18466014b4","https://git.kernel.org/stable/c/81f1ddffdc22ca5789e33b9d4712914e302090c1","https://git.kernel.org/stable/c/a28ed09dafee20da51eb26452950839633afd824"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49497
|
Medium |
fixed |
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
net: remove two BUG() from skb_checksum_help()
I have a syzbot report that managed to get a crash in skb_checksum_help()
If syzbot can trigger these BUG(), it makes sense to replace
them with more friendly WARN_ON_ONCE() since skb_checksum_help()
can instead return an error code.
Note that syzbot will still crash there, until real bug is fixed. |
["https://git.kernel.org/stable/c/312c43e98ed190bd8fd7a71a0addf9539d5b8ab1","https://git.kernel.org/stable/c/6320ae1b5876c30bf98203b6a5abe8b5c45e6a04","https://git.kernel.org/stable/c/b1320c9a4d30ff54b824a8ad6036e0b5fb4c5e73","https://git.kernel.org/stable/c/d5281245f3502e960cb6b89348767b935379cee3","https://git.kernel.org/stable/c/d7ea0d9df2a6265b2b180d17ebc64b38105968fc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49502
|
Medium |
fixed |
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
media: rga: fix possible memory leak in rga_probe
rga->m2m_dev needs to be freed when rga_probe fails. |
["https://git.kernel.org/stable/c/1cdc768468c25d6b10ab83ec1efd4a8554532d69","https://git.kernel.org/stable/c/8ddc89437ccefa18279918c19a61fd81527f40b9","https://git.kernel.org/stable/c/a71eb6025305192e646040cd76ccacb5bd48a1b5","https://git.kernel.org/stable/c/b7bbca4d08471bc8404a946bab1aa017dd05199b","https://git.kernel.org/stable/c/eeb4819e94aa69767b9e5591e70c63e8b7c5786a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49523
|
Medium |
fixed |
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
ath11k: disable spectral scan during spectral deinit
When ath11k modules are removed using rmmod with spectral scan enabled,
crash is observed. Different crash trace is observed for each crash.
Send spectral scan disable WMI command to firmware before cleaning
the spectral dbring in the spectral_deinit API to avoid this crash.
call trace from one of the crash observed:
[ 1252.880802] Unable to handle kernel NULL pointer dereference at virtual address 00000008
[ 1252.882722] pgd = 0f42e886
[ 1252.890955] [00000008] *pgd=00000000
[ 1252.893478] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 1253.093035] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.89 #0
[ 1253.115261] Hardware name: Generic DT based system
[ 1253.121149] PC is at ath11k_spectral_process_data+0x434/0x574 [ath11k]
[ 1253.125940] LR is at 0x88e31017
[ 1253.132448] pc : [<7f9387b8>] lr : [<88e31017>] psr: a0000193
[ 1253.135488] sp : 80d01bc8 ip : 00000001 fp : 970e0000
[ 1253.141737] r10: 88e31000 r9 : 970ec000 r8 : 00000080
[ 1253.146946] r7 : 94734040 r6 : a0000113 r5 : 00000057 r4 : 00000000
[ 1253.152159] r3 : e18cb694 r2 : 00000217 r1 : 1df1f000 r0 : 00000001
[ 1253.158755] Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
[ 1253.165266] Control: 10c0383d Table: 5e71006a DAC: 00000055
[ 1253.172472] Process swapper/0 (pid: 0, stack limit = 0x60870141)
[ 1253.458055] [<7f9387b8>] (ath11k_spectral_process_data [ath11k]) from [<7f917fdc>] (ath11k_dbring_buffer_release_event+0x214/0x2e4 [ath11k])
[ 1253.466139] [<7f917fdc>] (ath11k_dbring_buffer_release_event [ath11k]) from [<7f8ea3c4>] (ath11k_wmi_tlv_op_rx+0x1840/0x29cc [ath11k])
[ 1253.478807] [<7f8ea3c4>] (ath11k_wmi_tlv_op_rx [ath11k]) from [<7f8fe868>] (ath11k_htc_rx_completion_handler+0x180/0x4e0 [ath11k])
[ 1253.490699] [<7f8fe868>] (ath11k_htc_rx_completion_handler [ath11k]) from [<7f91308c>] (ath11k_ce_per_engine_service+0x2c4/0x3b4 [ath11k])
[ 1253.502386] [<7f91308c>] (ath11k_ce_per_engine_service [ath11k]) from [<7f9a4198>] (ath11k_pci_ce_tasklet+0x28/0x80 [ath11k_pci])
[ 1253.514811] [<7f9a4198>] (ath11k_pci_ce_tasklet [ath11k_pci]) from [<8032227c>] (tasklet_action_common.constprop.2+0x64/0xe8)
[ 1253.526476] [<8032227c>] (tasklet_action_common.constprop.2) from [<803021e8>] (__do_softirq+0x130/0x2d0)
[ 1253.537756] [<803021e8>] (__do_softirq) from [<80322610>] (irq_exit+0xcc/0xe8)
[ 1253.547304] [<80322610>] (irq_exit) from [<8036a4a4>] (__handle_domain_irq+0x60/0xb4)
[ 1253.554428] [<8036a4a4>] (__handle_domain_irq) from [<805eb348>] (gic_handle_irq+0x4c/0x90)
[ 1253.562321] [<805eb348>] (gic_handle_irq) from [<80301a78>] (__irq_svc+0x58/0x8c)
Tested-on: QCN6122 hw1.0 AHB WLAN.HK.2.6.0.1-00851-QCAHKSWPL_SILICONZ-1 |
["https://git.kernel.org/stable/c/161c64de239c7018e0295e7e0520a19f00aa32dc","https://git.kernel.org/stable/c/451b9076903a057b7b8d5b24dc84b3e436a1c743","https://git.kernel.org/stable/c/4b9c54caef58d2b55074710952cda70540722c01","https://git.kernel.org/stable/c/60afa4f4e1350c876d8a061182a70c224de275dd","https://git.kernel.org/stable/c/8f15e67af9bec5a69e815e0230a70cffddae371a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49549
|
Medium |
fixed |
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
x86/MCE/AMD: Fix memory leak when threshold_create_bank() fails
In mce_threshold_create_device(), if threshold_create_bank() fails, the
previously allocated threshold banks array @bp will be leaked because
the call to mce_threshold_remove_device() will not free it.
This happens because mce_threshold_remove_device() fetches the pointer
through the threshold_banks per-CPU variable but bp is written there
only after the bank creation is successful, and not before, when
threshold_create_bank() fails.
Add a helper which unwinds all the bank creation work previously done
and pass into it the previously allocated threshold banks array for
freeing.
[ bp: Massage. ] |
["https://git.kernel.org/stable/c/396b8e7ab2a99ddac57d3522b3da5e58cb608d37","https://git.kernel.org/stable/c/9708f1956eeb70c86943e0bc62fa3b0101b59616","https://git.kernel.org/stable/c/b4acb8e7f1594607bc9017ef0aacb40b24a003d6","https://git.kernel.org/stable/c/cc0dd4456f9573bf8af9b4d8754433918e809e1e","https://git.kernel.org/stable/c/e5f28623ceb103e13fc3d7bd45edf9818b227fd0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49569
|
Medium |
fixed |
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
spi: bcm2835: bcm2835_spi_handle_err(): fix NULL pointer deref for non DMA transfers
In case a IRQ based transfer times out the bcm2835_spi_handle_err()
function is called. Since commit 1513ceee70f2 ("spi: bcm2835: Drop
dma_pending flag") the TX and RX DMA transfers are unconditionally
canceled, leading to NULL pointer derefs if ctlr->dma_tx or
ctlr->dma_rx are not set.
Fix the NULL pointer deref by checking that ctlr->dma_tx and
ctlr->dma_rx are valid pointers before accessing them. |
["https://git.kernel.org/stable/c/49ffa473218012e765682343de2052eb4c1f06a7","https://git.kernel.org/stable/c/4ceaa684459d414992acbefb4e4c31f2dfc50641","https://git.kernel.org/stable/c/58466e05390043d2805685c70f55f3f59711bdf2","https://git.kernel.org/stable/c/684896e675edd8b669fd3e9f547c5038222d85bc","https://git.kernel.org/stable/c/76668d2a2f367d25ff448e6d7087406af7d7bb2b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49583
|
Medium |
fixed |
- 5.2
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
iavf: Fix handling of dummy receive descriptors
Fix memory leak caused by not handling dummy receive descriptor properly.
iavf_get_rx_buffer now sets the rx_buffer return value for dummy receive
descriptors. Without this patch, when the hardware writes a dummy
descriptor, iavf would not free the page allocated for the previous receive
buffer. This is an unlikely event but can still happen.
[Jesse: massaged commit message] |
["https://git.kernel.org/stable/c/2918419c06088f6709ceb543feb01752779ade4c","https://git.kernel.org/stable/c/6edb818732fc05fda495f5b3a749bd1cee01398b","https://git.kernel.org/stable/c/a9f49e0060301a9bfebeca76739158d0cf91cdf6","https://git.kernel.org/stable/c/c6af94324911ef0846af1a5ce5e049ca736db34b","https://git.kernel.org/stable/c/d88d59faf4e6f9cc4767664206afdb999b10ec77"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49643
|
Medium |
fixed |
- 5.4.207
- 5.10.132
- 5.15.56
- 5.18.13
|
In the Linux kernel, the following vulnerability has been resolved:
ima: Fix a potential integer overflow in ima_appraise_measurement
When the ima-modsig is enabled, the rc passed to evm_verifyxattr() may be
negative, which may cause the integer overflow problem. |
["https://git.kernel.org/stable/c/388f3df7c3c8b7f2a32b9ae0a9b2f9f6ad3b1b77","https://git.kernel.org/stable/c/640cea4c2839a821adfbb703b590a5928abe9286","https://git.kernel.org/stable/c/831e190175f10652be93b08436cc7bf2e62e4bb6","https://git.kernel.org/stable/c/c8d5d81940938b5f6c0f495ca9538e7740416f30","https://git.kernel.org/stable/c/d2ee2cfc4aa85ff6a2a3b198a3a524ec54e3d999"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49644
|
Medium |
fixed |
- 5.4.207
- 5.10.132
- 5.15.56
- 5.18.13
|
In the Linux kernel, the following vulnerability has been resolved:
drm/i915: fix a possible refcount leak in intel_dp_add_mst_connector()
If drm_connector_init fails, intel_connector_free will be called to take
care of proper free. So it is necessary to drop the refcount of port
before intel_connector_free.
(cherry picked from commit cea9ed611e85d36a05db52b6457bf584b7d969e2) |
["https://git.kernel.org/stable/c/505114dda5bbfd07f4ce9a2df5b7d8ef5f2a1218","https://git.kernel.org/stable/c/592f3bad00b7e2a95a6fb7a4f9e742c061c9c3c1","https://git.kernel.org/stable/c/72f231b9a88abcfac9f5ddaa1a0aacb3f9f87ba5","https://git.kernel.org/stable/c/85144df9ff4652816448369de76897c57cbb1b93","https://git.kernel.org/stable/c/a91522b4279bebb098106a19b91f82b9c3213be9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49668
|
Medium |
fixed |
- 5.4.204
- 5.10.129
- 5.15.53
- 5.18.10
|
In the Linux kernel, the following vulnerability has been resolved:
PM / devfreq: exynos-ppmu: Fix refcount leak in of_get_devfreq_events
of_get_child_by_name() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
This function only calls of_node_put() in normal path,
missing it in error paths.
Add missing of_node_put() to avoid refcount leak. |
["https://git.kernel.org/stable/c/01121e39ef537289926ae6f5374dce92c796d863","https://git.kernel.org/stable/c/194781229d4cbc804b8ded13156eb8addce87d6c","https://git.kernel.org/stable/c/bdecd912e99acfd61507f1720d3f4eed1b3418d8","https://git.kernel.org/stable/c/e65027fdebbacd40595e96ef7b5d2418f71bddf2","https://git.kernel.org/stable/c/f44b799603a9b5d2e375b0b2d54dd0b791eddfc2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49670
|
Medium |
fixed |
- 5.4.204
- 5.10.129
- 5.15.53
- 5.18.10
|
In the Linux kernel, the following vulnerability has been resolved:
linux/dim: Fix divide by 0 in RDMA DIM
Fix a divide 0 error in rdma_dim_stats_compare() when prev->cpe_ratio ==
0.
CallTrace:
Hardware name: H3C R4900 G3/RS33M2C9S, BIOS 2.00.37P21 03/12/2020
task: ffff880194b78000 task.stack: ffffc90006714000
RIP: 0010:backport_rdma_dim+0x10e/0x240 [mlx_compat]
RSP: 0018:ffff880c10e83ec0 EFLAGS: 00010202
RAX: 0000000000002710 RBX: ffff88096cd7f780 RCX: 0000000000000064
RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000001
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 000000001d7c6c09
R13: ffff88096cd7f780 R14: ffff880b174fe800 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff880c10e80000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000a0965b00 CR3: 000000000200a003 CR4: 00000000007606e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<IRQ>
ib_poll_handler+0x43/0x80 [ib_core]
irq_poll_softirq+0xae/0x110
__do_softirq+0xd1/0x28c
irq_exit+0xde/0xf0
do_IRQ+0x54/0xe0
common_interrupt+0x8f/0x8f
</IRQ>
? cpuidle_enter_state+0xd9/0x2a0
? cpuidle_enter_state+0xc7/0x2a0
? do_idle+0x170/0x1d0
? cpu_startup_entry+0x6f/0x80
? start_secondary+0x1b9/0x210
? secondary_startup_64+0xa5/0xb0
Code: 0f 87 e1 00 00 00 8b 4c 24 14 44 8b 43 14 89 c8 4d 63 c8 44 29 c0 99 31 d0 29 d0 31 d2 48 98 48 8d 04 80 48 8d 04 80 48 c1 e0 02 <49> f7 f1 48 83 f8 0a 0f 86 c1 00 00 00 44 39 c1 7f 10 48 89 df
RIP: backport_rdma_dim+0x10e/0x240 [mlx_compat] RSP: ffff880c10e83ec0 |
["https://git.kernel.org/stable/c/0b6e0eb5c45e79e9095de2498cc0ca5ec563fc5e","https://git.kernel.org/stable/c/0fe3dbbefb74a8575f61d7801b08dbc50523d60d","https://git.kernel.org/stable/c/5af106f8e072aebd88b95e164a08fa320651a99a","https://git.kernel.org/stable/c/7c1963391af51ee322378d1b2849c60e9037f069","https://git.kernel.org/stable/c/fae2a9fb1eaf348ad8732f90d42ebbb971bd7e95"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49693
|
Medium |
fixed |
- 5.4.202
- 5.10.127
- 5.15.51
- 5.18.8
|
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/mdp4: Fix refcount leak in mdp4_modeset_init_intf
of_graph_get_remote_node() returns remote device node pointer with
refcount incremented, we should use of_node_put() on it
when not need anymore.
Add missing of_node_put() to avoid refcount leak.
Patchwork: https://patchwork.freedesktop.org/patch/488473/ |
["https://git.kernel.org/stable/c/3c39a17197733bc37786ed68c83267c2f491840b","https://git.kernel.org/stable/c/b9cc4598607cb7f7eae5c75fc1e3209cd52ff5e0","https://git.kernel.org/stable/c/d1592d3e362cc59b29f15019707b16c695d70ca3","https://git.kernel.org/stable/c/d16a4339825e64f9ddcdff5277982d640bae933b","https://git.kernel.org/stable/c/d607da76fd2b1cf1d377af9d9b7c6f8fecbb0e1d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49716
|
Medium |
fixed |
- 5.4.200
- 5.10.124
- 5.15.49
- 5.18.6
|
In the Linux kernel, the following vulnerability has been resolved:
irqchip/gic-v3: Fix error handling in gic_populate_ppi_partitions
of_get_child_by_name() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
When kcalloc fails, it missing of_node_put() and results in refcount
leak. Fix this by goto out_put_node label. |
["https://git.kernel.org/stable/c/0b325d993995a321f6ab4e6c51f0504ec092bf5b","https://git.kernel.org/stable/c/58e67c81e229351027d28c610638378606e33a08","https://git.kernel.org/stable/c/7c9dd9d23f26dabcfb14148b9acdfba540418b19","https://git.kernel.org/stable/c/c83c34c57798fc41faefcf078be78683db2f4beb","https://git.kernel.org/stable/c/ec8401a429ffee34ccf38cebf3443f8d5ae6cb0d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48862
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
vhost: fix hung thread due to erroneous iotlb entries
In vhost_iotlb_add_range_ctx(), range size can overflow to 0 when
start is 0 and last is ULONG_MAX. One instance where it can happen
is when userspace sends an IOTLB message with iova=size=uaddr=0
(vhost_process_iotlb_msg). So, an entry with size = 0, start = 0,
last = ULONG_MAX ends up in the iotlb. Next time a packet is sent,
iotlb_access_ok() loops indefinitely due to that erroneous entry.
Call Trace:
<TASK>
iotlb_access_ok+0x21b/0x3e0 drivers/vhost/vhost.c:1340
vq_meta_prefetch+0xbc/0x280 drivers/vhost/vhost.c:1366
vhost_transport_do_send_pkt+0xe0/0xfd0 drivers/vhost/vsock.c:104
vhost_worker+0x23d/0x3d0 drivers/vhost/vhost.c:372
kthread+0x2e9/0x3a0 kernel/kthread.c:377
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
</TASK>
Reported by syzbot at:
https://syzkaller.appspot.com/bug?extid=0abd373e2e50d704db87
To fix this, do two things:
1. Return -EINVAL in vhost_chr_write_iter() when userspace asks to map
a range with size 0.
2. Fix vhost_iotlb_add_range_ctx() to handle the range [0, ULONG_MAX]
by splitting it into two entries. |
["https://git.kernel.org/stable/c/d9a747e6b6561280bf1791bb24c5e9e082193dad","https://git.kernel.org/stable/c/e2ae38cf3d91837a493cb2093c87700ff3cbe667","https://git.kernel.org/stable/c/f8d88e86e90ea1002226d7ac2430152bfea003d1","https://git.kernel.org/stable/c/d9a747e6b6561280bf1791bb24c5e9e082193dad","https://git.kernel.org/stable/c/e2ae38cf3d91837a493cb2093c87700ff3cbe667","https://git.kernel.org/stable/c/f8d88e86e90ea1002226d7ac2430152bfea003d1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-0394
|
Medium |
fixed |
|
A NULL pointer dereference flaw was found in rawv6_push_pending_frames in net/ipv6/raw.c in the network subcomponent in the Linux kernel. This flaw causes the system to crash. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb3e9864cdbe35ff6378966660edbcbac955fe17","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230302-0005/","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb3e9864cdbe35ff6378966660edbcbac955fe17","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230302-0005/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52462
|
Medium |
fixed |
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: fix check for attempt to corrupt spilled pointer
When register is spilled onto a stack as a 1/2/4-byte register, we set
slot_type[BPF_REG_SIZE - 1] (plus potentially few more below it,
depending on actual spill size). So to check if some stack slot has
spilled register we need to consult slot_type[7], not slot_type[0].
To avoid the need to remember and double-check this in the future, just
use is_spilled_reg() helper. |
["https://git.kernel.org/stable/c/2757f17972d87773b3677777f5682510f13c66ef","https://git.kernel.org/stable/c/40617d45ea05535105e202a8a819e388a2b1f036","https://git.kernel.org/stable/c/67e6707f07354ed1acb4e65552e97c60cf9d69cf","https://git.kernel.org/stable/c/8dc15b0670594543c356567a1a45b0182ec63174","https://git.kernel.org/stable/c/ab125ed3ec1c10ccc36bc98c7a4256ad114a3dae","https://git.kernel.org/stable/c/fc3e3c50a0a4cac1463967c110686189e4a59104","https://git.kernel.org/stable/c/2757f17972d87773b3677777f5682510f13c66ef","https://git.kernel.org/stable/c/40617d45ea05535105e202a8a819e388a2b1f036","https://git.kernel.org/stable/c/67e6707f07354ed1acb4e65552e97c60cf9d69cf","https://git.kernel.org/stable/c/8dc15b0670594543c356567a1a45b0182ec63174","https://git.kernel.org/stable/c/ab125ed3ec1c10ccc36bc98c7a4256ad114a3dae","https://git.kernel.org/stable/c/fc3e3c50a0a4cac1463967c110686189e4a59104","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49108
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: Fix memory leaks on probe
Handle the error branches to free memory where required.
Addresses-Coverity-ID: 1491825 ("Resource leak") |
["https://git.kernel.org/stable/c/02742d1d5c95cff8b6e9379aae4ab12674f7265d","https://git.kernel.org/stable/c/7a688c91d3fd54c53e7a9edd6052cdae98dd99d8","https://git.kernel.org/stable/c/c6a0b413398588fc2d8b174a79ea715b66413fca"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49342
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: bgmac: Fix refcount leak in bcma_mdio_mii_register
of_get_child_by_name() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak. |
["https://git.kernel.org/stable/c/7fb1fe7d9a167205413f1de8db9f7d0f82c78286","https://git.kernel.org/stable/c/b51996e35bbfcc7a27d94dfeed5cc2429b2c0df4","https://git.kernel.org/stable/c/b8d91399775c55162073bb2aca061ec42e3d4bc1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49476
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7921: fix kernel crash at mt7921_pci_remove
The crash log shown it is possible that mt7921_irq_handler is called while
devm_free_irq is being handled so mt76_free_device need to be postponed
until devm_free_irq is completed to solve the crash we free the mt76 device
too early.
[ 9299.339655] BUG: kernel NULL pointer dereference, address: 0000000000000008
[ 9299.339705] #PF: supervisor read access in kernel mode
[ 9299.339735] #PF: error_code(0x0000) - not-present page
[ 9299.339768] PGD 0 P4D 0
[ 9299.339786] Oops: 0000 [#1] SMP PTI
[ 9299.339812] CPU: 1 PID: 1624 Comm: prepare-suspend Not tainted 5.15.14-1.fc32.qubes.x86_64 #1
[ 9299.339863] Hardware name: Xen HVM domU, BIOS 4.14.3 01/20/2022
[ 9299.339901] RIP: 0010:mt7921_irq_handler+0x1e/0x70 [mt7921e]
[ 9299.340048] RSP: 0018:ffffa81b80c27cb0 EFLAGS: 00010082
[ 9299.340081] RAX: 0000000000000000 RBX: ffff98a4cb752020 RCX: ffffffffa96211c5
[ 9299.340123] RDX: 0000000000000000 RSI: 00000000000d4204 RDI: ffff98a4cb752020
[ 9299.340165] RBP: ffff98a4c28a62a4 R08: ffff98a4c37a96c0 R09: 0000000080150011
[ 9299.340207] R10: 0000000040000000 R11: 0000000000000000 R12: ffff98a4c4eaa080
[ 9299.340249] R13: ffff98a4c28a6360 R14: ffff98a4cb752020 R15: ffff98a4c28a6228
[ 9299.340297] FS: 00007260840d3740(0000) GS:ffff98a4ef700000(0000) knlGS:0000000000000000
[ 9299.340345] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 9299.340383] CR2: 0000000000000008 CR3: 0000000004c56001 CR4: 0000000000770ee0
[ 9299.340432] PKRU: 55555554
[ 9299.340449] Call Trace:
[ 9299.340467] <TASK>
[ 9299.340485] __free_irq+0x221/0x350
[ 9299.340527] free_irq+0x30/0x70
[ 9299.340553] devm_free_irq+0x55/0x80
[ 9299.340579] mt7921_pci_remove+0x2f/0x40 [mt7921e]
[ 9299.340616] pci_device_remove+0x3b/0xa0
[ 9299.340651] __device_release_driver+0x17a/0x240
[ 9299.340686] device_driver_detach+0x3c/0xa0
[ 9299.340714] unbind_store+0x113/0x130
[ 9299.340740] kernfs_fop_write_iter+0x124/0x1b0
[ 9299.340775] new_sync_write+0x15c/0x1f0
[ 9299.340806] vfs_write+0x1d2/0x270
[ 9299.340831] ksys_write+0x67/0xe0
[ 9299.340857] do_syscall_64+0x3b/0x90
[ 9299.340887] entry_SYSCALL_64_after_hwframe+0x44/0xae |
["https://git.kernel.org/stable/c/09693f5b636fb3f6dd56fd943226fc1bbc600b51","https://git.kernel.org/stable/c/677e669973bf5460705bc65033445ea9f6615999","https://git.kernel.org/stable/c/ad483ed9dd5193a54293269c852a29051813b7bd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49563
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - add param check for RSA
Reject requests with a source buffer that is bigger than the size of the
key. This is to prevent a possible integer underflow that might happen
when copying the source scatterlist into a linear buffer. |
["https://git.kernel.org/stable/c/4d6d2adce08788b7667a6e58002682ea1bbf6a79","https://git.kernel.org/stable/c/9714061423b8b24b8afb31b8eb4df977c63f19c4","https://git.kernel.org/stable/c/f993321e50ba7a8ba4f5b19939e1772a921a1c42"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49564
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - add param check for DH
Reject requests with a source buffer that is bigger than the size of the
key. This is to prevent a possible integer underflow that might happen
when copying the source scatterlist into a linear buffer. |
["https://git.kernel.org/stable/c/2acbb8771f6ac82422886e63832ee7a0f4b1635b","https://git.kernel.org/stable/c/76c9216833e7c20a67c987cf89719a3f01666aaa","https://git.kernel.org/stable/c/e7f979ed51f96495328157df663c835b17db1e30"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49566
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - fix memory leak in RSA
When an RSA key represented in form 2 (as defined in PKCS #1 V2.1) is
used, some components of the private key persist even after the TFM is
released.
Replace the explicit calls to free the buffers in qat_rsa_exit_tfm()
with a call to qat_rsa_clear_ctx() which frees all buffers referenced in
the TFM context. |
["https://git.kernel.org/stable/c/0f967fdc09955221a1951a279481b0bf4d359941","https://git.kernel.org/stable/c/80a52e1ee7757b742f96bfb0d58f0c14eb6583d0","https://git.kernel.org/stable/c/a843925e0287eebb4aa808666bf22c664dfe4c53"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49570
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
gpio: gpio-xilinx: Fix integer overflow
Current implementation is not able to configure more than 32 pins
due to incorrect data type. So type casting with unsigned long
to avoid it. |
["https://git.kernel.org/stable/c/32c094a09d5829ad9b02cdf667569aefa8de0ea6","https://git.kernel.org/stable/c/6f16a5390640807dde420ee5ccbc4c95577aea6a","https://git.kernel.org/stable/c/e129e5486b981d324057e6986059f852658b0d00"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49591
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: microchip: ksz_common: Fix refcount leak bug
In ksz_switch_register(), we should call of_node_put() for the
reference returned by of_get_child_by_name() which has increased
the refcount. |
["https://git.kernel.org/stable/c/4165e02716518bbbe9c9104b39530d40928bc7ce","https://git.kernel.org/stable/c/88ec2ff42da3ac93b2437dc52fe25cd4372148e6","https://git.kernel.org/stable/c/a14bd7475452c51835dd5a0cee4c8fa48dd0b539"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49615
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: rt711-sdca: fix kernel NULL pointer dereference when IO error
The initial settings will be written before the codec probe function.
But, the rt711->component doesn't be assigned yet.
If IO error happened during initial settings operations, it will cause the kernel panic.
This patch changed component->dev to slave->dev to fix this issue. |
["https://git.kernel.org/stable/c/1df793d479bef546569fc2e409ff8bb3f0fb8e99","https://git.kernel.org/stable/c/269be8b2907378adf72d7347cfa43ef230351a06","https://git.kernel.org/stable/c/7bb71133cae88d3003a3490b97864af76533072b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49703
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: ibmvfc: Store vhost pointer during subcrq allocation
Currently the back pointer from a queue to the vhost adapter isn't set
until after subcrq interrupt registration. The value is available when a
queue is first allocated and can/should be also set for primary and async
queues as well as subcrqs.
This fixes a crash observed during kexec/kdump on Power 9 with legacy XICS
interrupt controller where a pending subcrq interrupt from the previous
kernel can be replayed immediately upon IRQ registration resulting in
dereference of a garbage backpointer in ibmvfc_interrupt_scsi().
Kernel attempted to read user page (58) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x00000058
Faulting instruction address: 0xc008000003216a08
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP [c008000003216a08] ibmvfc_interrupt_scsi+0x40/0xb0 [ibmvfc]
LR [c0000000082079e8] __handle_irq_event_percpu+0x98/0x270
Call Trace:
[c000000047fa3d80] [c0000000123e6180] 0xc0000000123e6180 (unreliable)
[c000000047fa3df0] [c0000000082079e8] __handle_irq_event_percpu+0x98/0x270
[c000000047fa3ea0] [c000000008207d18] handle_irq_event+0x98/0x188
[c000000047fa3ef0] [c00000000820f564] handle_fasteoi_irq+0xc4/0x310
[c000000047fa3f40] [c000000008205c60] generic_handle_irq+0x50/0x80
[c000000047fa3f60] [c000000008015c40] __do_irq+0x70/0x1a0
[c000000047fa3f90] [c000000008016d7c] __do_IRQ+0x9c/0x130
[c000000014622f60] [0000000020000000] 0x20000000
[c000000014622ff0] [c000000008016e50] do_IRQ+0x40/0xa0
[c000000014623020] [c000000008017044] replay_soft_interrupts+0x194/0x2f0
[c000000014623210] [c0000000080172a8] arch_local_irq_restore+0x108/0x170
[c000000014623240] [c000000008eb1008] _raw_spin_unlock_irqrestore+0x58/0xb0
[c000000014623270] [c00000000820b12c] __setup_irq+0x49c/0x9f0
[c000000014623310] [c00000000820b7c0] request_threaded_irq+0x140/0x230
[c000000014623380] [c008000003212a50] ibmvfc_register_scsi_channel+0x1e8/0x2f0 [ibmvfc]
[c000000014623450] [c008000003213d1c] ibmvfc_init_sub_crqs+0xc4/0x1f0 [ibmvfc]
[c0000000146234d0] [c0080000032145a8] ibmvfc_reset_crq+0x150/0x210 [ibmvfc]
[c000000014623550] [c0080000032147c8] ibmvfc_init_crq+0x160/0x280 [ibmvfc]
[c0000000146235f0] [c00800000321a9cc] ibmvfc_probe+0x2a4/0x530 [ibmvfc] |
["https://git.kernel.org/stable/c/6d38e3b614ded59da8b95377a98df969a5a5627a","https://git.kernel.org/stable/c/8540f66196ca35b7b5e902932571c18b9fde0cd1","https://git.kernel.org/stable/c/aeaadcde1a60138bceb65de3cdaeec78170b4459"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49704
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
9p: fix fid refcount leak in v9fs_vfs_get_link
we check for protocol version later than required, after a fid has
been obtained. Just move the version check earlier. |
["https://git.kernel.org/stable/c/e5690f263208c5abce7451370b7786eb25b405eb","https://git.kernel.org/stable/c/e7b6d622bd812013eb39c8f4cd65b7ee8ede1e02","https://git.kernel.org/stable/c/f0126bcaee81dabc1926012126aa74caa03a4c6e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49705
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
9p: fix fid refcount leak in v9fs_vfs_atomic_open_dotl
We need to release directory fid if we fail halfway through open
This fixes fid leaking with xfstests generic 531 |
["https://git.kernel.org/stable/c/22832ac3eb5be3f7168816a76b64c1284e12eb3c","https://git.kernel.org/stable/c/8bc5412ba1a45edfd1e451874c483c26a097af2b","https://git.kernel.org/stable/c/beca774fc51a9ba8abbc869cf0c3d965ff17cd24"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49714
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
irqchip/realtek-rtl: Fix refcount leak in map_interrupts
of_find_node_by_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
This function doesn't call of_node_put() in error path.
Call of_node_put() directly after of_property_read_u32() to cover
both normal path and error path. |
["https://git.kernel.org/stable/c/e85b1b797de0e7a271b906291ce28245822820b8","https://git.kernel.org/stable/c/eff4780f83d0ae3e5b6c02ff5d999dc4c1c5c8ce","https://git.kernel.org/stable/c/f6d6223df0666fbc054e3a8c6ac14eb0af37c286"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-58089
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix double accounting race when btrfs_run_delalloc_range() failed
[BUG]
When running btrfs with block size (4K) smaller than page size (64K,
aarch64), there is a very high chance to crash the kernel at
generic/750, with the following messages:
(before the call traces, there are 3 extra debug messages added)
BTRFS warning (device dm-3): read-write for sector size 4096 with page size 65536 is experimental
BTRFS info (device dm-3): checking UUID tree
hrtimer: interrupt took 5451385 ns
BTRFS error (device dm-3): cow_file_range failed, root=4957 inode=257 start=1605632 len=69632: -28
BTRFS error (device dm-3): run_delalloc_nocow failed, root=4957 inode=257 start=1605632 len=69632: -28
BTRFS error (device dm-3): failed to run delalloc range, root=4957 ino=257 folio=1572864 submit_bitmap=8-15 start=1605632 len=69632: -28
------------[ cut here ]------------
WARNING: CPU: 2 PID: 3020984 at ordered-data.c:360 can_finish_ordered_extent+0x370/0x3b8 [btrfs]
CPU: 2 UID: 0 PID: 3020984 Comm: kworker/u24:1 Tainted: G OE 6.13.0-rc1-custom+ #89
Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022
Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs]
pc : can_finish_ordered_extent+0x370/0x3b8 [btrfs]
lr : can_finish_ordered_extent+0x1ec/0x3b8 [btrfs]
Call trace:
can_finish_ordered_extent+0x370/0x3b8 [btrfs] (P)
can_finish_ordered_extent+0x1ec/0x3b8 [btrfs] (L)
btrfs_mark_ordered_io_finished+0x130/0x2b8 [btrfs]
extent_writepage+0x10c/0x3b8 [btrfs]
extent_write_cache_pages+0x21c/0x4e8 [btrfs]
btrfs_writepages+0x94/0x160 [btrfs]
do_writepages+0x74/0x190
filemap_fdatawrite_wbc+0x74/0xa0
start_delalloc_inodes+0x17c/0x3b0 [btrfs]
btrfs_start_delalloc_roots+0x17c/0x288 [btrfs]
shrink_delalloc+0x11c/0x280 [btrfs]
flush_space+0x288/0x328 [btrfs]
btrfs_async_reclaim_data_space+0x180/0x228 [btrfs]
process_one_work+0x228/0x680
worker_thread+0x1bc/0x360
kthread+0x100/0x118
ret_from_fork+0x10/0x20
---[ end trace 0000000000000000 ]---
BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1605632 OE len=16384 to_dec=16384 left=0
BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1622016 OE len=12288 to_dec=12288 left=0
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1634304 OE len=8192 to_dec=4096 left=0
CPU: 1 UID: 0 PID: 3286940 Comm: kworker/u24:3 Tainted: G W OE 6.13.0-rc1-custom+ #89
Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022
Workqueue: btrfs_work_helper [btrfs] (btrfs-endio-write)
pstate: 404000c5 (nZcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : process_one_work+0x110/0x680
lr : worker_thread+0x1bc/0x360
Call trace:
process_one_work+0x110/0x680 (P)
worker_thread+0x1bc/0x360 (L)
worker_thread+0x1bc/0x360
kthread+0x100/0x118
ret_from_fork+0x10/0x20
Code: f84086a1 f9000fe1 53041c21 b9003361 (f9400661)
---[ end trace 0000000000000000 ]---
Kernel panic - not syncing: Oops: Fatal exception
SMP: stopping secondary CPUs
SMP: failed to stop secondary CPUs 2-3
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: 0x275bb9540000 from 0xffff800080000000
PHYS_OFFSET: 0xffff8fbba0000000
CPU features: 0x100,00000070,00801250,8201720b
[CAUSE]
The above warning is triggered immediately after the delalloc range
failure, this happens in the following sequence:
- Range [1568K, 1636K) is dirty
1536K 1568K 1600K 1636K 1664K
| |/////////|////////| |
Where 1536K, 1600K and 1664K are page boundaries (64K page size)
- Enter extent_writepage() for page 1536K
- Enter run_delalloc_nocow() with locke
---truncated--- |
["https://git.kernel.org/stable/c/0283ee1912c8e243c931f4ee5b3672e954fe0384","https://git.kernel.org/stable/c/21333148b5c9e52f41fafcedec3810b56a5e0e40","https://git.kernel.org/stable/c/72dad8e377afa50435940adfb697e070d3556670"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21861
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mm/migrate_device: don't add folio to be freed to LRU in migrate_device_finalize()
If migration succeeded, we called
folio_migrate_flags()->mem_cgroup_migrate() to migrate the memcg from the
old to the new folio. This will set memcg_data of the old folio to 0.
Similarly, if migration failed, memcg_data of the dst folio is left unset.
If we call folio_putback_lru() on such folios (memcg_data == 0), we will
add the folio to be freed to the LRU, making memcg code unhappy. Running
the hmm selftests:
# ./hmm-tests
...
# RUN hmm.hmm_device_private.migrate ...
[ 102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00
[ 102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff)
[ 102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9
[ 102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000
[ 102.085331][T14893] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg && !mem_cgroup_disabled())
[ 102.087230][T14893] ------------[ cut here ]------------
[ 102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 folio_lruvec_lock_irqsave+0x10e/0x170
[ 102.090478][T14893] Modules linked in:
[ 102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151
[ 102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014
[ 102.094848][T14893] RIP: 0010:folio_lruvec_lock_irqsave+0x10e/0x170
[ 102.096104][T14893] Code: ...
[ 102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293
[ 102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426
[ 102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880
[ 102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000
[ 102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8
[ 102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000
[ 102.108830][T14893] FS: 00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000
[ 102.110643][T14893] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0
[ 102.113478][T14893] PKRU: 55555554
[ 102.114172][T14893] Call Trace:
[ 102.114805][T14893] <TASK>
[ 102.115397][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170
[ 102.116547][T14893] ? __warn.cold+0x110/0x210
[ 102.117461][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170
[ 102.118667][T14893] ? report_bug+0x1b9/0x320
[ 102.119571][T14893] ? handle_bug+0x54/0x90
[ 102.120494][T14893] ? exc_invalid_op+0x17/0x50
[ 102.121433][T14893] ? asm_exc_invalid_op+0x1a/0x20
[ 102.122435][T14893] ? __wake_up_klogd.part.0+0x76/0xd0
[ 102.123506][T14893] ? dump_page+0x4f/0x60
[ 102.124352][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170
[ 102.125500][T14893] folio_batch_move_lru+0xd4/0x200
[ 102.126577][T14893] ? __pfx_lru_add+0x10/0x10
[ 102.127505][T14893] __folio_batch_add_and_move+0x391/0x720
[ 102.128633][T14893] ? __pfx_lru_add+0x10/0x10
[ 102.129550][T14893] folio_putback_lru+0x16/0x80
[ 102.130564][T14893] migrate_device_finalize+0x9b/0x530
[ 102.131640][T14893] dmirror_migrate_to_device.constprop.0+0x7c5/0xad0
[ 102.133047][T14893] dmirror_fops_unlocked_ioctl+0x89b/0xc80
Likely, nothing else goes wrong: putting the last folio reference will
remove the folio from the LRU again. So besides memcg complaining, adding
the folio to be freed to the LRU is just an unnecessary step.
The new flow resembles what we have in migrate_folio_move(): add the dst
to the lru, rem
---truncated--- |
["https://git.kernel.org/stable/c/069dd21ea8262204f94737878389c2815a054a9e","https://git.kernel.org/stable/c/3f9240d59e9a95d19f06120bfd1d0e681c6c0ac7","https://git.kernel.org/stable/c/41cddf83d8b00f29fd105e7a0777366edc69a5cf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56647
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: Fix icmp host relookup triggering ip_rt_bug
arp link failure may trigger ip_rt_bug while xfrm enabled, call trace is:
WARNING: CPU: 0 PID: 0 at net/ipv4/route.c:1241 ip_rt_bug+0x14/0x20
Modules linked in:
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:ip_rt_bug+0x14/0x20
Call Trace:
<IRQ>
ip_send_skb+0x14/0x40
__icmp_send+0x42d/0x6a0
ipv4_link_failure+0xe2/0x1d0
arp_error_report+0x3c/0x50
neigh_invalidate+0x8d/0x100
neigh_timer_handler+0x2e1/0x330
call_timer_fn+0x21/0x120
__run_timer_base.part.0+0x1c9/0x270
run_timer_softirq+0x4c/0x80
handle_softirqs+0xac/0x280
irq_exit_rcu+0x62/0x80
sysvec_apic_timer_interrupt+0x77/0x90
The script below reproduces this scenario:
ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 \
dir out priority 0 ptype main flag localok icmp
ip l a veth1 type veth
ip a a 192.168.141.111/24 dev veth0
ip l s veth0 up
ping 192.168.141.155 -c 1
icmp_route_lookup() create input routes for locally generated packets
while xfrm relookup ICMP traffic.Then it will set input route
(dst->out = ip_rt_bug) to skb for DESTUNREACH.
For ICMP err triggered by locally generated packets, dst->dev of output
route is loopback. Generally, xfrm relookup verification is not required
on loopback interfaces (net.ipv4.conf.lo.disable_xfrm = 1).
Skip icmp relookup for locally generated packets to fix it. |
["https://git.kernel.org/stable/c/9545011e7b2a8fc0cbd6e387a09f12cd41d7d82f","https://git.kernel.org/stable/c/c44daa7e3c73229f7ac74985acb8c7fb909c4e0a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-47654
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
samples/landlock: Fix path_list memory leak
Clang static analysis reports this error
sandboxer.c:134:8: warning: Potential leak of memory
pointed to by 'path_list'
ret = 0;
^
path_list is allocated in parse_path() but never freed. |
["https://git.kernel.org/stable/c/017196730299ccd6eed24bbfabed8af4ffd81530","https://git.kernel.org/stable/c/20fbf100f84b9aeb9c91421abe1927bc152bc32b","https://git.kernel.org/stable/c/49b0d8bf05809df5f87e5c03e26d74bdfdab4571","https://git.kernel.org/stable/c/66b513b7c64a7290c1fbb88e657f7cece992e131"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-47657
|
Medium |
fixed |
- 5.12
- 5.15.32
- 5.16.18
- 5.17.1
|
In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: Ensure that objs is not NULL in virtio_gpu_array_put_free()
If virtio_gpu_object_shmem_init() fails (e.g. due to fault injection, as it
happened in the bug report by syzbot), virtio_gpu_array_put_free() could be
called with objs equal to NULL.
Ensure that objs is not NULL in virtio_gpu_array_put_free(), or otherwise
return from the function. |
["https://git.kernel.org/stable/c/6b79f96f4a23846516e5e6e4dd37fc06f43a60dd","https://git.kernel.org/stable/c/abc9ad36df16e27ac1c665085157f1a082d39bac","https://git.kernel.org/stable/c/ac92b474eeeed75b8660374ba1d129a121c09da8","https://git.kernel.org/stable/c/b094fece3810c71ceee6f0921676cb65d4e68c5a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-47660
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix some memory leaks in an error handling path of 'log_replay()'
All error handling paths lead to 'out' where many resources are freed.
Do it as well here instead of a direct return, otherwise 'log', 'ra' and
'log->one_page_buf' (at least) will leak. |
["https://git.kernel.org/stable/c/2c97519ed6b4239594c58ddacf3d0d576cf070cc","https://git.kernel.org/stable/c/bc4a1d384a04c6dba9312e1421a9f9f7c03339a4","https://git.kernel.org/stable/c/d8be98ab88250dc12a98efdb703792a537b0eac3","https://git.kernel.org/stable/c/e589f9b7078e1c0191613cd736f598e81d2390de"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49046
|
Medium |
fixed |
- 4.5
- 4.10
- 4.15
- 4.20
- 5.5
- 5.15.35
- 5.17.4
|
In the Linux kernel, the following vulnerability has been resolved:
i2c: dev: check return value when calling dev_set_name()
If dev_set_name() fails, the dev_name() is null, check the return
value of dev_set_name() to avoid the null-ptr-deref. |
["https://git.kernel.org/stable/c/2e539b17d4cbe5fb8b5152dd9a6e4a8828f97db2","https://git.kernel.org/stable/c/2f345bb14ad4744950499ff222e2899209297afa","https://git.kernel.org/stable/c/993eb48fa199b5f476df8204e652eff63dd19361","https://git.kernel.org/stable/c/c74d77a2d07744147d734138acd6ce9dba715e5d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49065
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix the svc_deferred_event trace class
Fix a NULL deref crash that occurs when an svc_rqst is deferred
while the sunrpc tracing subsystem is enabled. svc_revisit() sets
dr->xprt to NULL, so it can't be relied upon in the tracepoint to
provide the remote's address.
Unfortunately we can't revert the "svc_deferred_class" hunk in
commit ece200ddd54b ("sunrpc: Save remote presentation address in
svc_xprt for trace events") because there is now a specific check
of event format specifiers for unsafe dereferences. The warning
that check emits is:
event svc_defer_recv has unsafe dereference of argument 1
A "%pISpc" format specifier with a "struct sockaddr *" is indeed
flagged by this check.
Instead, take the brute-force approach used by the svcrdma_qp_error
tracepoint. Convert the dr::addr field into a presentation address
in the TP_fast_assign() arm of the trace event, and store that as
a string. This fix can be backported to -stable kernels.
In the meantime, commit c6ced22997ad ("tracing: Update print fmt
check to handle new __get_sockaddr() macro") is now in v5.18, so
this wonky fix can be replaced with __sockaddr() and friends
properly during the v5.19 merge window. |
["https://git.kernel.org/stable/c/4d5004451ab2218eab94a30e1841462c9316ba19","https://git.kernel.org/stable/c/726ae7300fcc25fefa46d188cc07eb16dc908f9e","https://git.kernel.org/stable/c/85ee17ca21cf92989e8c923e3ea4514c291e9d38","https://git.kernel.org/stable/c/c2456f470eea3bd06574d988bf6089e7c3f4c5cc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49071
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/panel: ili9341: fix optional regulator handling
If the optional regulator lookup fails, reset the pointer to NULL.
Other functions such as mipi_dbi_poweron_reset_conditional() only do
a NULL pointer check and will otherwise dereference the error pointer. |
["https://git.kernel.org/stable/c/28dc1503a9d36654f9c61adb2915682515a30f71","https://git.kernel.org/stable/c/4ea189854b1e625ed5ec80d30147870f984db44c","https://git.kernel.org/stable/c/d14eb80e27795b7b20060f7b151cdfe39722a813","https://git.kernel.org/stable/c/e3d982c111a6c033671dd6084b07f62fbf50f76f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49096
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: sfc: add missing xdp queue reinitialization
After rx/tx ring buffer size is changed, kernel panic occurs when
it acts XDP_TX or XDP_REDIRECT.
When tx/rx ring buffer size is changed(ethtool -G), sfc driver
reallocates and reinitializes rx and tx queues and their buffer
(tx_queue->buffer).
But it misses reinitializing xdp queues(efx->xdp_tx_queues).
So, while it is acting XDP_TX or XDP_REDIRECT, it uses the uninitialized
tx_queue->buffer.
A new function efx_set_xdp_channels() is separated from efx_set_channels()
to handle only xdp queues.
Splat looks like:
BUG: kernel NULL pointer dereference, address: 000000000000002a
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 0 P4D 0
Oops: 0002 [#4] PREEMPT SMP NOPTI
RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc]
CPU: 2 PID: 0 Comm: swapper/2 Tainted: G D 5.17.0+ #55 e8beeee8289528f11357029357cf
Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80
RSP: 0018:ffff92f121e45c60 EFLAGS: 00010297
RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc]
RAX: 0000000000000040 RBX: ffff92ea506895c0 RCX: ffffffffc0330870
RDX: 0000000000000001 RSI: 00000001139b10ce RDI: ffff92ea506895c0
RBP: ffffffffc0358a80 R08: 00000001139b110d R09: 0000000000000000
R10: 0000000000000001 R11: ffff92ea414c0088 R12: 0000000000000040
R13: 0000000000000018 R14: 00000001139b10ce R15: ffff92ea506895c0
FS: 0000000000000000(0000) GS:ffff92f121ec0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80
CR2: 000000000000002a CR3: 00000003e6810004 CR4: 00000000007706e0
RSP: 0018:ffff92f121e85c60 EFLAGS: 00010297
PKRU: 55555554
RAX: 0000000000000040 RBX: ffff92ea50689700 RCX: ffffffffc0330870
RDX: 0000000000000001 RSI: 00000001145a90ce RDI: ffff92ea50689700
RBP: ffffffffc0358a80 R08: 00000001145a910d R09: 0000000000000000
R10: 0000000000000001 R11: ffff92ea414c0088 R12: 0000000000000040
R13: 0000000000000018 R14: 00000001145a90ce R15: ffff92ea50689700
FS: 0000000000000000(0000) GS:ffff92f121e80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000002a CR3: 00000003e6810005 CR4: 00000000007706e0
PKRU: 55555554
Call Trace:
<IRQ>
efx_xdp_tx_buffers+0x12b/0x3d0 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]
__efx_rx_packet+0x5c3/0x930 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]
efx_rx_packet+0x28c/0x2e0 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]
efx_ef10_ev_process+0x5f8/0xf40 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]
? enqueue_task_fair+0x95/0x550
efx_poll+0xc4/0x360 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5] |
["https://git.kernel.org/stable/c/059a47f1da93811d37533556d67e72f2261b1127","https://git.kernel.org/stable/c/b8c46bc358d84701e7f7ffa054037db25f25da0e","https://git.kernel.org/stable/c/dcc85e1593686e42c6749ef3d356db34759d59e8","https://git.kernel.org/stable/c/ed7a824fda8732578d1014fad1f7fb0363705090"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49102
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
habanalabs: fix possible memory leak in MMU DR fini
This patch fixes what seems to be copy paste error.
We will have a memory leak if the host-resident shadow is NULL (which
will likely happen as the DR and HR are not dependent). |
["https://git.kernel.org/stable/c/12e49aefda2e04b07604f13e03f40027cbeb0dc6","https://git.kernel.org/stable/c/30058d3a83cfe8c6aacbfe5ab13c01dd0c1799e3","https://git.kernel.org/stable/c/6d421fb7a9eddd8ce0a05641a3db97283fe20699","https://git.kernel.org/stable/c/eb85eec858c1a5c11d3a0bff403f6440b05b40dc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49106
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
staging: vchiq_arm: Avoid NULL ptr deref in vchiq_dump_platform_instances
vchiq_get_state() can return a NULL pointer. So handle this cases and
avoid a NULL pointer derefence in vchiq_dump_platform_instances. |
["https://git.kernel.org/stable/c/176df12b38c70b0a45e6392a0ee5bc83489dfc29","https://git.kernel.org/stable/c/4627250cabaa80278d3ab01ad107893cea83799f","https://git.kernel.org/stable/c/51e5e5c34c22c0bfec0808d8c33e0b2fcf4c7c89","https://git.kernel.org/stable/c/aa899e686d442c63d50f4d369cc02dbbf0941cb0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49126
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpi3mr: Fix memory leaks
Fix memory leaks related to operational reply queue's memory segments which
are not getting freed while unloading the driver. |
["https://git.kernel.org/stable/c/27fc9e90171ab0a94a411f3fdb3522ef5acb9537","https://git.kernel.org/stable/c/5d76a88b8536d75ff5362e232097e85946b8aadf","https://git.kernel.org/stable/c/71c7ac65a084ae7d387c3c1d02d59edfdecb009f","https://git.kernel.org/stable/c/d44b5fefb22e139408ae12b864da1ecb9ad9d1d2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49128
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/bridge: Add missing pm_runtime_put_sync
pm_runtime_get_sync() will increase the rumtime PM counter
even when it returns an error. Thus a pairing decrement is needed
to prevent refcount leak. Fix this by replacing this API with
pm_runtime_resume_and_get(), which will not change the runtime
PM counter on error. Besides, a matching decrement is needed
on the error handling path to keep the counter balanced. |
["https://git.kernel.org/stable/c/46f47807738441e354873546dde0b000106c068a","https://git.kernel.org/stable/c/792533e54cd6e89191798ccd1abd590c62b9077e","https://git.kernel.org/stable/c/9df80dc738926a2ea4bd1ce5993c3d0f4b0e855c","https://git.kernel.org/stable/c/ff13c90d7f7ab606b37be6d15140d19013d6736c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49135
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix memory leak
[why]
Resource release is needed on the error handling path
to prevent memory leak.
[how]
Fix this by adding kfree on the error handling path. |
["https://git.kernel.org/stable/c/3ce1497add6d17b48cc9df65095bd20202d93994","https://git.kernel.org/stable/c/5d5c6dba2b43e28845d7d7ed32a36802329a5f52","https://git.kernel.org/stable/c/7e10369c72db7a0e2f77b2e306aadc07aef6b07a","https://git.kernel.org/stable/c/9d0bef3cc22cf250278ed45b829f062a00af9e27"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49183
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_ct: fix ref leak when switching zones
When switching zones or network namespaces without doing a ct clear in
between, it is now leaking a reference to the old ct entry. That's
because tcf_ct_skb_nfct_cached() returns false and
tcf_ct_flow_table_lookup() may simply overwrite it.
The fix is to, as the ct entry is not reusable, free it already at
tcf_ct_skb_nfct_cached(). |
["https://git.kernel.org/stable/c/4bb42d73def9411e5cad885b9811987d72431df1","https://git.kernel.org/stable/c/b24793a37d91aacad7cb9893b226a7924a89636a","https://git.kernel.org/stable/c/bcb74e132a76ce0502bb33d5b65533a4ed72d159","https://git.kernel.org/stable/c/bcbf4e5c3b5b373cd61528392dd1ec8e9c0fd33d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49184
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: sparx5: switchdev: fix possible NULL pointer dereference
As the possible failure of the allocation, devm_kzalloc() may return NULL
pointer.
Therefore, it should be better to check the 'db' in order to prevent
the dereference of NULL pointer. |
["https://git.kernel.org/stable/c/0906f3a3df07835e37077d8971aac65347f2ed57","https://git.kernel.org/stable/c/b375ea083fa649092cd016ac1f89a2d1fd8f8e8b","https://git.kernel.org/stable/c/c346791877e6ce923bb21e34b30c6f99326aa5a8","https://git.kernel.org/stable/c/e7e1fff76c4c57688dc7d53a3b6212182d5628d0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49187
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
clk: Fix clk_hw_get_clk() when dev is NULL
Any registered clk_core structure can have a NULL pointer in its dev
field. While never actually documented, this is evidenced by the wide
usage of clk_register and clk_hw_register with a NULL device pointer,
and the fact that the core of_clk_hw_register() function also passes a
NULL device pointer.
A call to clk_hw_get_clk() on a clk_hw struct whose clk_core is in that
case will result in a NULL pointer derefence when it calls dev_name() on
that NULL device pointer.
Add a test for this case and use NULL as the dev_id if the device
pointer is NULL. |
["https://git.kernel.org/stable/c/0c1b56df451716ba207bbf59f303473643eee4fd","https://git.kernel.org/stable/c/23f89fe005b105f0dcc55034c13eb89f9b570fac","https://git.kernel.org/stable/c/4be3e4c05d8dd1b83b75652cad88c9e752ec7054","https://git.kernel.org/stable/c/d183f20cf5a7b546d4108e796b98210ceb317579"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49207
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix memleak in sk_psock_queue_msg
If tcp_bpf_sendmsg is running during a tear down operation we may enqueue
data on the ingress msg queue while tear down is trying to free it.
sk1 (redirect sk2) sk2
------------------- ---------------
tcp_bpf_sendmsg()
tcp_bpf_send_verdict()
tcp_bpf_sendmsg_redir()
bpf_tcp_ingress()
sock_map_close()
lock_sock()
lock_sock() ... blocking
sk_psock_stop
sk_psock_clear_state(psock, SK_PSOCK_TX_ENABLED);
release_sock(sk);
lock_sock()
sk_mem_charge()
get_page()
sk_psock_queue_msg()
sk_psock_test_state(psock, SK_PSOCK_TX_ENABLED);
drop_sk_msg()
release_sock()
While drop_sk_msg(), the msg has charged memory form sk by sk_mem_charge
and has sg pages need to put. To fix we use sk_msg_free() and then kfee()
msg.
This issue can cause the following info:
WARNING: CPU: 0 PID: 9202 at net/core/stream.c:205 sk_stream_kill_queues+0xc8/0xe0
Call Trace:
<IRQ>
inet_csk_destroy_sock+0x55/0x110
tcp_rcv_state_process+0xe5f/0xe90
? sk_filter_trim_cap+0x10d/0x230
? tcp_v4_do_rcv+0x161/0x250
tcp_v4_do_rcv+0x161/0x250
tcp_v4_rcv+0xc3a/0xce0
ip_protocol_deliver_rcu+0x3d/0x230
ip_local_deliver_finish+0x54/0x60
ip_local_deliver+0xfd/0x110
? ip_protocol_deliver_rcu+0x230/0x230
ip_rcv+0xd6/0x100
? ip_local_deliver+0x110/0x110
__netif_receive_skb_one_core+0x85/0xa0
process_backlog+0xa4/0x160
__napi_poll+0x29/0x1b0
net_rx_action+0x287/0x300
__do_softirq+0xff/0x2fc
do_softirq+0x79/0x90
</IRQ>
WARNING: CPU: 0 PID: 531 at net/ipv4/af_inet.c:154 inet_sock_destruct+0x175/0x1b0
Call Trace:
<TASK>
__sk_destruct+0x24/0x1f0
sk_psock_destroy+0x19b/0x1c0
process_one_work+0x1b3/0x3c0
? process_one_work+0x3c0/0x3c0
worker_thread+0x30/0x350
? process_one_work+0x3c0/0x3c0
kthread+0xe6/0x110
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x22/0x30
</TASK> |
["https://git.kernel.org/stable/c/03948ed6553960db62f1c33bec29e64d7c191a3f","https://git.kernel.org/stable/c/4dd2e947d3be13a4de3b3028859b9a6497266bcf","https://git.kernel.org/stable/c/938d3480b92fa5e454b7734294f12a7b75126f09","https://git.kernel.org/stable/c/ef9785f429794567792561a584901faa9291d3ee"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49208
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/irdma: Prevent some integer underflows
My static checker complains that:
drivers/infiniband/hw/irdma/ctrl.c:3605 irdma_sc_ceq_init()
warn: can subtract underflow 'info->dev->hmc_fpm_misc.max_ceqs'?
It appears that "info->dev->hmc_fpm_misc.max_ceqs" comes from the firmware
in irdma_sc_parse_fpm_query_buf() so, yes, there is a chance that it could
be zero. Even if we trust the firmware, it's easy enough to change the
condition just as a hardenning measure. |
["https://git.kernel.org/stable/c/6f6dbb819dfc1a35bcb8b709b5c83a3ea8beff75","https://git.kernel.org/stable/c/7340c3675d7ac946f4019b84cd7c64ed542dfe4c","https://git.kernel.org/stable/c/d52dab6e03550f9c97121b0c11c0a3ed78ee76a4","https://git.kernel.org/stable/c/f21056f15bbeacab7b4b87af232f5599d1f2bff1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49273
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
rtc: pl031: fix rtc features null pointer dereference
When there is no interrupt line, rtc alarm feature is disabled.
The clearing of the alarm feature bit was being done prior to allocations
of ldata->rtc device, resulting in a null pointer dereference.
Clear RTC_FEATURE_ALARM after the rtc device is allocated. |
["https://git.kernel.org/stable/c/1b915703964f7e636961df04c540261dc55c6c70","https://git.kernel.org/stable/c/cd2722e411e8ab7e5ae41102f6925fa13dffdac5","https://git.kernel.org/stable/c/d274ce4a3dfd0b9a292667535578359b865765cb","https://git.kernel.org/stable/c/ea6af39f3da50c86367a71eb3cc674ade3ed244c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49284
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
coresight: syscfg: Fix memleak on registration failure in cscfg_create_device
device_register() calls device_initialize(),
according to doc of device_initialize:
Use put_device() to give up your reference instead of freeing
* @dev directly once you have called this function.
To prevent potential memleak, use put_device() for error handling. |
["https://git.kernel.org/stable/c/412225b32986d5b11c3c1ad9234c50a3f5c52c76","https://git.kernel.org/stable/c/a529af1f5a5c096f3e18f0d5a32cfcc3d82df1ec","https://git.kernel.org/stable/c/c61e2fc87f24cae4701f352fe9ecd4c5c143106c","https://git.kernel.org/stable/c/cfa5dbcdd7aece76f3415284569f2f384aff0253"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49294
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check if modulo is 0 before dividing.
[How & Why]
If a value of 0 is read, then this will cause a divide-by-0 panic. |
["https://git.kernel.org/stable/c/07efce8269a038c37814eb656b4de14aa3015fc6","https://git.kernel.org/stable/c/10ef82d6e0af5536ec64770c07f6bbabfdd6977c","https://git.kernel.org/stable/c/49947b906a6bd9668eaf4f9cf691973c25c26955","https://git.kernel.org/stable/c/96725758eff7b3805e4e94d1443a100757412720"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49310
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
char: xillybus: fix a refcount leak in cleanup_dev()
usb_get_dev is called in xillyusb_probe. So it is better to call
usb_put_dev before xdev is released. |
["https://git.kernel.org/stable/c/21f1f167d727f3f857e26d509ef5a6d47fd31bc3","https://git.kernel.org/stable/c/b67d19662fdee275c479d21853bc1239600a798f","https://git.kernel.org/stable/c/bc8fceda3b89006e8a7dda8a097d36045d044c25","https://git.kernel.org/stable/c/e277b95acdab84cd5d2f8d537a37aef6d21e988b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49329
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
vduse: Fix NULL pointer dereference on sysfs access
The control device has no drvdata. So we will get a
NULL pointer dereference when accessing control
device's msg_timeout attribute via sysfs:
[ 132.841881][ T3644] BUG: kernel NULL pointer dereference, address: 00000000000000f8
[ 132.850619][ T3644] RIP: 0010:msg_timeout_show (drivers/vdpa/vdpa_user/vduse_dev.c:1271)
[ 132.869447][ T3644] dev_attr_show (drivers/base/core.c:2094)
[ 132.870215][ T3644] sysfs_kf_seq_show (fs/sysfs/file.c:59)
[ 132.871164][ T3644] ? device_remove_bin_file (drivers/base/core.c:2088)
[ 132.872082][ T3644] kernfs_seq_show (fs/kernfs/file.c:164)
[ 132.872838][ T3644] seq_read_iter (fs/seq_file.c:230)
[ 132.873578][ T3644] ? __vmalloc_area_node (mm/vmalloc.c:3041)
[ 132.874532][ T3644] kernfs_fop_read_iter (fs/kernfs/file.c:238)
[ 132.875513][ T3644] __kernel_read (fs/read_write.c:440 (discriminator 1))
[ 132.876319][ T3644] kernel_read (fs/read_write.c:459)
[ 132.877129][ T3644] kernel_read_file (fs/kernel_read_file.c:94)
[ 132.877978][ T3644] kernel_read_file_from_fd (include/linux/file.h:45 fs/kernel_read_file.c:186)
[ 132.879019][ T3644] __do_sys_finit_module (kernel/module.c:4207)
[ 132.879930][ T3644] __ia32_sys_finit_module (kernel/module.c:4189)
[ 132.880930][ T3644] do_int80_syscall_32 (arch/x86/entry/common.c:112 arch/x86/entry/common.c:132)
[ 132.881847][ T3644] entry_INT80_compat (arch/x86/entry/entry_64_compat.S:419)
To fix it, don't create the unneeded attribute for
control device anymore. |
["https://git.kernel.org/stable/c/30fd1b56621e187346f65d01fe34870634b15188","https://git.kernel.org/stable/c/3a7a81f4835dfda11f39fdd27586da14331896eb","https://git.kernel.org/stable/c/b22fdee17ec62604060fb0fda5e1414b634666e1","https://git.kernel.org/stable/c/b27ee76c74dc831d6e092eaebc2dfc9c0beed1c9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49366
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix reference count leak in smb_check_perm_dacl()
The issue happens in a specific path in smb_check_perm_dacl(). When
"id" and "uid" have the same value, the function simply jumps out of
the loop without decrementing the reference count of the object
"posix_acls", which is increased by get_acl() earlier. This may
result in memory leaks.
Fix it by decreasing the reference count of "posix_acls" before
jumping to label "check_access_bits". |
["https://git.kernel.org/stable/c/248d71b440aef829f5cc5f6545ca113ef5062900","https://git.kernel.org/stable/c/9758a6653c27867d810de02b4e5697163dda9883","https://git.kernel.org/stable/c/cf824b95c12a1abacadbc2d069931963221a3414","https://git.kernel.org/stable/c/d21a580dafc69aa04f46e6099616146a536b0724"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49392
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
serial: 8250_aspeed_vuart: Fix potential NULL dereference in aspeed_vuart_probe
platform_get_resource() may fail and return NULL, so we should
better check it's return value to avoid a NULL pointer dereference. |
["https://git.kernel.org/stable/c/0e0fd55719fa081de6f9e5d9e6cef48efb04d34a","https://git.kernel.org/stable/c/90a6b6fc52bfdcfe9698454bf5bea26112abbcd1","https://git.kernel.org/stable/c/923d34ce069e8e51a4d003caa6b66a8cd6ecd0ed","https://git.kernel.org/stable/c/d5f1275f101e0e8a172d300d897f5a12e87e3485"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49437
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
powerpc/xive: Fix refcount leak in xive_spapr_init
of_find_compatible_node() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak. |
["https://git.kernel.org/stable/c/1d1fb9618bdd5a5fbf9a9eb75133da301d33721c","https://git.kernel.org/stable/c/65f11ccdd746e0e7f0b469cc989ba43d4f30ecfe","https://git.kernel.org/stable/c/6e806485d851986a2445267608f27cb4ba2ed774","https://git.kernel.org/stable/c/cc62dde2a5f4ba14016fd9caec76f08d388f4b9c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49448
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
soc: bcm: Check for NULL return of devm_kzalloc()
As the potential failure of allocation, devm_kzalloc() may return NULL. Then
the 'pd->pmb' and the follow lines of code may bring null pointer dereference.
Therefore, it is better to check the return value of devm_kzalloc() to avoid
this confusion. |
["https://git.kernel.org/stable/c/36339ea7bae4943be01c8e9545e46e334591fecd","https://git.kernel.org/stable/c/5650e103bfc70156001615861fb8aafb3947da6e","https://git.kernel.org/stable/c/b48b98743b568bb219152ba2e15af6ef0d3d8a9b","https://git.kernel.org/stable/c/b4bd2aafacce48db26b0a213d849818d940556dd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49454
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
PCI: mediatek: Fix refcount leak in mtk_pcie_subsys_powerup()
The of_find_compatible_node() function returns a node pointer with
refcount incremented, We should use of_node_put() on it when done
Add the missing of_node_put() to release the refcount. |
["https://git.kernel.org/stable/c/09b2d906d78ddf5042b1f3e0091835fc6997e8a4","https://git.kernel.org/stable/c/214e0d8fe4a813ae6ffd62bc2dfe7544c20914f4","https://git.kernel.org/stable/c/4cef4237d6c37257cb6ddc397723e9c0dded0efe","https://git.kernel.org/stable/c/ad1c9d13e04509ae24fae8dd2897148657323519"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49466
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
regulator: scmi: Fix refcount leak in scmi_regulator_probe
of_find_node_by_name() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak. |
["https://git.kernel.org/stable/c/299a002161c7bfb72e99ba45e5b660aecc344ea0","https://git.kernel.org/stable/c/4a59c763ef9b68c711dc2fd2ef4a6648da5480ee","https://git.kernel.org/stable/c/68d6c8476fd4f448e70e0ab31ff972838ac41dae","https://git.kernel.org/stable/c/9ebbfa73d69909b7c737f599fd4ebd42318fc881"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49480
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: imx-hdmi: Fix refcount leak in imx_hdmi_probe
of_find_device_by_node() takes reference, we should use put_device()
to release it. when devm_kzalloc() fails, it doesn't have a
put_device(), it will cause refcount leak.
Add missing put_device() to fix this. |
["https://git.kernel.org/stable/c/81b7edaabd44ba133006ad72056914eb36828d60","https://git.kernel.org/stable/c/8205a0114db10ec41bd2b748cdd7528632082eca","https://git.kernel.org/stable/c/cf760e494ee5fa6bc2dc222f0098c741ad460801","https://git.kernel.org/stable/c/ed46731d8e86c8d65f5fc717671e1f1f6c3146d2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49485
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/v3d: Fix null pointer dereference of pointer perfmon
In the unlikely event that pointer perfmon is null the WARN_ON return path
occurs after the pointer has already been deferenced. Fix this by only
dereferencing perfmon after it has been null checked. |
["https://git.kernel.org/stable/c/1df8f8901babcc8c8eea2c067179e455b5c828fd","https://git.kernel.org/stable/c/3b72deb784a7d4ae8519a5c584cd87c4b57aa6c8","https://git.kernel.org/stable/c/4be045434923e549a50846a066a04b7b6c1d6d33","https://git.kernel.org/stable/c/ce7a1ecf3f9f1fccaf67295307614511d8e11b13"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49487
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mtd: rawnand: intel: fix possible null-ptr-deref in ebu_nand_probe()
It will cause null-ptr-deref when using 'res', if platform_get_resource()
returns NULL, so move using 'res' after devm_ioremap_resource() that
will check it to avoid null-ptr-deref. |
["https://git.kernel.org/stable/c/daa5166450b447415aeeaac0199e445bae7bd0f2","https://git.kernel.org/stable/c/ddf66aefd685fd46500b9917333e1b1e118276dc","https://git.kernel.org/stable/c/e5b1e419cdb6dd8709eb05ed34039a3ded8e6003","https://git.kernel.org/stable/c/f8e262eb7575a4a2412f30f7a1b293875aceba80"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49507
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
regulator: da9121: Fix uninit-value in da9121_assign_chip_model()
KASAN report slab-out-of-bounds in __regmap_init as follows:
BUG: KASAN: slab-out-of-bounds in __regmap_init drivers/base/regmap/regmap.c:841
Read of size 1 at addr ffff88803678cdf1 by task xrun/9137
CPU: 0 PID: 9137 Comm: xrun Tainted: G W 5.18.0-rc2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x15a lib/dump_stack.c:88
print_report.cold+0xcd/0x69b mm/kasan/report.c:313
kasan_report+0x8e/0xc0 mm/kasan/report.c:491
__regmap_init+0x4540/0x4ba0 drivers/base/regmap/regmap.c:841
__devm_regmap_init+0x7a/0x100 drivers/base/regmap/regmap.c:1266
__devm_regmap_init_i2c+0x65/0x80 drivers/base/regmap/regmap-i2c.c:394
da9121_i2c_probe+0x386/0x6d1 drivers/regulator/da9121-regulator.c:1039
i2c_device_probe+0x959/0xac0 drivers/i2c/i2c-core-base.c:563
This happend when da9121 device is probe by da9121_i2c_id, but with
invalid dts. Thus, chip->subvariant_id is set to -EINVAL, and later
da9121_assign_chip_model() will access 'regmap' without init it.
Fix it by return -EINVAL from da9121_assign_chip_model() if
'chip->subvariant_id' is invalid. |
["https://git.kernel.org/stable/c/60f21eda69f1b5727a97d2077da766eb27fcc21f","https://git.kernel.org/stable/c/7da64c7c82c9b29b628a62c88a8c2fb06990563d","https://git.kernel.org/stable/c/bab76514aca36bc513224525d5598da676938218","https://git.kernel.org/stable/c/be96baa0c79588084e0d7a4fa21c574cec9a57f4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49618
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: aspeed: Fix potential NULL dereference in aspeed_pinmux_set_mux()
pdesc could be null but still dereference pdesc->name and it will lead to
a null pointer access. So we move a null check before dereference. |
["https://git.kernel.org/stable/c/3cb392b64304a05bf647e2e44efacd9a1f3c3c6a","https://git.kernel.org/stable/c/84a85d3fef2e75b1fe9fc2af6f5267122555a1ed","https://git.kernel.org/stable/c/e162a24f1dd06c0dcae71f2565c9f3da2827b98e","https://git.kernel.org/stable/c/ef1e38532f4b2f0f3b460e938a2e7076c3bed5ee"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49627
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ima: Fix potential memory leak in ima_init_crypto()
On failure to allocate the SHA1 tfm, IMA fails to initialize and exits
without freeing the ima_algo_array. Add the missing kfree() for
ima_algo_array to avoid the potential memory leak. |
["https://git.kernel.org/stable/c/067d2521874135267e681c19d42761c601d503d6","https://git.kernel.org/stable/c/601ae26aa2802a4c10c94d7388a99eabdbefab2b","https://git.kernel.org/stable/c/830de9667b3ada0a75a3f098dfc7159709fe397b","https://git.kernel.org/stable/c/c1d9702ceb4a091da6bee380627596d1fba09274"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49664
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
tipc: move bc link creation back to tipc_node_create
Shuang Li reported a NULL pointer dereference crash:
[] BUG: kernel NULL pointer dereference, address: 0000000000000068
[] RIP: 0010:tipc_link_is_up+0x5/0x10 [tipc]
[] Call Trace:
[] <IRQ>
[] tipc_bcast_rcv+0xa2/0x190 [tipc]
[] tipc_node_bc_rcv+0x8b/0x200 [tipc]
[] tipc_rcv+0x3af/0x5b0 [tipc]
[] tipc_udp_recv+0xc7/0x1e0 [tipc]
It was caused by the 'l' passed into tipc_bcast_rcv() is NULL. When it
creates a node in tipc_node_check_dest(), after inserting the new node
into hashtable in tipc_node_create(), it creates the bc link. However,
there is a gap between this insert and bc link creation, a bc packet
may come in and get the node from the hashtable then try to dereference
its bc link, which is NULL.
This patch is to fix it by moving the bc link creation before inserting
into the hashtable.
Note that for a preliminary node becoming "real", the bc link creation
should also be called before it's rehashed, as we don't create it for
preliminary nodes. |
["https://git.kernel.org/stable/c/35fcb2ba35b4d9b592b558c3bcc6e0d90e213588","https://git.kernel.org/stable/c/456bc338871c4a52117dd5ef29cce3745456d248","https://git.kernel.org/stable/c/cb8092d70a6f5f01ec1490fce4d35efed3ed996c","https://git.kernel.org/stable/c/e52910e671f58c619e33dac476b11b35e2d3ab6f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49671
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cm: Fix memory leak in ib_cm_insert_listen
cm_alloc_id_priv() allocates resource for the cm_id_priv. When
cm_init_listen() fails it doesn't free it, leading to memory leak.
Add the missing error unwind. |
["https://git.kernel.org/stable/c/2990f223ffa7bb25422956b9f79f9176a5b38346","https://git.kernel.org/stable/c/2febf09a8a8ae4accf908f043f1bab1421056568","https://git.kernel.org/stable/c/889000874c1204e47c7f2a4945db262a47e7efc9","https://git.kernel.org/stable/c/b0cab8b517aeaf2592c3479294f934209c41a26f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49676
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
memory: samsung: exynos5422-dmc: Fix refcount leak in of_get_dram_timings
of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
This function doesn't call of_node_put() in some error paths.
To unify the structure, Add put_node label and goto it on errors. |
["https://git.kernel.org/stable/c/1332661e09304b7b8e84e5edc11811ba08d12abe","https://git.kernel.org/stable/c/889aad2203e09eed2071ca8985c25e9d6aea5735","https://git.kernel.org/stable/c/bb2a481778c60f912c363e271ae46b55ff8132db","https://git.kernel.org/stable/c/cde4480b5ab06195b9164184b0c02ced71e601b4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49683
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: adi-axi-adc: Fix refcount leak in adi_axi_adc_attach_client
of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak. |
["https://git.kernel.org/stable/c/501652a2ad5450b4908e1f204ce75b2414c305b7","https://git.kernel.org/stable/c/5eaa84e1605035a90a64d25b6cba79e89d188175","https://git.kernel.org/stable/c/ab7bf025cee89db73c649216ddd2bc589c3d3862","https://git.kernel.org/stable/c/ada7b0c0dedafd7d059115adf49e48acba3153a8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49728
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix signed integer overflow in __ip6_append_data
Resurrect ubsan overflow checks and ubsan report this warning,
fix it by change the variable [length] type to size_t.
UBSAN: signed-integer-overflow in net/ipv6/ip6_output.c:1489:19
2147479552 + 8567 cannot be represented in type 'int'
CPU: 0 PID: 253 Comm: err Not tainted 5.16.0+ #1
Hardware name: linux,dummy-virt (DT)
Call trace:
dump_backtrace+0x214/0x230
show_stack+0x30/0x78
dump_stack_lvl+0xf8/0x118
dump_stack+0x18/0x30
ubsan_epilogue+0x18/0x60
handle_overflow+0xd0/0xf0
__ubsan_handle_add_overflow+0x34/0x44
__ip6_append_data.isra.48+0x1598/0x1688
ip6_append_data+0x128/0x260
udpv6_sendmsg+0x680/0xdd0
inet6_sendmsg+0x54/0x90
sock_sendmsg+0x70/0x88
____sys_sendmsg+0xe8/0x368
___sys_sendmsg+0x98/0xe0
__sys_sendmmsg+0xf4/0x3b8
__arm64_sys_sendmmsg+0x34/0x48
invoke_syscall+0x64/0x160
el0_svc_common.constprop.4+0x124/0x300
do_el0_svc+0x44/0xc8
el0_svc+0x3c/0x1e8
el0t_64_sync_handler+0x88/0xb0
el0t_64_sync+0x16c/0x170
Changes since v1:
-Change the variable [length] type to unsigned, as Eric Dumazet suggested.
Changes since v2:
-Don't change exthdrlen type in ip6_make_skb, as Paolo Abeni suggested.
Changes since v3:
-Don't change ulen type in udpv6_sendmsg and l2tp_ip6_sendmsg, as
Jakub Kicinski suggested. |
["https://git.kernel.org/stable/c/70549c80fe80ac4e2a22068c76ebebced24f7e74","https://git.kernel.org/stable/c/84dc940890e91e42898e4443a093281702440abf","https://git.kernel.org/stable/c/f26422eabeb517629568edf8c2dd9c6cb9147584","https://git.kernel.org/stable/c/f93431c86b631bbca5614c66f966bf3ddb3c2803"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2016-3695
|
Medium |
|
N/A
|
The einj_error_inject function in drivers/acpi/apei/einj.c in the Linux kernel allows local users to simulate hardware errors and consequently cause a denial of service by leveraging failure to disable APEI error injection through EINJ when securelevel is set. |
["http://www.securityfocus.com/bid/102327","https://bugzilla.redhat.com/show_bug.cgi?id=1322755","https://github.com/mjg59/linux/commit/d7a6be58edc01b1c66ecd8fcc91236bfbce0a420","http://www.securityfocus.com/bid/102327","https://bugzilla.redhat.com/show_bug.cgi?id=1322755","https://github.com/mjg59/linux/commit/d7a6be58edc01b1c66ecd8fcc91236bfbce0a420"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49738
|
High |
fixed |
- 5.4.232
- 5.10.168
- 5.15.93
- 6.1.11
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on i_extra_isize in is_alive()
syzbot found a f2fs bug:
BUG: KASAN: slab-out-of-bounds in data_blkaddr fs/f2fs/f2fs.h:2891 [inline]
BUG: KASAN: slab-out-of-bounds in is_alive fs/f2fs/gc.c:1117 [inline]
BUG: KASAN: slab-out-of-bounds in gc_data_segment fs/f2fs/gc.c:1520 [inline]
BUG: KASAN: slab-out-of-bounds in do_garbage_collect+0x386a/0x3df0 fs/f2fs/gc.c:1734
Read of size 4 at addr ffff888076557568 by task kworker/u4:3/52
CPU: 1 PID: 52 Comm: kworker/u4:3 Not tainted 6.1.0-rc4-syzkaller-00362-gfef7fd48922d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Workqueue: writeback wb_workfn (flush-7:0)
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:284 [inline]
print_report+0x15e/0x45d mm/kasan/report.c:395
kasan_report+0xbb/0x1f0 mm/kasan/report.c:495
data_blkaddr fs/f2fs/f2fs.h:2891 [inline]
is_alive fs/f2fs/gc.c:1117 [inline]
gc_data_segment fs/f2fs/gc.c:1520 [inline]
do_garbage_collect+0x386a/0x3df0 fs/f2fs/gc.c:1734
f2fs_gc+0x88c/0x20a0 fs/f2fs/gc.c:1831
f2fs_balance_fs+0x544/0x6b0 fs/f2fs/segment.c:410
f2fs_write_inode+0x57e/0xe20 fs/f2fs/inode.c:753
write_inode fs/fs-writeback.c:1440 [inline]
__writeback_single_inode+0xcfc/0x1440 fs/fs-writeback.c:1652
writeback_sb_inodes+0x54d/0xf90 fs/fs-writeback.c:1870
wb_writeback+0x2c5/0xd70 fs/fs-writeback.c:2044
wb_do_writeback fs/fs-writeback.c:2187 [inline]
wb_workfn+0x2dc/0x12f0 fs/fs-writeback.c:2227
process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289
worker_thread+0x665/0x1080 kernel/workqueue.c:2436
kthread+0x2e4/0x3a0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
The root cause is that we forgot to do sanity check on .i_extra_isize
in below path, result in accessing invalid address later, fix it.
- gc_data_segment
- is_alive
- data_blkaddr
- offset_in_addr |
["https://git.kernel.org/stable/c/5b25035fb888cb2f78bf0b9c9f95b1dc54480d36","https://git.kernel.org/stable/c/914e38f02a490dafd980ff0f39cccedc074deb29","https://git.kernel.org/stable/c/97ccfffcc061e54ce87e4a51a40e2e9cb0b7076a","https://git.kernel.org/stable/c/d3b7b4afd6b2c344eabf9cc26b8bfa903c164c7c","https://git.kernel.org/stable/c/e5142a4935c1f15841d06047b8130078fc4d7b8f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1989
|
High |
fixed |
- 4.14.312
- 4.19.280
- 5.4.240
- 5.10.177
- 5.15.105
- 6.1.22
- 6.2.9
|
A use-after-free flaw was found in btsdio_remove in drivers\bluetooth\btsdio.c in the Linux Kernel. In this flaw, a call to btsdio_remove with an unfinished job, may cause a race problem leading to a UAF on hdev devices. |
["https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=f132c2d13088","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230601-0004/","https://www.debian.org/security/2023/dsa-5492","https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=f132c2d13088","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230601-0004/","https://www.debian.org/security/2023/dsa-5492"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56572
|
Medium |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.12.4
|
In the Linux kernel, the following vulnerability has been resolved:
media: platform: allegro-dvt: Fix possible memory leak in allocate_buffers_internal()
The buffer in the loop should be released under the exception path,
otherwise there may be a memory leak here.
To mitigate this, free the buffer when allegro_alloc_buffer fails. |
["https://git.kernel.org/stable/c/0f514068fbc5d4d189c817adc7c4e32cffdc2e47","https://git.kernel.org/stable/c/17e5613666209be4e5be1f1894f1a6014a8a0658","https://git.kernel.org/stable/c/64f72a738864b506ab50b4a6cb3ce3c3e04b71af","https://git.kernel.org/stable/c/6712a28a4f923ffdf51cff267ad05a634ee1babc","https://git.kernel.org/stable/c/74a65313578b35e1239966adfa7ac2bdd60caf00","https://git.kernel.org/stable/c/891b5790bee8fc6ddba17874dd87a646128d0b99","https://git.kernel.org/stable/c/cf642904be39ae0d441dbdfa8f485e0a46260be4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56643
|
Medium |
fixed |
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
dccp: Fix memory leak in dccp_feat_change_recv
If dccp_feat_push_confirm() fails after new value for SP feature was accepted
without reconciliation ('entry == NULL' branch), memory allocated for that value
with dccp_feat_clone_sp_val() is never freed.
Here is the kmemleak stack for this:
unreferenced object 0xffff88801d4ab488 (size 8):
comm "syz-executor310", pid 1127, jiffies 4295085598 (age 41.666s)
hex dump (first 8 bytes):
01 b4 4a 1d 80 88 ff ff ..J.....
backtrace:
[<00000000db7cabfe>] kmemdup+0x23/0x50 mm/util.c:128
[<0000000019b38405>] kmemdup include/linux/string.h:465 [inline]
[<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:371 [inline]
[<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:367 [inline]
[<0000000019b38405>] dccp_feat_change_recv net/dccp/feat.c:1145 [inline]
[<0000000019b38405>] dccp_feat_parse_options+0x1196/0x2180 net/dccp/feat.c:1416
[<00000000b1f6d94a>] dccp_parse_options+0xa2a/0x1260 net/dccp/options.c:125
[<0000000030d7b621>] dccp_rcv_state_process+0x197/0x13d0 net/dccp/input.c:650
[<000000001f74c72e>] dccp_v4_do_rcv+0xf9/0x1a0 net/dccp/ipv4.c:688
[<00000000a6c24128>] sk_backlog_rcv include/net/sock.h:1041 [inline]
[<00000000a6c24128>] __release_sock+0x139/0x3b0 net/core/sock.c:2570
[<00000000cf1f3a53>] release_sock+0x54/0x1b0 net/core/sock.c:3111
[<000000008422fa23>] inet_wait_for_connect net/ipv4/af_inet.c:603 [inline]
[<000000008422fa23>] __inet_stream_connect+0x5d0/0xf70 net/ipv4/af_inet.c:696
[<0000000015b6f64d>] inet_stream_connect+0x53/0xa0 net/ipv4/af_inet.c:735
[<0000000010122488>] __sys_connect_file+0x15c/0x1a0 net/socket.c:1865
[<00000000b4b70023>] __sys_connect+0x165/0x1a0 net/socket.c:1882
[<00000000f4cb3815>] __do_sys_connect net/socket.c:1892 [inline]
[<00000000f4cb3815>] __se_sys_connect net/socket.c:1889 [inline]
[<00000000f4cb3815>] __x64_sys_connect+0x6e/0xb0 net/socket.c:1889
[<00000000e7b1e839>] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
[<0000000055e91434>] entry_SYSCALL_64_after_hwframe+0x67/0xd1
Clean up the allocated memory in case of dccp_feat_push_confirm() failure
and bail out with an error reset code.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller. |
["https://git.kernel.org/stable/c/22be4727a8f898442066bcac34f8a1ad0bc72e14","https://git.kernel.org/stable/c/623be080ab3c13d71570bd32f7202a8efa8e2252","https://git.kernel.org/stable/c/6ff67909ee2ffad911e3122616df41dee23ff4f6","https://git.kernel.org/stable/c/9ee68b0f23706a77f53c832457b9384178b76421","https://git.kernel.org/stable/c/bc3d4423def1a9412a0ae454cb4477089ab79276","https://git.kernel.org/stable/c/c99507fff94b926fc92279c92d80f229c91cb85d","https://git.kernel.org/stable/c/d3ec686a369fae5034303061f003cd3f94ddfd23"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-20265
|
Medium |
|
N/A
|
A flaw was found in the way memory resources were freed in the unix_stream_recvmsg function in the Linux kernel when a signal was pending. This flaw allows an unprivileged local user to crash the system by exhausting available memory. The highest threat from this vulnerability is to system availability. |
["https://bugzilla.redhat.com/show_bug.cgi?id=1908827","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa0dc04df259ba2df3ce1920e9690c7842f8fa4b","https://www.oracle.com/security-alerts/cpuoct2021.html","https://bugzilla.redhat.com/show_bug.cgi?id=1908827","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa0dc04df259ba2df3ce1920e9690c7842f8fa4b","https://www.oracle.com/security-alerts/cpuoct2021.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-0617
|
Medium |
fixed |
|
A flaw null pointer dereference in the Linux kernel UDF file system functionality was found in the way user triggers udf_file_write_iter function for the malicious UDF image. A local user could use this flaw to crash the system. Actual from Linux kernel 4.2-rc1 till 5.17-rc2. |
["http://www.openwall.com/lists/oss-security/2022/04/13/2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7fc3b7c2981bbd1047916ade327beccb90994eee","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ea8569194b43f0f01f0a84c689388542c7254a1f","https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://lore.kernel.org/lkml/20220114172329.ygzry5rlz64ua2nr%40quack3.lan/T/","https://www.debian.org/security/2022/dsa-5095","https://www.debian.org/security/2022/dsa-5096","http://www.openwall.com/lists/oss-security/2022/04/13/2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7fc3b7c2981bbd1047916ade327beccb90994eee","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ea8569194b43f0f01f0a84c689388542c7254a1f","https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://lore.kernel.org/lkml/20220114172329.ygzry5rlz64ua2nr%40quack3.lan/T/","https://www.debian.org/security/2022/dsa-5095","https://www.debian.org/security/2022/dsa-5096"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26793
|
High |
fixed |
- 4.19.309
- 5.4.271
- 5.10.212
- 5.15.151
- 6.1.81
- 6.6.21
- 6.7.9
|
In the Linux kernel, the following vulnerability has been resolved:
gtp: fix use-after-free and null-ptr-deref in gtp_newlink()
The gtp_link_ops operations structure for the subsystem must be
registered after registering the gtp_net_ops pernet operations structure.
Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:
[ 1010.702740] gtp: GTP module unloaded
[ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI
[ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
[ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1
[ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014
[ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp]
[ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00
[ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203
[ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000
[ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282
[ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000
[ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80
[ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400
[ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000
[ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0
[ 1010.715968] PKRU: 55555554
[ 1010.715972] Call Trace:
[ 1010.715985] ? __die_body.cold+0x1a/0x1f
[ 1010.715995] ? die_addr+0x43/0x70
[ 1010.716002] ? exc_general_protection+0x199/0x2f0
[ 1010.716016] ? asm_exc_general_protection+0x1e/0x30
[ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp]
[ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp]
[ 1010.716042] __rtnl_newlink+0x1063/0x1700
[ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0
[ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0
[ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0
[ 1010.716076] ? __kernel_text_address+0x56/0xa0
[ 1010.716084] ? unwind_get_return_address+0x5a/0xa0
[ 1010.716091] ? create_prof_cpu_mask+0x30/0x30
[ 1010.716098] ? arch_stack_walk+0x9e/0xf0
[ 1010.716106] ? stack_trace_save+0x91/0xd0
[ 1010.716113] ? stack_trace_consume_entry+0x170/0x170
[ 1010.716121] ? __lock_acquire+0x15c5/0x5380
[ 1010.716139] ? mark_held_locks+0x9e/0xe0
[ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0
[ 1010.716155] ? __rtnl_newlink+0x1700/0x1700
[ 1010.716160] rtnl_newlink+0x69/0xa0
[ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50
[ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0
[ 1010.716179] ? lock_acquire+0x1fe/0x560
[ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50
[ 1010.716196] netlink_rcv_skb+0x14d/0x440
[ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0
[ 1010.716208] ? netlink_ack+0xab0/0xab0
[ 1010.716213] ? netlink_deliver_tap+0x202/0xd50
[ 1010.716220] ? netlink_deliver_tap+0x218/0xd50
[ 1010.716226] ? __virt_addr_valid+0x30b/0x590
[ 1010.716233] netlink_unicast+0x54b/0x800
[ 1010.716240] ? netlink_attachskb+0x870/0x870
[ 1010.716248] ? __check_object_size+0x2de/0x3b0
[ 1010.716254] netlink_sendmsg+0x938/0xe40
[ 1010.716261] ? netlink_unicast+0x800/0x800
[ 1010.716269] ? __import_iovec+0x292/0x510
[ 1010.716276] ? netlink_unicast+0x800/0x800
[ 1010.716284] __sock_sendmsg+0x159/0x190
[ 1010.716290] ____sys_sendmsg+0x712/0x880
[ 1010.716297] ? sock_write_iter+0x3d0/0x3d0
[ 1010.716304] ? __ia32_sys_recvmmsg+0x270/0x270
[ 1010.716309] ? lock_acquire+0x1fe/0x560
[ 1010.716315] ? drain_array_locked+0x90/0x90
[ 1010.716324] ___sys_sendmsg+0xf8/0x170
[ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170
[ 1010.716337] ? lockdep_init_map
---truncated--- |
["https://git.kernel.org/stable/c/01129059d5141d62fae692f7a336ae3bc712d3eb","https://git.kernel.org/stable/c/5366969a19a8a0d2ffb3d27ef6e8905e5e4216f8","https://git.kernel.org/stable/c/616d82c3cfa2a2146dd7e3ae47bda7e877ee549e","https://git.kernel.org/stable/c/9376d059a705c5dfaac566c2d09891242013ae16","https://git.kernel.org/stable/c/93dd420bc41531c9a31498b9538ca83ba6ec191e","https://git.kernel.org/stable/c/abd32d7f5c0294c1b2454c5a3b13b18446bac627","https://git.kernel.org/stable/c/e668b92a3a01429923fd5ca13e99642aab47de69","https://git.kernel.org/stable/c/ec92aa2cab6f0048f10d6aa4f025c5885cb1a1b6","https://git.kernel.org/stable/c/01129059d5141d62fae692f7a336ae3bc712d3eb","https://git.kernel.org/stable/c/5366969a19a8a0d2ffb3d27ef6e8905e5e4216f8","https://git.kernel.org/stable/c/616d82c3cfa2a2146dd7e3ae47bda7e877ee549e","https://git.kernel.org/stable/c/9376d059a705c5dfaac566c2d09891242013ae16","https://git.kernel.org/stable/c/93dd420bc41531c9a31498b9538ca83ba6ec191e","https://git.kernel.org/stable/c/abd32d7f5c0294c1b2454c5a3b13b18446bac627","https://git.kernel.org/stable/c/e668b92a3a01429923fd5ca13e99642aab47de69","https://git.kernel.org/stable/c/ec92aa2cab6f0048f10d6aa4f025c5885cb1a1b6","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49059
|
High |
fixed |
- 4.9.311
- 4.14.276
- 4.19.239
- 5.4.190
- 5.10.112
- 5.15.35
- 5.17.4
|
In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: add flush_workqueue to prevent uaf
Our detector found a concurrent use-after-free bug when detaching an
NCI device. The main reason for this bug is the unexpected scheduling
between the used delayed mechanism (timer and workqueue).
The race can be demonstrated below:
Thread-1 Thread-2
| nci_dev_up()
| nci_open_device()
| __nci_request(nci_reset_req)
| nci_send_cmd
| queue_work(cmd_work)
nci_unregister_device() |
nci_close_device() | ...
del_timer_sync(cmd_timer)[1] |
... | Worker
nci_free_device() | nci_cmd_work()
kfree(ndev)[3] | mod_timer(cmd_timer)[2]
In short, the cleanup routine thought that the cmd_timer has already
been detached by [1] but the mod_timer can re-attach the timer [2], even
it is already released [3], resulting in UAF.
This UAF is easy to trigger, crash trace by POC is like below
[ 66.703713] ==================================================================
[ 66.703974] BUG: KASAN: use-after-free in enqueue_timer+0x448/0x490
[ 66.703974] Write of size 8 at addr ffff888009fb7058 by task kworker/u4:1/33
[ 66.703974]
[ 66.703974] CPU: 1 PID: 33 Comm: kworker/u4:1 Not tainted 5.18.0-rc2 #5
[ 66.703974] Workqueue: nfc2_nci_cmd_wq nci_cmd_work
[ 66.703974] Call Trace:
[ 66.703974] <TASK>
[ 66.703974] dump_stack_lvl+0x57/0x7d
[ 66.703974] print_report.cold+0x5e/0x5db
[ 66.703974] ? enqueue_timer+0x448/0x490
[ 66.703974] kasan_report+0xbe/0x1c0
[ 66.703974] ? enqueue_timer+0x448/0x490
[ 66.703974] enqueue_timer+0x448/0x490
[ 66.703974] __mod_timer+0x5e6/0xb80
[ 66.703974] ? mark_held_locks+0x9e/0xe0
[ 66.703974] ? try_to_del_timer_sync+0xf0/0xf0
[ 66.703974] ? lockdep_hardirqs_on_prepare+0x17b/0x410
[ 66.703974] ? queue_work_on+0x61/0x80
[ 66.703974] ? lockdep_hardirqs_on+0xbf/0x130
[ 66.703974] process_one_work+0x8bb/0x1510
[ 66.703974] ? lockdep_hardirqs_on_prepare+0x410/0x410
[ 66.703974] ? pwq_dec_nr_in_flight+0x230/0x230
[ 66.703974] ? rwlock_bug.part.0+0x90/0x90
[ 66.703974] ? _raw_spin_lock_irq+0x41/0x50
[ 66.703974] worker_thread+0x575/0x1190
[ 66.703974] ? process_one_work+0x1510/0x1510
[ 66.703974] kthread+0x2a0/0x340
[ 66.703974] ? kthread_complete_and_exit+0x20/0x20
[ 66.703974] ret_from_fork+0x22/0x30
[ 66.703974] </TASK>
[ 66.703974]
[ 66.703974] Allocated by task 267:
[ 66.703974] kasan_save_stack+0x1e/0x40
[ 66.703974] __kasan_kmalloc+0x81/0xa0
[ 66.703974] nci_allocate_device+0xd3/0x390
[ 66.703974] nfcmrvl_nci_register_dev+0x183/0x2c0
[ 66.703974] nfcmrvl_nci_uart_open+0xf2/0x1dd
[ 66.703974] nci_uart_tty_ioctl+0x2c3/0x4a0
[ 66.703974] tty_ioctl+0x764/0x1310
[ 66.703974] __x64_sys_ioctl+0x122/0x190
[ 66.703974] do_syscall_64+0x3b/0x90
[ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 66.703974]
[ 66.703974] Freed by task 406:
[ 66.703974] kasan_save_stack+0x1e/0x40
[ 66.703974] kasan_set_track+0x21/0x30
[ 66.703974] kasan_set_free_info+0x20/0x30
[ 66.703974] __kasan_slab_free+0x108/0x170
[ 66.703974] kfree+0xb0/0x330
[ 66.703974] nfcmrvl_nci_unregister_dev+0x90/0xd0
[ 66.703974] nci_uart_tty_close+0xdf/0x180
[ 66.703974] tty_ldisc_kill+0x73/0x110
[ 66.703974] tty_ldisc_hangup+0x281/0x5b0
[ 66.703974] __tty_hangup.part.0+0x431/0x890
[ 66.703974] tty_release+0x3a8/0xc80
[ 66.703974] __fput+0x1f0/0x8c0
[ 66.703974] task_work_run+0xc9/0x170
[ 66.703974] exit_to_user_mode_prepare+0x194/0x1a0
[ 66.703974] syscall_exit_to_user_mode+0x19/0x50
[ 66.703974] do_syscall_64+0x48/0x90
[ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0x
---truncated--- |
["https://git.kernel.org/stable/c/1a1748d0dd0f0a98535c6baeef671c8722107639","https://git.kernel.org/stable/c/5c63ad2b0a267a524c12c88acb1ba9c2d109a801","https://git.kernel.org/stable/c/67677050cecbe0edfdd81cd508415e9636ba7c65","https://git.kernel.org/stable/c/7d3232214ca4ea8f7d18df264c3b254aa8089d7f","https://git.kernel.org/stable/c/9d243aff5f7e6b04e907c617426bbdf26e996ac8","https://git.kernel.org/stable/c/9ded5ae40f4fe37fcc28f36d76bf45df20be5432","https://git.kernel.org/stable/c/edd4600120641e1714e30112e69a548cfb68e067","https://git.kernel.org/stable/c/ef27324e2cb7bb24542d6cb2571740eefe6b00dc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4921
|
High |
fixed |
- 4.14.326
- 4.19.295
- 5.4.257
- 5.10.195
- 5.15.132
- 6.1.54
- 6.5.4
|
A use-after-free vulnerability in the Linux kernel's net/sched: sch_qfq component can be exploited to achieve local privilege escalation.
When the plug qdisc is used as a class of the qfq qdisc, sending network packets triggers use-after-free in qfq_dequeue() due to the incorrect .peek handler of sch_plug and lack of error checking in agg_dequeue().
We recommend upgrading past commit 8fc134fee27f2263988ae38920bc03da416b03d8. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8fc134fee27f2263988ae38920bc03da416b03d8","https://kernel.dance/8fc134fee27f2263988ae38920bc03da416b03d8","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8fc134fee27f2263988ae38920bc03da416b03d8","https://kernel.dance/8fc134fee27f2263988ae38920bc03da416b03d8","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3176
|
High |
fixed |
- 5.4.212
- 5.10.141
- 5.15.65
- 5.17
|
There exists a use-after-free in io_uring in the Linux kernel. Signalfd_poll() and binder_poll() use a waitqueue whose lifetime is the current task. It will send a POLLFREE notification to all waiters before the queue is freed. Unfortunately, the io_uring poll doesn't handle POLLFREE. This allows a use-after-free to occur if a signalfd or binder fd is polled with io_uring poll, and the waitqueue gets freed. We recommend upgrading past commit fc78b2fc21f10c4c9c4d5d659a685710ffa63659 |
["https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?h=linux-5.4.y\u0026id=fc78b2fc21f10c4c9c4d5d659a685710ffa63659","https://kernel.dance/#fc78b2fc21f10c4c9c4d5d659a685710ffa63659","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://security.netapp.com/advisory/ntap-20230216-0003/","https://www.debian.org/security/2022/dsa-5257","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?h=linux-5.4.y\u0026id=fc78b2fc21f10c4c9c4d5d659a685710ffa63659","https://kernel.dance/#fc78b2fc21f10c4c9c4d5d659a685710ffa63659","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://security.netapp.com/advisory/ntap-20230216-0003/","https://www.debian.org/security/2022/dsa-5257"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52531
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: Fix a memory corruption issue
A few lines above, space is kzalloc()'ed for:
sizeof(struct iwl_nvm_data) +
sizeof(struct ieee80211_channel) +
sizeof(struct ieee80211_rate)
'mvm->nvm_data' is a 'struct iwl_nvm_data', so it is fine.
At the end of this structure, there is the 'channels' flex array.
Each element is of type 'struct ieee80211_channel'.
So only 1 element is allocated in this array.
When doing:
mvm->nvm_data->bands[0].channels = mvm->nvm_data->channels;
We point at the first element of the 'channels' flex array.
So this is fine.
However, when doing:
mvm->nvm_data->bands[0].bitrates =
(void *)((u8 *)mvm->nvm_data->channels + 1);
because of the "(u8 *)" cast, we add only 1 to the address of the beginning
of the flex array.
It is likely that we want point at the 'struct ieee80211_rate' allocated
just after.
Remove the spurious casting so that the pointer arithmetic works as
expected. |
["https://git.kernel.org/stable/c/6b3223449c959a8be94a1f042288059e40fcccb0","https://git.kernel.org/stable/c/7c8faa31080342aec4903c9acb20caf82fcca1ef","https://git.kernel.org/stable/c/8ba438ef3cacc4808a63ed0ce24d4f0942cfe55d","https://git.kernel.org/stable/c/f06cdd8d4ba5252986f51f80cc30263636397128","https://git.kernel.org/stable/c/6b3223449c959a8be94a1f042288059e40fcccb0","https://git.kernel.org/stable/c/7c8faa31080342aec4903c9acb20caf82fcca1ef","https://git.kernel.org/stable/c/8ba438ef3cacc4808a63ed0ce24d4f0942cfe55d","https://git.kernel.org/stable/c/f06cdd8d4ba5252986f51f80cc30263636397128"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1158
|
High |
fixed |
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
A flaw was found in KVM. When updating a guest's page table entry, vm_pgoff was improperly used as the offset to get the page's pfn. As vaddr and vm_pgoff are controllable by user-mode processes, this flaw allows unprivileged local users on the host to write outside the userspace region and potentially corrupt the kernel, resulting in a denial of service condition. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2069793","https://security.netapp.com/advisory/ntap-20230214-0003/","https://www.openwall.com/lists/oss-security/2022/04/08/4","https://bugzilla.redhat.com/show_bug.cgi?id=2069793","https://security.netapp.com/advisory/ntap-20230214-0003/","https://www.openwall.com/lists/oss-security/2022/04/08/4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3609
|
High |
fixed |
|
A use-after-free vulnerability in the Linux kernel's net/sched: cls_u32 component can be exploited to achieve local privilege escalation.
If tcf_change_indev() fails, u32_set_parms() will immediately return an error after incrementing or decrementing the reference counter in tcf_bind_filter(). If an attacker can control the reference counter and set it to zero, they can cause the reference to be freed, leading to a use-after-free vulnerability.
We recommend upgrading past commit 04c55383fa5689357bcdd2c8036725a55ed632bc. |
["http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=04c55383fa5689357bcdd2c8036725a55ed632bc","https://kernel.dance/04c55383fa5689357bcdd2c8036725a55ed632bc","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230818-0005/","https://www.debian.org/security/2023/dsa-5480","http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=04c55383fa5689357bcdd2c8036725a55ed632bc","https://kernel.dance/04c55383fa5689357bcdd2c8036725a55ed632bc","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230818-0005/","https://www.debian.org/security/2023/dsa-5480"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1118
|
High |
fixed |
- 4.14.308
- 4.19.276
- 5.4.235
- 5.10.173
- 5.15.99
- 6.1.16
- 6.2.3
|
A flaw use after free in the Linux kernel integrated infrared receiver/transceiver driver was found in the way user detaching rc device. A local user could use this flaw to crash the system or potentially escalate their privileges on the system. |
["https://github.com/torvalds/linux/commit/29b0589a865b6f66d141d79b2dd1373e4e50fe17","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230413-0003/","https://github.com/torvalds/linux/commit/29b0589a865b6f66d141d79b2dd1373e4e50fe17","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230413-0003/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-51042
|
High |
fixed |
|
In the Linux kernel before 6.4.12, amdgpu_cs_wait_all_fences in drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c has a fence use-after-free. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.12","https://github.com/torvalds/linux/commit/2e54154b9f27262efd0cb4f903cc7d5ad1fe9628","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.12","https://github.com/torvalds/linux/commit/2e54154b9f27262efd0cb4f903cc7d5ad1fe9628"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-2978
|
High |
fixed |
- 4.9.331
- 4.14.296
- 4.19.262
- 5.4.218
- 5.10.148
- 5.15.73
- 5.19.15
- 6.0.1
|
A flaw use after free in the Linux kernel NILFS file system was found in the way user triggers function security_inode_alloc to fail with following call to function nilfs_mdt_destroy. A local user could use this flaw to crash the system or potentially escalate their privileges on the system. |
["https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://lore.kernel.org/linux-fsdevel/20220816040859.659129-1-dzm91%40hust.edu.cn/T/#u","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://lore.kernel.org/linux-fsdevel/20220816040859.659129-1-dzm91%40hust.edu.cn/T/#u"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-39189
|
High |
fixed |
- 5.4.244
- 5.10.180
- 5.15.60
- 5.18.17
|
An issue was discovered the x86 KVM subsystem in the Linux kernel before 5.18.17. Unprivileged guest users can compromise the guest kernel because TLB flush operations are mishandled in certain KVM_VCPU_PREEMPTED situations. |
["https://bugs.chromium.org/p/project-zero/issues/detail?id=2309","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.17","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6cd88243c7e03845a450795e134b488fc2afb736","https://github.com/torvalds/linux/commit/6cd88243c7e03845a450795e134b488fc2afb736","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20230214-0007/","https://www.debian.org/security/2023/dsa-5480","https://bugs.chromium.org/p/project-zero/issues/detail?id=2309","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.17","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6cd88243c7e03845a450795e134b488fc2afb736","https://github.com/torvalds/linux/commit/6cd88243c7e03845a450795e134b488fc2afb736","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20230214-0007/","https://www.debian.org/security/2023/dsa-5480"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3111
|
High |
fixed |
- 4.14.318
- 4.19.286
- 5.4.247
- 5.10.184
- 5.15.63
- 5.19.4
|
A use after free vulnerability was found in prepare_to_relocate in fs/btrfs/relocation.c in btrfs in the Linux Kernel. This possible flaw can be triggered by calling btrfs_ioctl_balance() before calling btrfs_ioctl_defrag(). |
["https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://patchwork.kernel.org/project/linux-btrfs/patch/20220721074829.2905233-1-r33s3n6%40gmail.com/","https://security.netapp.com/advisory/ntap-20230703-0007/","https://www.debian.org/security/2023/dsa-5480","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://patchwork.kernel.org/project/linux-btrfs/patch/20220721074829.2905233-1-r33s3n6%40gmail.com/","https://security.netapp.com/advisory/ntap-20230703-0007/","https://www.debian.org/security/2023/dsa-5480"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49755
|
High |
fixed |
- 4.14.305
- 4.19.272
- 5.4.231
- 5.10.166
- 5.15.91
- 6.1.9
|
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait
While performing fast composition switch, there is a possibility that the
process of ffs_ep0_write/ffs_ep0_read get into a race condition
due to ep0req being freed up from functionfs_unbind.
Consider the scenario that the ffs_ep0_write calls the ffs_ep0_queue_wait
by taking a lock &ffs->ev.waitq.lock. However, the functionfs_unbind isn't
bounded so it can go ahead and mark the ep0req to NULL, and since there
is no NULL check in ffs_ep0_queue_wait we will end up in use-after-free.
Fix this by making a serialized execution between the two functions using
a mutex_lock(ffs->mutex). |
["https://git.kernel.org/stable/c/6a19da111057f69214b97c62fb0ac59023970850","https://git.kernel.org/stable/c/6aee197b7fbcd61596a78b47d553f2f99111f217","https://git.kernel.org/stable/c/6dd9ea05534f323668db94fcc2726c7a84547e78","https://git.kernel.org/stable/c/a8d40942df074f4ebcb9bd3413596d92f323b064","https://git.kernel.org/stable/c/ae8e136bcaae96163b5821984de1036efc9abb1a","https://git.kernel.org/stable/c/e9036e951f93fb8d7b5e9d6e2c7f94a4da312ae4","https://git.kernel.org/stable/c/facf353c9e8d7885b686d9a4b173d4e0af6441d2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1281
|
High |
fixed |
|
Use After Free vulnerability in Linux kernel traffic control index filter (tcindex) allows Privilege Escalation. The imperfect hash area can be updated while packets are traversing, which will cause a use-after-free when 'tcf_exts_exec()' is called with the destroyed tcf_ext. A local attacker user can use this vulnerability to elevate its privileges to root.
This issue affects Linux Kernel: from 4.14 before git commit ee059170b1f7e94e55fa6cadee544e176a6e59c2. |
["http://www.openwall.com/lists/oss-security/2023/04/11/3","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ee059170b1f7e94e55fa6cadee544e176a6e59c2","https://kernel.dance/#ee059170b1f7e94e55fa6cadee544e176a6e59c2","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230427-0004/","http://www.openwall.com/lists/oss-security/2023/04/11/3","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ee059170b1f7e94e55fa6cadee544e176a6e59c2","https://kernel.dance/#ee059170b1f7e94e55fa6cadee544e176a6e59c2","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230427-0004/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52988
|
High |
fixed |
- 4.14.306
- 4.19.273
- 5.4.232
- 5.10.168
- 5.15.93
- 6.1.11
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: hda/via: Avoid potential array out-of-bound in add_secret_dac_path()
snd_hda_get_connections() can return a negative error code.
It may lead to accessing 'conn' array at a negative index.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/1b9256c96220bcdba287eeeb90e7c910c77f8c46","https://git.kernel.org/stable/c/2b557fa635e7487f638c0f030c305870839eeda2","https://git.kernel.org/stable/c/437e50ef6290ac835d526d0e45f466a0aa69ba1b","https://git.kernel.org/stable/c/6e1f586ddec48d71016b81acf68ba9f49ca54db8","https://git.kernel.org/stable/c/b9cee506da2b7920b5ea02ccd8e78a907d0ee7aa","https://git.kernel.org/stable/c/d6870f3800dbb212ae8433183ee82f566d067c6c","https://git.kernel.org/stable/c/f011360ad234a07cb6fbcc720fff646a93a9f0d6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-22040
|
High |
fixed |
- 6.1.134
- 6.6.87
- 6.12.23
- 6.13.11
- 6.14.2
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix session use-after-free in multichannel connection
There is a race condition between session setup and
ksmbd_sessions_deregister. The session can be freed before the connection
is added to channel list of session.
This patch check reference count of session before freeing it. |
["https://git.kernel.org/stable/c/3980770cb1470054e6400fd97668665975726737","https://git.kernel.org/stable/c/596407adb9af1ee75fe7c7529607783d31b66e7f","https://git.kernel.org/stable/c/7dfbd4c43eed91dd2548a95236908025707a8dfd","https://git.kernel.org/stable/c/9069939d762138e232a6f79e3e1462682ed6a17d","https://git.kernel.org/stable/c/94c281721d4ed2d972232414b91d98a6f5bdb16b","https://git.kernel.org/stable/c/fa4cdb8cbca7d6cb6aa13e4d8d83d1103f6345db"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-22041
|
High |
fixed |
- 6.1.134
- 6.6.87
- 6.12.13
- 6.13.11
- 6.14.2
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in ksmbd_sessions_deregister()
In multichannel mode, UAF issue can occur in session_deregister
when the second channel sets up a session through the connection of
the first channel. session that is freed through the global session
table can be accessed again through ->sessions of connection. |
["https://git.kernel.org/stable/c/15a9605f8d69dc85005b1a00c31a050b8625e1aa","https://git.kernel.org/stable/c/33cc29e221df7a3085ae413e8c26c4e81a151153","https://git.kernel.org/stable/c/8ed0e9d2f410f63525afb8351181eea36c80bcf1","https://git.kernel.org/stable/c/a8a8ae303a8395cbac270b5b404d85df6ec788f8","https://git.kernel.org/stable/c/ca042cc0e4f9e0d2c8f86dd67e4b22f30a516a9b","https://git.kernel.org/stable/c/f0eb3f575138b816da74697bd506682574742fcd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-22097
|
High |
fixed |
- 5.15.180
- 6.1.134
- 6.6.87
- 6.12.23
- 6.13.11
- 6.14.2
|
In the Linux kernel, the following vulnerability has been resolved:
drm/vkms: Fix use after free and double free on init error
If the driver initialization fails, the vkms_exit() function might
access an uninitialized or freed default_config pointer and it might
double free it.
Fix both possible errors by initializing default_config only when the
driver initialization succeeded. |
["https://git.kernel.org/stable/c/1f68f1cf09d06061eb549726ff8339e064eddebd","https://git.kernel.org/stable/c/49a69f67f53518bdd9b7eeebf019a2da6cc0e954","https://git.kernel.org/stable/c/561fc0c5cf41f646f3e9e61784cbc0fc832fb936","https://git.kernel.org/stable/c/79d138d137b80eeb0a83244d1cff29e64cf91067","https://git.kernel.org/stable/c/b8a18bb53e06d6d3c1fd03d12533d6e333ba8853","https://git.kernel.org/stable/c/d5eb8e347905ab17788a7903fa1d3d06747355f5","https://git.kernel.org/stable/c/ed15511a773df86205bda66c37193569575ae828"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49761
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: always report error in run_one_delayed_ref()
Currently we have a btrfs_debug() for run_one_delayed_ref() failure, but
if end users hit such problem, there will be no chance that
btrfs_debug() is enabled. This can lead to very little useful info for
debugging.
This patch will:
- Add extra info for error reporting
Including:
* logical bytenr
* num_bytes
* type
* action
* ref_mod
- Replace the btrfs_debug() with btrfs_err()
- Move the error reporting into run_one_delayed_ref()
This is to avoid use-after-free, the @node can be freed in the caller.
This error should only be triggered at most once.
As if run_one_delayed_ref() failed, we trigger the error message, then
causing the call chain to error out:
btrfs_run_delayed_refs()
`- btrfs_run_delayed_refs()
`- btrfs_run_delayed_refs_for_head()
`- run_one_delayed_ref()
And we will abort the current transaction in btrfs_run_delayed_refs().
If we have to run delayed refs for the abort transaction,
run_one_delayed_ref() will just cleanup the refs and do nothing, thus no
new error messages would be output. |
["https://git.kernel.org/stable/c/18bd1c9c02e64a3567f90c83c2c8b855531c8098","https://git.kernel.org/stable/c/39f501d68ec1ed5cd5c66ac6ec2a7131c517bb92","https://git.kernel.org/stable/c/853ffa1511b058c79a4c9bb1407b3b20ce311792","https://git.kernel.org/stable/c/fdb4a70bb768d2a87890409597529ad81cb3de8a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3566
|
High |
|
N/A
|
A vulnerability, which was classified as problematic, was found in Linux Kernel. This affects the function tcp_getsockopt/tcp_setsockopt of the component TCP Handler. The manipulation leads to race condition. It is recommended to apply a patch to fix this issue. The identifier VDB-211089 was assigned to this vulnerability. |
["https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f49cd2f4d6170d27a2c61f1fecb03d8a70c91f57","https://vuldb.com/?id.211089","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f49cd2f4d6170d27a2c61f1fecb03d8a70c91f57","https://vuldb.com/?id.211089"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50006
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix i_data_sem unlock order in ext4_ind_migrate()
Fuzzing reports a possible deadlock in jbd2_log_wait_commit.
This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require
synchronous updates because the file descriptor is opened with O_SYNC.
This can lead to the jbd2_journal_stop() function calling
jbd2_might_wait_for_commit(), potentially causing a deadlock if the
EXT4_IOC_MIGRATE call races with a write(2) system call.
This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this
case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the
jbd2_journal_stop function while i_data_sem is locked. This triggers
lockdep because the jbd2_journal_start function might also lock the same
jbd2_handle simultaneously.
Found by Linux Verification Center (linuxtesting.org) with syzkaller.
Rule: add |
["https://git.kernel.org/stable/c/3c46d6060d3e38de22196c1fe7706c5a3c696285","https://git.kernel.org/stable/c/4192adefc9c570698821c5eb9873320eac2fcbf1","https://git.kernel.org/stable/c/53b1999cfd2c7addf2e581a32865fe8835467b44","https://git.kernel.org/stable/c/6252cb6bde7fc76cb8dcb49d1def7c326b190820","https://git.kernel.org/stable/c/9fedf51ab8cf7b69bff08f37fe0989fec7f5d870","https://git.kernel.org/stable/c/cc749e61c011c255d81b192a822db650c68b313f","https://git.kernel.org/stable/c/d43776b907659affef1de888525847d64b244194","https://git.kernel.org/stable/c/d58a00e981d3118b91d503da263e640b7cde6729","https://git.kernel.org/stable/c/ef05572da0c0eb89614ed01cc17d3c882bdbd1ff"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-22027
|
Medium |
fixed |
- 6.1.134
- 6.6.87
- 6.12.23
- 6.13.11
- 6.14.2
|
In the Linux kernel, the following vulnerability has been resolved:
media: streamzap: fix race between device disconnection and urb callback
Syzkaller has reported a general protection fault at function
ir_raw_event_store_with_filter(). This crash is caused by a NULL pointer
dereference of dev->raw pointer, even though it is checked for NULL in
the same function, which means there is a race condition. It occurs due
to the incorrect order of actions in the streamzap_disconnect() function:
rc_unregister_device() is called before usb_kill_urb(). The dev->raw
pointer is freed and set to NULL in rc_unregister_device(), and only
after that usb_kill_urb() waits for in-progress requests to finish.
If rc_unregister_device() is called while streamzap_callback() handler is
not finished, this can lead to accessing freed resources. Thus
rc_unregister_device() should be called after usb_kill_urb().
Found by Linux Verification Center (linuxtesting.org) with Syzkaller. |
["https://git.kernel.org/stable/c/15483afb930fc2f883702dc96f80efbe4055235e","https://git.kernel.org/stable/c/30ef7cfee752ca318d5902cb67b60d9797ccd378","https://git.kernel.org/stable/c/4db62b60af2ccdea6ac5452fd20e29587ed85f57","https://git.kernel.org/stable/c/8760da4b9d44c36b93b6e4cf401ec7fe520015bd","https://git.kernel.org/stable/c/adf0ddb914c9e5b3e50da4c97959e82de2df75c3","https://git.kernel.org/stable/c/e11652a6514ec805440c1bb3739e6c6236fffcc7","https://git.kernel.org/stable/c/f1d518c0bad01abe83c2df880274cb6a39f4a457","https://git.kernel.org/stable/c/f656cfbc7a293a039d6a0c7100e1c846845148c1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-24959
|
Medium |
fixed |
|
An issue was discovered in the Linux kernel before 5.16.5. There is a memory leak in yam_siocdevprivate in drivers/net/hamradio/yam.c. |
["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.5","https://github.com/torvalds/linux/commit/29eb31542787e1019208a2e1047bb7c76c069536","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://www.debian.org/security/2022/dsa-5092","https://www.debian.org/security/2022/dsa-5096","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.5","https://github.com/torvalds/linux/commit/29eb31542787e1019208a2e1047bb7c76c069536","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://www.debian.org/security/2022/dsa-5092","https://www.debian.org/security/2022/dsa-5096"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1184
|
Medium |
fixed |
- 4.9.138
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
A use-after-free flaw was found in fs/ext4/namei.c:dx_insert_block() in the Linux kernel’s filesystem sub-component. This flaw allows a local attacker with a user privilege to cause a denial of service. |
["https://access.redhat.com/security/cve/CVE-2022-1184","https://bugzilla.redhat.com/show_bug.cgi?id=2070205","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://ubuntu.com/security/CVE-2022-1184","https://www.debian.org/security/2022/dsa-5257","https://access.redhat.com/security/cve/CVE-2022-1184","https://bugzilla.redhat.com/show_bug.cgi?id=2070205","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://ubuntu.com/security/CVE-2022-1184","https://www.debian.org/security/2022/dsa-5257"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46827
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix firmware crash due to invalid peer nss
Currently, if the access point receives an association
request containing an Extended HE Capabilities Information
Element with an invalid MCS-NSS, it triggers a firmware
crash.
This issue arises when EHT-PHY capabilities shows support
for a bandwidth and MCS-NSS set for that particular
bandwidth is filled by zeros and due to this, driver obtains
peer_nss as 0 and sending this value to firmware causes
crash.
Address this issue by implementing a validation step for
the peer_nss value before passing it to the firmware. If
the value is greater than zero, proceed with forwarding
it to the firmware. However, if the value is invalid,
reject the association request to prevent potential
firmware crashes.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 |
["https://git.kernel.org/stable/c/25a15f80253a7c8776e4e4880d797d20ec864154","https://git.kernel.org/stable/c/838c2cfdb6be7d7d8c06c711edf893eb34ca2e7c","https://git.kernel.org/stable/c/db163a463bb93cd3e37e1e7b10b9726fb6f95857"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-47641
|
Medium |
fixed |
- 4.9.311
- 4.14.276
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
video: fbdev: cirrusfb: check pixclock to avoid divide by zero
Do a sanity check on pixclock value to avoid divide by zero.
If the pixclock value is zero, the cirrusfb driver will round up
pixclock to get the derived frequency as close to maxclock as
possible.
Syzkaller reported a divide error in cirrusfb_check_pixclock.
divide error: 0000 [#1] SMP KASAN PTI
CPU: 0 PID: 14938 Comm: cirrusfb_test Not tainted 5.15.0-rc6 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2
RIP: 0010:cirrusfb_check_var+0x6f1/0x1260
Call Trace:
fb_set_var+0x398/0xf90
do_fb_ioctl+0x4b8/0x6f0
fb_ioctl+0xeb/0x130
__x64_sys_ioctl+0x19d/0x220
do_syscall_64+0x3a/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae |
["https://git.kernel.org/stable/c/1d3fb46439ad4e8f0c5739eb33d1875ac9e0f135","https://git.kernel.org/stable/c/40b13e3d85744210db13457785646634e2d056bd","https://git.kernel.org/stable/c/45800c42ef000f417270bcfc08630e42486fca99","https://git.kernel.org/stable/c/53a2088a396cfa1da92690a1da289634cd73bf0d","https://git.kernel.org/stable/c/5c6f402bdcf9e7239c6bc7087eda71ac99b31379","https://git.kernel.org/stable/c/6fe23ff94e7840097202e85c148688940b37c9b1","https://git.kernel.org/stable/c/8c7e2141fb89c620ab4e41512e262fbf25b8260d","https://git.kernel.org/stable/c/c656d04247a2654ede5cead2ecbf83431dad5261","https://git.kernel.org/stable/c/e498b504f8c81b07efab9febf8503448de4dc9cf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-47652
|
Medium |
fixed |
- 4.9.311
- 4.14.276
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
video: fbdev: smscufx: Fix null-ptr-deref in ufx_usb_probe()
I got a null-ptr-deref report:
BUG: kernel NULL pointer dereference, address: 0000000000000000
...
RIP: 0010:fb_destroy_modelist+0x38/0x100
...
Call Trace:
ufx_usb_probe.cold+0x2b5/0xac1 [smscufx]
usb_probe_interface+0x1aa/0x3c0 [usbcore]
really_probe+0x167/0x460
...
ret_from_fork+0x1f/0x30
If fb_alloc_cmap() fails in ufx_usb_probe(), fb_destroy_modelist() will
be called to destroy modelist in the error handling path. But modelist
has not been initialized yet, so it will result in null-ptr-deref.
Initialize modelist before calling fb_alloc_cmap() to fix this bug. |
["https://git.kernel.org/stable/c/0fd28daec73525382e5c992db8743bf76e42cd5c","https://git.kernel.org/stable/c/1791f487f877a9e83d81c8677bd3e7b259e7cb27","https://git.kernel.org/stable/c/64ec3e678d76419f207b9cdd338dda438ca10b1c","https://git.kernel.org/stable/c/9280ef235b05e8f19f8bc6d547b992f0a0ef398d","https://git.kernel.org/stable/c/c420b540db4b5d69de0a36d8b9d9a6a79a04f05a","https://git.kernel.org/stable/c/d1b6a1f0c23b7164250479bf92e2893291dca539","https://git.kernel.org/stable/c/d396c651e2b508b6179bb678cc029f3becbf5170","https://git.kernel.org/stable/c/da8b269cc0a2526ebeaccbe2484c999eb0f822cf","https://git.kernel.org/stable/c/dd3a6cc7385b89ec2303f39dfc3bafa4e24cec4b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49185
|
Medium |
fixed |
- 4.9.311
- 4.14.276
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: nomadik: Add missing of_node_put() in nmk_pinctrl_probe
This node pointer is returned by of_parse_phandle() with refcount
incremented in this function. Calling of_node_put() to avoid
the refcount leak. |
["https://git.kernel.org/stable/c/0067ba448f1c29ca06e5aee00d8506889ed1f9d0","https://git.kernel.org/stable/c/0356d4b64a03d23daf99a2a29d7d7d91d6ec2ea8","https://git.kernel.org/stable/c/59250d547542f1c7765a78dc97ddfe5e6b0d2ab0","https://git.kernel.org/stable/c/62580a40c9bef3d8a90629c64dda381344b35ffd","https://git.kernel.org/stable/c/669b05ff43bd7ed684379c6e2006a6dad5127b71","https://git.kernel.org/stable/c/9511c6018cd772668def8b034bc67269847e591a","https://git.kernel.org/stable/c/bc1e29a35147c1ba6ea2b06a16cb0028f7c852d2","https://git.kernel.org/stable/c/c09ac191b1f97cfa06f394dbfd7a5db07986cefc","https://git.kernel.org/stable/c/c52703355766c347f270df222a744e0c491a02f2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49216
|
Medium |
fixed |
- 4.9.311
- 4.14.276
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
drm/tegra: Fix reference leak in tegra_dsi_ganged_probe
The reference taken by 'of_find_device_by_node()' must be released when
not needed anymore. Add put_device() call to fix this. |
["https://git.kernel.org/stable/c/0e2f4e434e71dffd1085c3dccd676514bd71d316","https://git.kernel.org/stable/c/1e06710c43a090f14bb67714265a01cd1d7a37c5","https://git.kernel.org/stable/c/221e3638feb8bc42143833c9a704fa89b6c366bb","https://git.kernel.org/stable/c/2d6ae8b747fe55f54de4a4441d636974aa53f56a","https://git.kernel.org/stable/c/5e8fdb6392d945d33fef959eab73f8c34bc0a63b","https://git.kernel.org/stable/c/852c1f5f3119a38ee68e319bab10277fc1ab06b7","https://git.kernel.org/stable/c/a725070701883fe62266ee6d2f31d67e6cdd31df","https://git.kernel.org/stable/c/cd78b74031cbc94133965f1017deb822657fc1a6","https://git.kernel.org/stable/c/f3c99c686e098300c246e5e8a1474133e3dacb05"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49224
|
Medium |
fixed |
- 4.9.311
- 4.14.276
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
power: supply: ab8500: Fix memory leak in ab8500_fg_sysfs_init
kobject_init_and_add() takes reference even when it fails.
According to the doc of kobject_init_and_add():
If this function returns an error, kobject_put() must be called to
properly clean up the memory associated with the object.
Fix memory leak by calling kobject_put(). |
["https://git.kernel.org/stable/c/19aa3c98ed7b2616e105946cec804f897837ab84","https://git.kernel.org/stable/c/261041097ab3470f1120b7733cbf472712304d1e","https://git.kernel.org/stable/c/31cdf7897dba1f096b74f69d840f0575b8cdb9ae","https://git.kernel.org/stable/c/41ed61364285ff38bbbe9ca8a45c8372ba72921d","https://git.kernel.org/stable/c/6a4760463dbc6b603690938c468839985189ce0a","https://git.kernel.org/stable/c/879356a6a05559582b0a7895d86d2d4359745c08","https://git.kernel.org/stable/c/c32f6b6196b6efc1c68990dfeaac36fb8eb3b8e1","https://git.kernel.org/stable/c/db3a61ef8e6aef3b888baa6a85926c2230c2cc56","https://git.kernel.org/stable/c/ffb8e92b4cef92bd25563cf3d8b4489eb22bc61f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49235
|
Medium |
fixed |
- 4.9.311
- 4.14.276
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
ath9k_htc: fix uninit value bugs
Syzbot reported 2 KMSAN bugs in ath9k. All of them are caused by missing
field initialization.
In htc_connect_service() svc_meta_len and pad are not initialized. Based
on code it looks like in current skb there is no service data, so simply
initialize svc_meta_len to 0.
htc_issue_send() does not initialize htc_frame_hdr::control array. Based
on firmware code, it will initialize it by itself, so simply zero whole
array to make KMSAN happy
Fail logs:
BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430
usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430
hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline]
hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479
htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline]
htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275
...
Uninit was created at:
slab_post_alloc_hook mm/slab.h:524 [inline]
slab_alloc_node mm/slub.c:3251 [inline]
__kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974
kmalloc_reserve net/core/skbuff.c:354 [inline]
__alloc_skb+0x545/0xf90 net/core/skbuff.c:426
alloc_skb include/linux/skbuff.h:1126 [inline]
htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258
...
Bytes 4-7 of 18 are uninitialized
Memory access of size 18 starts at ffff888027377e00
BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430
usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430
hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline]
hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479
htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline]
htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275
...
Uninit was created at:
slab_post_alloc_hook mm/slab.h:524 [inline]
slab_alloc_node mm/slub.c:3251 [inline]
__kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974
kmalloc_reserve net/core/skbuff.c:354 [inline]
__alloc_skb+0x545/0xf90 net/core/skbuff.c:426
alloc_skb include/linux/skbuff.h:1126 [inline]
htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258
...
Bytes 16-17 of 18 are uninitialized
Memory access of size 18 starts at ffff888027377e00 |
["https://git.kernel.org/stable/c/0b700f7d06492de34964b6f414120043364f8191","https://git.kernel.org/stable/c/11f11ac281f0c0b363d2940204f28bae0422ed71","https://git.kernel.org/stable/c/4d244b731188e0b63fc40a9d2dec72e9181fb37c","https://git.kernel.org/stable/c/5abf2b761b998063f5e2bae93fd4ab10e2a80f10","https://git.kernel.org/stable/c/5c2a6a8daa17a3f65b38b9a5574bb362c13fa1d9","https://git.kernel.org/stable/c/7da6169b6ebb75816b57be3beb829afa74f3b4b6","https://git.kernel.org/stable/c/d1e0df1c57bd30871dd1c855742a7c346dbca853","https://git.kernel.org/stable/c/e352acdd378e9263cc4c6018e588f2dac7161d07","https://git.kernel.org/stable/c/ee4222052a76559c20e821bc3519cefb58b6d3e9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49242
|
Medium |
fixed |
- 4.9.311
- 4.14.276
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: mxs: Fix error handling in mxs_sgtl5000_probe
This function only calls of_node_put() in the regular path.
And it will cause refcount leak in error paths.
For example, when codec_np is NULL, saif_np[0] and saif_np[1]
are not NULL, it will cause leaks.
of_node_put() will check if the node pointer is NULL, so we can
call it directly to release the refcount of regular pointers. |
["https://git.kernel.org/stable/c/44acdaf7acb60054d872bed18ce0e7db8ce900ce","https://git.kernel.org/stable/c/67e12f1cb2f97468c12b59e21975eaa0f332e7d2","https://git.kernel.org/stable/c/6ae0a4d8fec551ec581d620f0eb1fe31f755551c","https://git.kernel.org/stable/c/790d2628e3fcc819d8f5572eb5615113fb2e727a","https://git.kernel.org/stable/c/86b6cf989437e694fd0a15782b5a513853a739e0","https://git.kernel.org/stable/c/8d880226c86f37624e2a5f3c6d92ac0ec3375f96","https://git.kernel.org/stable/c/d2923b48d99fe663cb93d8b481c93299fcd68656","https://git.kernel.org/stable/c/f16ad2c0e22687f80e5981c67374023f51c204b9","https://git.kernel.org/stable/c/f8d38056bcd220ea6f0802a5586d1a12ebcce849"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49276
|
Medium |
fixed |
- 4.9.311
- 4.14.276
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
jffs2: fix memory leak in jffs2_scan_medium
If an error is returned in jffs2_scan_eraseblock() and some memory
has been added to the jffs2_summary *s, we can observe the following
kmemleak report:
--------------------------------------------
unreferenced object 0xffff88812b889c40 (size 64):
comm "mount", pid 692, jiffies 4294838325 (age 34.288s)
hex dump (first 32 bytes):
40 48 b5 14 81 88 ff ff 01 e0 31 00 00 00 50 00 @H........1...P.
00 00 01 00 00 00 01 00 00 00 02 00 00 00 09 08 ................
backtrace:
[<ffffffffae93a3a3>] __kmalloc+0x613/0x910
[<ffffffffaf423b9c>] jffs2_sum_add_dirent_mem+0x5c/0xa0
[<ffffffffb0f3afa8>] jffs2_scan_medium.cold+0x36e5/0x4794
[<ffffffffb0f3dbe1>] jffs2_do_mount_fs.cold+0xa7/0x2267
[<ffffffffaf40acf3>] jffs2_do_fill_super+0x383/0xc30
[<ffffffffaf40c00a>] jffs2_fill_super+0x2ea/0x4c0
[<ffffffffb0315d64>] mtd_get_sb+0x254/0x400
[<ffffffffb0315f5f>] mtd_get_sb_by_nr+0x4f/0xd0
[<ffffffffb0316478>] get_tree_mtd+0x498/0x840
[<ffffffffaf40bd15>] jffs2_get_tree+0x25/0x30
[<ffffffffae9f358d>] vfs_get_tree+0x8d/0x2e0
[<ffffffffaea7a98f>] path_mount+0x50f/0x1e50
[<ffffffffaea7c3d7>] do_mount+0x107/0x130
[<ffffffffaea7c5c5>] __se_sys_mount+0x1c5/0x2f0
[<ffffffffaea7c917>] __x64_sys_mount+0xc7/0x160
[<ffffffffb10142f5>] do_syscall_64+0x45/0x70
unreferenced object 0xffff888114b54840 (size 32):
comm "mount", pid 692, jiffies 4294838325 (age 34.288s)
hex dump (first 32 bytes):
c0 75 b5 14 81 88 ff ff 02 e0 02 00 00 00 02 00 .u..............
00 00 84 00 00 00 44 00 00 00 6b 6b 6b 6b 6b a5 ......D...kkkkk.
backtrace:
[<ffffffffae93be24>] kmem_cache_alloc_trace+0x584/0x880
[<ffffffffaf423b04>] jffs2_sum_add_inode_mem+0x54/0x90
[<ffffffffb0f3bd44>] jffs2_scan_medium.cold+0x4481/0x4794
[...]
unreferenced object 0xffff888114b57280 (size 32):
comm "mount", pid 692, jiffies 4294838393 (age 34.357s)
hex dump (first 32 bytes):
10 d5 6c 11 81 88 ff ff 08 e0 05 00 00 00 01 00 ..l.............
00 00 38 02 00 00 28 00 00 00 6b 6b 6b 6b 6b a5 ..8...(...kkkkk.
backtrace:
[<ffffffffae93be24>] kmem_cache_alloc_trace+0x584/0x880
[<ffffffffaf423c34>] jffs2_sum_add_xattr_mem+0x54/0x90
[<ffffffffb0f3a24f>] jffs2_scan_medium.cold+0x298c/0x4794
[...]
unreferenced object 0xffff8881116cd510 (size 16):
comm "mount", pid 692, jiffies 4294838395 (age 34.355s)
hex dump (first 16 bytes):
00 00 00 00 00 00 00 00 09 e0 60 02 00 00 6b a5 ..........`...k.
backtrace:
[<ffffffffae93be24>] kmem_cache_alloc_trace+0x584/0x880
[<ffffffffaf423cc4>] jffs2_sum_add_xref_mem+0x54/0x90
[<ffffffffb0f3b2e3>] jffs2_scan_medium.cold+0x3a20/0x4794
[...]
--------------------------------------------
Therefore, we should call jffs2_sum_reset_collected(s) on exit to
release the memory added in s. In addition, a new tag "out_buf" is
added to prevent the NULL pointer reference caused by s being NULL.
(thanks to Zhang Yi for this analysis) |
["https://git.kernel.org/stable/c/455f4a23490bfcbedc8e5c245c463a59b19e5ddd","https://git.kernel.org/stable/c/51dbb5e36d59f62e34d462b801c1068248149cfe","https://git.kernel.org/stable/c/52ba0ab4f0a606f02a6163493378989faa1ec10a","https://git.kernel.org/stable/c/82462324bf35b6b553400af1c1aa265069cee28f","https://git.kernel.org/stable/c/9b0c69182f09b70779817af4dcf89780955d5c4c","https://git.kernel.org/stable/c/9cdd3128874f5fe759e2c4e1360ab7fb96a8d1df","https://git.kernel.org/stable/c/b26bbc0c122cad038831f226a4cb4de702225e16","https://git.kernel.org/stable/c/b36bccb04e14cc0c1e2d0e92d477fe220314fad6","https://git.kernel.org/stable/c/e711913463af916d777a4873068f415f1fe2ad33"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49277
|
Medium |
fixed |
- 4.9.311
- 4.14.276
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
jffs2: fix memory leak in jffs2_do_mount_fs
If jffs2_build_filesystem() in jffs2_do_mount_fs() returns an error,
we can observe the following kmemleak report:
--------------------------------------------
unreferenced object 0xffff88811b25a640 (size 64):
comm "mount", pid 691, jiffies 4294957728 (age 71.952s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffffa493be24>] kmem_cache_alloc_trace+0x584/0x880
[<ffffffffa5423a06>] jffs2_sum_init+0x86/0x130
[<ffffffffa5400e58>] jffs2_do_mount_fs+0x798/0xac0
[<ffffffffa540acf3>] jffs2_do_fill_super+0x383/0xc30
[<ffffffffa540c00a>] jffs2_fill_super+0x2ea/0x4c0
[...]
unreferenced object 0xffff88812c760000 (size 65536):
comm "mount", pid 691, jiffies 4294957728 (age 71.952s)
hex dump (first 32 bytes):
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................
backtrace:
[<ffffffffa493a449>] __kmalloc+0x6b9/0x910
[<ffffffffa5423a57>] jffs2_sum_init+0xd7/0x130
[<ffffffffa5400e58>] jffs2_do_mount_fs+0x798/0xac0
[<ffffffffa540acf3>] jffs2_do_fill_super+0x383/0xc30
[<ffffffffa540c00a>] jffs2_fill_super+0x2ea/0x4c0
[...]
--------------------------------------------
This is because the resources allocated in jffs2_sum_init() are not
released. Call jffs2_sum_exit() to release these resources to solve
the problem. |
["https://git.kernel.org/stable/c/0978e9af4559a171ac7a74a1b3ef21804b0a0fa9","https://git.kernel.org/stable/c/2a9d8184458562e6bf2f40d0e677fc85e2dd3834","https://git.kernel.org/stable/c/4392e8aeebc5a4f8073620bccba7de1b1f6d7c88","https://git.kernel.org/stable/c/5f34310d1376ca5b2ed798258def2c2ab3cc6699","https://git.kernel.org/stable/c/607d3aab7349f18e0d9dba4100d09d16fe27caca","https://git.kernel.org/stable/c/9a0f6610c7daedd2eace430beeb08a8b7ac80699","https://git.kernel.org/stable/c/c94128470e6fe53d9bd9d16d2d3271813f9d37af","https://git.kernel.org/stable/c/d051cef784de4d54835f6b6836d98a8f6935772c","https://git.kernel.org/stable/c/dbe0d0521eaa6a3d235517319266c539bb5c5112"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49280
|
Medium |
fixed |
- 4.9.311
- 4.14.276
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
NFSD: prevent underflow in nfssvc_decode_writeargs()
Smatch complains:
fs/nfsd/nfsxdr.c:341 nfssvc_decode_writeargs()
warn: no lower bound on 'args->len'
Change the type to unsigned to prevent this issue. |
["https://git.kernel.org/stable/c/184416d4b98509fb4c3d8fc3d6dc1437896cc159","https://git.kernel.org/stable/c/1a33e0de60feda402d05ac8a6cf409c19ea3e0b3","https://git.kernel.org/stable/c/2764af8ce0bf03cc43ee4a11897cab96bde6caae","https://git.kernel.org/stable/c/413d8fefafe531a9442bb623e3fe292a38f88d65","https://git.kernel.org/stable/c/438068f4912183a59fcb6b7496a06437f7fd4e2b","https://git.kernel.org/stable/c/614a61e1592051cc42d3c38f899c9f7bdaad8a1d","https://git.kernel.org/stable/c/65e21cc042f4c1518c8c55283f53bc725b78419d","https://git.kernel.org/stable/c/85259340fc9bd54e3d567b41b881ecb4d0055da1","https://git.kernel.org/stable/c/9f0f048c1bfa7867d565a95fd8c28f4484ba1043"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49298
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8712: fix uninit-value in r871xu_drv_init()
When 'tmpU1b' returns from r8712_read8(padapter, EE_9346CR) is 0,
'mac[6]' will not be initialized.
BUG: KMSAN: uninit-value in r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541
r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541
usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396
really_probe+0x653/0x14b0 drivers/base/dd.c:596
__driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752
driver_probe_device drivers/base/dd.c:782 [inline]
__device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899
bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427
__device_attach+0x593/0x8e0 drivers/base/dd.c:970
device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017
bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487
device_add+0x1fff/0x26e0 drivers/base/core.c:3405
usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170
usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238
usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293
really_probe+0x653/0x14b0 drivers/base/dd.c:596
__driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752
driver_probe_device drivers/base/dd.c:782 [inline]
__device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899
bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427
__device_attach+0x593/0x8e0 drivers/base/dd.c:970
device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017
bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487
device_add+0x1fff/0x26e0 drivers/base/core.c:3405
usb_new_device+0x1b8e/0x2950 drivers/usb/core/hub.c:2566
hub_port_connect drivers/usb/core/hub.c:5358 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5502 [inline]
port_event drivers/usb/core/hub.c:5660 [inline]
hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5742
process_one_work+0xdb6/0x1820 kernel/workqueue.c:2307
worker_thread+0x10b3/0x21e0 kernel/workqueue.c:2454
kthread+0x3c7/0x500 kernel/kthread.c:377
ret_from_fork+0x1f/0x30
Local variable mac created at:
r871xu_drv_init+0x1771/0x3070 drivers/staging/rtl8712/usb_intf.c:394
usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396
KMSAN: uninit-value in r871xu_drv_init
https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8 |
["https://git.kernel.org/stable/c/0458e5428e5e959d201a40ffe71d762a79ecedc4","https://git.kernel.org/stable/c/0b7371a22489cbb2e8e826ca03fb5ce92afb04fe","https://git.kernel.org/stable/c/277faa442fe0c59f418ac53f47a78e1266addd65","https://git.kernel.org/stable/c/52a0d88c328098b4e9fb8f2f3877fec0eff4104b","https://git.kernel.org/stable/c/70df04433fd351ba72bc635bd0b5fe443d9ac964","https://git.kernel.org/stable/c/76a964ad0ea8f2b10abd69a7532e174a28258283","https://git.kernel.org/stable/c/a6535d00a9d54ce1c2a8d86a85001ffb6844f9b2","https://git.kernel.org/stable/c/f36e754a1f0bafb9feeea63463de78080acb6de0","https://git.kernel.org/stable/c/ff727ab0b7d7a56b5ef281f12abd00c4b85894e9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49299
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc2: gadget: don't reset gadget's driver->bus
UDC driver should not touch gadget's driver internals, especially it
should not reset driver->bus. This wasn't harmful so far, but since
commit fc274c1e9973 ("USB: gadget: Add a new bus for gadgets") gadget
subsystem got it's own bus and messing with ->bus triggers the
following NULL pointer dereference:
dwc2 12480000.hsotg: bound driver g_ether
8<--- cut here ---
Unable to handle kernel NULL pointer dereference at virtual address 00000000
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in: ...
CPU: 0 PID: 620 Comm: modprobe Not tainted 5.18.0-rc5-next-20220504 #11862
Hardware name: Samsung Exynos (Flattened Device Tree)
PC is at module_add_driver+0x44/0xe8
LR is at sysfs_do_create_link_sd+0x84/0xe0
...
Process modprobe (pid: 620, stack limit = 0x(ptrval))
...
module_add_driver from bus_add_driver+0xf4/0x1e4
bus_add_driver from driver_register+0x78/0x10c
driver_register from usb_gadget_register_driver_owner+0x40/0xb4
usb_gadget_register_driver_owner from do_one_initcall+0x44/0x1e0
do_one_initcall from do_init_module+0x44/0x1c8
do_init_module from load_module+0x19b8/0x1b9c
load_module from sys_finit_module+0xdc/0xfc
sys_finit_module from ret_fast_syscall+0x0/0x54
Exception stack(0xf1771fa8 to 0xf1771ff0)
...
dwc2 12480000.hsotg: new device is high-speed
---[ end trace 0000000000000000 ]---
Fix this by removing driver->bus entry reset. |
["https://git.kernel.org/stable/c/172cfc167c8ee6238f24f9c16efd598602af643c","https://git.kernel.org/stable/c/3120aac6d0ecd9accf56894aeac0e265f74d3d5a","https://git.kernel.org/stable/c/5127c0f365265bb69cd776ad6e4b872c309f3fa8","https://git.kernel.org/stable/c/547ebdc200b862dff761ff4890f66d8217c33316","https://git.kernel.org/stable/c/5b0c0298f7c3b57417f1729ec4071f76864b72dd","https://git.kernel.org/stable/c/bee8f9808a7e82addfc73a0973b16a8bb684205b","https://git.kernel.org/stable/c/d2159feb9d28ce496d77df98313ab454646372ac","https://git.kernel.org/stable/c/d232ca0bbc7d03144bad0ffd1792c3352bfd03fa","https://git.kernel.org/stable/c/efb15ff4a77fe053c941281775fefa91c87770e0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49302
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
USB: host: isp116x: check return value after calling platform_get_resource()
It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value. |
["https://git.kernel.org/stable/c/134a3408c2d3f7e23eb0e4556e0a2d9f36c2614e","https://git.kernel.org/stable/c/3592cfd8b848bf0c4d7740d78a87a7b8f6e1fa9a","https://git.kernel.org/stable/c/3825db88d8c704e7992b685618a03f82bffcf2ef","https://git.kernel.org/stable/c/7bffda1560a6f255fdf504e059fbbdb5d46b9e44","https://git.kernel.org/stable/c/804de302ada3544699c5f48c5314b249af76faa3","https://git.kernel.org/stable/c/82a101f14943f479fd190b1e5b40d91c77e2ac1b","https://git.kernel.org/stable/c/aca0cab0e9ed33b6371aafb519a6c38f2850ffc3","https://git.kernel.org/stable/c/c91a74b1f0f2d2d7e728742ae55e3ffe9ba7853d","https://git.kernel.org/stable/c/ee105039d3653444de4d3ede642383c92855dc1e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49307
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
tty: synclink_gt: Fix null-pointer-dereference in slgt_clean()
When the driver fails at alloc_hdlcdev(), and then we remove the driver
module, we will get the following splat:
[ 25.065966] general protection fault, probably for non-canonical address 0xdffffc0000000182: 0000 [#1] PREEMPT SMP KASAN PTI
[ 25.066914] KASAN: null-ptr-deref in range [0x0000000000000c10-0x0000000000000c17]
[ 25.069262] RIP: 0010:detach_hdlc_protocol+0x2a/0x3e0
[ 25.077709] Call Trace:
[ 25.077924] <TASK>
[ 25.078108] unregister_hdlc_device+0x16/0x30
[ 25.078481] slgt_cleanup+0x157/0x9f0 [synclink_gt]
Fix this by checking whether the 'info->netdev' is a null pointer first. |
["https://git.kernel.org/stable/c/078212ad15dbd88840c82c97f12c93d83703c8fd","https://git.kernel.org/stable/c/1ceb4ca9543a8a788febf6bc8dad2e605e172d5e","https://git.kernel.org/stable/c/50c341f9a2adc4c32a8ad5a39eb99d9c4a419e0d","https://git.kernel.org/stable/c/689ca31c542687709ba21ec2195c1fbce34fd029","https://git.kernel.org/stable/c/8a95696bdc0e13f8980f05b54a3b9081963d1256","https://git.kernel.org/stable/c/ba08cbc5b53e151d0acf1930fb526fc65b7f3e65","https://git.kernel.org/stable/c/d68d5e68b7f64de7170f8e04dd9b995c36b2c71c","https://git.kernel.org/stable/c/ddd67751ab86c6a65f95c35293c42f85a42ac05d","https://git.kernel.org/stable/c/f6e07eb7ebec53ffe81fc2489589320fbe4a6b75"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49314
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
tty: Fix a possible resource leak in icom_probe
When pci_read_config_dword failed, call pci_release_regions() and
pci_disable_device() to recycle the resource previously allocated. |
["https://git.kernel.org/stable/c/23e155b51d403c0ccedc60c0d6c3c452afed07fe","https://git.kernel.org/stable/c/5f9b2e4ca88cab1a96b86ecd45544e488ca43faf","https://git.kernel.org/stable/c/8c014373f178a4f13a08e045ef63bdb23f62e892","https://git.kernel.org/stable/c/9a8305f357a8d03698fc7bc855ff9c6865d5486b","https://git.kernel.org/stable/c/a2df0b4d080cc770b4da7bff487048c803dfd07e","https://git.kernel.org/stable/c/cb7147afd328c07edeeee287710d8d96ac0459f5","https://git.kernel.org/stable/c/d703d912a985c1c5b50dd38c3181fc3540fa77cb","https://git.kernel.org/stable/c/ee157a79e7c82b01ae4c25de0ac75899801f322c","https://git.kernel.org/stable/c/f4c836d90da1ece88905d62ce2ce39a962f25d1a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49331
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling
Error paths do not free previously allocated memory. Add devm_kfree() to
those failure paths. |
["https://git.kernel.org/stable/c/3eca2c42daa4659965db6817479027cbc6df7899","https://git.kernel.org/stable/c/54423649bc0ed464b75807a7cf2857a5871f738f","https://git.kernel.org/stable/c/55904086041ba4ee4070187b36590f8f8d6df4cd","https://git.kernel.org/stable/c/593773088d615a46a42c97e01a0550d192bb7f74","https://git.kernel.org/stable/c/6fce324b530dd74750ad870699e33eeed1029ded","https://git.kernel.org/stable/c/996419e0594abb311fb958553809f24f38e7abbe","https://git.kernel.org/stable/c/d221ce54ce331c1a23be71eebf57f6a088632383","https://git.kernel.org/stable/c/db836b97464d44340b568e041fd24602858713f7","https://git.kernel.org/stable/c/f444ecd3f57f4ba5090fe8b6756933e37de4226e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49335
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/cs: make commands with 0 chunks illegal behaviour.
Submitting a cs with 0 chunks, causes an oops later, found trying
to execute the wrong userspace driver.
MESA_LOADER_DRIVER_OVERRIDE=v3d glxinfo
[172536.665184] BUG: kernel NULL pointer dereference, address: 00000000000001d8
[172536.665188] #PF: supervisor read access in kernel mode
[172536.665189] #PF: error_code(0x0000) - not-present page
[172536.665191] PGD 6712a0067 P4D 6712a0067 PUD 5af9ff067 PMD 0
[172536.665195] Oops: 0000 [#1] SMP NOPTI
[172536.665197] CPU: 7 PID: 2769838 Comm: glxinfo Tainted: P O 5.10.81 #1-NixOS
[172536.665199] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CROSSHAIR V FORMULA-Z, BIOS 2201 03/23/2015
[172536.665272] RIP: 0010:amdgpu_cs_ioctl+0x96/0x1ce0 [amdgpu]
[172536.665274] Code: 75 18 00 00 4c 8b b2 88 00 00 00 8b 46 08 48 89 54 24 68 49 89 f7 4c 89 5c 24 60 31 d2 4c 89 74 24 30 85 c0 0f 85 c0 01 00 00 <48> 83 ba d8 01 00 00 00 48 8b b4 24 90 00 00 00 74 16 48 8b 46 10
[172536.665276] RSP: 0018:ffffb47c0e81bbe0 EFLAGS: 00010246
[172536.665277] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[172536.665278] RDX: 0000000000000000 RSI: ffffb47c0e81be28 RDI: ffffb47c0e81bd68
[172536.665279] RBP: ffff936524080010 R08: 0000000000000000 R09: ffffb47c0e81be38
[172536.665281] R10: ffff936524080010 R11: ffff936524080000 R12: ffffb47c0e81bc40
[172536.665282] R13: ffffb47c0e81be28 R14: ffff9367bc410000 R15: ffffb47c0e81be28
[172536.665283] FS: 00007fe35e05d740(0000) GS:ffff936c1edc0000(0000) knlGS:0000000000000000
[172536.665284] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[172536.665286] CR2: 00000000000001d8 CR3: 0000000532e46000 CR4: 00000000000406e0
[172536.665287] Call Trace:
[172536.665322] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu]
[172536.665332] drm_ioctl_kernel+0xaa/0xf0 [drm]
[172536.665338] drm_ioctl+0x201/0x3b0 [drm]
[172536.665369] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu]
[172536.665372] ? selinux_file_ioctl+0x135/0x230
[172536.665399] amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[172536.665403] __x64_sys_ioctl+0x83/0xb0
[172536.665406] do_syscall_64+0x33/0x40
[172536.665409] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2018 |
["https://git.kernel.org/stable/c/15c3bcc9b5349d40207e5f8d4d799b8b4b7d13b8","https://git.kernel.org/stable/c/20b947e5a3c74c5084d661c097517a554989d462","https://git.kernel.org/stable/c/31ab27b14daaa75541a415c6794d6f3567fea44a","https://git.kernel.org/stable/c/70276460e914d560e96bfc208695a872fe9469c9","https://git.kernel.org/stable/c/7086a23890d255bb5761604e39174b20d06231a4","https://git.kernel.org/stable/c/8189f44270db1be78169e11eec51a3eeb980bc63","https://git.kernel.org/stable/c/aa25acbe96692e4bf8482311c293f72d8c6034c0","https://git.kernel.org/stable/c/be585921f29df5422a39c952d188b418ad48ffab","https://git.kernel.org/stable/c/c12984cdb077b9042d2dc20ca18cb16a87bcc774"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49351
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
net: altera: Fix refcount leak in altera_tse_mdio_create
Every iteration of for_each_child_of_node() decrements
the reference count of the previous node.
When break from a for_each_child_of_node() loop,
we need to explicitly call of_node_put() on the child node when
not need anymore.
Add missing of_node_put() to avoid refcount leak. |
["https://git.kernel.org/stable/c/11ec18b1d8d92b9df307d31950dcba0b3dd7283c","https://git.kernel.org/stable/c/1fd12298a0e0ca23478c715e672ee64c85670584","https://git.kernel.org/stable/c/4f850fe0a32c3f1e19b76996a3b1ca32637a14de","https://git.kernel.org/stable/c/5cd0e22fa11f4a21a8c09cc258f20b1474c95801","https://git.kernel.org/stable/c/803b217f1fb49a2dbb2123acdb45111b9c48b8be","https://git.kernel.org/stable/c/8174acbef87b8dd8bf3731eba2a5af1ac857e239","https://git.kernel.org/stable/c/96bf5ed057df2d157274d4e2079002f9a9404bb8","https://git.kernel.org/stable/c/a013fa884d8738ad8455aa1a843b8c9d80c6c833","https://git.kernel.org/stable/c/e31d9ba169860687dba19bdc8fccbfd34077f655"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49354
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
ata: pata_octeon_cf: Fix refcount leak in octeon_cf_probe
of_find_device_by_node() takes reference, we should use put_device()
to release it when not need anymore.
Add missing put_device() to avoid refcount leak. |
["https://git.kernel.org/stable/c/10d6bdf532902be1d8aa5900b3c03c5671612aa2","https://git.kernel.org/stable/c/19cb3ece14547cb1ca2021798aaf49a3f82643d1","https://git.kernel.org/stable/c/7bd85c5ba1687daf54e3b6907673c3604b1e75cf","https://git.kernel.org/stable/c/888312dc297a8a103f6371ef668c7e04f57a7679","https://git.kernel.org/stable/c/8d8ad067b90f231b8fdb14acee673ca4012f6045","https://git.kernel.org/stable/c/a4d3e5f1d7d4f8b5e3834fec0f057a762c55806b","https://git.kernel.org/stable/c/c9782e1b21bee4b783a64b2a91e7e71406c21a21","https://git.kernel.org/stable/c/d5a1e7f33c88780b279835d63665d7e38ccb671f","https://git.kernel.org/stable/c/fb2cb409b504bb3a69e65a17f3120328c8e50219"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49370
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle
kobject_init_and_add() takes reference even when it fails.
According to the doc of kobject_init_and_add()
If this function returns an error, kobject_put() must be called to
properly clean up the memory associated with the object.
Fix this issue by calling kobject_put(). |
["https://git.kernel.org/stable/c/3ba359ebe914ac3f8c6c832b28007c14c39d3766","https://git.kernel.org/stable/c/660ba678f9998aca6db74f2dd912fa5124f0fa31","https://git.kernel.org/stable/c/985706bd3bbeffc8737bc05965ca8d24837bc7db","https://git.kernel.org/stable/c/a724634b2a49f6ff0177a9e19a5a92fc1545e1b7","https://git.kernel.org/stable/c/a9bfb37d6ba7c376b0d53337a4c5f5ff324bd725","https://git.kernel.org/stable/c/c66cc3c62870a27ea8f060a7e4c1ad8d26dd3f0d","https://git.kernel.org/stable/c/ec752973aa721ee281d5441e497364637c626c7b","https://git.kernel.org/stable/c/ed38d04342dfbe9e5aca745c8b5eb4188a74f0ef","https://git.kernel.org/stable/c/fdffa4ad8f6bf1ece877edfb807f2b2c729d8578"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49375
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
rtc: mt6397: check return value after calling platform_get_resource()
It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value. |
["https://git.kernel.org/stable/c/3867f0bbb94773d41e789257abec0d14f37da217","https://git.kernel.org/stable/c/58a729c55ce3a432eb827fdaa24c7909cd3b0a6b","https://git.kernel.org/stable/c/6ecd4d5c28408df36a1a6f0b1973f633c949ac1f","https://git.kernel.org/stable/c/79fa3f5758d8712df0678df98161f948fc4370e5","https://git.kernel.org/stable/c/82bfea344e8f7e9a0e0b1bf9af27552baa756620","https://git.kernel.org/stable/c/865051de2d9eaa50630e055b73921ceaf3c4a7fc","https://git.kernel.org/stable/c/d3b43eb505bffb8e4cdf6800c15660c001553fe6","https://git.kernel.org/stable/c/d77f28c1bc9d3043a52069fe42e4a26fbf961ebd","https://git.kernel.org/stable/c/da38e86d6cf6dd3bc65c602d998f357145aa1a0b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49381
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
jffs2: fix memory leak in jffs2_do_fill_super
If jffs2_iget() or d_make_root() in jffs2_do_fill_super() returns
an error, we can observe the following kmemleak report:
--------------------------------------------
unreferenced object 0xffff888105a65340 (size 64):
comm "mount", pid 710, jiffies 4302851558 (age 58.239s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff859c45e5>] kmem_cache_alloc_trace+0x475/0x8a0
[<ffffffff86160146>] jffs2_sum_init+0x96/0x1a0
[<ffffffff86140e25>] jffs2_do_mount_fs+0x745/0x2120
[<ffffffff86149fec>] jffs2_do_fill_super+0x35c/0x810
[<ffffffff8614aae9>] jffs2_fill_super+0x2b9/0x3b0
[...]
unreferenced object 0xffff8881bd7f0000 (size 65536):
comm "mount", pid 710, jiffies 4302851558 (age 58.239s)
hex dump (first 32 bytes):
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................
backtrace:
[<ffffffff858579ba>] kmalloc_order+0xda/0x110
[<ffffffff85857a11>] kmalloc_order_trace+0x21/0x130
[<ffffffff859c2ed1>] __kmalloc+0x711/0x8a0
[<ffffffff86160189>] jffs2_sum_init+0xd9/0x1a0
[<ffffffff86140e25>] jffs2_do_mount_fs+0x745/0x2120
[<ffffffff86149fec>] jffs2_do_fill_super+0x35c/0x810
[<ffffffff8614aae9>] jffs2_fill_super+0x2b9/0x3b0
[...]
--------------------------------------------
This is because the resources allocated in jffs2_sum_init() are not
released. Call jffs2_sum_exit() to release these resources to solve
the problem. |
["https://git.kernel.org/stable/c/28048a4cf3813b7cf5cc8cce629dfdc7951cb1c2","https://git.kernel.org/stable/c/3252d327f977b14663a10967f3b0930d6c325687","https://git.kernel.org/stable/c/4ba7bbeab8009faf3a726e565d98816593ddd5b0","https://git.kernel.org/stable/c/4da8763a3d2b684c773b72ed80fad40bc264bc40","https://git.kernel.org/stable/c/69295267c481545f636b69ff341b8db75aa136b9","https://git.kernel.org/stable/c/c14adb1cf70a984ed081c67e9d27bc3caad9537c","https://git.kernel.org/stable/c/cf9db013e167bc8fc2ecd7a13ed97a37df0c9dab","https://git.kernel.org/stable/c/d3a4fff1e7e408c32649030daa7c2c42a7e19a95","https://git.kernel.org/stable/c/ecc53e58596542791e82eff00702f8af7a313f70"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49389
|
Medium |
fixed |
- 3.17
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
usb: usbip: fix a refcount leak in stub_probe()
usb_get_dev() is called in stub_device_alloc(). When stub_probe() fails
after that, usb_put_dev() needs to be called to release the reference.
Fix this by moving usb_put_dev() to sdev_free error path handling.
Find this by code review. |
["https://git.kernel.org/stable/c/11c65408bd0ba1d9cd1307caa38169292de9cdfb","https://git.kernel.org/stable/c/247d3809e45a34d9e1a3a2bb7012e31ed8b46031","https://git.kernel.org/stable/c/2f0ae93ec33c8456cdfbf7876b80403a6318ebce","https://git.kernel.org/stable/c/51422046be504515eb5a591adf0f424b62f46804","https://git.kernel.org/stable/c/6bafee2f18af5e5ac125e42960bc65496d0e56a0","https://git.kernel.org/stable/c/8afb048800919d0ab10c57983940eba956339f21","https://git.kernel.org/stable/c/9ec4cbf1cc55d126759051acfe328d489c5d6e60","https://git.kernel.org/stable/c/bcbb795a9e78180d74c6ab21518da87e803dfdce","https://git.kernel.org/stable/c/f20d2d3b3364ce6525c050a8b6b4c54c8c19674d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49404
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hfi1: Fix potential integer multiplication overflow errors
When multiplying of different types, an overflow is possible even when
storing the result in a larger type. This is because the conversion is
done after the multiplication. So arithmetic overflow and thus in
incorrect value is possible.
Correct an instance of this in the inter packet delay calculation. Fix by
ensuring one of the operands is u64 which will promote the other to u64 as
well ensuring no overflow. |
["https://git.kernel.org/stable/c/06039d8afefdbac05bcea5f397188407eba2996d","https://git.kernel.org/stable/c/252f4afd4557a2e7075f793a5c80fe6dd9e9ee4a","https://git.kernel.org/stable/c/31dca00d0cc9f4133320d72eb7e3720badc6d6e6","https://git.kernel.org/stable/c/3f09ec80f115d2875d747ed28adc1773037e0f8b","https://git.kernel.org/stable/c/79c164e61f818054cd6012e9035701840d895c51","https://git.kernel.org/stable/c/8858284dd74906fa00f04f0252c75df4893a7959","https://git.kernel.org/stable/c/a89cb7ddf6a89bab6012e19da38b7cdb26175c19","https://git.kernel.org/stable/c/ef5ab2e48a5f9960e2352332b7cdb7064bb49032","https://git.kernel.org/stable/c/f93e91a0372c922c20d5bee260b0f43b4b8a1bee"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49438
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
Input: sparcspkr - fix refcount leak in bbc_beep_probe
of_find_node_by_path() calls of_find_node_opts_by_path(),
which returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak. |
["https://git.kernel.org/stable/c/1124e39fea0e2fdb4202f95b716cb97cc7de7cc7","https://git.kernel.org/stable/c/2f51db16cb740ff90086189a1ef2581eab665591","https://git.kernel.org/stable/c/353bc58ac6c782d4dcde9136a91d1f90867938fe","https://git.kernel.org/stable/c/418b6a3e12f75638abc5673eb76cb32127d0ab13","https://git.kernel.org/stable/c/6e07ccc7d56130f760d23f67a70c45366c07debc","https://git.kernel.org/stable/c/73d6f42d8d86648bec2e73d34fe1648cb6d23e08","https://git.kernel.org/stable/c/bbc2b0ce6042dd3117827f10ea8cb67e0ab786da","https://git.kernel.org/stable/c/c8994b30d71d64d5dcc9bc0edbfdf367171aa96f","https://git.kernel.org/stable/c/f13064b0f2c651a3fbb0749932795c6fd21556a8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49447
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
ARM: hisi: Add missing of_node_put after of_find_compatible_node
of_find_compatible_node will increment the refcount of the returned
device_node. Calling of_node_put() to avoid the refcount leak |
["https://git.kernel.org/stable/c/21a3effe446dd6dc5eed7fe897c2f9b88c9a5d6d","https://git.kernel.org/stable/c/45d211668d33c49d73f5213e8c2b58468108647c","https://git.kernel.org/stable/c/46cb7868811d025c3d29c10d18b3422db1cf20d5","https://git.kernel.org/stable/c/9bc72e47d4630d58a840a66a869c56b29554cfe4","https://git.kernel.org/stable/c/a3265a9440030068547a20dfee646666f3ca5278","https://git.kernel.org/stable/c/cafaaae4bb9ce84a2791fa29bf6907a9466c3883","https://git.kernel.org/stable/c/dd4be8ecfb41a29e7c4e551b4e866157ce4a3429","https://git.kernel.org/stable/c/e109058165137ef42841abd989f080adfefa14fa","https://git.kernel.org/stable/c/f8da78b2bae1f54746647a2bb44f8bd6025c57af"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49450
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix listen() setting the bar too high for the prealloc rings
AF_RXRPC's listen() handler lets you set the backlog up to 32 (if you bump
up the sysctl), but whilst the preallocation circular buffers have 32 slots
in them, one of them has to be a dead slot because we're using CIRC_CNT().
This means that listen(rxrpc_sock, 32) will cause an oops when the socket
is closed because rxrpc_service_prealloc_one() allocated one too many calls
and rxrpc_discard_prealloc() won't then be able to get rid of them because
it'll think the ring is empty. rxrpc_release_calls_on_socket() then tries
to abort them, but oopses because call->peer isn't yet set.
Fix this by setting the maximum backlog to RXRPC_BACKLOG_MAX - 1 to match
the ring capacity.
BUG: kernel NULL pointer dereference, address: 0000000000000086
...
RIP: 0010:rxrpc_send_abort_packet+0x73/0x240 [rxrpc]
Call Trace:
<TASK>
? __wake_up_common_lock+0x7a/0x90
? rxrpc_notify_socket+0x8e/0x140 [rxrpc]
? rxrpc_abort_call+0x4c/0x60 [rxrpc]
rxrpc_release_calls_on_socket+0x107/0x1a0 [rxrpc]
rxrpc_release+0xc9/0x1c0 [rxrpc]
__sock_release+0x37/0xa0
sock_close+0x11/0x20
__fput+0x89/0x240
task_work_run+0x59/0x90
do_exit+0x319/0xaa0 |
["https://git.kernel.org/stable/c/369de57492c4f1a42563c5a3bd365822ca3bfc79","https://git.kernel.org/stable/c/4a3a78b7918bdd723d8c7c9786522ca969bffcc4","https://git.kernel.org/stable/c/5b4826657d36c218e9f08e8d3223b0edce3de88f","https://git.kernel.org/stable/c/616f76498d5ddf26b997caf64a95cda3c8a55533","https://git.kernel.org/stable/c/61fb38cfbb1d54d3dafd0c25752f684b3cd00b32","https://git.kernel.org/stable/c/88e22159750b0d55793302eeed8ee603f5c1a95c","https://git.kernel.org/stable/c/91b34bf0409f43bb60453bab23c5beadd726d022","https://git.kernel.org/stable/c/b3a9b227d5e7467b8518160ff034ea22bb9de573","https://git.kernel.org/stable/c/e198f1930050e3115c80b67d9249f80f98a27c67"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49457
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
ARM: versatile: Add missing of_node_put in dcscb_init
The device_node pointer is returned by of_find_compatible_node
with refcount incremented. We should use of_node_put() to avoid
the refcount leak. |
["https://git.kernel.org/stable/c/23b44f9c649bbef10b45fa33080cd8b4166800ae","https://git.kernel.org/stable/c/2d7b23db35254b7d46e852967090c64cdccf24da","https://git.kernel.org/stable/c/3c6006faed9aba5144b33176d061031a9be66954","https://git.kernel.org/stable/c/83c329b980bddbc8c6a3d287d91f2103a4d4a860","https://git.kernel.org/stable/c/a0fc05cd17617e63fc13ad0c01f3f0afd890d8ec","https://git.kernel.org/stable/c/bbdfb7d4f036118d36415a2575efa6f5246505ae","https://git.kernel.org/stable/c/d146e2a9864ade19914494de3fb520390b415d58","https://git.kernel.org/stable/c/d6de7b181c29cd4578ec139aafb5eac062abbe1b","https://git.kernel.org/stable/c/fcd1999ba97445a12cc394f5f42ffd9116bf0185"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49481
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
regulator: pfuze100: Fix refcount leak in pfuze_parse_regulators_dt
of_node_get() returns a node with refcount incremented.
Calling of_node_put() to drop the reference when not needed anymore. |
["https://git.kernel.org/stable/c/0be5d9da5743b9825a95baec85a67500b2c1d362","https://git.kernel.org/stable/c/49d785baeb91568332197be356d138e5e59c7ddb","https://git.kernel.org/stable/c/56ab0c01027492cd161c64148e1dc892c56887ad","https://git.kernel.org/stable/c/671be14fc31374b1a10a3abd93db6a8480838fc9","https://git.kernel.org/stable/c/6ca675f4abbc74bc991d154a1ecc8b384dc2aae4","https://git.kernel.org/stable/c/984cfef0675ed7398814e14af2c5323911723e1c","https://git.kernel.org/stable/c/9f564e29a51210a49df3d925117777c157a17d6d","https://git.kernel.org/stable/c/afaa7b933ef00a2d3262f4d1252087613fb5c06d","https://git.kernel.org/stable/c/b74c0dd9179d21b7260260e075d597b23970100c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49482
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: mxs-saif: Fix refcount leak in mxs_saif_probe
of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done. |
["https://git.kernel.org/stable/c/18b907ff0ae4bf20120aae1538f7156b9d08e3a7","https://git.kernel.org/stable/c/24491124406666bf0dcb9ee10c5575c6ce6a1730","https://git.kernel.org/stable/c/2a0da7641e1f17a744ac7b3f76471388c97b63dc","https://git.kernel.org/stable/c/2be84f73785fa9ed6443e3c5b158730266f1c2ee","https://git.kernel.org/stable/c/30d110ca703ce60162ec337aa564a3e4da30715f","https://git.kernel.org/stable/c/4e2a1bcc51bdebed48176f6e88c150f175983f9c","https://git.kernel.org/stable/c/c933829cbf3338b684869e6c4c8931abf5d68fbd","https://git.kernel.org/stable/c/d42601e93fce7802bb8d70dd59b60cfeefa20469","https://git.kernel.org/stable/c/d855505851ee8ba666eb204149b49f906130dc17"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49491
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/rockchip: vop: fix possible null-ptr-deref in vop_bind()
It will cause null-ptr-deref in resource_size(), if platform_get_resource()
returns NULL, move calling resource_size() after devm_ioremap_resource() that
will check 'res' to avoid null-ptr-deref. |
["https://git.kernel.org/stable/c/3451852312303d54a003c73bd0ae39cebb960bd5","https://git.kernel.org/stable/c/452922955df215a417c80d09dab72bbc667a1861","https://git.kernel.org/stable/c/6ff986e057bf28e2f7690dad410768b2270f9453","https://git.kernel.org/stable/c/769c53bb6116d0eaec0f1fe4ec4b27a74465cad1","https://git.kernel.org/stable/c/a9b4599665e437de8a1152799c34841b799a2e1c","https://git.kernel.org/stable/c/b54926bd558d97c888c3d2d87886f3c159d3254a","https://git.kernel.org/stable/c/ecfa52654d0c9c333c1fe1611f47105f6bce9591","https://git.kernel.org/stable/c/f8c242908ad15bbd604d3bcb54961b7d454c43f8","https://git.kernel.org/stable/c/fcd6a886443730c39170b8383411e52118aec0a3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49492
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
nvme-pci: fix a NULL pointer dereference in nvme_alloc_admin_tags
In nvme_alloc_admin_tags, the admin_q can be set to an error (typically
-ENOMEM) if the blk_mq_init_queue call fails to set up the queue, which
is checked immediately after the call. However, when we return the error
message up the stack, to nvme_reset_work the error takes us to
nvme_remove_dead_ctrl()
nvme_dev_disable()
nvme_suspend_queue(&dev->queues[0]).
Here, we only check that the admin_q is non-NULL, rather than not
an error or NULL, and begin quiescing a queue that never existed, leading
to bad / NULL pointer dereference. |
["https://git.kernel.org/stable/c/54a4c1e47d1b2585e74920399455bd9abbfb2bd7","https://git.kernel.org/stable/c/7a28556082d1fbcbc599baf1c24252dfc73efefc","https://git.kernel.org/stable/c/8321b17789f614414206af07e17ce4751c95dc76","https://git.kernel.org/stable/c/8da2b7bdb47e94bbc4062a3978c708926bcb022c","https://git.kernel.org/stable/c/906c81dba8ee8057523859b5e1a2479e9fd34860","https://git.kernel.org/stable/c/9e649471b396fa0139d53919354ce1eace9b9a24","https://git.kernel.org/stable/c/af98940dd33c9f9e1beb4f71c0a39260100e2a65","https://git.kernel.org/stable/c/da42761181627e9bdc37d18368b827948a583929","https://git.kernel.org/stable/c/f76729662650cd7bc8f8194e057af381370349a7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49495
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/hdmi: check return value after calling platform_get_resource_byname()
It will cause null-ptr-deref if platform_get_resource_byname() returns NULL,
we need check the return value.
Patchwork: https://patchwork.freedesktop.org/patch/482992/ |
["https://git.kernel.org/stable/c/0978fcce91b90b561b8c82e7c492ba9fc8440eef","https://git.kernel.org/stable/c/2b3ed7547b1a052209da6c4ab886ffe0eed88c42","https://git.kernel.org/stable/c/4cd66a8016b872a153bf892fe4258cbc0dacf5b1","https://git.kernel.org/stable/c/6369dda4a2209142ab819f01d3d2076d81e3ebdd","https://git.kernel.org/stable/c/9cb1ee33efccb8b107ee04b7b3441820de3fd2da","https://git.kernel.org/stable/c/9f5495a5c51c1d11c6ffc13aa2befffec0c2651a","https://git.kernel.org/stable/c/a36e506711548df923ceb7ec9f6001375be799a5","https://git.kernel.org/stable/c/c1bfacf0daf25a5fc7d667399d6ff2dffda84cd8","https://git.kernel.org/stable/c/d9cb951d11a4ace4de5c50b1178ad211de17079e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49514
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
ASoC: mediatek: Fix error handling in mt8173_max98090_dev_probe
Call of_node_put(platform_node) to avoid refcount leak in
the error path. |
["https://git.kernel.org/stable/c/0a1901f34f775b83ea4b8dbb5ed992147b9b8531","https://git.kernel.org/stable/c/1e932aba3c7628c9f880ee9c2cfcc2ae3ba0c01e","https://git.kernel.org/stable/c/23f340ed906c758cec6527376768e3bc1474ac30","https://git.kernel.org/stable/c/48889eb3cce91d7f58e02bc07277b7f724b7a54a","https://git.kernel.org/stable/c/4f4e0454e226de3bf4efd7e7924d1edc571c52d5","https://git.kernel.org/stable/c/98d5afe868df998b0244f4c229ab758b4083684a","https://git.kernel.org/stable/c/cc43b9fdca519c5b13be6a717bacbebccd628cf6","https://git.kernel.org/stable/c/ebd5cb4f1f3f10b839e7575219e0f17b60c23113","https://git.kernel.org/stable/c/fb66e0512e5ccc093070e21cf88cce8d98c181b5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49538
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: jack: Access input_dev under mutex
It is possible when using ASoC that input_dev is unregistered while
calling snd_jack_report, which causes NULL pointer dereference.
In order to prevent this serialize access to input_dev using mutex lock. |
["https://git.kernel.org/stable/c/1b6a6fc5280e97559287b61eade2d4b363e836f2","https://git.kernel.org/stable/c/582aea6084cc59fec881204f026816d1219f2348","https://git.kernel.org/stable/c/5cc6f623f4818c7d7e9e966a45ebf324901ca9c5","https://git.kernel.org/stable/c/74bab3bcf422593c582e47130aa8eb41ebb2dc09","https://git.kernel.org/stable/c/8487a88136d54a1a4d3f26f1399685db648ab879","https://git.kernel.org/stable/c/9e6a73b0c0f2014eb89249fb1640c5a3d58221c4","https://git.kernel.org/stable/c/c093b62c40027c21d649c5534ad7aa3605a99b00","https://git.kernel.org/stable/c/e2b8681769f6e205382f026b907d28aa5ec9d59a","https://git.kernel.org/stable/c/f68bed124c7699e23ffb4ce4fcc84671e9193cde"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49544
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
ipw2x00: Fix potential NULL dereference in libipw_xmit()
crypt and crypt->ops could be null, so we need to checking null
before dereference |
["https://git.kernel.org/stable/c/167affc11781d7d35c4c3a7630a549ac74dd0b21","https://git.kernel.org/stable/c/1ff6b0727c8988f25eeb670b6c038c1120bb58dd","https://git.kernel.org/stable/c/48d4a820fd33f012e5f63735a59d15b5a3882882","https://git.kernel.org/stable/c/528d2023ccf4748fd542582955236c1634a7d293","https://git.kernel.org/stable/c/5f7ea274e88c0eeffe6bd6dbf6cf5c479d356af6","https://git.kernel.org/stable/c/8fb1b9beb085bb767ae43e441db5ac6fcd66a04d","https://git.kernel.org/stable/c/98d1dc32f890642476dbb78ed3437a456bf421b0","https://git.kernel.org/stable/c/b4628e0d3754ab2fc98ee6e3d21851ba45798077","https://git.kernel.org/stable/c/e8366bbabe1d207cf7c5b11ae50e223ae6fc278b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26633
|
Medium |
fixed |
- 4.19.306
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim()
syzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken.
Reading frag_off can only be done if we pulled enough bytes
to skb->head. Currently we might access garbage.
[1]
BUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
xmit_one net/core/dev.c:3548 [inline]
dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
neigh_output include/net/neighbour.h:542 [inline]
ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
dst_output include/net/dst.h:451 [inline]
ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
__sys_sendmsg net/socket.c:2667 [inline]
__do_sys_sendmsg net/socket.c:2676 [inline]
__se_sys_sendmsg net/socket.c:2674 [inline]
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2674
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at:
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
slab_alloc_node mm/slub.c:3478 [inline]
__kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
__do_kmalloc_node mm/slab_common.c:1006 [inline]
__kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027
kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582
pskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098
__pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655
pskb_may_pull_reason include/linux/skbuff.h:2673 [inline]
pskb_may_pull include/linux/skbuff.h:2681 [inline]
ip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408
ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
xmit_one net/core/dev.c:3548 [inline]
dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
neigh_output include/net/neighbour.h:542 [inline]
ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
dst_output include/net/dst.h:451 [inline]
ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
__sys_sendmsg net/socket.c:2667 [inline]
__do_sys_sendms
---truncated--- |
["https://git.kernel.org/stable/c/135414f300c5db995e2a2f3bf0f455de9d014aee","https://git.kernel.org/stable/c/3f15ba3dc14e6ee002ea01b4faddc3d49200377c","https://git.kernel.org/stable/c/4329426cf6b8e22b798db2331c7ef1dd2a9c748d","https://git.kernel.org/stable/c/62a1fedeb14c7ac0947ef33fadbabd35ed2400a2","https://git.kernel.org/stable/c/687c5d52fe53e602e76826dbd4d7af412747e183","https://git.kernel.org/stable/c/ba8d904c274268b18ef3dc11d3ca7b24a96cb087","https://git.kernel.org/stable/c/d375b98e0248980681e5e56b712026174d617198","https://git.kernel.org/stable/c/da23bd709b46168f7dfc36055801011222b076cd","https://git.kernel.org/stable/c/135414f300c5db995e2a2f3bf0f455de9d014aee","https://git.kernel.org/stable/c/3f15ba3dc14e6ee002ea01b4faddc3d49200377c","https://git.kernel.org/stable/c/4329426cf6b8e22b798db2331c7ef1dd2a9c748d","https://git.kernel.org/stable/c/62a1fedeb14c7ac0947ef33fadbabd35ed2400a2","https://git.kernel.org/stable/c/687c5d52fe53e602e76826dbd4d7af412747e183","https://git.kernel.org/stable/c/ba8d904c274268b18ef3dc11d3ca7b24a96cb087","https://git.kernel.org/stable/c/d375b98e0248980681e5e56b712026174d617198","https://git.kernel.org/stable/c/da23bd709b46168f7dfc36055801011222b076cd","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://security.netapp.com/advisory/ntap-20241220-0001/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50285
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: check outstanding simultaneous SMB operations
If Client send simultaneous SMB operations to ksmbd, It exhausts too much
memory through the "ksmbd_work_cache”. It will cause OOM issue.
ksmbd has a credit mechanism but it can't handle this problem. This patch
add the check if it exceeds max credits to prevent this problem by assuming
that one smb request consumes at least one credit. |
["https://git.kernel.org/stable/c/0a77d947f599b1f39065015bec99390d0c0022ee","https://git.kernel.org/stable/c/1f993777275cbd8f74765c4f9d9285cb907c9be5","https://git.kernel.org/stable/c/e257ac6fe138623cf59fca8898abdf659dbc8356"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21672
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
afs: Fix merge preference rule failure condition
syzbot reported a lock held when returning to userspace[1]. This is
because if argc is less than 0 and the function returns directly, the held
inode lock is not released.
Fix this by store the error in ret and jump to done to clean up instead of
returning directly.
[dh: Modified Lizhi Xu's original patch to make it honour the error code
from afs_split_string()]
[1]
WARNING: lock held when returning to user space!
6.13.0-rc3-syzkaller-00209-g499551201b5f #0 Not tainted
------------------------------------------------
syz-executor133/5823 is leaving the kernel with locks still held!
1 lock held by syz-executor133/5823:
#0: ffff888071cffc00 (&sb->s_type->i_mutex_key#9){++++}-{4:4}, at: inode_lock include/linux/fs.h:818 [inline]
#0: ffff888071cffc00 (&sb->s_type->i_mutex_key#9){++++}-{4:4}, at: afs_proc_addr_prefs_write+0x2bb/0x14e0 fs/afs/addr_prefs.c:388 |
["https://git.kernel.org/stable/c/17a4fde81d3a7478d97d15304a6d61094a10c2e3","https://git.kernel.org/stable/c/22be1d90a6211c88dd093b25d1f3aa974d0d9f9d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21912
|
Medium |
fixed |
- 5.15.179
- 6.1.131
- 6.6.83
- 6.12.19
- 6.13.7
|
In the Linux kernel, the following vulnerability has been resolved:
gpio: rcar: Use raw_spinlock to protect register access
Use raw_spinlock in order to fix spurious messages about invalid context
when spinlock debugging is enabled. The lock is only used to serialize
register access.
[ 4.239592] =============================
[ 4.239595] [ BUG: Invalid wait context ]
[ 4.239599] 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 Not tainted
[ 4.239603] -----------------------------
[ 4.239606] kworker/u8:5/76 is trying to lock:
[ 4.239609] ffff0000091898a0 (&p->lock){....}-{3:3}, at: gpio_rcar_config_interrupt_input_mode+0x34/0x164
[ 4.239641] other info that might help us debug this:
[ 4.239643] context-{5:5}
[ 4.239646] 5 locks held by kworker/u8:5/76:
[ 4.239651] #0: ffff0000080fb148 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x190/0x62c
[ 4.250180] OF: /soc/sound@ec500000/ports/port@0/endpoint: Read of boolean property 'frame-master' with a value.
[ 4.254094] #1: ffff80008299bd80 ((work_completion)(&entry->work)){+.+.}-{0:0}, at: process_one_work+0x1b8/0x62c
[ 4.254109] #2: ffff00000920c8f8
[ 4.258345] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'bitclock-master' with a value.
[ 4.264803] (&dev->mutex){....}-{4:4}, at: __device_attach_async_helper+0x3c/0xdc
[ 4.264820] #3: ffff00000a50ca40 (request_class#2){+.+.}-{4:4}, at: __setup_irq+0xa0/0x690
[ 4.264840] #4:
[ 4.268872] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'frame-master' with a value.
[ 4.273275] ffff00000a50c8c8 (lock_class){....}-{2:2}, at: __setup_irq+0xc4/0x690
[ 4.296130] renesas_sdhi_internal_dmac ee100000.mmc: mmc1 base at 0x00000000ee100000, max clock rate 200 MHz
[ 4.304082] stack backtrace:
[ 4.304086] CPU: 1 UID: 0 PID: 76 Comm: kworker/u8:5 Not tainted 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35
[ 4.304092] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)
[ 4.304097] Workqueue: async async_run_entry_fn
[ 4.304106] Call trace:
[ 4.304110] show_stack+0x14/0x20 (C)
[ 4.304122] dump_stack_lvl+0x6c/0x90
[ 4.304131] dump_stack+0x14/0x1c
[ 4.304138] __lock_acquire+0xdfc/0x1584
[ 4.426274] lock_acquire+0x1c4/0x33c
[ 4.429942] _raw_spin_lock_irqsave+0x5c/0x80
[ 4.434307] gpio_rcar_config_interrupt_input_mode+0x34/0x164
[ 4.440061] gpio_rcar_irq_set_type+0xd4/0xd8
[ 4.444422] __irq_set_trigger+0x5c/0x178
[ 4.448435] __setup_irq+0x2e4/0x690
[ 4.452012] request_threaded_irq+0xc4/0x190
[ 4.456285] devm_request_threaded_irq+0x7c/0xf4
[ 4.459398] ata1: link resume succeeded after 1 retries
[ 4.460902] mmc_gpiod_request_cd_irq+0x68/0xe0
[ 4.470660] mmc_start_host+0x50/0xac
[ 4.474327] mmc_add_host+0x80/0xe4
[ 4.477817] tmio_mmc_host_probe+0x2b0/0x440
[ 4.482094] renesas_sdhi_probe+0x488/0x6f4
[ 4.486281] renesas_sdhi_internal_dmac_probe+0x60/0x78
[ 4.491509] platform_probe+0x64/0xd8
[ 4.495178] really_probe+0xb8/0x2a8
[ 4.498756] __driver_probe_device+0x74/0x118
[ 4.503116] driver_probe_device+0x3c/0x154
[ 4.507303] __device_attach_driver+0xd4/0x160
[ 4.511750] bus_for_each_drv+0x84/0xe0
[ 4.515588] __device_attach_async_helper+0xb0/0xdc
[ 4.520470] async_run_entry_fn+0x30/0xd8
[ 4.524481] process_one_work+0x210/0x62c
[ 4.528494] worker_thread+0x1ac/0x340
[ 4.532245] kthread+0x10c/0x110
[ 4.535476] ret_from_fork+0x10/0x20 |
["https://git.kernel.org/stable/c/3e300913c42041e81c5b17a970c4e078086ff2d1","https://git.kernel.org/stable/c/51ef3073493e2a25dced05fdd59dfb059e7e284d","https://git.kernel.org/stable/c/7c1f36f9c9aca507d317479a3d3388150ae40a87","https://git.kernel.org/stable/c/b42c84f9e4ec5bc2885e7fd80c79ec0352f5d2af","https://git.kernel.org/stable/c/c10365031f16514a29c812cd909085a6e4ea4b61","https://git.kernel.org/stable/c/f02c41f87cfe61440c18bf77d1ef0a884b9ee2b5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21951
|
Medium |
fixed |
- 5.15.179
- 6.1.131
- 6.6.83
- 6.12.19
- 6.13.7
|
In the Linux kernel, the following vulnerability has been resolved:
bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock
There are multiple places from where the recovery work gets scheduled
asynchronously. Also, there are multiple places where the caller waits
synchronously for the recovery to be completed. One such place is during
the PM shutdown() callback.
If the device is not alive during recovery_work, it will try to reset the
device using pci_reset_function(). This function internally will take the
device_lock() first before resetting the device. By this time, if the lock
has already been acquired, then recovery_work will get stalled while
waiting for the lock. And if the lock was already acquired by the caller
which waits for the recovery_work to be completed, it will lead to
deadlock.
This is what happened on the X1E80100 CRD device when the device died
before shutdown() callback. Driver core calls the driver's shutdown()
callback while holding the device_lock() leading to deadlock.
And this deadlock scenario can occur on other paths as well, like during
the PM suspend() callback, where the driver core would hold the
device_lock() before calling driver's suspend() callback. And if the
recovery_work was already started, it could lead to deadlock. This is also
observed on the X1E80100 CRD.
So to fix both issues, use pci_try_reset_function() in recovery_work. This
function first checks for the availability of the device_lock() before
trying to reset the device. If the lock is available, it will acquire it
and reset the device. Otherwise, it will return -EAGAIN. If that happens,
recovery_work will fail with the error message "Recovery failed" as not
much could be done. |
["https://git.kernel.org/stable/c/1f9eb7078bc6b5fb5cbfbcb37c4bc01685332b95","https://git.kernel.org/stable/c/62505657475c245c9cd46e42ac01026d1e61f027","https://git.kernel.org/stable/c/7746f3bb8917fccb4571a576f3837d80fc513054","https://git.kernel.org/stable/c/7a5ffadd54fe2662f5c99cdccf30144d060376f7","https://git.kernel.org/stable/c/985d3cf56d8745ca637deee273929e01df449f85","https://git.kernel.org/stable/c/a321d163de3d8aa38a6449ab2becf4b1581aed96"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49568
|
Medium |
fixed |
- 5.4.210
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
KVM: Don't null dereference ops->destroy
A KVM device cleanup happens in either of two callbacks:
1) destroy() which is called when the VM is being destroyed;
2) release() which is called when a device fd is closed.
Most KVM devices use 1) but Book3s's interrupt controller KVM devices
(XICS, XIVE, XIVE-native) use 2) as they need to close and reopen during
the machine execution. The error handling in kvm_ioctl_create_device()
assumes destroy() is always defined which leads to NULL dereference as
discovered by Syzkaller.
This adds a checks for destroy!=NULL and adds a missing release().
This is not changing kvm_destroy_devices() as devices with defined
release() should have been removed from the KVM devices list by then. |
["https://git.kernel.org/stable/c/170465715a60cbb7876e6b961b21bd3225469da8","https://git.kernel.org/stable/c/3616776bc51cd3262bb1be60cc01c72e0a1959cf","https://git.kernel.org/stable/c/d4a5a79b780891c5cbdfdc6124d46fdf8d13dba1","https://git.kernel.org/stable/c/e8bc2427018826e02add7b0ed0fc625a60390ae5","https://git.kernel.org/stable/c/e91665fbbf3ccb268b268a7d71a6513538d813ac"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49125
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/sprd: fix potential NULL dereference
'drm' could be null in sprd_drm_shutdown, and drm_warn maybe dereference
it, remove this warning log.
v1 -> v2:
- Split checking platform_get_resource() return value to a separate patch
- Use dev_warn() instead of removing the warning log |
["https://git.kernel.org/stable/c/8668658aebb0a19d877d5a81c004baf716c4aaa6","https://git.kernel.org/stable/c/c3acc8db1bc221604e2db9807f01d8a44b97a64d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49134
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum: Guard against invalid local ports
When processing events generated by the device's firmware, the driver
protects itself from events reported for non-existent local ports, but
not for the CPU port (local port 0), which exists, but does not have all
the fields as any local port.
This can result in a NULL pointer dereference when trying access
'struct mlxsw_sp_port' fields which are not initialized for CPU port.
Commit 63b08b1f6834 ("mlxsw: spectrum: Protect driver from buggy firmware")
already handled such issue by bailing early when processing a PUDE event
reported for the CPU port.
Generalize the approach by moving the check to a common function and
making use of it in all relevant places. |
["https://git.kernel.org/stable/c/4cad27ba2e5a5843a7fab5aa30de2b8e8c3db3a8","https://git.kernel.org/stable/c/bcdfd615f83b4bd04678109bf18022d1476e4bbf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49177
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
hwrng: cavium - fix NULL but dereferenced coccicheck error
Fix following coccicheck warning:
./drivers/char/hw_random/cavium-rng-vf.c:182:17-20: ERROR:
pdev is NULL but dereferenced. |
["https://git.kernel.org/stable/c/e47b12f9415169eceda6770fcf45802e0c8d2a66","https://git.kernel.org/stable/c/e6205ad58a7ac194abfb33897585b38687d797fa"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49317
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: avoid infinite loop to flush node pages
xfstests/generic/475 can give EIO all the time which give an infinite loop
to flush node page like below. Let's avoid it.
[16418.518551] Call Trace:
[16418.518553] ? dm_submit_bio+0x48/0x400
[16418.518574] ? submit_bio_checks+0x1ac/0x5a0
[16418.525207] __submit_bio+0x1a9/0x230
[16418.525210] ? kmem_cache_alloc+0x29e/0x3c0
[16418.525223] submit_bio_noacct+0xa8/0x2b0
[16418.525226] submit_bio+0x4d/0x130
[16418.525238] __submit_bio+0x49/0x310 [f2fs]
[16418.525339] ? bio_add_page+0x6a/0x90
[16418.525344] f2fs_submit_page_bio+0x134/0x1f0 [f2fs]
[16418.525365] read_node_page+0x125/0x1b0 [f2fs]
[16418.525388] __get_node_page.part.0+0x58/0x3f0 [f2fs]
[16418.525409] __get_node_page+0x2f/0x60 [f2fs]
[16418.525431] f2fs_get_dnode_of_data+0x423/0x860 [f2fs]
[16418.525452] ? asm_sysvec_apic_timer_interrupt+0x12/0x20
[16418.525458] ? __mod_memcg_state.part.0+0x2a/0x30
[16418.525465] ? __mod_memcg_lruvec_state+0x27/0x40
[16418.525467] ? __xa_set_mark+0x57/0x70
[16418.525472] f2fs_do_write_data_page+0x10e/0x7b0 [f2fs]
[16418.525493] f2fs_write_single_data_page+0x555/0x830 [f2fs]
[16418.525514] ? sysvec_apic_timer_interrupt+0x4e/0x90
[16418.525518] ? asm_sysvec_apic_timer_interrupt+0x12/0x20
[16418.525523] f2fs_write_cache_pages+0x303/0x880 [f2fs]
[16418.525545] ? blk_flush_plug_list+0x47/0x100
[16418.525548] f2fs_write_data_pages+0xfd/0x320 [f2fs]
[16418.525569] do_writepages+0xd5/0x210
[16418.525648] filemap_fdatawrite_wbc+0x7d/0xc0
[16418.525655] filemap_fdatawrite+0x50/0x70
[16418.525658] f2fs_sync_dirty_inodes+0xa4/0x230 [f2fs]
[16418.525679] f2fs_write_checkpoint+0x16d/0x1720 [f2fs]
[16418.525699] ? ttwu_do_wakeup+0x1c/0x160
[16418.525709] ? ttwu_do_activate+0x6d/0xd0
[16418.525711] ? __wait_for_common+0x11d/0x150
[16418.525715] kill_f2fs_super+0xca/0x100 [f2fs]
[16418.525733] deactivate_locked_super+0x3b/0xb0
[16418.525739] deactivate_super+0x40/0x50
[16418.525741] cleanup_mnt+0x139/0x190
[16418.525747] __cleanup_mnt+0x12/0x20
[16418.525749] task_work_run+0x6d/0xa0
[16418.525765] exit_to_user_mode_prepare+0x1ad/0x1b0
[16418.525771] syscall_exit_to_user_mode+0x27/0x50
[16418.525774] do_syscall_64+0x48/0xc0
[16418.525776] entry_SYSCALL_64_after_hwframe+0x44/0xae |
["https://git.kernel.org/stable/c/a7b8618aa2f0f926ce85f2486ac835a85c753ca7","https://git.kernel.org/stable/c/bd47ea5d776d8b524fb6f60de3240f95603901dd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49484
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7915: fix possible NULL pointer dereference in mt7915_mac_fill_rx_vector
Fix possible NULL pointer dereference in mt7915_mac_fill_rx_vector
routine if the chip does not support dbdc and the hw reports band_idx
set to 1. |
["https://git.kernel.org/stable/c/268e8ef187eb8780d021b0e4f5ffa92dee5c4983","https://git.kernel.org/stable/c/62fdc974894eec80d678523458cf99bbdb887e22"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49516
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ice: always check VF VSI pointer values
The ice_get_vf_vsi function can return NULL in some cases, such as if
handling messages during a reset where the VSI is being removed and
recreated.
Several places throughout the driver do not bother to check whether this
VSI pointer is valid. Static analysis tools maybe report issues because
they detect paths where a potentially NULL pointer could be dereferenced.
Fix this by checking the return value of ice_get_vf_vsi everywhere. |
["https://git.kernel.org/stable/c/baeb705fd6a7245cc1fa69ed991a9cffdf44a174","https://git.kernel.org/stable/c/e7be3877589d539c52e5d1d23a625f889b541b9d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49529
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/pm: fix the null pointer while the smu is disabled
It needs to check if the pp_funcs is initialized while release the
context, otherwise it will trigger null pointer panic while the software
smu is not enabled.
[ 1109.404555] BUG: kernel NULL pointer dereference, address: 0000000000000078
[ 1109.404609] #PF: supervisor read access in kernel mode
[ 1109.404638] #PF: error_code(0x0000) - not-present page
[ 1109.404657] PGD 0 P4D 0
[ 1109.404672] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 1109.404701] CPU: 7 PID: 9150 Comm: amdgpu_test Tainted: G OEL 5.16.0-custom #1
[ 1109.404732] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 1109.404765] RIP: 0010:amdgpu_dpm_force_performance_level+0x1d/0x170 [amdgpu]
[ 1109.405109] Code: 5d c3 44 8b a3 f0 80 00 00 eb e5 66 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 08 4c 8b b7 f0 7d 00 00 <49> 83 7e 78 00 0f 84 f2 00 00 00 80 bf 87 80 00 00 00 48 89 fb 0f
[ 1109.405176] RSP: 0018:ffffaf3083ad7c20 EFLAGS: 00010282
[ 1109.405203] RAX: 0000000000000000 RBX: ffff9796b1c14600 RCX: 0000000002862007
[ 1109.405229] RDX: ffff97968591c8c0 RSI: 0000000000000001 RDI: ffff9796a3700000
[ 1109.405260] RBP: ffffaf3083ad7c50 R08: ffffffff9897de00 R09: ffff979688d9db60
[ 1109.405286] R10: 0000000000000000 R11: ffff979688d9db90 R12: 0000000000000001
[ 1109.405316] R13: ffff9796a3700000 R14: 0000000000000000 R15: ffff9796a3708fc0
[ 1109.405345] FS: 00007ff055cff180(0000) GS:ffff9796bfdc0000(0000) knlGS:0000000000000000
[ 1109.405378] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1109.405400] CR2: 0000000000000078 CR3: 000000000a394000 CR4: 00000000000506e0
[ 1109.405434] Call Trace:
[ 1109.405445] <TASK>
[ 1109.405456] ? delete_object_full+0x1d/0x20
[ 1109.405480] amdgpu_ctx_set_stable_pstate+0x7c/0xa0 [amdgpu]
[ 1109.405698] amdgpu_ctx_fini.part.0+0xcb/0x100 [amdgpu]
[ 1109.405911] amdgpu_ctx_do_release+0x71/0x80 [amdgpu]
[ 1109.406121] amdgpu_ctx_ioctl+0x52d/0x550 [amdgpu]
[ 1109.406327] ? _raw_spin_unlock+0x1a/0x30
[ 1109.406354] ? drm_gem_handle_delete+0x81/0xb0 [drm]
[ 1109.406400] ? amdgpu_ctx_get_entity+0x2c0/0x2c0 [amdgpu]
[ 1109.406609] drm_ioctl_kernel+0xb6/0x140 [drm] |
["https://git.kernel.org/stable/c/49ec3441aa5e5940f3e82dd2f0205b9c856e399d","https://git.kernel.org/stable/c/eea5c7b3390c6e006ba4cbd906447dd8cea8cfbf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49534
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Protect memory leak for NPIV ports sending PLOGI_RJT
There is a potential memory leak in lpfc_ignore_els_cmpl() and
lpfc_els_rsp_reject() that was allocated from NPIV PLOGI_RJT
(lpfc_rcv_plogi()'s login_mbox).
Check if cmdiocb->context_un.mbox was allocated in lpfc_ignore_els_cmpl(),
and then free it back to phba->mbox_mem_pool along with mbox->ctx_buf for
service parameters.
For lpfc_els_rsp_reject() failure, free both the ctx_buf for service
parameters and the login_mbox. |
["https://git.kernel.org/stable/c/672d1cb40551ea9c95efad43ab6d45e4ab4e015f","https://git.kernel.org/stable/c/c00df0f34a6d5e14da379f96ea67e501ce67b002"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21833
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE
There is a WARN_ON_ONCE to catch an unlikely situation when
domain_remove_dev_pasid can't find the `pasid`. In case it nevertheless
happens we must avoid using a NULL pointer. |
["https://git.kernel.org/stable/c/60f030f7418d3f1d94f2fb207fe3080e1844630b","https://git.kernel.org/stable/c/df96876be3b064aefc493f760e0639765d13ed0d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50111
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Enable IRQ if do_ale() triggered in irq-enabled context
Unaligned access exception can be triggered in irq-enabled context such
as user mode, in this case do_ale() may call get_user() which may cause
sleep. Then we will get:
BUG: sleeping function called from invalid context at arch/loongarch/kernel/access-helper.h:7
in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 129, name: modprobe
preempt_count: 0, expected: 0
RCU nest depth: 0, expected: 0
CPU: 0 UID: 0 PID: 129 Comm: modprobe Tainted: G W 6.12.0-rc1+ #1723
Tainted: [W]=WARN
Stack : 9000000105e0bd48 0000000000000000 9000000003803944 9000000105e08000
9000000105e0bc70 9000000105e0bc78 0000000000000000 0000000000000000
9000000105e0bc78 0000000000000001 9000000185e0ba07 9000000105e0b890
ffffffffffffffff 9000000105e0bc78 73924b81763be05b 9000000100194500
000000000000020c 000000000000000a 0000000000000000 0000000000000003
00000000000023f0 00000000000e1401 00000000072f8000 0000007ffbb0e260
0000000000000000 0000000000000000 9000000005437650 90000000055d5000
0000000000000000 0000000000000003 0000007ffbb0e1f0 0000000000000000
0000005567b00490 0000000000000000 9000000003803964 0000007ffbb0dfec
00000000000000b0 0000000000000007 0000000000000003 0000000000071c1d
...
Call Trace:
[<9000000003803964>] show_stack+0x64/0x1a0
[<9000000004c57464>] dump_stack_lvl+0x74/0xb0
[<9000000003861ab4>] __might_resched+0x154/0x1a0
[<900000000380c96c>] emulate_load_store_insn+0x6c/0xf60
[<9000000004c58118>] do_ale+0x78/0x180
[<9000000003801bc8>] handle_ale+0x128/0x1e0
So enable IRQ if unaligned access exception is triggered in irq-enabled
context to fix it. |
["https://git.kernel.org/stable/c/69cc6fad5df4ce652d969be69acc60e269e5eea1","https://git.kernel.org/stable/c/8915ed160dbd32b5ef5864df9a9fc11db83a77bb","https://git.kernel.org/stable/c/afbfb3568d78082078acc8bb2b29bb47af87253c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-23004
|
Medium |
fixed |
|
In the Linux kernel before 5.19, drivers/gpu/drm/arm/malidp_planes.c misinterprets the get_sg_table return value (expects it to be NULL in the error case, whereas it is actually an error pointer). |
["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19","https://github.com/torvalds/linux/commit/15342f930ebebcfe36f2415049736a77d7d2e045","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19","https://github.com/torvalds/linux/commit/15342f930ebebcfe36f2415049736a77d7d2e045","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1073
|
Medium |
|
N/A
|
A memory corruption flaw was found in the Linux kernel’s human interface device (HID) subsystem in how a user inserts a malicious USB device. This flaw allows a local user to crash or potentially escalate their privileges on the system. |
["http://www.openwall.com/lists/oss-security/2023/11/05/2","http://www.openwall.com/lists/oss-security/2023/11/05/3","https://bugzilla.redhat.com/show_bug.cgi?id=2173403","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/id=b12fece4c64857e5fab4290bf01b2e0317a88456","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://www.openwall.com/lists/osssecurity/2023/01/17/3","http://www.openwall.com/lists/oss-security/2023/11/05/2","http://www.openwall.com/lists/oss-security/2023/11/05/3","https://bugzilla.redhat.com/show_bug.cgi?id=2173403","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/id=b12fece4c64857e5fab4290bf01b2e0317a88456","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://www.openwall.com/lists/osssecurity/2023/01/17/3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-0646
|
High |
fixed |
- 5.4.267
- 5.10.208
- 5.15.147
- 6.1.69
- 6.6.7
|
An out-of-bounds memory write flaw was found in the Linux kernel’s Transport Layer Security functionality in how a user calls a function splice with a ktls socket as the destination. This flaw allows a local user to crash or potentially escalate their privileges on the system. |
["https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:0850","https://access.redhat.com/errata/RHSA-2024:0851","https://access.redhat.com/errata/RHSA-2024:0876","https://access.redhat.com/errata/RHSA-2024:0881","https://access.redhat.com/errata/RHSA-2024:0897","https://access.redhat.com/errata/RHSA-2024:1248","https://access.redhat.com/errata/RHSA-2024:1250","https://access.redhat.com/errata/RHSA-2024:1251","https://access.redhat.com/errata/RHSA-2024:1253","https://access.redhat.com/errata/RHSA-2024:1268","https://access.redhat.com/errata/RHSA-2024:1269","https://access.redhat.com/errata/RHSA-2024:1278","https://access.redhat.com/errata/RHSA-2024:1306","https://access.redhat.com/errata/RHSA-2024:1367","https://access.redhat.com/errata/RHSA-2024:1368","https://access.redhat.com/errata/RHSA-2024:1377","https://access.redhat.com/errata/RHSA-2024:1382","https://access.redhat.com/errata/RHSA-2024:1404","https://access.redhat.com/errata/RHSA-2024:2094","https://access.redhat.com/security/cve/CVE-2024-0646","https://bugzilla.redhat.com/show_bug.cgi?id=2253908","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c5a595000e267","https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:0850","https://access.redhat.com/errata/RHSA-2024:0851","https://access.redhat.com/errata/RHSA-2024:0876","https://access.redhat.com/errata/RHSA-2024:0881","https://access.redhat.com/errata/RHSA-2024:0897","https://access.redhat.com/errata/RHSA-2024:1248","https://access.redhat.com/errata/RHSA-2024:1250","https://access.redhat.com/errata/RHSA-2024:1251","https://access.redhat.com/errata/RHSA-2024:1253","https://access.redhat.com/errata/RHSA-2024:1268","https://access.redhat.com/errata/RHSA-2024:1269","https://access.redhat.com/errata/RHSA-2024:1278","https://access.redhat.com/errata/RHSA-2024:1306","https://access.redhat.com/errata/RHSA-2024:1367","https://access.redhat.com/errata/RHSA-2024:1368","https://access.redhat.com/errata/RHSA-2024:1377","https://access.redhat.com/errata/RHSA-2024:1382","https://access.redhat.com/errata/RHSA-2024:1404","https://access.redhat.com/errata/RHSA-2024:2094","https://access.redhat.com/security/cve/CVE-2024-0646","https://bugzilla.redhat.com/show_bug.cgi?id=2253908","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c5a595000e267","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-42753
|
High |
fixed |
- 4.5
- 4.10
- 4.15
- 4.19.295
- 5.4.257
- 5.10.195
- 5.15.132
- 6.1.53
- 6.4.16
- 6.5.3
|
An array indexing vulnerability was found in the netfilter subsystem of the Linux kernel. A missing macro could lead to a miscalculation of the `h->nets` array offset, providing attackers with the primitive to arbitrarily increment/decrement a memory buffer out-of-bound. This issue may allow a local user to crash the system or potentially escalate their privileges on the system. |
["https://access.redhat.com/errata/RHSA-2023:7370","https://access.redhat.com/errata/RHSA-2023:7379","https://access.redhat.com/errata/RHSA-2023:7382","https://access.redhat.com/errata/RHSA-2023:7389","https://access.redhat.com/errata/RHSA-2023:7411","https://access.redhat.com/errata/RHSA-2023:7418","https://access.redhat.com/errata/RHSA-2023:7539","https://access.redhat.com/errata/RHSA-2023:7558","https://access.redhat.com/errata/RHSA-2024:0089","https://access.redhat.com/errata/RHSA-2024:0113","https://access.redhat.com/errata/RHSA-2024:0134","https://access.redhat.com/errata/RHSA-2024:0340","https://access.redhat.com/errata/RHSA-2024:0346","https://access.redhat.com/errata/RHSA-2024:0347","https://access.redhat.com/errata/RHSA-2024:0371","https://access.redhat.com/errata/RHSA-2024:0376","https://access.redhat.com/errata/RHSA-2024:0378","https://access.redhat.com/errata/RHSA-2024:0402","https://access.redhat.com/errata/RHSA-2024:0403","https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:0461","https://access.redhat.com/errata/RHSA-2024:0562","https://access.redhat.com/errata/RHSA-2024:0563","https://access.redhat.com/errata/RHSA-2024:0593","https://access.redhat.com/errata/RHSA-2024:0999","https://access.redhat.com/security/cve/CVE-2023-42753","https://bugzilla.redhat.com/show_bug.cgi?id=2239843","https://seclists.org/oss-sec/2023/q3/216","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://access.redhat.com/errata/RHSA-2023:7370","https://access.redhat.com/errata/RHSA-2023:7379","https://access.redhat.com/errata/RHSA-2023:7382","https://access.redhat.com/errata/RHSA-2023:7389","https://access.redhat.com/errata/RHSA-2023:7411","https://access.redhat.com/errata/RHSA-2023:7418","https://access.redhat.com/errata/RHSA-2023:7539","https://access.redhat.com/errata/RHSA-2023:7558","https://access.redhat.com/errata/RHSA-2024:0089","https://access.redhat.com/errata/RHSA-2024:0113","https://access.redhat.com/errata/RHSA-2024:0134","https://access.redhat.com/errata/RHSA-2024:0340","https://access.redhat.com/errata/RHSA-2024:0346","https://access.redhat.com/errata/RHSA-2024:0347","https://access.redhat.com/errata/RHSA-2024:0371","https://access.redhat.com/errata/RHSA-2024:0376","https://access.redhat.com/errata/RHSA-2024:0378","https://access.redhat.com/errata/RHSA-2024:0402","https://access.redhat.com/errata/RHSA-2024:0403","https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:0461","https://access.redhat.com/errata/RHSA-2024:0562","https://access.redhat.com/errata/RHSA-2024:0563","https://access.redhat.com/errata/RHSA-2024:0593","https://access.redhat.com/errata/RHSA-2024:0999","https://access.redhat.com/security/cve/CVE-2023-42753","https://bugzilla.redhat.com/show_bug.cgi?id=2239843","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://seclists.org/oss-sec/2023/q3/216","https://www.openwall.com/lists/oss-security/2023/09/22/10"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3625
|
High |
fixed |
- 5.4.211
- 5.10.138
- 5.15.63
- 5.19.4
|
A vulnerability was found in Linux Kernel. It has been classified as critical. This affects the function devlink_param_set/devlink_param_get of the file net/core/devlink.c of the component IPsec. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The identifier VDB-211929 was assigned to this vulnerability. |
["https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=6b4db2e528f650c7fb712961aac36455468d5902","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://vuldb.com/?id.211929","https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=6b4db2e528f650c7fb712961aac36455468d5902","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://vuldb.com/?id.211929"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3630
|
Medium |
|
N/A
|
A vulnerability was found in Linux Kernel. It has been rated as problematic. This issue affects some unknown processing of the file fs/fscache/cookie.c of the component IPsec. The manipulation leads to memory leak. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211931. |
["https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=fb24771faf72a2fd62b3b6287af3c610c3ec9cf1","https://vuldb.com/?id.211931","https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=fb24771faf72a2fd62b3b6287af3c610c3ec9cf1","https://vuldb.com/?id.211931"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-22038
|
High |
fixed |
- 6.1.134
- 6.6.87
- 6.12.23
- 6.13.11
- 6.14.2
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate zero num_subauth before sub_auth is accessed
Access psid->sub_auth[psid->num_subauth - 1] without checking
if num_subauth is non-zero leads to an out-of-bounds read.
This patch adds a validation step to ensure num_subauth != 0
before sub_auth is accessed. |
["https://git.kernel.org/stable/c/0e36a3e080d6d8bd7a34e089345d043da4ac8283","https://git.kernel.org/stable/c/3ac65de111c686c95316ade660f8ba7aea3cd3cc","https://git.kernel.org/stable/c/56de7778a48560278c334077ace7b9ac4bfb2fd1","https://git.kernel.org/stable/c/68c6c3142bfcdb049839d40a9a59ebe8ea865002","https://git.kernel.org/stable/c/bf21e29d78cd2c2371023953d9c82dfef82ebb36","https://git.kernel.org/stable/c/c8bfe1954a0b89e7b29b3a3e7f4c5e0ebd295e20"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49740
|
High |
fixed |
- 5.4.232
- 5.10.168
- 5.15.93
- 6.1.11
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: Check the count value of channel spec to prevent out-of-bounds reads
This patch fixes slab-out-of-bounds reads in brcmfmac that occur in
brcmf_construct_chaninfo() and brcmf_enable_bw40_2g() when the count
value of channel specifications provided by the device is greater than
the length of 'list->element[]', decided by the size of the 'list'
allocated with kzalloc(). The patch adds checks that make the functions
free the buffer and return -EINVAL if that is the case. Note that the
negative return is handled by the caller, brcmf_setup_wiphybands() or
brcmf_cfg80211_attach().
Found by a modified version of syzkaller.
Crash Report from brcmf_construct_chaninfo():
==================================================================
BUG: KASAN: slab-out-of-bounds in brcmf_setup_wiphybands+0x1238/0x1430
Read of size 4 at addr ffff888115f24600 by task kworker/0:2/1896
CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G W O 5.14.0+ #132
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
Workqueue: usb_hub_wq hub_event
Call Trace:
dump_stack_lvl+0x57/0x7d
print_address_description.constprop.0.cold+0x93/0x334
kasan_report.cold+0x83/0xdf
brcmf_setup_wiphybands+0x1238/0x1430
brcmf_cfg80211_attach+0x2118/0x3fd0
brcmf_attach+0x389/0xd40
brcmf_usb_probe+0x12de/0x1690
usb_probe_interface+0x25f/0x710
really_probe+0x1be/0xa90
__driver_probe_device+0x2ab/0x460
driver_probe_device+0x49/0x120
__device_attach_driver+0x18a/0x250
bus_for_each_drv+0x123/0x1a0
__device_attach+0x207/0x330
bus_probe_device+0x1a2/0x260
device_add+0xa61/0x1ce0
usb_set_configuration+0x984/0x1770
usb_generic_driver_probe+0x69/0x90
usb_probe_device+0x9c/0x220
really_probe+0x1be/0xa90
__driver_probe_device+0x2ab/0x460
driver_probe_device+0x49/0x120
__device_attach_driver+0x18a/0x250
bus_for_each_drv+0x123/0x1a0
__device_attach+0x207/0x330
bus_probe_device+0x1a2/0x260
device_add+0xa61/0x1ce0
usb_new_device.cold+0x463/0xf66
hub_event+0x10d5/0x3330
process_one_work+0x873/0x13e0
worker_thread+0x8b/0xd10
kthread+0x379/0x450
ret_from_fork+0x1f/0x30
Allocated by task 1896:
kasan_save_stack+0x1b/0x40
__kasan_kmalloc+0x7c/0x90
kmem_cache_alloc_trace+0x19e/0x330
brcmf_setup_wiphybands+0x290/0x1430
brcmf_cfg80211_attach+0x2118/0x3fd0
brcmf_attach+0x389/0xd40
brcmf_usb_probe+0x12de/0x1690
usb_probe_interface+0x25f/0x710
really_probe+0x1be/0xa90
__driver_probe_device+0x2ab/0x460
driver_probe_device+0x49/0x120
__device_attach_driver+0x18a/0x250
bus_for_each_drv+0x123/0x1a0
__device_attach+0x207/0x330
bus_probe_device+0x1a2/0x260
device_add+0xa61/0x1ce0
usb_set_configuration+0x984/0x1770
usb_generic_driver_probe+0x69/0x90
usb_probe_device+0x9c/0x220
really_probe+0x1be/0xa90
__driver_probe_device+0x2ab/0x460
driver_probe_device+0x49/0x120
__device_attach_driver+0x18a/0x250
bus_for_each_drv+0x123/0x1a0
__device_attach+0x207/0x330
bus_probe_device+0x1a2/0x260
device_add+0xa61/0x1ce0
usb_new_device.cold+0x463/0xf66
hub_event+0x10d5/0x3330
process_one_work+0x873/0x13e0
worker_thread+0x8b/0xd10
kthread+0x379/0x450
ret_from_fork+0x1f/0x30
The buggy address belongs to the object at ffff888115f24000
which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 1536 bytes inside of
2048-byte region [ffff888115f24000, ffff888115f24800)
Memory state around the buggy address:
ffff888115f24500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff888115f24580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff888115f24600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff888115f24680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888115f24700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
Crash Report from brcmf_enable_bw40_2g():
==========
---truncated--- |
["https://git.kernel.org/stable/c/4920ab131b2dbae7464b72bdcac465d070254209","https://git.kernel.org/stable/c/9cf5e99c1ae1a85286a76c9a970202750538394c","https://git.kernel.org/stable/c/b2e412879595821ff1b5545cbed5f108fba7f5b6","https://git.kernel.org/stable/c/e4991910f15013db72f6ec0db7038ea67a57052e","https://git.kernel.org/stable/c/f06de1bb6d61f0c18b0213bbc6298960037f9d42"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49152
|
Medium |
fixed |
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
XArray: Fix xas_create_range() when multi-order entry present
If there is already an entry present that is of order >= XA_CHUNK_SHIFT
when we call xas_create_range(), xas_create_range() will misinterpret
that entry as a node and dereference xa_node->parent, generally leading
to a crash that looks something like this:
general protection fault, probably for non-canonical address 0xdffffc0000000001:
0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 PID: 32 Comm: khugepaged Not tainted 5.17.0-rc8-syzkaller-00003-g56e337f2cf13 #0
RIP: 0010:xa_parent_locked include/linux/xarray.h:1207 [inline]
RIP: 0010:xas_create_range+0x2d9/0x6e0 lib/xarray.c:725
It's deterministically reproducable once you know what the problem is,
but producing it in a live kernel requires khugepaged to hit a race.
While the problem has been present since xas_create_range() was
introduced, I'm not aware of a way to hit it before the page cache was
converted to use multi-index entries. |
["https://git.kernel.org/stable/c/18f13edf3424b3b61814b69d5269b2e14584800c","https://git.kernel.org/stable/c/1ac49c8fd49fdf53d3cd8b77eb8ffda08d7fbe22","https://git.kernel.org/stable/c/29968329b926d238e3107ec071a250397555d264","https://git.kernel.org/stable/c/3e2852eda19ee1a400cd809d7a9322680f34a262","https://git.kernel.org/stable/c/3e3c658055c002900982513e289398a1aad4a488","https://git.kernel.org/stable/c/7521a97b1929042604bef6859f62fa8b4bbc077b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49295
|
Medium |
fixed |
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
nbd: call genl_unregister_family() first in nbd_cleanup()
Otherwise there may be race between module removal and the handling of
netlink command, which can lead to the oops as shown below:
BUG: kernel NULL pointer dereference, address: 0000000000000098
Oops: 0002 [#1] SMP PTI
CPU: 1 PID: 31299 Comm: nbd-client Tainted: G E 5.14.0-rc4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:down_write+0x1a/0x50
Call Trace:
start_creating+0x89/0x130
debugfs_create_dir+0x1b/0x130
nbd_start_device+0x13d/0x390 [nbd]
nbd_genl_connect+0x42f/0x748 [nbd]
genl_family_rcv_msg_doit.isra.0+0xec/0x150
genl_rcv_msg+0xe5/0x1e0
netlink_rcv_skb+0x55/0x100
genl_rcv+0x29/0x40
netlink_unicast+0x1a8/0x250
netlink_sendmsg+0x21b/0x430
____sys_sendmsg+0x2a4/0x2d0
___sys_sendmsg+0x81/0xc0
__sys_sendmsg+0x62/0xb0
__x64_sys_sendmsg+0x1f/0x30
do_syscall_64+0x3b/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
Modules linked in: nbd(E-) |
["https://git.kernel.org/stable/c/013a79f1b5c89290e2e97f1ebf14b14e0cf5fe5c","https://git.kernel.org/stable/c/06c4da89c24e7023ea448cadf8e9daf06a0aae6e","https://git.kernel.org/stable/c/1be608e1ee1f222464b2856bda9b85ab5184a33e","https://git.kernel.org/stable/c/3d5da1ffba3388c2ae2e6c598855a4d887d3bf79","https://git.kernel.org/stable/c/6f505bbb8063fd3a238a4239d2d8c165e5279f6f","https://git.kernel.org/stable/c/8a1435c862ea09b06be7acda325128dc08458e25","https://git.kernel.org/stable/c/c0868f6e728c3c28bef0e8bee89d2daf86a8bbca","https://git.kernel.org/stable/c/cbeafa7a79d08ecdb55f8f1d41a11323d0f709db"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1205
|
Medium |
|
N/A
|
A NULL pointer dereference flaw was found in the Linux kernel’s Amateur Radio AX.25 protocol functionality in the way a user connects with the protocol. This flaw allows a local user to crash the system. |
["https://access.redhat.com/security/cve/CVE-2022-1205","https://bugzilla.redhat.com/show_bug.cgi?id=2071047","https://github.com/torvalds/linux/commit/82e31755e55fbcea6a9dfaae5fe4860ade17cbc0","https://github.com/torvalds/linux/commit/fc6d01ff9ef03b66d4a3a23b46fc3c3d8cf92009","https://www.openwall.com/lists/oss-security/2022/04/02/4","https://access.redhat.com/security/cve/CVE-2022-1205","https://bugzilla.redhat.com/show_bug.cgi?id=2071047","https://github.com/torvalds/linux/commit/82e31755e55fbcea6a9dfaae5fe4860ade17cbc0","https://github.com/torvalds/linux/commit/fc6d01ff9ef03b66d4a3a23b46fc3c3d8cf92009","https://www.openwall.com/lists/oss-security/2022/04/02/4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49003
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
nvme: fix SRCU protection of nvme_ns_head list
Walking the nvme_ns_head siblings list is protected by the head's srcu
in nvme_ns_head_submit_bio() but not nvme_mpath_revalidate_paths().
Removing namespaces from the list also fails to synchronize the srcu.
Concurrent scan work can therefore cause use-after-frees.
Hold the head's srcu lock in nvme_mpath_revalidate_paths() and
synchronize with the srcu, not the global RCU, in nvme_ns_remove().
Observed the following panic when making NVMe/RDMA connections
with native multipath on the Rocky Linux 8.6 kernel
(it seems the upstream kernel has the same race condition).
Disassembly shows the faulting instruction is cmp 0x50(%rdx),%rcx;
computing capacity != get_capacity(ns->disk).
Address 0x50 is dereferenced because ns->disk is NULL.
The NULL disk appears to be the result of concurrent scan work
freeing the namespace (note the log line in the middle of the panic).
[37314.206036] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
[37314.206036] nvme0n3: detected capacity change from 0 to 11811160064
[37314.299753] PGD 0 P4D 0
[37314.299756] Oops: 0000 [#1] SMP PTI
[37314.299759] CPU: 29 PID: 322046 Comm: kworker/u98:3 Kdump: loaded Tainted: G W X --------- - - 4.18.0-372.32.1.el8test86.x86_64 #1
[37314.299762] Hardware name: Dell Inc. PowerEdge R720/0JP31P, BIOS 2.7.0 05/23/2018
[37314.299763] Workqueue: nvme-wq nvme_scan_work [nvme_core]
[37314.299783] RIP: 0010:nvme_mpath_revalidate_paths+0x26/0xb0 [nvme_core]
[37314.299790] Code: 1f 44 00 00 66 66 66 66 90 55 53 48 8b 5f 50 48 8b 83 c8 c9 00 00 48 8b 13 48 8b 48 50 48 39 d3 74 20 48 8d 42 d0 48 8b 50 20 <48> 3b 4a 50 74 05 f0 80 60 70 ef 48 8b 50 30 48 8d 42 d0 48 39 d3
[37315.058803] RSP: 0018:ffffabe28f913d10 EFLAGS: 00010202
[37315.121316] RAX: ffff927a077da800 RBX: ffff92991dd70000 RCX: 0000000001600000
[37315.206704] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff92991b719800
[37315.292106] RBP: ffff929a6b70c000 R08: 000000010234cd4a R09: c0000000ffff7fff
[37315.377501] R10: 0000000000000001 R11: ffffabe28f913a30 R12: 0000000000000000
[37315.462889] R13: ffff92992716600c R14: ffff929964e6e030 R15: ffff92991dd70000
[37315.548286] FS: 0000000000000000(0000) GS:ffff92b87fb80000(0000) knlGS:0000000000000000
[37315.645111] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[37315.713871] CR2: 0000000000000050 CR3: 0000002208810006 CR4: 00000000000606e0
[37315.799267] Call Trace:
[37315.828515] nvme_update_ns_info+0x1ac/0x250 [nvme_core]
[37315.892075] nvme_validate_or_alloc_ns+0x2ff/0xa00 [nvme_core]
[37315.961871] ? __blk_mq_free_request+0x6b/0x90
[37316.015021] nvme_scan_work+0x151/0x240 [nvme_core]
[37316.073371] process_one_work+0x1a7/0x360
[37316.121318] ? create_worker+0x1a0/0x1a0
[37316.168227] worker_thread+0x30/0x390
[37316.212024] ? create_worker+0x1a0/0x1a0
[37316.258939] kthread+0x10a/0x120
[37316.297557] ? set_kthread_struct+0x50/0x50
[37316.347590] ret_from_fork+0x35/0x40
[37316.390360] Modules linked in: nvme_rdma nvme_tcp(X) nvme_fabrics nvme_core netconsole iscsi_tcp libiscsi_tcp dm_queue_length dm_service_time nf_conntrack_netlink br_netfilter bridge stp llc overlay nft_chain_nat ipt_MASQUERADE nf_nat xt_addrtype xt_CT nft_counter xt_state xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment xt_multiport nft_compat nf_tables libcrc32c nfnetlink dm_multipath tg3 rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm intel_rapl_msr iTCO_wdt iTCO_vendor_support dcdbas intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ipmi_ssif kvm irqbypass crct10dif_pclmul crc32_pclmul mlx5_ib ghash_clmulni_intel ib_uverbs rapl intel_cstate intel_uncore ib_core ipmi_si joydev mei_me pcspkr ipmi_devintf mei lpc_ich wmi ipmi_msghandler acpi_power_meter ex
---truncated--- |
["https://git.kernel.org/stable/c/5b566d09ab1b975566a53f9c5466ee260d087582","https://git.kernel.org/stable/c/787d81d4eb150e443e5d1276c6e8f03cfecc2302","https://git.kernel.org/stable/c/899d2a05dc14733cfba6224083c6b0dd5a738590"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-45919
|
High |
fixed |
- 4.14.317
- 4.19.285
- 5.4.246
- 5.10.183
- 5.15.116
- 6.1.33
- 6.3.7
|
An issue was discovered in the Linux kernel through 6.0.10. In drivers/media/dvb-core/dvb_ca_en50221.c, a use-after-free can occur is there is a disconnect after an open, because of the lack of a wait_event. |
["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=280a8ab81733da8bc442253c700a52c4c0886ffd","https://lore.kernel.org/linux-media/20221121063308.GA33821%40ubuntu/T/#u","https://security.netapp.com/advisory/ntap-20230113-0008/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=280a8ab81733da8bc442253c700a52c4c0886ffd","https://lore.kernel.org/linux-media/20221121063308.GA33821%40ubuntu/T/#u","https://security.netapp.com/advisory/ntap-20230113-0008/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-2961
|
High |
fixed |
|
A use-after-free flaw was found in the Linux kernel’s PLP Rose functionality in the way a user triggers a race condition by calling bind while simultaneously triggering the rose_bind() function. This flaw allows a local user to crash or potentially escalate their privileges on the system. |
["https://access.redhat.com/security/cve/CVE-2022-2961","https://security.netapp.com/advisory/ntap-20230214-0004/","https://access.redhat.com/security/cve/CVE-2022-2961","https://security.netapp.com/advisory/ntap-20230214-0004/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-51781
|
High |
fixed |
|
An issue was discovered in the Linux kernel before 6.6.8. atalk_ioctl in net/appletalk/ddp.c has a use-after-free because of an atalk_recvmsg race condition. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.8","https://github.com/torvalds/linux/commit/189ff16722ee36ced4d2a2469d4ab65a8fee4198","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.8","https://github.com/torvalds/linux/commit/189ff16722ee36ced4d2a2469d4ab65a8fee4198","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-22062
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
sctp: add mutual exclusion in proc_sctp_do_udp_port()
We must serialize calls to sctp_udp_sock_stop() and sctp_udp_sock_start()
or risk a crash as syzbot reported:
Oops: general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]
CPU: 1 UID: 0 PID: 6551 Comm: syz.1.44 Not tainted 6.14.0-syzkaller-g7f2ff7b62617 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
RIP: 0010:kernel_sock_shutdown+0x47/0x70 net/socket.c:3653
Call Trace:
<TASK>
udp_tunnel_sock_release+0x68/0x80 net/ipv4/udp_tunnel_core.c:181
sctp_udp_sock_stop+0x71/0x160 net/sctp/protocol.c:930
proc_sctp_do_udp_port+0x264/0x450 net/sctp/sysctl.c:553
proc_sys_call_handler+0x3d0/0x5b0 fs/proc/proc_sysctl.c:601
iter_file_splice_write+0x91c/0x1150 fs/splice.c:738
do_splice_from fs/splice.c:935 [inline]
direct_splice_actor+0x18f/0x6c0 fs/splice.c:1158
splice_direct_to_actor+0x342/0xa30 fs/splice.c:1102
do_splice_direct_actor fs/splice.c:1201 [inline]
do_splice_direct+0x174/0x240 fs/splice.c:1227
do_sendfile+0xafd/0xe50 fs/read_write.c:1368
__do_sys_sendfile64 fs/read_write.c:1429 [inline]
__se_sys_sendfile64 fs/read_write.c:1415 [inline]
__x64_sys_sendfile64+0x1d8/0x220 fs/read_write.c:1415
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] |
["https://git.kernel.org/stable/c/10206302af856791fbcc27a33ed3c3eb09b2793d","https://git.kernel.org/stable/c/386507cb6fb7cdef598ddcb3f0fa37e6ca9e789d","https://git.kernel.org/stable/c/65ccb2793da7401772a3ffe85355c831b313c59f","https://git.kernel.org/stable/c/b3598f53211ba1025485306de2733bdd241311a3","https://git.kernel.org/stable/c/d3d7675d77622f6ca1aae14c51f80027b36283f8","https://git.kernel.org/stable/c/e5178bfc55b3a78000f0f8298e7ade88783ce581","https://git.kernel.org/stable/c/efb8cb487be8f4ba6aaef616011d702d6a083ed1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-22081
|
Medium |
fixed |
- 5.15.180
- 6.1.134
- 6.6.87
- 6.12.23
- 6.13.11
- 6.14.2
|
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix a couple integer overflows on 32bit systems
On 32bit systems the "off + sizeof(struct NTFS_DE)" addition can
have an integer wrapping issue. Fix it by using size_add(). |
["https://git.kernel.org/stable/c/0538f52410b619737e663167b6a2b2d0bc1a589d","https://git.kernel.org/stable/c/0922d86a7a6032cb1694eab0b44b861bd33ba8d5","https://git.kernel.org/stable/c/0dfe700fbd3525f30a36ffbe390a5b9319bd009a","https://git.kernel.org/stable/c/1a14e9718a19d2e88de004a1360bfd7a86ed1395","https://git.kernel.org/stable/c/284c9549386e9883855fb82b730303bb2edea9de","https://git.kernel.org/stable/c/4d0f4f42922a832388a0c2fe5204c0a1037ff786","https://git.kernel.org/stable/c/5ad414f4df2294b28836b5b7b69787659d6aa708"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-38152
|
Medium |
fixed |
- 5.15.180
- 6.1.134
- 6.6.87
- 6.12.23
- 6.13.11
- 6.14.2
|
In the Linux kernel, the following vulnerability has been resolved:
remoteproc: core: Clear table_sz when rproc_shutdown
There is case as below could trigger kernel dump:
Use U-Boot to start remote processor(rproc) with resource table
published to a fixed address by rproc. After Kernel boots up,
stop the rproc, load a new firmware which doesn't have resource table
,and start rproc.
When starting rproc with a firmware not have resource table,
`memcpy(loaded_table, rproc->cached_table, rproc->table_sz)` will
trigger dump, because rproc->cache_table is set to NULL during the last
stop operation, but rproc->table_sz is still valid.
This issue is found on i.MX8MP and i.MX9.
Dump as below:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
Mem abort info:
ESR = 0x0000000096000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
Data abort info:
ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af63000
[0000000000000000] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
Modules linked in:
CPU: 2 UID: 0 PID: 1060 Comm: sh Not tainted 6.14.0-rc7-next-20250317-dirty #38
Hardware name: NXP i.MX8MPlus EVK board (DT)
pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __pi_memcpy_generic+0x110/0x22c
lr : rproc_start+0x88/0x1e0
Call trace:
__pi_memcpy_generic+0x110/0x22c (P)
rproc_boot+0x198/0x57c
state_store+0x40/0x104
dev_attr_store+0x18/0x2c
sysfs_kf_write+0x7c/0x94
kernfs_fop_write_iter+0x120/0x1cc
vfs_write+0x240/0x378
ksys_write+0x70/0x108
__arm64_sys_write+0x1c/0x28
invoke_syscall+0x48/0x10c
el0_svc_common.constprop.0+0xc0/0xe0
do_el0_svc+0x1c/0x28
el0_svc+0x30/0xcc
el0t_64_sync_handler+0x10c/0x138
el0t_64_sync+0x198/0x19c
Clear rproc->table_sz to address the issue. |
["https://git.kernel.org/stable/c/068f6648ff5b0c7adeb6c363fae7fb188aa178fa","https://git.kernel.org/stable/c/2df19f5f6f72da6f6ebab7cdb3a3b9f7686bb476","https://git.kernel.org/stable/c/6e66bca8cd51ebedd5d32426906a38e4a3c69c5f","https://git.kernel.org/stable/c/7c6bb82a6f3da6ab2d3fbea03901482231708b98","https://git.kernel.org/stable/c/8e0fd2a3b9852ac3cf540edb06ccc0153b38b5af","https://git.kernel.org/stable/c/e6015ca453b82ec54aec9682dcc38773948fcc48","https://git.kernel.org/stable/c/efdde3d73ab25cef4ff2d06783b0aad8b093c0e4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3077
|
Medium |
fixed |
|
A buffer overflow vulnerability was found in the Linux kernel Intel’s iSMT SMBus host controller driver in the way it handled the I2C_SMBUS_BLOCK_PROC_CALL case (via the ioctl I2C_SMBUS) with malicious input data. This flaw could allow a local user to crash the system. |
["https://github.com/torvalds/linux/commit/690b2549b19563ec5ad53e5c82f6a944d910086e","https://github.com/torvalds/linux/commit/690b2549b19563ec5ad53e5c82f6a944d910086e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1204
|
Medium |
fixed |
|
A use-after-free flaw was found in the Linux kernel’s Amateur Radio AX.25 protocol functionality in the way a user connects with the protocol. This flaw allows a local user to crash the system. |
["https://access.redhat.com/security/cve/CVE-2022-1204","https://bugzilla.redhat.com/show_bug.cgi?id=2071051","https://security-tracker.debian.org/tracker/CVE-2022-1204","https://www.openwall.com/lists/oss-security/2022/04/02/2","https://access.redhat.com/security/cve/CVE-2022-1204","https://bugzilla.redhat.com/show_bug.cgi?id=2071051","https://security-tracker.debian.org/tracker/CVE-2022-1204","https://www.openwall.com/lists/oss-security/2022/04/02/2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56751
|
Medium |
fixed |
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
ipv6: release nexthop on device removal
The CI is hitting some aperiodic hangup at device removal time in the
pmtu.sh self-test:
unregister_netdevice: waiting for veth_A-R1 to become free. Usage count = 6
ref_tracker: veth_A-R1@ffff888013df15d8 has 1/5 users at
dst_init+0x84/0x4a0
dst_alloc+0x97/0x150
ip6_dst_alloc+0x23/0x90
ip6_rt_pcpu_alloc+0x1e6/0x520
ip6_pol_route+0x56f/0x840
fib6_rule_lookup+0x334/0x630
ip6_route_output_flags+0x259/0x480
ip6_dst_lookup_tail.constprop.0+0x5c2/0x940
ip6_dst_lookup_flow+0x88/0x190
udp_tunnel6_dst_lookup+0x2a7/0x4c0
vxlan_xmit_one+0xbde/0x4a50 [vxlan]
vxlan_xmit+0x9ad/0xf20 [vxlan]
dev_hard_start_xmit+0x10e/0x360
__dev_queue_xmit+0xf95/0x18c0
arp_solicit+0x4a2/0xe00
neigh_probe+0xaa/0xf0
While the first suspect is the dst_cache, explicitly tracking the dst
owing the last device reference via probes proved such dst is held by
the nexthop in the originating fib6_info.
Similar to commit f5b51fe804ec ("ipv6: route: purge exception on
removal"), we need to explicitly release the originating fib info when
disconnecting a to-be-removed device from a live ipv6 dst: move the
fib6_info cleanup into ip6_dst_ifdown().
Tested running:
./pmtu.sh cleanup_ipv6_exception
in a tight loop for more than 400 iterations with no spat, running an
unpatched kernel I observed a splat every ~10 iterations. |
["https://git.kernel.org/stable/c/0e4c6faaef8a24b762a24ffb767280e263ef8e10","https://git.kernel.org/stable/c/43e25adc80269f917d2a195f0d59f74cdd182955","https://git.kernel.org/stable/c/77aa9855a878fb43f547ddfbda3127a1e88ad31a","https://git.kernel.org/stable/c/a3c3f8a4d025acc8c857246ec2b812c59102487a","https://git.kernel.org/stable/c/b2f26a27ea3f72f75d18330f76f5d1007c791848","https://git.kernel.org/stable/c/eb02688c5c45c3e7af7e71f036a7144f5639cbfe"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-2380
|
Medium |
fixed |
|
The Linux kernel was found vulnerable out of bounds memory access in the drivers/video/fbdev/sm712fb.c:smtcfb_read() function. The vulnerability could result in local attackers being able to crash the kernel. |
["https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git/commit/?h=for-next\u0026id=bd771cf5c4254511cc4abb88f3dab3bd58bdf8e8","https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git/commit/?h=for-next\u0026id=bd771cf5c4254511cc4abb88f3dab3bd58bdf8e8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52607
|
Medium |
fixed |
- 4.19.307
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
powerpc/mm: Fix null-pointer dereference in pgtable_cache_add
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity. |
["https://git.kernel.org/stable/c/145febd85c3bcc5c74d87ef9a598fc7d9122d532","https://git.kernel.org/stable/c/21e45a7b08d7cd98d6a53c5fc5111879f2d96611","https://git.kernel.org/stable/c/aa28eecb43cac6e20ef14dfc50b8892c1fbcda5b","https://git.kernel.org/stable/c/ac3ed969a40357b0542d20f096a6d43acdfa6cc7","https://git.kernel.org/stable/c/d482d61025e303a2bef3733a011b6b740215cfa1","https://git.kernel.org/stable/c/f46c8a75263f97bda13c739ba1c90aced0d3b071","https://git.kernel.org/stable/c/f6781add1c311c17eff43e14c786004bbacf901e","https://git.kernel.org/stable/c/ffd29dc45bc0355393859049f6becddc3ed08f74","https://git.kernel.org/stable/c/145febd85c3bcc5c74d87ef9a598fc7d9122d532","https://git.kernel.org/stable/c/21e45a7b08d7cd98d6a53c5fc5111879f2d96611","https://git.kernel.org/stable/c/aa28eecb43cac6e20ef14dfc50b8892c1fbcda5b","https://git.kernel.org/stable/c/ac3ed969a40357b0542d20f096a6d43acdfa6cc7","https://git.kernel.org/stable/c/d482d61025e303a2bef3733a011b6b740215cfa1","https://git.kernel.org/stable/c/f46c8a75263f97bda13c739ba1c90aced0d3b071","https://git.kernel.org/stable/c/f6781add1c311c17eff43e14c786004bbacf901e","https://git.kernel.org/stable/c/ffd29dc45bc0355393859049f6becddc3ed08f74","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-4155
|
Medium |
fixed |
|
A data leak flaw was found in the way XFS_IOC_ALLOCSP IOCTL in the XFS filesystem allowed for size increase of files with unaligned size. A local attacker could use this flaw to leak data on the XFS filesystem otherwise not accessible to them. |
["https://access.redhat.com/security/cve/CVE-2021-4155","https://bugzilla.redhat.com/show_bug.cgi?id=2034813","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=983d8e60f50806f90534cc5373d0ce867e5aaf79","https://security-tracker.debian.org/tracker/CVE-2021-4155","https://www.openwall.com/lists/oss-security/2022/01/10/1","https://access.redhat.com/security/cve/CVE-2021-4155","https://bugzilla.redhat.com/show_bug.cgi?id=2034813","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=983d8e60f50806f90534cc5373d0ce867e5aaf79","https://security-tracker.debian.org/tracker/CVE-2021-4155","https://www.openwall.com/lists/oss-security/2022/01/10/1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-57950
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Initialize denominator defaults to 1
[WHAT & HOW]
Variables, used as denominators and maybe not assigned to other values,
should be initialized to non-zero to avoid DIVIDE_BY_ZERO, as reported
by Coverity.
(cherry picked from commit e2c4c6c10542ccfe4a0830bb6c9fd5b177b7bbb7) |
["https://git.kernel.org/stable/c/36b23e3baf9129d5b6c3a3a85b6b7ffb75ae287c","https://git.kernel.org/stable/c/c9d6afb4f9c338049662d27d169fba7dd60e337d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21696
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mm: clear uffd-wp PTE/PMD state on mremap()
When mremap()ing a memory region previously registered with userfaultfd as
write-protected but without UFFD_FEATURE_EVENT_REMAP, an inconsistency in
flag clearing leads to a mismatch between the vma flags (which have
uffd-wp cleared) and the pte/pmd flags (which do not have uffd-wp
cleared). This mismatch causes a subsequent mprotect(PROT_WRITE) to
trigger a warning in page_table_check_pte_flags() due to setting the pte
to writable while uffd-wp is still set.
Fix this by always explicitly clearing the uffd-wp pte/pmd flags on any
such mremap() so that the values are consistent with the existing clearing
of VM_UFFD_WP. Be careful to clear the logical flag regardless of its
physical form; a PTE bit, a swap PTE bit, or a PTE marker. Cover PTE,
huge PMD and hugetlb paths. |
["https://git.kernel.org/stable/c/0cef0bb836e3cfe00f08f9606c72abd72fe78ca3","https://git.kernel.org/stable/c/310ac886d68de661c3a334198d8604b722d7fdf8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26828
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix underflow in parse_server_interfaces()
In this loop, we step through the buffer and after each item we check
if the size_left is greater than the minimum size we need. However,
the problem is that "bytes_left" is type ssize_t while sizeof() is type
size_t. That means that because of type promotion, the comparison is
done as an unsigned and if we have negative bytes left the loop
continues instead of ending. |
["https://git.kernel.org/stable/c/7190353835b4a219abb70f90b06cdcae97f11512","https://git.kernel.org/stable/c/cffe487026be13eaf37ea28b783d9638ab147204","https://git.kernel.org/stable/c/df2af9fdbc4ddde18a3371c4ca1a86596e8be301","https://git.kernel.org/stable/c/f7ff1c89fb6e9610d2b01c1821727729e6609308","https://git.kernel.org/stable/c/7190353835b4a219abb70f90b06cdcae97f11512","https://git.kernel.org/stable/c/cffe487026be13eaf37ea28b783d9638ab147204","https://git.kernel.org/stable/c/df2af9fdbc4ddde18a3371c4ca1a86596e8be301","https://git.kernel.org/stable/c/f7ff1c89fb6e9610d2b01c1821727729e6609308"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52530
|
High |
fixed |
- 5.4.285
- 5.10.288
- 5.15.169
- 6.1.57
- 6.5.7
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix potential key use-after-free
When ieee80211_key_link() is called by ieee80211_gtk_rekey_add()
but returns 0 due to KRACK protection (identical key reinstall),
ieee80211_gtk_rekey_add() will still return a pointer into the
key, in a potential use-after-free. This normally doesn't happen
since it's only called by iwlwifi in case of WoWLAN rekey offload
which has its own KRACK protection, but still better to fix, do
that by returning an error code and converting that to success on
the cfg80211 boundary only, leaving the error for bad callers of
ieee80211_gtk_rekey_add(). |
["https://git.kernel.org/stable/c/2408f491ff998d674707725eadc47d8930aced09","https://git.kernel.org/stable/c/2f4e16e39e4f5e78248dd9e51276a83203950b36","https://git.kernel.org/stable/c/31db78a4923ef5e2008f2eed321811ca79e7f71b","https://git.kernel.org/stable/c/65c72a7201704574dace708cbc96a8f367b1491d","https://git.kernel.org/stable/c/e8a834eb09bb95c2bf9c76f1a28ecef7d8c439d0","https://git.kernel.org/stable/c/e8e599a635066c50ac214c3e10858f1d37e03022","https://git.kernel.org/stable/c/2f4e16e39e4f5e78248dd9e51276a83203950b36","https://git.kernel.org/stable/c/31db78a4923ef5e2008f2eed321811ca79e7f71b","https://git.kernel.org/stable/c/65c72a7201704574dace708cbc96a8f367b1491d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26622
|
High |
fixed |
- 5.10.212
- 5.15.151
- 6.1.81
- 6.6.21
- 6.7.9
|
In the Linux kernel, the following vulnerability has been resolved:
tomoyo: fix UAF write bug in tomoyo_write_control()
Since tomoyo_write_control() updates head->write_buf when write()
of long lines is requested, we need to fetch head->write_buf after
head->io_sem is held. Otherwise, concurrent write() requests can
cause use-after-free-write and double-free problems. |
["https://git.kernel.org/stable/c/2caa605079488da9601099fbda460cfc1702839f","https://git.kernel.org/stable/c/2f03fc340cac9ea1dc63cbf8c93dd2eb0f227815","https://git.kernel.org/stable/c/3bfe04c1273d30b866f4c7c238331ed3b08e5824","https://git.kernel.org/stable/c/6edefe1b6c29a9932f558a898968a9fcbeec5711","https://git.kernel.org/stable/c/7d930a4da17958f869ef679ee0e4a8729337affc","https://git.kernel.org/stable/c/a23ac1788e2c828c097119e9a3178f0b7e503fee","https://git.kernel.org/stable/c/2caa605079488da9601099fbda460cfc1702839f","https://git.kernel.org/stable/c/2f03fc340cac9ea1dc63cbf8c93dd2eb0f227815","https://git.kernel.org/stable/c/3bfe04c1273d30b866f4c7c238331ed3b08e5824","https://git.kernel.org/stable/c/6edefe1b6c29a9932f558a898968a9fcbeec5711","https://git.kernel.org/stable/c/7d930a4da17958f869ef679ee0e4a8729337affc","https://git.kernel.org/stable/c/a23ac1788e2c828c097119e9a3178f0b7e503fee","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-2235
|
High |
fixed |
|
A use-after-free vulnerability in the Linux Kernel Performance Events system can be exploited to achieve local privilege escalation.
The perf_group_detach function did not check the event's siblings' attach_state before calling add_event_to_groups(), but remove_on_exec made it possible to call list_del_event() on before detaching from their group, making it possible to use a dangling pointer causing a use-after-free vulnerability.
We recommend upgrading past commit fd0815f632c24878e325821943edccc7fde947a2. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fd0815f632c24878e325821943edccc7fde947a2","https://kernel.dance/fd0815f632c24878e325821943edccc7fde947a2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fd0815f632c24878e325821943edccc7fde947a2","https://kernel.dance/fd0815f632c24878e325821943edccc7fde947a2","https://security.netapp.com/advisory/ntap-20230609-0002/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26689
|
High |
fixed |
- 5.10.210
- 5.15.149
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
ceph: prevent use-after-free in encode_cap_msg()
In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was
caught by KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. This
implies before the refcount could be increment here, it was freed.
In same file, in "handle_cap_grant()" refcount is decremented by this
line - 'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race
occurred and resource was freed by the latter line before the former
line could increment it.
encode_cap_msg() is called by __send_cap() and __send_cap() is called by
ceph_check_caps() after calling __prep_cap(). __prep_cap() is where
arg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot where
the refcount must be increased to prevent "use after free" error. |
["https://git.kernel.org/stable/c/70e329b440762390258a6fe8c0de93c9fdd56c77","https://git.kernel.org/stable/c/7958c1bf5b03c6f1f58e724dbdec93f8f60b96fc","https://git.kernel.org/stable/c/8180d0c27b93a6eb60da1b08ea079e3926328214","https://git.kernel.org/stable/c/ae20db45e482303a20e56f2db667a9d9c54ac7e7","https://git.kernel.org/stable/c/cda4672da1c26835dcbd7aec2bfed954eda9b5ef","https://git.kernel.org/stable/c/f3f98d7d84b31828004545e29fd7262b9f444139","https://git.kernel.org/stable/c/70e329b440762390258a6fe8c0de93c9fdd56c77","https://git.kernel.org/stable/c/7958c1bf5b03c6f1f58e724dbdec93f8f60b96fc","https://git.kernel.org/stable/c/8180d0c27b93a6eb60da1b08ea079e3926328214","https://git.kernel.org/stable/c/ae20db45e482303a20e56f2db667a9d9c54ac7e7","https://git.kernel.org/stable/c/cda4672da1c26835dcbd7aec2bfed954eda9b5ef","https://git.kernel.org/stable/c/f3f98d7d84b31828004545e29fd7262b9f444139","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52474
|
High |
fixed |
- 5.10.180
- 5.15.111
- 6.1.28
- 6.2.15
- 6.3.2
|
In the Linux kernel, the following vulnerability has been resolved:
IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests
hfi1 user SDMA request processing has two bugs that can cause data
corruption for user SDMA requests that have multiple payload iovecs
where an iovec other than the tail iovec does not run up to the page
boundary for the buffer pointed to by that iovec.a
Here are the specific bugs:
1. user_sdma_txadd() does not use struct user_sdma_iovec->iov.iov_len.
Rather, user_sdma_txadd() will add up to PAGE_SIZE bytes from iovec
to the packet, even if some of those bytes are past
iovec->iov.iov_len and are thus not intended to be in the packet.
2. user_sdma_txadd() and user_sdma_send_pkts() fail to advance to the
next iovec in user_sdma_request->iovs when the current iovec
is not PAGE_SIZE and does not contain enough data to complete the
packet. The transmitted packet will contain the wrong data from the
iovec pages.
This has not been an issue with SDMA packets from hfi1 Verbs or PSM2
because they only produce iovecs that end short of PAGE_SIZE as the tail
iovec of an SDMA request.
Fixing these bugs exposes other bugs with the SDMA pin cache
(struct mmu_rb_handler) that get in way of supporting user SDMA requests
with multiple payload iovecs whose buffers do not end at PAGE_SIZE. So
this commit fixes those issues as well.
Here are the mmu_rb_handler bugs that non-PAGE_SIZE-end multi-iovec
payload user SDMA requests can hit:
1. Overlapping memory ranges in mmu_rb_handler will result in duplicate
pinnings.
2. When extending an existing mmu_rb_handler entry (struct mmu_rb_node),
the mmu_rb code (1) removes the existing entry under a lock, (2)
releases that lock, pins the new pages, (3) then reacquires the lock
to insert the extended mmu_rb_node.
If someone else comes in and inserts an overlapping entry between (2)
and (3), insert in (3) will fail.
The failure path code in this case unpins _all_ pages in either the
original mmu_rb_node or the new mmu_rb_node that was inserted between
(2) and (3).
3. In hfi1_mmu_rb_remove_unless_exact(), mmu_rb_node->refcount is
incremented outside of mmu_rb_handler->lock. As a result, mmu_rb_node
could be evicted by another thread that gets mmu_rb_handler->lock and
checks mmu_rb_node->refcount before mmu_rb_node->refcount is
incremented.
4. Related to #2 above, SDMA request submission failure path does not
check mmu_rb_node->refcount before freeing mmu_rb_node object.
If there are other SDMA requests in progress whose iovecs have
pointers to the now-freed mmu_rb_node(s), those pointers to the
now-freed mmu_rb nodes will be dereferenced when those SDMA requests
complete. |
["https://git.kernel.org/stable/c/00cbce5cbf88459cd1aa1d60d0f1df15477df127","https://git.kernel.org/stable/c/7e6010f79b58f45b204cf18aa58f4b73c3f30adc","https://git.kernel.org/stable/c/9c4c6512d7330b743c4ffd18bd999a86ca26db0d","https://git.kernel.org/stable/c/a2bd706ab63509793b5cd5065e685b7ef5cba678","https://git.kernel.org/stable/c/c76cb8f4bdf26d04cfa5485a93ce297dba5e6a80","https://git.kernel.org/stable/c/dce59b5443700fbd0d2433ec6e4d4cf063448844","https://git.kernel.org/stable/c/00cbce5cbf88459cd1aa1d60d0f1df15477df127","https://git.kernel.org/stable/c/7e6010f79b58f45b204cf18aa58f4b73c3f30adc","https://git.kernel.org/stable/c/9c4c6512d7330b743c4ffd18bd999a86ca26db0d","https://git.kernel.org/stable/c/a2bd706ab63509793b5cd5065e685b7ef5cba678","https://git.kernel.org/stable/c/c76cb8f4bdf26d04cfa5485a93ce297dba5e6a80","https://git.kernel.org/stable/c/dce59b5443700fbd0d2433ec6e4d4cf063448844"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52509
|
High |
fixed |
- 5.4.259
- 5.10.199
- 5.15.136
- 6.1.59
- 6.5.8
|
In the Linux kernel, the following vulnerability has been resolved:
ravb: Fix use-after-free issue in ravb_tx_timeout_work()
The ravb_stop() should call cancel_work_sync(). Otherwise,
ravb_tx_timeout_work() is possible to use the freed priv after
ravb_remove() was called like below:
CPU0 CPU1
ravb_tx_timeout()
ravb_remove()
unregister_netdev()
free_netdev(ndev)
// free priv
ravb_tx_timeout_work()
// use priv
unregister_netdev() will call .ndo_stop() so that ravb_stop() is
called. And, after phy_stop() is called, netif_carrier_off()
is also called. So that .ndo_tx_timeout() will not be called
after phy_stop(). |
["https://git.kernel.org/stable/c/105abd68ad8f781985113aee2e92e0702b133705","https://git.kernel.org/stable/c/3971442870713de527684398416970cf025b4f89","https://git.kernel.org/stable/c/616761cf9df9af838c0a1a1232a69322a9eb67e6","https://git.kernel.org/stable/c/65d34cfd4e347054eb4193bc95d9da7eaa72dee5","https://git.kernel.org/stable/c/6f6fa8061f756aedb93af12a8a5d3cf659127965","https://git.kernel.org/stable/c/db9aafa19547833240f58c2998aed7baf414dc82","https://git.kernel.org/stable/c/105abd68ad8f781985113aee2e92e0702b133705","https://git.kernel.org/stable/c/3971442870713de527684398416970cf025b4f89","https://git.kernel.org/stable/c/616761cf9df9af838c0a1a1232a69322a9eb67e6","https://git.kernel.org/stable/c/65d34cfd4e347054eb4193bc95d9da7eaa72dee5","https://git.kernel.org/stable/c/6f6fa8061f756aedb93af12a8a5d3cf659127965","https://git.kernel.org/stable/c/db9aafa19547833240f58c2998aed7baf414dc82"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26782
|
High |
fixed |
- 5.10.212
- 5.15.151
- 6.1.81
- 6.6.21
- 6.7.9
|
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix double-free on socket dismantle
when MPTCP server accepts an incoming connection, it clones its listener
socket. However, the pointer to 'inet_opt' for the new socket has the same
value as the original one: as a consequence, on program exit it's possible
to observe the following splat:
BUG: KASAN: double-free in inet_sock_destruct+0x54f/0x8b0
Free of addr ffff888485950880 by task swapper/25/0
CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609
Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0 07/26/2013
Call Trace:
<IRQ>
dump_stack_lvl+0x32/0x50
print_report+0xca/0x620
kasan_report_invalid_free+0x64/0x90
__kasan_slab_free+0x1aa/0x1f0
kfree+0xed/0x2e0
inet_sock_destruct+0x54f/0x8b0
__sk_destruct+0x48/0x5b0
rcu_do_batch+0x34e/0xd90
rcu_core+0x559/0xac0
__do_softirq+0x183/0x5a4
irq_exit_rcu+0x12d/0x170
sysvec_apic_timer_interrupt+0x6b/0x80
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x16/0x20
RIP: 0010:cpuidle_enter_state+0x175/0x300
Code: 30 00 0f 84 1f 01 00 00 83 e8 01 83 f8 ff 75 e5 48 83 c4 18 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc fb 45 85 ed <0f> 89 60 ff ff ff 48 c1 e5 06 48 c7 43 18 00 00 00 00 48 83 44 2b
RSP: 0018:ffff888481cf7d90 EFLAGS: 00000202
RAX: 0000000000000000 RBX: ffff88887facddc8 RCX: 0000000000000000
RDX: 1ffff1110ff588b1 RSI: 0000000000000019 RDI: ffff88887fac4588
RBP: 0000000000000004 R08: 0000000000000002 R09: 0000000000043080
R10: 0009b02ea273363f R11: ffff88887fabf42b R12: ffffffff932592e0
R13: 0000000000000004 R14: 0000000000000000 R15: 00000022c880ec80
cpuidle_enter+0x4a/0xa0
do_idle+0x310/0x410
cpu_startup_entry+0x51/0x60
start_secondary+0x211/0x270
secondary_startup_64_no_verify+0x184/0x18b
</TASK>
Allocated by task 6853:
kasan_save_stack+0x1c/0x40
kasan_save_track+0x10/0x30
__kasan_kmalloc+0xa6/0xb0
__kmalloc+0x1eb/0x450
cipso_v4_sock_setattr+0x96/0x360
netlbl_sock_setattr+0x132/0x1f0
selinux_netlbl_socket_post_create+0x6c/0x110
selinux_socket_post_create+0x37b/0x7f0
security_socket_post_create+0x63/0xb0
__sock_create+0x305/0x450
__sys_socket_create.part.23+0xbd/0x130
__sys_socket+0x37/0xb0
__x64_sys_socket+0x6f/0xb0
do_syscall_64+0x83/0x160
entry_SYSCALL_64_after_hwframe+0x6e/0x76
Freed by task 6858:
kasan_save_stack+0x1c/0x40
kasan_save_track+0x10/0x30
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x12c/0x1f0
kfree+0xed/0x2e0
inet_sock_destruct+0x54f/0x8b0
__sk_destruct+0x48/0x5b0
subflow_ulp_release+0x1f0/0x250
tcp_cleanup_ulp+0x6e/0x110
tcp_v4_destroy_sock+0x5a/0x3a0
inet_csk_destroy_sock+0x135/0x390
tcp_fin+0x416/0x5c0
tcp_data_queue+0x1bc8/0x4310
tcp_rcv_state_process+0x15a3/0x47b0
tcp_v4_do_rcv+0x2c1/0x990
tcp_v4_rcv+0x41fb/0x5ed0
ip_protocol_deliver_rcu+0x6d/0x9f0
ip_local_deliver_finish+0x278/0x360
ip_local_deliver+0x182/0x2c0
ip_rcv+0xb5/0x1c0
__netif_receive_skb_one_core+0x16e/0x1b0
process_backlog+0x1e3/0x650
__napi_poll+0xa6/0x500
net_rx_action+0x740/0xbb0
__do_softirq+0x183/0x5a4
The buggy address belongs to the object at ffff888485950880
which belongs to the cache kmalloc-64 of size 64
The buggy address is located 0 bytes inside of
64-byte region [ffff888485950880, ffff8884859508c0)
The buggy address belongs to the physical page:
page:0000000056d1e95e refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888485950700 pfn:0x485950
flags: 0x57ffffc0000800(slab|node=1|zone=2|lastcpupid=0x1fffff)
page_type: 0xffffffff()
raw: 0057ffffc0000800 ffff88810004c640 ffffea00121b8ac0 dead000000000006
raw: ffff888485950700 0000000000200019 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888485950780: fa fb fb
---truncated--- |
["https://git.kernel.org/stable/c/10048689def7e40a4405acda16fdc6477d4ecc5c","https://git.kernel.org/stable/c/4a4eeb6912538c2d0b158e8d11b62d96c1dada4e","https://git.kernel.org/stable/c/85933e80d077c9ae2227226beb86c22f464059cc","https://git.kernel.org/stable/c/ce0809ada38dca8d6d41bb57ab40494855c30582","https://git.kernel.org/stable/c/d93fd40c62397326046902a2c5cb75af50882a85","https://git.kernel.org/stable/c/f74362a004225df935863dea6eb7d82daaa5b16e","https://git.kernel.org/stable/c/10048689def7e40a4405acda16fdc6477d4ecc5c","https://git.kernel.org/stable/c/4a4eeb6912538c2d0b158e8d11b62d96c1dada4e","https://git.kernel.org/stable/c/85933e80d077c9ae2227226beb86c22f464059cc","https://git.kernel.org/stable/c/ce0809ada38dca8d6d41bb57ab40494855c30582","https://git.kernel.org/stable/c/d93fd40c62397326046902a2c5cb75af50882a85","https://git.kernel.org/stable/c/f74362a004225df935863dea6eb7d82daaa5b16e","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52482
|
High |
fixed |
- 5.10.215
- 5.15.134
- 6.1.56
- 6.5.6
|
In the Linux kernel, the following vulnerability has been resolved:
x86/srso: Add SRSO mitigation for Hygon processors
Add mitigation for the speculative return stack overflow vulnerability
which exists on Hygon processors too. |
["https://git.kernel.org/stable/c/6ce2f297a7168274547d0b5aea6c7c16268b8a96","https://git.kernel.org/stable/c/a5ef7d68cea1344cf524f04981c2b3f80bedbb0d","https://git.kernel.org/stable/c/cf43b304b6952b549d58feabc342807b334f03d4","https://git.kernel.org/stable/c/e7ea043bc3f19473561c08565047b3f1671bf35d","https://git.kernel.org/stable/c/f090a8b4d2e3ec6f318d6fdab243a2edc5a8cc37","https://git.kernel.org/stable/c/6ce2f297a7168274547d0b5aea6c7c16268b8a96","https://git.kernel.org/stable/c/a5ef7d68cea1344cf524f04981c2b3f80bedbb0d","https://git.kernel.org/stable/c/cf43b304b6952b549d58feabc342807b334f03d4","https://git.kernel.org/stable/c/e7ea043bc3f19473561c08565047b3f1671bf35d","https://git.kernel.org/stable/c/f090a8b4d2e3ec6f318d6fdab243a2edc5a8cc37","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52614
|
High |
fixed |
- 5.10.216
- 5.15.149
- 6.1.76
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
PM / devfreq: Fix buffer overflow in trans_stat_show
Fix buffer overflow in trans_stat_show().
Convert simple snprintf to the more secure scnprintf with size of
PAGE_SIZE.
Add condition checking if we are exceeding PAGE_SIZE and exit early from
loop. Also add at the end a warning that we exceeded PAGE_SIZE and that
stats is disabled.
Return -EFBIG in the case where we don't have enough space to write the
full transition table.
Also document in the ABI that this function can return -EFBIG error. |
["https://git.kernel.org/stable/c/087de000e4f8c878c81d9dd3725f00a1d292980c","https://git.kernel.org/stable/c/08e23d05fa6dc4fc13da0ccf09defdd4bbc92ff4","https://git.kernel.org/stable/c/796d3fad8c35ee9df9027899fb90ceaeb41b958f","https://git.kernel.org/stable/c/8a7729cda2dd276d7a3994638038fb89035b6f2c","https://git.kernel.org/stable/c/a979f56aa4b93579cf0e4265ae04d7e9300fd3e8","https://git.kernel.org/stable/c/eaef4650fa2050147ca25fd7ee43bc0082e03c87","https://git.kernel.org/stable/c/087de000e4f8c878c81d9dd3725f00a1d292980c","https://git.kernel.org/stable/c/08e23d05fa6dc4fc13da0ccf09defdd4bbc92ff4","https://git.kernel.org/stable/c/796d3fad8c35ee9df9027899fb90ceaeb41b958f","https://git.kernel.org/stable/c/8a7729cda2dd276d7a3994638038fb89035b6f2c","https://git.kernel.org/stable/c/a979f56aa4b93579cf0e4265ae04d7e9300fd3e8","https://git.kernel.org/stable/c/eaef4650fa2050147ca25fd7ee43bc0082e03c87","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52452
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix accesses to uninit stack slots
Privileged programs are supposed to be able to read uninitialized stack
memory (ever since 6715df8d5) but, before this patch, these accesses
were permitted inconsistently. In particular, accesses were permitted
above state->allocated_stack, but not below it. In other words, if the
stack was already "large enough", the access was permitted, but
otherwise the access was rejected instead of being allowed to "grow the
stack". This undesired rejection was happening in two places:
- in check_stack_slot_within_bounds()
- in check_stack_range_initialized()
This patch arranges for these accesses to be permitted. A bunch of tests
that were relying on the old rejection had to change; all of them were
changed to add also run unprivileged, in which case the old behavior
persists. One tests couldn't be updated - global_func16 - because it
can't run unprivileged for other reasons.
This patch also fixes the tracking of the stack size for variable-offset
reads. This second fix is bundled in the same commit as the first one
because they're inter-related. Before this patch, writes to the stack
using registers containing a variable offset (as opposed to registers
with fixed, known values) were not properly contributing to the
function's needed stack size. As a result, it was possible for a program
to verify, but then to attempt to read out-of-bounds data at runtime
because a too small stack had been allocated for it.
Each function tracks the size of the stack it needs in
bpf_subprog_info.stack_depth, which is maintained by
update_stack_depth(). For regular memory accesses, check_mem_access()
was calling update_state_depth() but it was passing in only the fixed
part of the offset register, ignoring the variable offset. This was
incorrect; the minimum possible value of that register should be used
instead.
This tracking is now fixed by centralizing the tracking of stack size in
grow_stack_state(), and by lifting the calls to grow_stack_state() to
check_stack_access_within_bounds() as suggested by Andrii. The code is
now simpler and more convincingly tracks the correct maximum stack size.
check_stack_range_initialized() can now rely on enough stack having been
allocated for the access; this helps with the fix for the first issue.
A few tests were changed to also check the stack depth computation. The
one that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv. |
["https://git.kernel.org/stable/c/0954982db8283016bf38e9db2da5adf47a102e19","https://git.kernel.org/stable/c/6b4a64bafd107e521c01eec3453ce94a3fb38529","https://git.kernel.org/stable/c/fbcf372c8eda2290470268e0afb5ab5d5f5d5fde","https://git.kernel.org/stable/c/0954982db8283016bf38e9db2da5adf47a102e19","https://git.kernel.org/stable/c/6b4a64bafd107e521c01eec3453ce94a3fb38529","https://git.kernel.org/stable/c/fbcf372c8eda2290470268e0afb5ab5d5f5d5fde"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52591
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
reiserfs: Avoid touching renamed directory if parent does not change
The VFS will not be locking moved directory if its parent does not
change. Change reiserfs rename code to avoid touching renamed directory
if its parent does not change as without locking that can corrupt the
filesystem. |
["https://git.kernel.org/stable/c/17e1361cb91dc1325834da95d2ab532959d2debc","https://git.kernel.org/stable/c/49db9b1b86a82448dfaf3fcfefcf678dee56c8ed","https://git.kernel.org/stable/c/c04c162f82ac403917780eb6d1654694455d4e7c","https://git.kernel.org/stable/c/17e1361cb91dc1325834da95d2ab532959d2debc","https://git.kernel.org/stable/c/49db9b1b86a82448dfaf3fcfefcf678dee56c8ed","https://git.kernel.org/stable/c/c04c162f82ac403917780eb6d1654694455d4e7c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-26242
|
High |
|
N/A
|
afu_mmio_region_get_by_offset in drivers/fpga/dfl-afu-region.c in the Linux kernel through 6.1.12 has an integer overflow. |
["https://bugzilla.suse.com/show_bug.cgi?id=1208518","https://patchwork.kernel.org/project/linux-fpga/patch/20230206054326.89323-1-k1rh4.lee%40gmail.com","https://security.netapp.com/advisory/ntap-20230406-0002/","https://bugzilla.suse.com/show_bug.cgi?id=1208518","https://patchwork.kernel.org/project/linux-fpga/patch/20230206054326.89323-1-k1rh4.lee%40gmail.com","https://security.netapp.com/advisory/ntap-20230406-0002/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52441
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix out of bounds in init_smb2_rsp_hdr()
If client send smb2 negotiate request and then send smb1 negotiate
request, init_smb2_rsp_hdr is called for smb1 negotiate request since
need_neg is set to false. This patch ignore smb1 packets after ->need_neg
is set to false. |
["https://git.kernel.org/stable/c/330d900620dfc9893011d725b3620cd2ee0bc2bc","https://git.kernel.org/stable/c/536bb492d39bb6c080c92f31e8a55fe9934f452b","https://git.kernel.org/stable/c/5c0df9d30c289d6b9d7d44e2a450de2f8e3cf40b","https://git.kernel.org/stable/c/aa669ef229ae8dd779da9caa24e254964545895f","https://git.kernel.org/stable/c/330d900620dfc9893011d725b3620cd2ee0bc2bc","https://git.kernel.org/stable/c/536bb492d39bb6c080c92f31e8a55fe9934f452b","https://git.kernel.org/stable/c/5c0df9d30c289d6b9d7d44e2a450de2f8e3cf40b","https://git.kernel.org/stable/c/aa669ef229ae8dd779da9caa24e254964545895f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4611
|
Medium |
fixed |
|
A use-after-free flaw was found in mm/mempolicy.c in the memory management subsystem in the Linux Kernel. This issue is caused by a race between mbind() and VMA-locked page fault, and may allow a local attacker to crash the system or lead to a kernel information leak. |
["https://access.redhat.com/security/cve/CVE-2023-4611","https://bugzilla.redhat.com/show_bug.cgi?id=2227244","https://www.spinics.net/lists/stable-commits/msg310136.html","https://access.redhat.com/security/cve/CVE-2023-4611","https://bugzilla.redhat.com/show_bug.cgi?id=2227244","https://www.spinics.net/lists/stable-commits/msg310136.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52597
|
Medium |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: fix setting of fpc register
kvm_arch_vcpu_ioctl_set_fpu() allows to set the floating point control
(fpc) register of a guest cpu. The new value is tested for validity by
temporarily loading it into the fpc register.
This may lead to corruption of the fpc register of the host process:
if an interrupt happens while the value is temporarily loaded into the fpc
register, and within interrupt context floating point or vector registers
are used, the current fp/vx registers are saved with save_fpu_regs()
assuming they belong to user space and will be loaded into fp/vx registers
when returning to user space.
test_fp_ctl() restores the original user space / host process fpc register
value, however it will be discarded, when returning to user space.
In result the host process will incorrectly continue to run with the value
that was supposed to be used for a guest cpu.
Fix this by simply removing the test. There is another test right before
the SIE context is entered which will handles invalid values.
This results in a change of behaviour: invalid values will now be accepted
instead of that the ioctl fails with -EINVAL. This seems to be acceptable,
given that this interface is most likely not used anymore, and this is in
addition the same behaviour implemented with the memory mapped interface
(replace invalid values with zero) - see sync_regs() in kvm-s390.c. |
["https://git.kernel.org/stable/c/0671f42a9c1084db10d68ac347d08dbf6689ecb3","https://git.kernel.org/stable/c/150a3a3871490e8c454ffbac2e60abeafcecff99","https://git.kernel.org/stable/c/2823db0010c400e4b2b12d02aa5d0d3ecb15d7c7","https://git.kernel.org/stable/c/3a04410b0bc7e056e0843ac598825dd359246d18","https://git.kernel.org/stable/c/5e63c9ae8055109d805aacdaf2a4fe2c3b371ba1","https://git.kernel.org/stable/c/732a3bea7aba5b15026ea42d14953c3425cc7dc2","https://git.kernel.org/stable/c/b988b1bb0053c0dcd26187d29ef07566a565cf55","https://git.kernel.org/stable/c/c87d7d910775a025e230fd6359b60627e392460f","https://git.kernel.org/stable/c/0671f42a9c1084db10d68ac347d08dbf6689ecb3","https://git.kernel.org/stable/c/150a3a3871490e8c454ffbac2e60abeafcecff99","https://git.kernel.org/stable/c/2823db0010c400e4b2b12d02aa5d0d3ecb15d7c7","https://git.kernel.org/stable/c/3a04410b0bc7e056e0843ac598825dd359246d18","https://git.kernel.org/stable/c/5e63c9ae8055109d805aacdaf2a4fe2c3b371ba1","https://git.kernel.org/stable/c/732a3bea7aba5b15026ea42d14953c3425cc7dc2","https://git.kernel.org/stable/c/b988b1bb0053c0dcd26187d29ef07566a565cf55","https://git.kernel.org/stable/c/c87d7d910775a025e230fd6359b60627e392460f","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-1312
|
Medium |
fixed |
|
A use-after-free flaw was found in the Linux kernel's Memory Management subsystem when a user wins two races at the same time with a fail in the mas_prev_slot function. This issue could allow a local user to crash the system. |
["https://access.redhat.com/security/cve/CVE-2024-1312","https://bugzilla.redhat.com/show_bug.cgi?id=2225569","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/mm/memory.c?h=v6.8-rc3\u0026id=657b5146955eba331e01b9a6ae89ce2e716ba306","https://access.redhat.com/security/cve/CVE-2024-1312","https://bugzilla.redhat.com/show_bug.cgi?id=2225569","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/mm/memory.c?h=v6.8-rc3\u0026id=657b5146955eba331e01b9a6ae89ce2e716ba306"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-28356
|
Medium |
fixed |
|
In the Linux kernel before 5.17.1, a refcount leak bug was found in net/llc/af_llc.c. |
["http://www.openwall.com/lists/oss-security/2022/04/06/1","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.1","https://github.com/torvalds/linux/commit/764f4eb6846f5475f1244767d24d25dd86528a4a","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://security.netapp.com/advisory/ntap-20220506-0006/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173","http://www.openwall.com/lists/oss-security/2022/04/06/1","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.1","https://github.com/torvalds/linux/commit/764f4eb6846f5475f1244767d24d25dd86528a4a","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://security.netapp.com/advisory/ntap-20220506-0006/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-40133
|
Medium |
fixed |
|
A use-after-free(UAF) vulnerability was found in function 'vmw_execbuf_tie_context' in drivers/gpu/vmxgfx/vmxgfx_execbuf.c in Linux kernel's vmwgfx driver with device file '/dev/dri/renderD128 (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS). |
["https://bugzilla.openanolis.cn/show_bug.cgi?id=2075","https://bugzilla.openanolis.cn/show_bug.cgi?id=2075"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-47233
|
Medium |
|
N/A
|
The brcm80211 component in the Linux kernel through 6.5.10 has a brcmf_cfg80211_detach use-after-free in the device unplugging (disconnect the USB by hotplug) code. For physically proximate attackers with local access, this "could be exploited in a real world scenario." This is related to brcmf_cfg80211_escan_timeout_worker in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c. |
["https://bugzilla.suse.com/show_bug.cgi?id=1216702","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0f7352557a35ab7888bc7831411ec8a3cbe20d78","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lore.kernel.org/all/20231104054709.716585-1-zyytlz.wz%40163.com/","https://marc.info/?l=linux-kernel\u0026m=169907678011243\u0026w=2","https://bugzilla.suse.com/show_bug.cgi?id=1216702","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0f7352557a35ab7888bc7831411ec8a3cbe20d78","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lore.kernel.org/all/20231104054709.716585-1-zyytlz.wz%40163.com/","https://marc.info/?l=linux-kernel\u0026m=169907678011243\u0026w=2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21943
|
Medium |
fixed |
- 5.10.235
- 5.15.179
- 6.1.131
- 6.6.83
- 6.12.19
- 6.13.7
|
In the Linux kernel, the following vulnerability has been resolved:
gpio: aggregator: protect driver attr handlers against module unload
Both new_device_store and delete_device_store touch module global
resources (e.g. gpio_aggregator_lock). To prevent race conditions with
module unload, a reference needs to be held.
Add try_module_get() in these handlers.
For new_device_store, this eliminates what appears to be the most dangerous
scenario: if an id is allocated from gpio_aggregator_idr but
platform_device_register has not yet been called or completed, a concurrent
module unload could fail to unregister/delete the device, leaving behind a
dangling platform device/GPIO forwarder. This can result in various issues.
The following simple reproducer demonstrates these problems:
#!/bin/bash
while :; do
# note: whether 'gpiochip0 0' exists or not does not matter.
echo 'gpiochip0 0' > /sys/bus/platform/drivers/gpio-aggregator/new_device
done &
while :; do
modprobe gpio-aggregator
modprobe -r gpio-aggregator
done &
wait
Starting with the following warning, several kinds of warnings will appear
and the system may become unstable:
------------[ cut here ]------------
list_del corruption, ffff888103e2e980->next is LIST_POISON1 (dead000000000100)
WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120
[...]
RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120
[...]
Call Trace:
<TASK>
? __list_del_entry_valid_or_report+0xa3/0x120
? __warn.cold+0x93/0xf2
? __list_del_entry_valid_or_report+0xa3/0x120
? report_bug+0xe6/0x170
? __irq_work_queue_local+0x39/0xe0
? handle_bug+0x58/0x90
? exc_invalid_op+0x13/0x60
? asm_exc_invalid_op+0x16/0x20
? __list_del_entry_valid_or_report+0xa3/0x120
gpiod_remove_lookup_table+0x22/0x60
new_device_store+0x315/0x350 [gpio_aggregator]
kernfs_fop_write_iter+0x137/0x1f0
vfs_write+0x262/0x430
ksys_write+0x60/0xd0
do_syscall_64+0x6c/0x180
entry_SYSCALL_64_after_hwframe+0x76/0x7e
[...]
</TASK>
---[ end trace 0000000000000000 ]--- |
["https://git.kernel.org/stable/c/12f65d1203507f7db3ba59930fe29a3b8eee9945","https://git.kernel.org/stable/c/56281a76b805b5ac61feb5d580139695a22f87f0","https://git.kernel.org/stable/c/807789018186cf508ceb3a1f8f02935cd195717b","https://git.kernel.org/stable/c/8fb07fb1bba91d45846ed8605c3097fe67a7d54c","https://git.kernel.org/stable/c/9334c88fc2fbc6836b307d269fcc1744c69701c0","https://git.kernel.org/stable/c/d99dc8f7ea01ee1b21306e0eda8eb18a4af80db6","https://git.kernel.org/stable/c/fd6aa1f8cbe0979eb66ac32ebc231bf0b10a2117"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-39188
|
Medium |
fixed |
|
An issue was discovered in include/asm-generic/tlb.h in the Linux kernel before 5.19. Because of a race condition (unmap_mapping_range versus munmap), a device driver can free a page while it still has stale TLB entries. This only occurs in situations with VM_PFNMAP VMAs. |
["https://bugs.chromium.org/p/project-zero/issues/detail?id=2329","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b67fbebd4cf980aecbcc750e1462128bffe8ae15","https://github.com/torvalds/linux/commit/b67fbebd4cf980aecbcc750e1462128bffe8ae15","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/stable/CAG48ez3SEqOPcPCYGHVZv4iqEApujD5VtM3Re-tCKLDEFdEdbg%40mail.gmail.com/","https://www.debian.org/security/2022/dsa-5257","https://bugs.chromium.org/p/project-zero/issues/detail?id=2329","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b67fbebd4cf980aecbcc750e1462128bffe8ae15","https://github.com/torvalds/linux/commit/b67fbebd4cf980aecbcc750e1462128bffe8ae15","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/stable/CAG48ez3SEqOPcPCYGHVZv4iqEApujD5VtM3Re-tCKLDEFdEdbg%40mail.gmail.com/","https://www.debian.org/security/2022/dsa-5257"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21947
|
Medium |
fixed |
- 6.1.131
- 6.6.83
- 6.12.19
- 6.13.7
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix type confusion via race condition when using ipc_msg_send_request
req->handle is allocated using ksmbd_acquire_id(&ipc_ida), based on
ida_alloc. req->handle from ksmbd_ipc_login_request and
FSCTL_PIPE_TRANSCEIVE ioctl can be same and it could lead to type confusion
between messages, resulting in access to unexpected parts of memory after
an incorrect delivery. ksmbd check type of ipc response but missing add
continue to check next ipc reponse. |
["https://git.kernel.org/stable/c/1e8833c03a38e1d5d5df6484e3f670a2fd38fb76","https://git.kernel.org/stable/c/3cb2b2e41541fe6f9cc55ca22d4c0bd260498aea","https://git.kernel.org/stable/c/6321bbda4244b93802d61cfe0887883aae322f4b","https://git.kernel.org/stable/c/76861630b29e51373e73e7b00ad0d467b6941162","https://git.kernel.org/stable/c/e2ff19f0b7a30e03516e6eb73b948e27a55bc9d2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4394
|
Medium |
fixed |
|
A use-after-free flaw was found in btrfs_get_dev_args_from_path in fs/btrfs/volumes.c in btrfs file-system in the Linux Kernel. This flaw allows a local attacker with special privileges to cause a system crash or leak internal kernel information |
["https://access.redhat.com/security/cve/CVE-2023-4394","https://bugzilla.redhat.com/show_bug.cgi?id=2219263","https://patchwork.kernel.org/project/linux-btrfs/patch/20220815151606.3479183-1-r33s3n6@gmail.com/","https://access.redhat.com/security/cve/CVE-2023-4394","https://bugzilla.redhat.com/show_bug.cgi?id=2219263","https://patchwork.kernel.org/project/linux-btrfs/patch/20220815151606.3479183-1-r33s3n6@gmail.com/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-23039
|
Medium |
fixed |
|
An issue was discovered in the Linux kernel through 6.2.0-rc2. drivers/tty/vcc.c has a race condition and resultant use-after-free if a physically proximate attacker removes a VCC device while calling open(), aka a race condition between vcc_open() and vcc_remove(). |
["https://lkml.org/lkml/2023/1/1/169","https://lkml.org/lkml/2023/1/1/169"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48635
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
fsdax: Fix infinite loop in dax_iomap_rw()
I got an infinite loop and a WARNING report when executing a tail command
in virtiofs.
WARNING: CPU: 10 PID: 964 at fs/iomap/iter.c:34 iomap_iter+0x3a2/0x3d0
Modules linked in:
CPU: 10 PID: 964 Comm: tail Not tainted 5.19.0-rc7
Call Trace:
<TASK>
dax_iomap_rw+0xea/0x620
? __this_cpu_preempt_check+0x13/0x20
fuse_dax_read_iter+0x47/0x80
fuse_file_read_iter+0xae/0xd0
new_sync_read+0xfe/0x180
? 0xffffffff81000000
vfs_read+0x14d/0x1a0
ksys_read+0x6d/0xf0
__x64_sys_read+0x1a/0x20
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
The tail command will call read() with a count of 0. In this case,
iomap_iter() will report this WARNING, and always return 1 which casuing
the infinite loop in dax_iomap_rw().
Fixing by checking count whether is 0 in dax_iomap_rw(). |
["https://git.kernel.org/stable/c/17d9c15c9b9e7fb285f7ac5367dfb5f00ff575e3","https://git.kernel.org/stable/c/60644dffac87b1bb47bdb393aa29d5f2ffcf41a0","https://git.kernel.org/stable/c/929ef155e1da41c06f4d8ca86ae12b851a83a744","https://git.kernel.org/stable/c/17d9c15c9b9e7fb285f7ac5367dfb5f00ff575e3","https://git.kernel.org/stable/c/60644dffac87b1bb47bdb393aa29d5f2ffcf41a0","https://git.kernel.org/stable/c/929ef155e1da41c06f4d8ca86ae12b851a83a744"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26763
|
High |
fixed |
- 4.19.308
- 5.4.270
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
dm-crypt: don't modify the data when using authenticated encryption
It was said that authenticated encryption could produce invalid tag when
the data that is being encrypted is modified [1]. So, fix this problem by
copying the data into the clone bio first and then encrypt them inside the
clone bio.
This may reduce performance, but it is needed to prevent the user from
corrupting the device by writing data with O_DIRECT and modifying them at
the same time.
[1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/ |
["https://git.kernel.org/stable/c/0dccbb93538fe89a86c6de31d4b1c8c560848eaa","https://git.kernel.org/stable/c/1a4371db68a31076afbe56ecce34fbbe6c80c529","https://git.kernel.org/stable/c/3c652f6fa1e1f9f02c3fbf359d260ad153ec5f90","https://git.kernel.org/stable/c/43a202bd552976497474ae144942e32cc5f34d7e","https://git.kernel.org/stable/c/50c70240097ce41fe6bce6478b80478281e4d0f7","https://git.kernel.org/stable/c/64ba01a365980755732972523600a961c4266b75","https://git.kernel.org/stable/c/d9e3763a505e50ba3bd22846f2a8db99429fb857","https://git.kernel.org/stable/c/e08c2a8d27e989f0f5b0888792643027d7e691e6","https://git.kernel.org/stable/c/0dccbb93538fe89a86c6de31d4b1c8c560848eaa","https://git.kernel.org/stable/c/1a4371db68a31076afbe56ecce34fbbe6c80c529","https://git.kernel.org/stable/c/3c652f6fa1e1f9f02c3fbf359d260ad153ec5f90","https://git.kernel.org/stable/c/43a202bd552976497474ae144942e32cc5f34d7e","https://git.kernel.org/stable/c/50c70240097ce41fe6bce6478b80478281e4d0f7","https://git.kernel.org/stable/c/64ba01a365980755732972523600a961c4266b75","https://git.kernel.org/stable/c/d9e3763a505e50ba3bd22846f2a8db99429fb857","https://git.kernel.org/stable/c/e08c2a8d27e989f0f5b0888792643027d7e691e6","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-23003
|
Medium |
fixed |
|
In the Linux kernel before 5.16, tools/perf/util/expr.c lacks a check for the hashmap__new return value. |
["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16","https://github.com/torvalds/linux/commit/0a515a06c5ebfa46fee3ac519e418f801e718da4","https://security.netapp.com/advisory/ntap-20230331-0003/","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16","https://github.com/torvalds/linux/commit/0a515a06c5ebfa46fee3ac519e418f801e718da4","https://security.netapp.com/advisory/ntap-20230331-0003/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52467
|
Medium |
fixed |
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
mfd: syscon: Fix null pointer dereference in of_syscon_register()
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. |
["https://git.kernel.org/stable/c/3ef1130deee98997275904d9bfc37af75e1e906c","https://git.kernel.org/stable/c/41673c66b3d0c09915698fec5c13b24336f18dd1","https://git.kernel.org/stable/c/527e8c5f3d00299822612c495d5adf1f8f43c001","https://git.kernel.org/stable/c/7f2c410ac470959b88e03dadd94b7a0b71df7973","https://git.kernel.org/stable/c/927626a2073887ee30ba00633260d4d203f8e875","https://git.kernel.org/stable/c/c3e3a2144bf50877551138ffce9f7aa6ddfe385b","https://git.kernel.org/stable/c/3ef1130deee98997275904d9bfc37af75e1e906c","https://git.kernel.org/stable/c/41673c66b3d0c09915698fec5c13b24336f18dd1","https://git.kernel.org/stable/c/527e8c5f3d00299822612c495d5adf1f8f43c001","https://git.kernel.org/stable/c/7f2c410ac470959b88e03dadd94b7a0b71df7973","https://git.kernel.org/stable/c/927626a2073887ee30ba00633260d4d203f8e875","https://git.kernel.org/stable/c/c3e3a2144bf50877551138ffce9f7aa6ddfe385b","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1198
|
Medium |
fixed |
|
A use-after-free vulnerabilitity was discovered in drivers/net/hamradio/6pack.c of linux that allows an attacker to crash linux kernel by simulating ax25 device using 6pack driver from user space. |
["https://access.redhat.com/security/cve/CVE-2022-1198","https://bugzilla.redhat.com/show_bug.cgi?id=2070689","https://github.com/torvalds/linux/commit/efe4186e6a1b54bf38b9e05450d43b0da1fd7739","https://www.openwall.com/lists/oss-security/2022/04/02/3","https://access.redhat.com/security/cve/CVE-2022-1198","https://bugzilla.redhat.com/show_bug.cgi?id=2070689","https://github.com/torvalds/linux/commit/efe4186e6a1b54bf38b9e05450d43b0da1fd7739","https://www.openwall.com/lists/oss-security/2022/04/02/3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26811
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate payload size in ipc response
If installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipc
response to ksmbd kernel server. ksmbd should validate payload size of
ipc response from ksmbd.mountd to avoid memory overrun or
slab-out-of-bounds. This patch validate 3 ipc response that has payload. |
["https://git.kernel.org/stable/c/51a6c2af9d20203ddeeaf73314ba8854b38d01bd","https://git.kernel.org/stable/c/76af689a45aa44714b46d1a7de4ffdf851ded896","https://git.kernel.org/stable/c/88b7f1143b15b29cccb8392b4f38e75b7bb3e300","https://git.kernel.org/stable/c/a637fabac554270a851033f5ab402ecb90bc479c","https://git.kernel.org/stable/c/a677ebd8ca2f2632ccdecbad7b87641274e15aac","https://git.kernel.org/stable/c/51a6c2af9d20203ddeeaf73314ba8854b38d01bd","https://git.kernel.org/stable/c/76af689a45aa44714b46d1a7de4ffdf851ded896","https://git.kernel.org/stable/c/88b7f1143b15b29cccb8392b4f38e75b7bb3e300","https://git.kernel.org/stable/c/a637fabac554270a851033f5ab402ecb90bc479c","https://git.kernel.org/stable/c/a677ebd8ca2f2632ccdecbad7b87641274e15aac"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-4135
|
Medium |
fixed |
|
A memory leak vulnerability was found in the Linux kernel's eBPF for the Simulated networking device driver in the way user uses BPF for the device such that function nsim_map_alloc_elem being called. A local user could use this flaw to get unauthorized access to some data. |
["https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=481221775d53","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=481221775d53"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-23851
|
Medium |
|
N/A
|
copy_params in drivers/md/dm-ioctl.c in the Linux kernel through 6.7.1 can attempt to allocate more than INT_MAX bytes, and crash, because of a missing param_kernel->data_size check. This is related to ctl_ioctl. |
["https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/EZOU3745CWCDZ7EMKMXB2OEEIB5Q3IWM/","https://www.spinics.net/lists/dm-devel/msg56574.html","https://www.spinics.net/lists/dm-devel/msg56694.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/EZOU3745CWCDZ7EMKMXB2OEEIB5Q3IWM/","https://www.spinics.net/lists/dm-devel/msg56574.html","https://www.spinics.net/lists/dm-devel/msg56694.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-4218
|
Medium |
|
N/A
|
A flaw was found in the Linux kernel’s implementation of reading the SVC RDMA counters. Reading the counter sysctl panics the system. This flaw allows a local attacker with local access to cause a denial of service while the system reboots. The issue is specific to CentOS/RHEL. |
["https://access.redhat.com/security/cve/CVE-2021-4218","https://bugs.centos.org/view.php?id=18395","https://bugzilla.redhat.com/show_bug.cgi?id=2048359","https://access.redhat.com/security/cve/CVE-2021-4218","https://bugs.centos.org/view.php?id=18395","https://bugzilla.redhat.com/show_bug.cgi?id=2048359"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52499
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
powerpc/47x: Fix 47x syscall return crash
Eddie reported that newer kernels were crashing during boot on his 476
FSP2 system:
kernel tried to execute user page (b7ee2000) - exploit attempt? (uid: 0)
BUG: Unable to handle kernel instruction fetch
Faulting instruction address: 0xb7ee2000
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K FSP-2
Modules linked in:
CPU: 0 PID: 61 Comm: mount Not tainted 6.1.55-d23900f.ppcnf-fsp2 #1
Hardware name: ibm,fsp2 476fpe 0x7ff520c0 FSP-2
NIP: b7ee2000 LR: 8c008000 CTR: 00000000
REGS: bffebd83 TRAP: 0400 Not tainted (6.1.55-d23900f.ppcnf-fs p2)
MSR: 00000030 <IR,DR> CR: 00001000 XER: 20000000
GPR00: c00110ac bffebe63 bffebe7e bffebe88 8c008000 00001000 00000d12 b7ee2000
GPR08: 00000033 00000000 00000000 c139df10 48224824 1016c314 10160000 00000000
GPR16: 10160000 10160000 00000008 00000000 10160000 00000000 10160000 1017f5b0
GPR24: 1017fa50 1017f4f0 1017fa50 1017f740 1017f630 00000000 00000000 1017f4f0
NIP [b7ee2000] 0xb7ee2000
LR [8c008000] 0x8c008000
Call Trace:
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
---[ end trace 0000000000000000 ]---
The problem is in ret_from_syscall where the check for
icache_44x_need_flush is done. When the flush is needed the code jumps
out-of-line to do the flush, and then intends to jump back to continue
the syscall return.
However the branch back to label 1b doesn't return to the correct
location, instead branching back just prior to the return to userspace,
causing bogus register values to be used by the rfi.
The breakage was introduced by commit 6f76a01173cc
("powerpc/syscall: implement system call entry/exit logic in C for PPC32") which
inadvertently removed the "1" label and reused it elsewhere.
Fix it by adding named local labels in the correct locations. Note that
the return label needs to be outside the ifdef so that CONFIG_PPC_47x=n
compiles. |
["https://git.kernel.org/stable/c/29017ab1a539101d9c7bec63cc13a019f97b2820","https://git.kernel.org/stable/c/70f6756ad96dd70177dddcfac2fe4bd4bb320746","https://git.kernel.org/stable/c/8ac2689502f986a46f4221e239d4ff2897f1ccb3","https://git.kernel.org/stable/c/f0eee815babed70a749d2496a7678be5b45b4c14","https://git.kernel.org/stable/c/29017ab1a539101d9c7bec63cc13a019f97b2820","https://git.kernel.org/stable/c/70f6756ad96dd70177dddcfac2fe4bd4bb320746","https://git.kernel.org/stable/c/8ac2689502f986a46f4221e239d4ff2897f1ccb3","https://git.kernel.org/stable/c/f0eee815babed70a749d2496a7678be5b45b4c14"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52506
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Set all reserved memblocks on Node#0 at initialization
After commit 61167ad5fecdea ("mm: pass nid to reserve_bootmem_region()")
we get a panic if DEFERRED_STRUCT_PAGE_INIT is enabled:
[ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000002b82, era == 90000000040e3f28, ra == 90000000040e3f18
[ 0.000000] Oops[#1]:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.5.0+ #733
[ 0.000000] pc 90000000040e3f28 ra 90000000040e3f18 tp 90000000046f4000 sp 90000000046f7c90
[ 0.000000] a0 0000000000000001 a1 0000000000200000 a2 0000000000000040 a3 90000000046f7ca0
[ 0.000000] a4 90000000046f7ca4 a5 0000000000000000 a6 90000000046f7c38 a7 0000000000000000
[ 0.000000] t0 0000000000000002 t1 9000000004b00ac8 t2 90000000040e3f18 t3 90000000040f0800
[ 0.000000] t4 00000000000f0000 t5 80000000ffffe07e t6 0000000000000003 t7 900000047fff5e20
[ 0.000000] t8 aaaaaaaaaaaaaaab u0 0000000000000018 s9 0000000000000000 s0 fffffefffe000000
[ 0.000000] s1 0000000000000000 s2 0000000000000080 s3 0000000000000040 s4 0000000000000000
[ 0.000000] s5 0000000000000000 s6 fffffefffe000000 s7 900000000470b740 s8 9000000004ad4000
[ 0.000000] ra: 90000000040e3f18 reserve_bootmem_region+0xec/0x21c
[ 0.000000] ERA: 90000000040e3f28 reserve_bootmem_region+0xfc/0x21c
[ 0.000000] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
[ 0.000000] PRMD: 00000000 (PPLV0 -PIE -PWE)
[ 0.000000] EUEN: 00000000 (-FPE -SXE -ASXE -BTE)
[ 0.000000] ECFG: 00070800 (LIE=11 VS=7)
[ 0.000000] ESTAT: 00010800 [PIL] (IS=11 ECode=1 EsubCode=0)
[ 0.000000] BADV: 0000000000002b82
[ 0.000000] PRID: 0014d000 (Loongson-64bit, Loongson-3A6000)
[ 0.000000] Modules linked in:
[ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____))
[ 0.000000] Stack : 0000000000000000 9000000002eb5430 0000003a00000020 90000000045ccd00
[ 0.000000] 900000000470e000 90000000002c1918 0000000000000000 9000000004110780
[ 0.000000] 00000000fe6c0000 0000000480000000 9000000004b4e368 9000000004110748
[ 0.000000] 0000000000000000 900000000421ca84 9000000004620000 9000000004564970
[ 0.000000] 90000000046f7d78 9000000002cc9f70 90000000002c1918 900000000470e000
[ 0.000000] 9000000004564970 90000000040bc0e0 90000000046f7d78 0000000000000000
[ 0.000000] 0000000000004000 90000000045ccd00 0000000000000000 90000000002c1918
[ 0.000000] 90000000002c1900 900000000470b700 9000000004b4df78 9000000004620000
[ 0.000000] 90000000046200a8 90000000046200a8 0000000000000000 9000000004218b2c
[ 0.000000] 9000000004270008 0000000000000001 0000000000000000 90000000045ccd00
[ 0.000000] ...
[ 0.000000] Call Trace:
[ 0.000000] [<90000000040e3f28>] reserve_bootmem_region+0xfc/0x21c
[ 0.000000] [<900000000421ca84>] memblock_free_all+0x114/0x350
[ 0.000000] [<9000000004218b2c>] mm_core_init+0x138/0x3cc
[ 0.000000] [<9000000004200e38>] start_kernel+0x488/0x7a4
[ 0.000000] [<90000000040df0d8>] kernel_entry+0xd8/0xdc
[ 0.000000]
[ 0.000000] Code: 02eb21ad 00410f4c 380c31ac <262b818d> 6800b70d 02c1c196 0015001c 57fe4bb1 260002cd
The reason is early memblock_reserve() in memblock_init() set node id to
MAX_NUMNODES, making NODE_DATA(nid) a NULL dereference in the call chain
reserve_bootmem_region() -> init_reserved_page(). After memblock_init(),
those late calls of memblock_reserve() operate on subregions of memblock
.memory regions. As a result, these reserved regions will be set to the
correct node at the first iteration of memmap_init_reserved_pages().
So set all reserved memblocks on Node#0 at initialization can avoid this
panic. |
["https://git.kernel.org/stable/c/19878758accf6b2788091a771d9f9fee7bab11ab","https://git.kernel.org/stable/c/b795fb9f5861ee256070d59e33130980a01fadd7","https://git.kernel.org/stable/c/f105e893a8edd48bdf4bef9fef845a9ff402f737","https://git.kernel.org/stable/c/19878758accf6b2788091a771d9f9fee7bab11ab","https://git.kernel.org/stable/c/b795fb9f5861ee256070d59e33130980a01fadd7","https://git.kernel.org/stable/c/f105e893a8edd48bdf4bef9fef845a9ff402f737"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26648
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix variable deferencing before NULL check in edp_setup_replay()
In edp_setup_replay(), 'struct dc *dc' & 'struct dmub_replay *replay'
was dereferenced before the pointer 'link' & 'replay' NULL check.
Fixes the below:
drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_edp_panel_control.c:947 edp_setup_replay() warn: variable dereferenced before check 'link' (see line 933) |
["https://git.kernel.org/stable/c/22ae604aea14756954e1c00ae653e34d2afd2935","https://git.kernel.org/stable/c/7073934f5d73f8b53308963cee36f0d389ea857c","https://git.kernel.org/stable/c/c02d257c654191ecda1dc1af6875d527e85310e7","https://git.kernel.org/stable/c/22ae604aea14756954e1c00ae653e34d2afd2935","https://git.kernel.org/stable/c/7073934f5d73f8b53308963cee36f0d389ea857c","https://git.kernel.org/stable/c/c02d257c654191ecda1dc1af6875d527e85310e7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-40768
|
Medium |
|
N/A
|
drivers/scsi/stex.c in the Linux kernel through 5.19.9 allows local users to obtain sensitive information from kernel memory because stex_queuecommand_lck lacks a memset for the PASSTHRU_CMD case. |
["http://www.openwall.com/lists/oss-security/2022/09/19/1","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6022f210461fef67e6e676fd8544ca02d1bcfa7a","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/scsi/stex.c","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://lore.kernel.org/all/20220908145154.2284098-1-gregkh%40linuxfoundation.org/","https://www.openwall.com/lists/oss-security/2022/09/09/1","http://www.openwall.com/lists/oss-security/2022/09/19/1","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6022f210461fef67e6e676fd8544ca02d1bcfa7a","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/scsi/stex.c","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://lore.kernel.org/all/20220908145154.2284098-1-gregkh%40linuxfoundation.org/","https://www.openwall.com/lists/oss-security/2022/09/09/1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3078
|
Medium |
fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. There is a lack of check after calling vzalloc() and lack of free after allocation in drivers/media/test-drivers/vidtv/vidtv_s302m.c. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=e6a21a14106d9718aa4f8e115b1e474888eeba44","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=e6a21a14106d9718aa4f8e115b1e474888eeba44"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3220
|
Medium |
fixed |
|
An issue was discovered in the Linux kernel through 6.1-rc8. dpu_crtc_atomic_check in drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c lacks check of the return value of kzalloc() and will cause the NULL Pointer Dereference. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=93340e10b9c5fc86730d149636e0aa8b47bb5a34","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=93340e10b9c5fc86730d149636e0aa8b47bb5a34"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52596
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
sysctl: Fix out of bounds access for empty sysctl registers
When registering tables to the sysctl subsystem there is a check to see
if header is a permanently empty directory (used for mounts). This check
evaluates the first element of the ctl_table. This results in an out of
bounds evaluation when registering empty directories.
The function register_sysctl_mount_point now passes a ctl_table of size
1 instead of size 0. It now relies solely on the type to identify
a permanently empty register.
Make sure that the ctl_table has at least one element before testing for
permanent emptiness. |
["https://git.kernel.org/stable/c/15893975e9e382f8294ea8d926f08dc2d8d39ede","https://git.kernel.org/stable/c/2ae7081bc10123b187e36a4f3a8e53768de31489","https://git.kernel.org/stable/c/315552310c7de92baea4e570967066569937a843","https://git.kernel.org/stable/c/15893975e9e382f8294ea8d926f08dc2d8d39ede","https://git.kernel.org/stable/c/2ae7081bc10123b187e36a4f3a8e53768de31489","https://git.kernel.org/stable/c/315552310c7de92baea4e570967066569937a843"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26715
|
Medium |
fixed |
- 3.17
- 4.5
- 5.15.149
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend
In current scenario if Plug-out and Plug-In performed continuously
there could be a chance while checking for dwc->gadget_driver in
dwc3_gadget_suspend, a NULL pointer dereference may occur.
Call Stack:
CPU1: CPU2:
gadget_unbind_driver dwc3_suspend_common
dwc3_gadget_stop dwc3_gadget_suspend
dwc3_disconnect_gadget
CPU1 basically clears the variable and CPU2 checks the variable.
Consider CPU1 is running and right before gadget_driver is cleared
and in parallel CPU2 executes dwc3_gadget_suspend where it finds
dwc->gadget_driver which is not NULL and resumes execution and then
CPU1 completes execution. CPU2 executes dwc3_disconnect_gadget where
it checks dwc->gadget_driver is already NULL because of which the
NULL pointer deference occur. |
["https://git.kernel.org/stable/c/36695d5eeeefe5a64b47d0336e7c8fc144e78182","https://git.kernel.org/stable/c/57e2e42ccd3cd6183228269715ed032f44536751","https://git.kernel.org/stable/c/61a348857e869432e6a920ad8ea9132e8d44c316","https://git.kernel.org/stable/c/88936ceab6b426f1312327e9ef849c215c6007a7","https://git.kernel.org/stable/c/c7ebd8149ee519d27232e6e4940e9c02071b568b","https://git.kernel.org/stable/c/36695d5eeeefe5a64b47d0336e7c8fc144e78182","https://git.kernel.org/stable/c/57e2e42ccd3cd6183228269715ed032f44536751","https://git.kernel.org/stable/c/61a348857e869432e6a920ad8ea9132e8d44c316","https://git.kernel.org/stable/c/88936ceab6b426f1312327e9ef849c215c6007a7","https://git.kernel.org/stable/c/c7ebd8149ee519d27232e6e4940e9c02071b568b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1079
|
Medium |
fixed |
|
A flaw was found in the Linux kernel. A use-after-free may be triggered in asus_kbd_backlight_set when plugging/disconnecting in a malicious USB device, which advertises itself as an Asus device. Similarly to the previous known CVE-2023-25012, but in asus devices, the work_struct may be scheduled by the LED controller while the device is disconnecting, triggering a use-after-free on the struct asus_kbd_leds *led structure. A malicious USB device may exploit the issue to cause memory corruption with controlled data. |
["https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=4ab3a086d10eeec1424f2e8a968827a6336203df","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=4ab3a086d10eeec1424f2e8a968827a6336203df","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52497
|
Medium |
fixed |
- 5.4.285
- 5.10.211
- 5.15.150
- 6.1.76
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
erofs: fix lz4 inplace decompression
Currently EROFS can map another compressed buffer for inplace
decompression, that was used to handle the cases that some pages of
compressed data are actually not in-place I/O.
However, like most simple LZ77 algorithms, LZ4 expects the compressed
data is arranged at the end of the decompressed buffer and it
explicitly uses memmove() to handle overlapping:
__________________________________________________________
|_ direction of decompression --> ____ |_ compressed data _|
Although EROFS arranges compressed data like this, it typically maps two
individual virtual buffers so the relative order is uncertain.
Previously, it was hardly observed since LZ4 only uses memmove() for
short overlapped literals and x86/arm64 memmove implementations seem to
completely cover it up and they don't have this issue. Juhyung reported
that EROFS data corruption can be found on a new Intel x86 processor.
After some analysis, it seems that recent x86 processors with the new
FSRM feature expose this issue with "rep movsb".
Let's strictly use the decompressed buffer for lz4 inplace
decompression for now. Later, as an useful improvement, we could try
to tie up these two buffers together in the correct order. |
["https://git.kernel.org/stable/c/33bf23c9940dbd3a22aad7f0cda4c84ed5701847","https://git.kernel.org/stable/c/3c12466b6b7bf1e56f9b32c366a3d83d87afb4de","https://git.kernel.org/stable/c/77cbc04a1a8610e303a0e0d74f2676667876a184","https://git.kernel.org/stable/c/9ff2d260b25df6fe1341a79113d88fecf6bd553e","https://git.kernel.org/stable/c/a0180e940cf1aefa7d516e20b259ad34f7a8b379","https://git.kernel.org/stable/c/bffc4cc334c5bb31ded54bc3cfd651735a3cb79e","https://git.kernel.org/stable/c/f36d200a80a3ca025532ed60dd1ac21b620e14ae","https://git.kernel.org/stable/c/33bf23c9940dbd3a22aad7f0cda4c84ed5701847","https://git.kernel.org/stable/c/3c12466b6b7bf1e56f9b32c366a3d83d87afb4de","https://git.kernel.org/stable/c/77cbc04a1a8610e303a0e0d74f2676667876a184","https://git.kernel.org/stable/c/a0180e940cf1aefa7d516e20b259ad34f7a8b379","https://git.kernel.org/stable/c/bffc4cc334c5bb31ded54bc3cfd651735a3cb79e","https://git.kernel.org/stable/c/f36d200a80a3ca025532ed60dd1ac21b620e14ae","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-35823
|
High |
fixed |
|
An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in saa7134_finidev in drivers/media/pci/saa7134/saa7134-core.c. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=30cf57da176cca80f11df0d9b7f71581fe601389","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/all/49bb0b6a-e669-d4e7-d742-a19d2763e947%40xs4all.nl/","https://lore.kernel.org/lkml/20230318085023.832510-1-zyytlz.wz%40163.com/t/","https://security.netapp.com/advisory/ntap-20230803-0002/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=30cf57da176cca80f11df0d9b7f71581fe601389","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/all/49bb0b6a-e669-d4e7-d742-a19d2763e947%40xs4all.nl/","https://lore.kernel.org/lkml/20230318085023.832510-1-zyytlz.wz%40163.com/t/","https://security.netapp.com/advisory/ntap-20230803-0002/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1247
|
High |
|
N/A
|
An issue found in linux-kernel that leads to a race condition in rose_connect(). The rose driver uses rose_neigh->use to represent how many objects are using the rose_neigh. When a user wants to delete a rose_route via rose_ioctl(), the rose driver calls rose_del_node() and removes neighbours only if their “count” and “use” are zero. |
["https://access.redhat.com/security/cve/CVE-2022-1247","https://bugzilla.redhat.com/show_bug.cgi?id=2066799","https://access.redhat.com/security/cve/CVE-2022-1247","https://bugzilla.redhat.com/show_bug.cgi?id=2066799"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46695
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
selinux,smack: don't bypass permissions check in inode_setsecctx hook
Marek Gresko reports that the root user on an NFS client is able to
change the security labels on files on an NFS filesystem that is
exported with root squashing enabled.
The end of the kerneldoc comment for __vfs_setxattr_noperm() states:
* This function requires the caller to lock the inode's i_mutex before it
* is executed. It also assumes that the caller will make the appropriate
* permission checks.
nfsd_setattr() does do permissions checking via fh_verify() and
nfsd_permission(), but those don't do all the same permissions checks
that are done by security_inode_setxattr() and its related LSM hooks do.
Since nfsd_setattr() is the only consumer of security_inode_setsecctx(),
simplest solution appears to be to replace the call to
__vfs_setxattr_noperm() with a call to __vfs_setxattr_locked(). This
fixes the above issue and has the added benefit of causing nfsd to
recall conflicting delegations on a file when a client tries to change
its security label. |
["https://git.kernel.org/stable/c/2dbc4b7bac60b02cc6e70d05bf6a7dfd551f9dda","https://git.kernel.org/stable/c/459584258d47ec3cc6245a82e8a49c9d08eb8b57","https://git.kernel.org/stable/c/76a0e79bc84f466999fa501fce5bf7a07641b8a7","https://git.kernel.org/stable/c/eebec98791d0137e455cc006411bb92a54250924","https://git.kernel.org/stable/c/f71ec019257ba4f7ab198bd948c5902a207bad96","https://git.kernel.org/stable/c/fe0cd53791119f6287b6532af8ce41576d664930"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-36402
|
Medium |
|
N/A
|
An integer overflow vulnerability was found in vmwgfx driver in drivers/gpu/vmxgfx/vmxgfx_execbuf.c in GPU component of Linux kernel with device file '/dev/dri/renderD128 (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS). |
["https://bugzilla.openanolis.cn/show_bug.cgi?id=2072","https://bugzilla.openanolis.cn/show_bug.cgi?id=2072"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-38096
|
Medium |
|
N/A
|
A NULL pointer dereference vulnerability was found in vmwgfx driver in drivers/gpu/vmxgfx/vmxgfx_execbuf.c in GPU component of Linux kernel with device file '/dev/dri/renderD128 (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS). |
["https://bugzilla.openanolis.cn/show_bug.cgi?id=2073","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://bugzilla.openanolis.cn/show_bug.cgi?id=2073","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-38457
|
Medium |
fixed |
|
A use-after-free(UAF) vulnerability was found in function 'vmw_cmd_res_check' in drivers/gpu/vmxgfx/vmxgfx_execbuf.c in Linux kernel's vmwgfx driver with device file '/dev/dri/renderD128 (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS). |
["https://bugzilla.openanolis.cn/show_bug.cgi?id=2074","https://bugzilla.openanolis.cn/show_bug.cgi?id=2074"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-3564
|
Medium |
|
N/A
|
A flaw double-free memory corruption in the Linux kernel HCI device initialization subsystem was found in the way user attach malicious HCI TTY Bluetooth device. A local user could use this flaw to crash the system. This flaw affects all the Linux kernel versions starting from 3.13. |
["http://www.openwall.com/lists/oss-security/2021/05/25/1","http://www.openwall.com/lists/oss-security/2021/06/01/2","https://bugzilla.redhat.com/show_bug.cgi?id=1964139","https://lists.debian.org/debian-lts-announce/2021/06/msg00019.html","https://lists.debian.org/debian-lts-announce/2021/06/msg00020.html","https://www.openwall.com/lists/oss-security/2021/05/25/1","http://www.openwall.com/lists/oss-security/2021/05/25/1","http://www.openwall.com/lists/oss-security/2021/06/01/2","https://bugzilla.redhat.com/show_bug.cgi?id=1964139","https://lists.debian.org/debian-lts-announce/2021/06/msg00019.html","https://lists.debian.org/debian-lts-announce/2021/06/msg00020.html","https://www.openwall.com/lists/oss-security/2021/05/25/1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-2898
|
Medium |
|
N/A
|
There is a null-pointer-dereference flaw found in f2fs_write_end_io in fs/f2fs/data.c in the Linux kernel. This flaw allows a local privileged user to cause a denial of service problem. |
["https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/linux-f2fs-devel/20230522124203.3838360-1-chao%40kernel.org/","https://security.netapp.com/advisory/ntap-20230929-0002/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/linux-f2fs-devel/20230522124203.3838360-1-chao%40kernel.org/","https://security.netapp.com/advisory/ntap-20230929-0002/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-40307
|
Medium |
|
N/A
|
An issue was discovered in the Linux kernel through 5.19.8. drivers/firmware/efi/capsule-loader.c has a race condition with a resultant use-after-free. |
["https://github.com/torvalds/linux/commit/9cb636b5f6a8cc6d1b50809ec8f8d33ae0c84c95","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://www.debian.org/security/2022/dsa-5257","https://github.com/torvalds/linux/commit/9cb636b5f6a8cc6d1b50809ec8f8d33ae0c84c95","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://www.debian.org/security/2022/dsa-5257"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-41848
|
Medium |
|
N/A
|
drivers/char/pcmcia/synclink_cs.c in the Linux kernel through 5.19.12 has a race condition and resultant use-after-free if a physically proximate attacker removes a PCMCIA device while calling ioctl, aka a race condition between mgslpc_ioctl and mgslpc_detach. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/char/pcmcia/synclink_cs.c","https://lore.kernel.org/lkml/20220919040251.GA302541%40ubuntu/T/#rc85e751f467b3e6f9ccef92cfa7fb8a6cc50c270","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/char/pcmcia/synclink_cs.c","https://lore.kernel.org/lkml/20220919040251.GA302541%40ubuntu/T/#rc85e751f467b3e6f9ccef92cfa7fb8a6cc50c270"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3636
|
High |
|
N/A
|
A vulnerability, which was classified as critical, was found in Linux Kernel. This affects the function __mtk_ppe_check_skb of the file drivers/net/ethernet/mediatek/mtk_ppe.c of the component Ethernet Handler. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211935. |
["https://git.kernel.org/pub/scm/linux/kernel/git/pabeni/net-next.git/commit/?id=17a5f6a78dc7b8db385de346092d7d9f9dc24df6","https://vuldb.com/?id.211935","https://www.debian.org/security/2023/dsa-5333","https://git.kernel.org/pub/scm/linux/kernel/git/pabeni/net-next.git/commit/?id=17a5f6a78dc7b8db385de346092d7d9f9dc24df6","https://vuldb.com/?id.211935","https://www.debian.org/security/2023/dsa-5333"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52510
|
High |
fixed |
- 4.14.328
- 4.19.297
- 5.4.259
- 5.10.199
- 5.15.136
- 6.1.59
- 6.5.8
|
In the Linux kernel, the following vulnerability has been resolved:
ieee802154: ca8210: Fix a potential UAF in ca8210_probe
If of_clk_add_provider() fails in ca8210_register_ext_clock(),
it calls clk_unregister() to release priv->clk and returns an
error. However, the caller ca8210_probe() then calls ca8210_remove(),
where priv->clk is freed again in ca8210_unregister_ext_clock(). In
this case, a use-after-free may happen in the second time we call
clk_unregister().
Fix this by removing the first clk_unregister(). Also, priv->clk could
be an error code on failure of clk_register_fixed_rate(). Use
IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock(). |
["https://git.kernel.org/stable/c/217efe32a45249eb07dcd7197e8403de98345e66","https://git.kernel.org/stable/c/28b68cba378e3e50a4082b65f262bc4f2c7c2add","https://git.kernel.org/stable/c/55e06850c7894f00d41b767c5f5665459f83f58f","https://git.kernel.org/stable/c/84c6aa0ae5c4dc121f9996bb8fed46c80909d80e","https://git.kernel.org/stable/c/85c2857ef90041f567ce98722c1c342c4d31f4bc","https://git.kernel.org/stable/c/becf5c147198f4345243c5df0c4f035415491640","https://git.kernel.org/stable/c/cdb46be93c1f7bbf2c4649e9fc5fb147cfb5245d","https://git.kernel.org/stable/c/f990874b1c98fe8e57ee9385669f501822979258","https://git.kernel.org/stable/c/217efe32a45249eb07dcd7197e8403de98345e66","https://git.kernel.org/stable/c/28b68cba378e3e50a4082b65f262bc4f2c7c2add","https://git.kernel.org/stable/c/55e06850c7894f00d41b767c5f5665459f83f58f","https://git.kernel.org/stable/c/84c6aa0ae5c4dc121f9996bb8fed46c80909d80e","https://git.kernel.org/stable/c/85c2857ef90041f567ce98722c1c342c4d31f4bc","https://git.kernel.org/stable/c/becf5c147198f4345243c5df0c4f035415491640","https://git.kernel.org/stable/c/cdb46be93c1f7bbf2c4649e9fc5fb147cfb5245d","https://git.kernel.org/stable/c/f990874b1c98fe8e57ee9385669f501822979258"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26895
|
High |
fixed |
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: wilc1000: prevent use-after-free on vif when cleaning up all interfaces
wilc_netdev_cleanup currently triggers a KASAN warning, which can be
observed on interface registration error path, or simply by
removing the module/unbinding device from driver:
echo spi0.1 > /sys/bus/spi/drivers/wilc1000_spi/unbind
==================================================================
BUG: KASAN: slab-use-after-free in wilc_netdev_cleanup+0x508/0x5cc
Read of size 4 at addr c54d1ce8 by task sh/86
CPU: 0 PID: 86 Comm: sh Not tainted 6.8.0-rc1+ #117
Hardware name: Atmel SAMA5
unwind_backtrace from show_stack+0x18/0x1c
show_stack from dump_stack_lvl+0x34/0x58
dump_stack_lvl from print_report+0x154/0x500
print_report from kasan_report+0xac/0xd8
kasan_report from wilc_netdev_cleanup+0x508/0x5cc
wilc_netdev_cleanup from wilc_bus_remove+0xc8/0xec
wilc_bus_remove from spi_remove+0x8c/0xac
spi_remove from device_release_driver_internal+0x434/0x5f8
device_release_driver_internal from unbind_store+0xbc/0x108
unbind_store from kernfs_fop_write_iter+0x398/0x584
kernfs_fop_write_iter from vfs_write+0x728/0xf88
vfs_write from ksys_write+0x110/0x1e4
ksys_write from ret_fast_syscall+0x0/0x1c
[...]
Allocated by task 1:
kasan_save_track+0x30/0x5c
__kasan_kmalloc+0x8c/0x94
__kmalloc_node+0x1cc/0x3e4
kvmalloc_node+0x48/0x180
alloc_netdev_mqs+0x68/0x11dc
alloc_etherdev_mqs+0x28/0x34
wilc_netdev_ifc_init+0x34/0x8ec
wilc_cfg80211_init+0x690/0x910
wilc_bus_probe+0xe0/0x4a0
spi_probe+0x158/0x1b0
really_probe+0x270/0xdf4
__driver_probe_device+0x1dc/0x580
driver_probe_device+0x60/0x140
__driver_attach+0x228/0x5d4
bus_for_each_dev+0x13c/0x1a8
bus_add_driver+0x2a0/0x608
driver_register+0x24c/0x578
do_one_initcall+0x180/0x310
kernel_init_freeable+0x424/0x484
kernel_init+0x20/0x148
ret_from_fork+0x14/0x28
Freed by task 86:
kasan_save_track+0x30/0x5c
kasan_save_free_info+0x38/0x58
__kasan_slab_free+0xe4/0x140
kfree+0xb0/0x238
device_release+0xc0/0x2a8
kobject_put+0x1d4/0x46c
netdev_run_todo+0x8fc/0x11d0
wilc_netdev_cleanup+0x1e4/0x5cc
wilc_bus_remove+0xc8/0xec
spi_remove+0x8c/0xac
device_release_driver_internal+0x434/0x5f8
unbind_store+0xbc/0x108
kernfs_fop_write_iter+0x398/0x584
vfs_write+0x728/0xf88
ksys_write+0x110/0x1e4
ret_fast_syscall+0x0/0x1c
[...]
David Mosberger-Tan initial investigation [1] showed that this
use-after-free is due to netdevice unregistration during vif list
traversal. When unregistering a net device, since the needs_free_netdev has
been set to true during registration, the netdevice object is also freed,
and as a consequence, the corresponding vif object too, since it is
attached to it as private netdevice data. The next occurrence of the loop
then tries to access freed vif pointer to the list to move forward in the
list.
Fix this use-after-free thanks to two mechanisms:
- navigate in the list with list_for_each_entry_safe, which allows to
safely modify the list as we go through each element. For each element,
remove it from the list with list_del_rcu
- make sure to wait for RCU grace period end after each vif removal to make
sure it is safe to free the corresponding vif too (through
unregister_netdev)
Since we are in a RCU "modifier" path (not a "reader" path), and because
such path is expected not to be concurrent to any other modifier (we are
using the vif_mutex lock), we do not need to use RCU list API, that's why
we can benefit from list_for_each_entry_safe.
[1] https://lore.kernel.org/linux-wireless/ab077dbe58b1ea5de0a3b2ca21f275a07af967d2.camel@egauge.net/ |
["https://git.kernel.org/stable/c/24228dcf1d30c2231caa332be7d3090ac59fbfe9","https://git.kernel.org/stable/c/3da9d32b7f4a1a9f7e4bb15bb82f2b2dd6719447","https://git.kernel.org/stable/c/5956f4203b6cdd0755bbdd21b45f3933c7026208","https://git.kernel.org/stable/c/73a2aa0aef86c2c07be5a2f42c9e6047e1a2f7bb","https://git.kernel.org/stable/c/a9545af2a533739ffb64d6c9a6fec6f13e2b505f","https://git.kernel.org/stable/c/cb5942b77c05d54310a0420cac12935e9b6aa21c","https://git.kernel.org/stable/c/fe20e3d56bc911408fc3c27a17c59e9d7885f7d1","https://git.kernel.org/stable/c/24228dcf1d30c2231caa332be7d3090ac59fbfe9","https://git.kernel.org/stable/c/3da9d32b7f4a1a9f7e4bb15bb82f2b2dd6719447","https://git.kernel.org/stable/c/5956f4203b6cdd0755bbdd21b45f3933c7026208","https://git.kernel.org/stable/c/73a2aa0aef86c2c07be5a2f42c9e6047e1a2f7bb","https://git.kernel.org/stable/c/a9545af2a533739ffb64d6c9a6fec6f13e2b505f","https://git.kernel.org/stable/c/cb5942b77c05d54310a0420cac12935e9b6aa21c","https://git.kernel.org/stable/c/fe20e3d56bc911408fc3c27a17c59e9d7885f7d1","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26885
|
High |
fixed |
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix DEVMAP_HASH overflow check on 32-bit arches
The devmap code allocates a number hash buckets equal to the next power
of two of the max_entries value provided when creating the map. When
rounding up to the next power of two, the 32-bit variable storing the
number of buckets can overflow, and the code checks for overflow by
checking if the truncated 32-bit value is equal to 0. However, on 32-bit
arches the rounding up itself can overflow mid-way through, because it
ends up doing a left-shift of 32 bits on an unsigned long value. If the
size of an unsigned long is four bytes, this is undefined behaviour, so
there is no guarantee that we'll end up with a nice and tidy 0-value at
the end.
Syzbot managed to turn this into a crash on arm32 by creating a
DEVMAP_HASH with max_entries > 0x80000000 and then trying to update it.
Fix this by moving the overflow check to before the rounding up
operation. |
["https://git.kernel.org/stable/c/1f5e352b9088211fa5eb4e1639cd365f4f7d2f65","https://git.kernel.org/stable/c/22079b3a423382335f47d9ed32114e6c9fe88d7c","https://git.kernel.org/stable/c/250051acc21f9d4c5c595e4fcb55986ea08c4691","https://git.kernel.org/stable/c/281d464a34f540de166cee74b723e97ac2515ec3","https://git.kernel.org/stable/c/4b81a9f92b3676cb74b907a7a209b3d15bd9a7f9","https://git.kernel.org/stable/c/c826502bed93970f2fd488918a7b8d5f1d30e2e3","https://git.kernel.org/stable/c/e89386f62ce9a9ab9a94835a9890883c23d9d52c","https://git.kernel.org/stable/c/edf7990baa48de5097daa9ac02e06cb4c798a737","https://git.kernel.org/stable/c/22079b3a423382335f47d9ed32114e6c9fe88d7c","https://git.kernel.org/stable/c/225da02acdc97af01b6bc6ce1a3e5362bf01d3fb","https://git.kernel.org/stable/c/250051acc21f9d4c5c595e4fcb55986ea08c4691","https://git.kernel.org/stable/c/281d464a34f540de166cee74b723e97ac2515ec3","https://git.kernel.org/stable/c/c826502bed93970f2fd488918a7b8d5f1d30e2e3","https://git.kernel.org/stable/c/e89386f62ce9a9ab9a94835a9890883c23d9d52c","https://git.kernel.org/stable/c/edf7990baa48de5097daa9ac02e06cb4c798a737","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3090
|
High |
fixed |
- 4.14.316
- 4.19.284
- 5.4.244
- 5.10.181
- 5.15.113
- 6.1.30
- 6.3.4
|
A heap out-of-bounds write vulnerability in the Linux Kernel ipvlan network driver can be exploited to achieve local privilege escalation.
The out-of-bounds write is caused by missing skb->cb initialization in the ipvlan network driver. The vulnerability is reachable if CONFIG_IPVLAN is enabled.
We recommend upgrading past commit 90cbed5247439a966b645b34eb0a2e037836ea8e. |
["http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=90cbed5247439a966b645b34eb0a2e037836ea8e","https://kernel.dance/90cbed5247439a966b645b34eb0a2e037836ea8e","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20230731-0002/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5480","http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=90cbed5247439a966b645b34eb0a2e037836ea8e","https://kernel.dance/90cbed5247439a966b645b34eb0a2e037836ea8e","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20230731-0002/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5480"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49053
|
High |
fixed |
- 4.14.276
- 4.19.239
- 5.4.190
- 5.10.112
- 5.15.35
- 5.17.4
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: tcmu: Fix possible page UAF
tcmu_try_get_data_page() looks up pages under cmdr_lock, but it does not
take refcount properly and just returns page pointer. When
tcmu_try_get_data_page() returns, the returned page may have been freed by
tcmu_blocks_release().
We need to get_page() under cmdr_lock to avoid concurrent
tcmu_blocks_release(). |
["https://git.kernel.org/stable/c/a6968f7a367f128d120447360734344d5a3d5336","https://git.kernel.org/stable/c/a9564d84ed9f6ee71017d062d0d2182154294a4b","https://git.kernel.org/stable/c/aec36b98a1bbaa84bfd8299a306e4c12314af626","https://git.kernel.org/stable/c/b7f3b5d70c834f49f7d87a2f2ed1c6284d9a0322","https://git.kernel.org/stable/c/d7c5d79e50be6e06b669141e3db1f977a0dd4e8e","https://git.kernel.org/stable/c/e3e0e067d5b34e4a68e3cc55f8eebc413f56f8ed","https://git.kernel.org/stable/c/fb7a5115422fbd6a4d505e8844f1ef5529f10489"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26913
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix dcn35 8k30 Underflow/Corruption Issue
[why]
odm calculation is missing for pipe split policy determination
and cause Underflow/Corruption issue.
[how]
Add the odm calculation. |
["https://git.kernel.org/stable/c/cdbe0be8874c63bca85b8c38e5b1eecbdd18df31","https://git.kernel.org/stable/c/faf51b201bc42adf500945732abb6220c707d6f3","https://git.kernel.org/stable/c/cdbe0be8874c63bca85b8c38e5b1eecbdd18df31","https://git.kernel.org/stable/c/faf51b201bc42adf500945732abb6220c707d6f3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56708
|
High |
fixed |
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
EDAC/igen6: Avoid segmentation fault on module unload
The segmentation fault happens because:
During modprobe:
1. In igen6_probe(), igen6_pvt will be allocated with kzalloc()
2. In igen6_register_mci(), mci->pvt_info will point to
&igen6_pvt->imc[mc]
During rmmod:
1. In mci_release() in edac_mc.c, it will kfree(mci->pvt_info)
2. In igen6_remove(), it will kfree(igen6_pvt);
Fix this issue by setting mci->pvt_info to NULL to avoid the double
kfree. |
["https://git.kernel.org/stable/c/029ac07bb92d2f7502d47a4916f197a8445d83bf","https://git.kernel.org/stable/c/2a80e710bbc088a2511c159ee4d910456c5f0832","https://git.kernel.org/stable/c/830cabb61113d92a425dd3038ccedbdfb3c8d079","https://git.kernel.org/stable/c/db60326f2c47b079e36785ace621eb3002db2088","https://git.kernel.org/stable/c/e5c7052664b61f9e2f896702d20552707d0ef60a","https://git.kernel.org/stable/c/fefaae90398d38a1100ccd73b46ab55ff4610fba"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56626
|
High |
fixed |
- 5.15.176
- 6.1.120
- 6.6.66
- 6.12.5
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix Out-of-Bounds Write in ksmbd_vfs_stream_write
An offset from client could be a negative value, It could allows
to write data outside the bounds of the allocated buffer.
Note that this issue is coming when setting
'vfs objects = streams_xattr parameter' in ksmbd.conf. |
["https://git.kernel.org/stable/c/164d3597d26d9acff5d5b8bc3208bdcca942dd6a","https://git.kernel.org/stable/c/1aea5c9470be2c7129704fb1b9562b1e3e0576f8","https://git.kernel.org/stable/c/313dab082289e460391c82d855430ec8a28ddf81","https://git.kernel.org/stable/c/8cd7490fc0f268883e86e840cda5311257af69ca","https://git.kernel.org/stable/c/c5797f195c67132d061d29c57a7c6d30530686f0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26884
|
High |
fixed |
- 4.19.311
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix hashtab overflow check on 32-bit arches
The hashtab code relies on roundup_pow_of_two() to compute the number of
hash buckets, and contains an overflow check by checking if the
resulting value is 0. However, on 32-bit arches, the roundup code itself
can overflow by doing a 32-bit left-shift of an unsigned long value,
which is undefined behaviour, so it is not guaranteed to truncate
neatly. This was triggered by syzbot on the DEVMAP_HASH type, which
contains the same check, copied from the hashtab code. So apply the same
fix to hashtab, by moving the overflow check to before the roundup. |
["https://git.kernel.org/stable/c/33ec04cadb77605b71d9298311919303d390c4d5","https://git.kernel.org/stable/c/3b08cfc65f07b1132c1979d73f014ae6e04de55d","https://git.kernel.org/stable/c/64f00b4df0597590b199b62a37a165473bf658a6","https://git.kernel.org/stable/c/6787d916c2cf9850c97a0a3f73e08c43e7d973b1","https://git.kernel.org/stable/c/8435f0961bf3dc65e204094349bd9aeaac1f8868","https://git.kernel.org/stable/c/92c81fbb3ed2e0dfc33a4183a67135e1ab566ace","https://git.kernel.org/stable/c/a6fa75b5096c0f9826a4fabe22d907b0a5bb1016","https://git.kernel.org/stable/c/a83fdaeaea3677b83a53f72ace2d73a19bcd6d93","https://git.kernel.org/stable/c/d817f0d34d927f2deb17dadbfe212c9a6a32ac3e","https://git.kernel.org/stable/c/33ec04cadb77605b71d9298311919303d390c4d5","https://git.kernel.org/stable/c/3b08cfc65f07b1132c1979d73f014ae6e04de55d","https://git.kernel.org/stable/c/64f00b4df0597590b199b62a37a165473bf658a6","https://git.kernel.org/stable/c/6787d916c2cf9850c97a0a3f73e08c43e7d973b1","https://git.kernel.org/stable/c/8435f0961bf3dc65e204094349bd9aeaac1f8868","https://git.kernel.org/stable/c/92c81fbb3ed2e0dfc33a4183a67135e1ab566ace","https://git.kernel.org/stable/c/a6fa75b5096c0f9826a4fabe22d907b0a5bb1016","https://git.kernel.org/stable/c/a83fdaeaea3677b83a53f72ace2d73a19bcd6d93","https://git.kernel.org/stable/c/d817f0d34d927f2deb17dadbfe212c9a6a32ac3e","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52601
|
High |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix array-index-out-of-bounds in dbAdjTree
Currently there is a bound check missing in the dbAdjTree while
accessing the dmt_stree. To add the required check added the bool is_ctl
which is required to determine the size as suggest in the following
commit.
https://lore.kernel.org/linux-kernel-mentees/f9475918-2186-49b8-b801-6f0f9e75f4fa@oracle.com/ |
["https://git.kernel.org/stable/c/2037cb9d95f1741885f7daf50e8a028c4ade5317","https://git.kernel.org/stable/c/2e16a1389b5a7983b45cb2aa20b0e3f0ee364d6c","https://git.kernel.org/stable/c/3d3898b4d72c677d47fe3cb554449f2df5c12555","https://git.kernel.org/stable/c/3f8217c323fd6ecd6829a0c3ae7ac3f14eac368e","https://git.kernel.org/stable/c/70780914cb57e2ba711e0ac1b677aaaa75103603","https://git.kernel.org/stable/c/74ecdda68242b174920fe7c6133a856fb7d8559b","https://git.kernel.org/stable/c/8393c80cce45f40c1256d72e21ad351b3650c57e","https://git.kernel.org/stable/c/fc67a2e18f4c4e3f07e9f9ae463da24530470e73","https://git.kernel.org/stable/c/2037cb9d95f1741885f7daf50e8a028c4ade5317","https://git.kernel.org/stable/c/2e16a1389b5a7983b45cb2aa20b0e3f0ee364d6c","https://git.kernel.org/stable/c/3d3898b4d72c677d47fe3cb554449f2df5c12555","https://git.kernel.org/stable/c/3f8217c323fd6ecd6829a0c3ae7ac3f14eac368e","https://git.kernel.org/stable/c/70780914cb57e2ba711e0ac1b677aaaa75103603","https://git.kernel.org/stable/c/74ecdda68242b174920fe7c6133a856fb7d8559b","https://git.kernel.org/stable/c/8393c80cce45f40c1256d72e21ad351b3650c57e","https://git.kernel.org/stable/c/fc67a2e18f4c4e3f07e9f9ae463da24530470e73","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52572
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix UAF in cifs_demultiplex_thread()
There is a UAF when xfstests on cifs:
BUG: KASAN: use-after-free in smb2_is_network_name_deleted+0x27/0x160
Read of size 4 at addr ffff88810103fc08 by task cifsd/923
CPU: 1 PID: 923 Comm: cifsd Not tainted 6.1.0-rc4+ #45
...
Call Trace:
<TASK>
dump_stack_lvl+0x34/0x44
print_report+0x171/0x472
kasan_report+0xad/0x130
kasan_check_range+0x145/0x1a0
smb2_is_network_name_deleted+0x27/0x160
cifs_demultiplex_thread.cold+0x172/0x5a4
kthread+0x165/0x1a0
ret_from_fork+0x1f/0x30
</TASK>
Allocated by task 923:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
__kasan_slab_alloc+0x54/0x60
kmem_cache_alloc+0x147/0x320
mempool_alloc+0xe1/0x260
cifs_small_buf_get+0x24/0x60
allocate_buffers+0xa1/0x1c0
cifs_demultiplex_thread+0x199/0x10d0
kthread+0x165/0x1a0
ret_from_fork+0x1f/0x30
Freed by task 921:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
kasan_save_free_info+0x2a/0x40
____kasan_slab_free+0x143/0x1b0
kmem_cache_free+0xe3/0x4d0
cifs_small_buf_release+0x29/0x90
SMB2_negotiate+0x8b7/0x1c60
smb2_negotiate+0x51/0x70
cifs_negotiate_protocol+0xf0/0x160
cifs_get_smb_ses+0x5fa/0x13c0
mount_get_conns+0x7a/0x750
cifs_mount+0x103/0xd00
cifs_smb3_do_mount+0x1dd/0xcb0
smb3_get_tree+0x1d5/0x300
vfs_get_tree+0x41/0xf0
path_mount+0x9b3/0xdd0
__x64_sys_mount+0x190/0x1d0
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
The UAF is because:
mount(pid: 921) | cifsd(pid: 923)
-------------------------------|-------------------------------
| cifs_demultiplex_thread
SMB2_negotiate |
cifs_send_recv |
compound_send_recv |
smb_send_rqst |
wait_for_response |
wait_event_state [1] |
| standard_receive3
| cifs_handle_standard
| handle_mid
| mid->resp_buf = buf; [2]
| dequeue_mid [3]
KILL the process [4] |
resp_iov[i].iov_base = buf |
free_rsp_buf [5] |
| is_network_name_deleted [6]
| callback
1. After send request to server, wait the response until
mid->mid_state != SUBMITTED;
2. Receive response from server, and set it to mid;
3. Set the mid state to RECEIVED;
4. Kill the process, the mid state already RECEIVED, get 0;
5. Handle and release the negotiate response;
6. UAF.
It can be easily reproduce with add some delay in [3] - [6].
Only sync call has the problem since async call's callback is
executed in cifsd process.
Add an extra state to mark the mid state to READY before wakeup the
waitter, then it can get the resp safely. |
["https://git.kernel.org/stable/c/76569e3819e0bb59fc19b1b8688b017e627c268a","https://git.kernel.org/stable/c/908b3b5e97d25e879de3d1f172a255665491c2c3","https://git.kernel.org/stable/c/99960d282fba6634fa758df4124cb73ef8a77d8a","https://git.kernel.org/stable/c/d527f51331cace562393a8038d870b3e9916686f","https://git.kernel.org/stable/c/ed3b36f351d97dacb62cd0f399e8cf79f73bd30a","https://git.kernel.org/stable/c/76569e3819e0bb59fc19b1b8688b017e627c268a","https://git.kernel.org/stable/c/908b3b5e97d25e879de3d1f172a255665491c2c3","https://git.kernel.org/stable/c/d527f51331cace562393a8038d870b3e9916686f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-6040
|
High |
fixed |
- 4.19.305
- 5.4.267
- 5.10.208
- 5.15.147
- 5.18
|
An out-of-bounds access vulnerability involving netfilter was reported and fixed as: f1082dd31fe4 (netfilter: nf_tables: Reject tables of unsupported family); While creating a new netfilter table, lack of a safeguard against invalid nf_tables family (pf) values within `nf_tables_newtable` function enables an attacker to achieve out-of-bounds access. |
["http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html","http://www.openwall.com/lists/oss-security/2024/01/12/1","https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6040","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://www.openwall.com/lists/oss-security/2024/01/12/1","http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html","http://www.openwall.com/lists/oss-security/2024/01/12/1","https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6040","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://www.openwall.com/lists/oss-security/2024/01/12/1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48425
|
High |
fixed |
|
In the Linux kernel through 6.2.7, fs/ntfs3/inode.c has an invalid kfree because it does not validate MFT flags before replaying logs. |
["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=467333af2f7b95eeaa61a5b5369a80063cd971fd","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/fs/ntfs3?id=467333af2f7b95eeaa61a5b5369a80063cd971fd","https://security.netapp.com/advisory/ntap-20230413-0006/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=467333af2f7b95eeaa61a5b5369a80063cd971fd","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/fs/ntfs3?id=467333af2f7b95eeaa61a5b5369a80063cd971fd","https://security.netapp.com/advisory/ntap-20230413-0006/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26704
|
High |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix double-free of blocks due to wrong extents moved_len
In ext4_move_extents(), moved_len is only updated when all moves are
successfully executed, and only discards orig_inode and donor_inode
preallocations when moved_len is not zero. When the loop fails to exit
after successfully moving some extents, moved_len is not updated and
remains at 0, so it does not discard the preallocations.
If the moved extents overlap with the preallocated extents, the
overlapped extents are freed twice in ext4_mb_release_inode_pa() and
ext4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4:
Fix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free is
incremented twice. Hence when trim is executed, a zero-division bug is
triggered in mb_update_avg_fragment_size() because bb_free is not zero
and bb_fragments is zero.
Therefore, update move_len after each extent move to avoid the issue. |
["https://git.kernel.org/stable/c/185eab30486ba3e7bf8b9c2e049c79a06ffd2bc1","https://git.kernel.org/stable/c/2883940b19c38d5884c8626483811acf4d7e148f","https://git.kernel.org/stable/c/55583e899a5357308274601364741a83e78d6ac4","https://git.kernel.org/stable/c/559ddacb90da1d8786dd8ec4fd76bbfa404eaef6","https://git.kernel.org/stable/c/afba9d11320dad5ce222ac8964caf64b7b4bedb1","https://git.kernel.org/stable/c/afbcad9ae7d6d11608399188f03a837451b6b3a1","https://git.kernel.org/stable/c/b4fbb89d722cbb16beaaea234b7230faaaf68c71","https://git.kernel.org/stable/c/d033a555d9a1cf53dbf3301af7199cc4a4c8f537","https://git.kernel.org/stable/c/185eab30486ba3e7bf8b9c2e049c79a06ffd2bc1","https://git.kernel.org/stable/c/2883940b19c38d5884c8626483811acf4d7e148f","https://git.kernel.org/stable/c/55583e899a5357308274601364741a83e78d6ac4","https://git.kernel.org/stable/c/559ddacb90da1d8786dd8ec4fd76bbfa404eaef6","https://git.kernel.org/stable/c/afba9d11320dad5ce222ac8964caf64b7b4bedb1","https://git.kernel.org/stable/c/afbcad9ae7d6d11608399188f03a837451b6b3a1","https://git.kernel.org/stable/c/b4fbb89d722cbb16beaaea234b7230faaaf68c71","https://git.kernel.org/stable/c/d033a555d9a1cf53dbf3301af7199cc4a4c8f537","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52451
|
High |
fixed |
- 4.19.306
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries/memhp: Fix access beyond end of drmem array
dlpar_memory_remove_by_index() may access beyond the bounds of the
drmem lmb array when the LMB lookup fails to match an entry with the
given DRC index. When the search fails, the cursor is left pointing to
&drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the
last valid entry in the array. The debug message at the end of the
function then dereferences this pointer:
pr_debug("Failed to hot-remove memory at %llx\n",
lmb->base_addr);
This was found by inspection and confirmed with KASAN:
pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234
==================================================================
BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658
Read of size 8 at addr c000000364e97fd0 by task bash/949
dump_stack_lvl+0xa4/0xfc (unreliable)
print_report+0x214/0x63c
kasan_report+0x140/0x2e0
__asan_load8+0xa8/0xe0
dlpar_memory+0x298/0x1658
handle_dlpar_errorlog+0x130/0x1d0
dlpar_store+0x18c/0x3e0
kobj_attr_store+0x68/0xa0
sysfs_kf_write+0xc4/0x110
kernfs_fop_write_iter+0x26c/0x390
vfs_write+0x2d4/0x4e0
ksys_write+0xac/0x1a0
system_call_exception+0x268/0x530
system_call_vectored_common+0x15c/0x2ec
Allocated by task 1:
kasan_save_stack+0x48/0x80
kasan_set_track+0x34/0x50
kasan_save_alloc_info+0x34/0x50
__kasan_kmalloc+0xd0/0x120
__kmalloc+0x8c/0x320
kmalloc_array.constprop.0+0x48/0x5c
drmem_init+0x2a0/0x41c
do_one_initcall+0xe0/0x5c0
kernel_init_freeable+0x4ec/0x5a0
kernel_init+0x30/0x1e0
ret_from_kernel_user_thread+0x14/0x1c
The buggy address belongs to the object at c000000364e80000
which belongs to the cache kmalloc-128k of size 131072
The buggy address is located 0 bytes to the right of
allocated 98256-byte region [c000000364e80000, c000000364e97fd0)
==================================================================
pseries-hotplug-mem: Failed to hot-remove memory at 0
Log failed lookups with a separate message and dereference the
cursor only when it points to a valid entry. |
["https://git.kernel.org/stable/c/026fd977dc50ff4a5e09bfb0603557f104d3f3a0","https://git.kernel.org/stable/c/708a4b59baad96c4718dc0bd3a3427d3ab22fedc","https://git.kernel.org/stable/c/999a27b3ce9a69d54ccd5db000ec3a447bc43e6d","https://git.kernel.org/stable/c/9b5f03500bc5b083c0df696d7dd169d7ef3dd0c7","https://git.kernel.org/stable/c/b582aa1f66411d4adcc1aa55b8c575683fb4687e","https://git.kernel.org/stable/c/bb79613a9a704469ddb8d6c6029d532a5cea384c","https://git.kernel.org/stable/c/bd68ffce69f6cf8ddd3a3c32549d1d2275e49fc5","https://git.kernel.org/stable/c/df16afba2378d985359812c865a15c05c70a967e","https://git.kernel.org/stable/c/026fd977dc50ff4a5e09bfb0603557f104d3f3a0","https://git.kernel.org/stable/c/708a4b59baad96c4718dc0bd3a3427d3ab22fedc","https://git.kernel.org/stable/c/999a27b3ce9a69d54ccd5db000ec3a447bc43e6d","https://git.kernel.org/stable/c/9b5f03500bc5b083c0df696d7dd169d7ef3dd0c7","https://git.kernel.org/stable/c/b582aa1f66411d4adcc1aa55b8c575683fb4687e","https://git.kernel.org/stable/c/bb79613a9a704469ddb8d6c6029d532a5cea384c","https://git.kernel.org/stable/c/bd68ffce69f6cf8ddd3a3c32549d1d2275e49fc5","https://git.kernel.org/stable/c/df16afba2378d985359812c865a15c05c70a967e","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52469
|
High |
fixed |
- 4.19.306
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
drivers/amd/pm: fix a use-after-free in kv_parse_power_table
When ps allocated by kzalloc equals to NULL, kv_parse_power_table
frees adev->pm.dpm.ps that allocated before. However, after the control
flow goes through the following call chains:
kv_parse_power_table
|-> kv_dpm_init
|-> kv_dpm_sw_init
|-> kv_dpm_fini
The adev->pm.dpm.ps is used in the for loop of kv_dpm_fini after its
first free in kv_parse_power_table and causes a use-after-free bug. |
["https://git.kernel.org/stable/c/28dd788382c43b330480f57cd34cde0840896743","https://git.kernel.org/stable/c/3426f059eacc33ecc676b0d66539297e1cfafd02","https://git.kernel.org/stable/c/35fa2394d26e919f63600ce631e6aefc95ec2706","https://git.kernel.org/stable/c/520e213a0b97b64735a13950e9371e0a5d7a5dc3","https://git.kernel.org/stable/c/8a27d9d9fc9b5564b8904c3a77a7dea482bfa34e","https://git.kernel.org/stable/c/8b55b06e737feb2a645b0293ea27e38418876d63","https://git.kernel.org/stable/c/95084632a65d5c0d682a83b55935560bdcd2a1e3","https://git.kernel.org/stable/c/b6dcba02ee178282e0d28684d241e0b8462dea6a","https://git.kernel.org/stable/c/28dd788382c43b330480f57cd34cde0840896743","https://git.kernel.org/stable/c/3426f059eacc33ecc676b0d66539297e1cfafd02","https://git.kernel.org/stable/c/35fa2394d26e919f63600ce631e6aefc95ec2706","https://git.kernel.org/stable/c/520e213a0b97b64735a13950e9371e0a5d7a5dc3","https://git.kernel.org/stable/c/8a27d9d9fc9b5564b8904c3a77a7dea482bfa34e","https://git.kernel.org/stable/c/8b55b06e737feb2a645b0293ea27e38418876d63","https://git.kernel.org/stable/c/95084632a65d5c0d682a83b55935560bdcd2a1e3","https://git.kernel.org/stable/c/b6dcba02ee178282e0d28684d241e0b8462dea6a","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26625
|
High |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
llc: call sock_orphan() at release time
syzbot reported an interesting trace [1] caused by a stale sk->sk_wq
pointer in a closed llc socket.
In commit ff7b11aa481f ("net: socket: set sock->sk to NULL after
calling proto_ops::release()") Eric Biggers hinted that some protocols
are missing a sock_orphan(), we need to perform a full audit.
In net-next, I plan to clear sock->sk from sock_orphan() and
amend Eric patch to add a warning.
[1]
BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline]
BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline]
BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline]
BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468
Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27
CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:377 [inline]
print_report+0xc4/0x620 mm/kasan/report.c:488
kasan_report+0xda/0x110 mm/kasan/report.c:601
list_empty include/linux/list.h:373 [inline]
waitqueue_active include/linux/wait.h:127 [inline]
sock_def_write_space_wfree net/core/sock.c:3384 [inline]
sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468
skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080
skb_release_all net/core/skbuff.c:1092 [inline]
napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404
e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970
e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline]
e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801
__napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576
napi_poll net/core/dev.c:6645 [inline]
net_rx_action+0x956/0xe90 net/core/dev.c:6778
__do_softirq+0x21a/0x8de kernel/softirq.c:553
run_ksoftirqd kernel/softirq.c:921 [inline]
run_ksoftirqd+0x31/0x60 kernel/softirq.c:913
smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164
kthread+0x2c6/0x3a0 kernel/kthread.c:388
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242
</TASK>
Allocated by task 5167:
kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
unpoison_slab_object mm/kasan/common.c:314 [inline]
__kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340
kasan_slab_alloc include/linux/kasan.h:201 [inline]
slab_post_alloc_hook mm/slub.c:3813 [inline]
slab_alloc_node mm/slub.c:3860 [inline]
kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879
alloc_inode_sb include/linux/fs.h:3019 [inline]
sock_alloc_inode+0x25/0x1c0 net/socket.c:308
alloc_inode+0x5d/0x220 fs/inode.c:260
new_inode_pseudo+0x16/0x80 fs/inode.c:1005
sock_alloc+0x40/0x270 net/socket.c:634
__sock_create+0xbc/0x800 net/socket.c:1535
sock_create net/socket.c:1622 [inline]
__sys_socket_create net/socket.c:1659 [inline]
__sys_socket+0x14c/0x260 net/socket.c:1706
__do_sys_socket net/socket.c:1720 [inline]
__se_sys_socket net/socket.c:1718 [inline]
__x64_sys_socket+0x72/0xb0 net/socket.c:1718
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Freed by task 0:
kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640
poison_slab_object mm/kasan/common.c:241 [inline]
__kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257
kasan_slab_free include/linux/kasan.h:184 [inline]
slab_free_hook mm/slub.c:2121 [inlin
---truncated--- |
["https://git.kernel.org/stable/c/3151051b787f7cd7e3329ea0016eb9113c248812","https://git.kernel.org/stable/c/64babb17e8150771c58575d8f93a35c5296b499f","https://git.kernel.org/stable/c/6b950c712a9a05cdda4aea7fcb2848766576c11b","https://git.kernel.org/stable/c/8e51f084b5716653f19e291ed5f026791d4b3ed4","https://git.kernel.org/stable/c/9c333d9891f34cea8af1b229dc754552304c8eee","https://git.kernel.org/stable/c/aa2b2eb3934859904c287bf5434647ba72e14c1c","https://git.kernel.org/stable/c/d0b5b1f12429df3cd9751ab8b2f53729b77733b7","https://git.kernel.org/stable/c/dbc1b89981f9c5360277071d33d7f04a43ffda4a","https://git.kernel.org/stable/c/3151051b787f7cd7e3329ea0016eb9113c248812","https://git.kernel.org/stable/c/64babb17e8150771c58575d8f93a35c5296b499f","https://git.kernel.org/stable/c/6b950c712a9a05cdda4aea7fcb2848766576c11b","https://git.kernel.org/stable/c/8e51f084b5716653f19e291ed5f026791d4b3ed4","https://git.kernel.org/stable/c/9c333d9891f34cea8af1b229dc754552304c8eee","https://git.kernel.org/stable/c/aa2b2eb3934859904c287bf5434647ba72e14c1c","https://git.kernel.org/stable/c/d0b5b1f12429df3cd9751ab8b2f53729b77733b7","https://git.kernel.org/stable/c/dbc1b89981f9c5360277071d33d7f04a43ffda4a","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52491
|
High |
fixed |
- 5.10.210
- 5.15.149
- 6.1.76
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_run
In mtk_jpeg_probe, &jpeg->job_timeout_work is bound with
mtk_jpeg_job_timeout_work.
In mtk_jpeg_dec_device_run, if error happens in
mtk_jpeg_set_dec_dst, it will finally start the worker while
mark the job as finished by invoking v4l2_m2m_job_finish.
There are two methods to trigger the bug. If we remove the
module, it which will call mtk_jpeg_remove to make cleanup.
The possible sequence is as follows, which will cause a
use-after-free bug.
CPU0 CPU1
mtk_jpeg_dec_... |
start worker |
|mtk_jpeg_job_timeout_work
mtk_jpeg_remove |
v4l2_m2m_release |
kfree(m2m_dev); |
|
| v4l2_m2m_get_curr_priv
| m2m_dev->curr_ctx //use
If we close the file descriptor, which will call mtk_jpeg_release,
it will have a similar sequence.
Fix this bug by starting timeout worker only if started jpegdec worker
successfully. Then v4l2_m2m_job_finish will only be called in
either mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run. |
["https://git.kernel.org/stable/c/1b1036c60a37a30caf6759a90fe5ecd06ec35590","https://git.kernel.org/stable/c/206c857dd17d4d026de85866f1b5f0969f2a109e","https://git.kernel.org/stable/c/43872f44eee6c6781fea1348b38885d8e78face9","https://git.kernel.org/stable/c/6e2f37022f0fc0893da4d85a0500c9d547fffd4c","https://git.kernel.org/stable/c/8254d54d00eb6cdb8367399c7f912eb8d354ecd7","https://git.kernel.org/stable/c/9fec4db7fff54d9b0306a332bab31eac47eeb5f6","https://git.kernel.org/stable/c/1b1036c60a37a30caf6759a90fe5ecd06ec35590","https://git.kernel.org/stable/c/206c857dd17d4d026de85866f1b5f0969f2a109e","https://git.kernel.org/stable/c/43872f44eee6c6781fea1348b38885d8e78face9","https://git.kernel.org/stable/c/6e2f37022f0fc0893da4d85a0500c9d547fffd4c","https://git.kernel.org/stable/c/8254d54d00eb6cdb8367399c7f912eb8d354ecd7","https://git.kernel.org/stable/c/9fec4db7fff54d9b0306a332bab31eac47eeb5f6","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50044
|
Low |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.57
- 6.11.4
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change
rfcomm_sk_state_change attempts to use sock_lock so it must never be
called with it locked but rfcomm_sock_ioctl always attempt to lock it
causing the following trace:
======================================================
WARNING: possible circular locking dependency detected
6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted
------------------------------------------------------
syz-executor386/5093 is trying to acquire lock:
ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline]
ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73
but task is already holding lock:
ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491 |
["https://git.kernel.org/stable/c/08d1914293dae38350b8088980e59fbc699a72fe","https://git.kernel.org/stable/c/38b2d5a57d125e1c17661b8308c0240c4a43b534","https://git.kernel.org/stable/c/496b2ab0fd10f205e08909a125485fdc98843dbe","https://git.kernel.org/stable/c/4cb9807c9b53bf1e5560420d26f319f528b50268","https://git.kernel.org/stable/c/869c6ee62ab8f01bf2419e45326642be5c9b670a","https://git.kernel.org/stable/c/b77b3fb12fd483cae7c28648903b1d8a6b275f01","https://git.kernel.org/stable/c/ced98072d3511b232ae1d3347945f35f30c0e303","https://git.kernel.org/stable/c/ef44274dae9b0a90d1a97ce8b242a3b8243a7745"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-30772
|
Medium |
fixed |
|
The Linux kernel before 6.2.9 has a race condition and resultant use-after-free in drivers/power/supply/da9150-charger.c if a physically proximate attacker unplugs a device. |
["https://bugzilla.suse.com/show_bug.cgi?id=1210329","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.9","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=06615d11cc78162dfd5116efb71f29eb29502d37","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://bugzilla.suse.com/show_bug.cgi?id=1210329","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.9","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=06615d11cc78162dfd5116efb71f29eb29502d37","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56745
|
Medium |
fixed |
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
PCI: Fix reset_method_store() memory leak
In reset_method_store(), a string is allocated via kstrndup() and assigned
to the local "options". options is then used in with strsep() to find
spaces:
while ((name = strsep(&options, " ")) != NULL) {
If there are no remaining spaces, then options is set to NULL by strsep(),
so the subsequent kfree(options) doesn't free the memory allocated via
kstrndup().
Fix by using a separate tmp_options to iterate with strsep() so options is
preserved. |
["https://git.kernel.org/stable/c/2985b1844f3f3447f2d938eff1ef6762592065a5","https://git.kernel.org/stable/c/403efb4457c0c8f8f51e904cc57d39193780c6bd","https://git.kernel.org/stable/c/543d0eb40e45c6a51f1bff02f417b602e54472d5","https://git.kernel.org/stable/c/8e098baf6bc3f3a6aefc383509aba07e202f7ee0","https://git.kernel.org/stable/c/931d07ccffcc3614f20aaf602b31e89754e21c59","https://git.kernel.org/stable/c/fe6fae61f3b993160aef5fe2b7141a83872c144f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49035
|
Medium |
fixed |
- 4.9.333
- 4.14.299
- 4.19.265
- 5.4.224
- 5.10.154
- 5.15.78
- 6.0.8
|
In the Linux kernel, the following vulnerability has been resolved:
media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZE
I expect that the hardware will have limited this to 16, but just in
case it hasn't, check for this corner case. |
["https://git.kernel.org/stable/c/1609231f86760c1f6a429de7913dd795b9faa08c","https://git.kernel.org/stable/c/2654e785bd4aa2439cdffbe7dc1ea30a0eddbfe4","https://git.kernel.org/stable/c/4a449430ecfb199b99ba58af63c467eb53500b39","https://git.kernel.org/stable/c/7ccb40f26cbefa1c6dfd3418bea54c9518cdbd8a","https://git.kernel.org/stable/c/93f65ce036863893c164ca410938e0968964b26c","https://git.kernel.org/stable/c/a2728bf9b6c65e46468c763e3dab7e04839d4e11","https://git.kernel.org/stable/c/cbfa26936f318b16ccf9ca31b8e8b30c0dc087bd","https://git.kernel.org/stable/c/fc0f76dd5f116fa9291327024dda392f8b4e849c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48656
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: ti: k3-udma-private: Fix refcount leak bug in of_xudma_dev_get()
We should call of_node_put() for the reference returned by
of_parse_phandle() in fail path or when it is not used anymore.
Here we only need to move the of_node_put() before the check. |
["https://git.kernel.org/stable/c/a17df55bf6d536712da6902a83db82b82e67d5a2","https://git.kernel.org/stable/c/aa11dae059a439af82bae541b134f8f53ac177b5","https://git.kernel.org/stable/c/dd5a6c5a08752b613e83ad2cb5133e72a64b876d","https://git.kernel.org/stable/c/f9fdb0b86f087c2b7f6c6168dd0985a3c1eda87e","https://git.kernel.org/stable/c/a17df55bf6d536712da6902a83db82b82e67d5a2","https://git.kernel.org/stable/c/aa11dae059a439af82bae541b134f8f53ac177b5","https://git.kernel.org/stable/c/dd5a6c5a08752b613e83ad2cb5133e72a64b876d","https://git.kernel.org/stable/c/f9fdb0b86f087c2b7f6c6168dd0985a3c1eda87e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48863
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mISDN: Fix memory leak in dsp_pipeline_build()
dsp_pipeline_build() allocates dup pointer by kstrdup(cfg),
but then it updates dup variable by strsep(&dup, "|").
As a result when it calls kfree(dup), the dup variable contains NULL.
Found by Linux Driver Verification project (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/640445d6fc059d4514ffea79eb4196299e0e2d0f","https://git.kernel.org/stable/c/7777b1f795af1bb43867375d8a776080111aae1b","https://git.kernel.org/stable/c/a3d5fcc6cf2ecbba5a269631092570aa285a24cb","https://git.kernel.org/stable/c/c6a502c2299941c8326d029cfc8a3bc8a4607ad5","https://git.kernel.org/stable/c/640445d6fc059d4514ffea79eb4196299e0e2d0f","https://git.kernel.org/stable/c/7777b1f795af1bb43867375d8a776080111aae1b","https://git.kernel.org/stable/c/a3d5fcc6cf2ecbba5a269631092570aa285a24cb","https://git.kernel.org/stable/c/c6a502c2299941c8326d029cfc8a3bc8a4607ad5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48865
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix kernel panic when enabling bearer
When enabling a bearer on a node, a kernel panic is observed:
[ 4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc]
...
[ 4.520030] Call Trace:
[ 4.520689] <IRQ>
[ 4.521236] tipc_link_build_proto_msg+0x375/0x750 [tipc]
[ 4.522654] tipc_link_build_state_msg+0x48/0xc0 [tipc]
[ 4.524034] __tipc_node_link_up+0xd7/0x290 [tipc]
[ 4.525292] tipc_rcv+0x5da/0x730 [tipc]
[ 4.526346] ? __netif_receive_skb_core+0xb7/0xfc0
[ 4.527601] tipc_l2_rcv_msg+0x5e/0x90 [tipc]
[ 4.528737] __netif_receive_skb_list_core+0x20b/0x260
[ 4.530068] netif_receive_skb_list_internal+0x1bf/0x2e0
[ 4.531450] ? dev_gro_receive+0x4c2/0x680
[ 4.532512] napi_complete_done+0x6f/0x180
[ 4.533570] virtnet_poll+0x29c/0x42e [virtio_net]
...
The node in question is receiving activate messages in another
thread after changing bearer status to allow message sending/
receiving in current thread:
thread 1 | thread 2
-------- | --------
|
tipc_enable_bearer() |
test_and_set_bit_lock() |
tipc_bearer_xmit_skb() |
| tipc_l2_rcv_msg()
| tipc_rcv()
| __tipc_node_link_up()
| tipc_link_build_state_msg()
| tipc_link_build_proto_msg()
| tipc_mon_prep()
| {
| ...
| // null-pointer dereference
| u16 gen = mon->dom_gen;
| ...
| }
// Not being executed yet |
tipc_mon_create() |
{ |
... |
// allocate |
mon = kzalloc(); |
... |
} |
Monitoring pointer in thread 2 is dereferenced before monitoring data
is allocated in thread 1. This causes kernel panic.
This commit fixes it by allocating the monitoring data before enabling
the bearer to receive messages. |
["https://git.kernel.org/stable/c/2de76d37d4a6dca9b96ea51da24d4290e6cfa1a5","https://git.kernel.org/stable/c/be4977b847f5d5cedb64d50eaaf2218c3a55a3a3","https://git.kernel.org/stable/c/f4f59fdbc748805b08c13dae14c01f0518c77c94","https://git.kernel.org/stable/c/f96dc3adb9a97b8f3dfdb88796483491a3006b71","https://git.kernel.org/stable/c/2de76d37d4a6dca9b96ea51da24d4290e6cfa1a5","https://git.kernel.org/stable/c/be4977b847f5d5cedb64d50eaaf2218c3a55a3a3","https://git.kernel.org/stable/c/f4f59fdbc748805b08c13dae14c01f0518c77c94","https://git.kernel.org/stable/c/f96dc3adb9a97b8f3dfdb88796483491a3006b71"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53187
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
io_uring: check for overflows in io_pin_pages
WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144
CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0
Call Trace:
<TASK>
__io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183
io_rings_map io_uring/io_uring.c:2611 [inline]
io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470
io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692
io_uring_setup io_uring/io_uring.c:3781 [inline]
...
</TASK>
io_pin_pages()'s uaddr parameter came directly from the user and can be
garbage. Don't just add size to it as it can overflow. |
["https://git.kernel.org/stable/c/0c0a4eae26ac78379d0c1db053de168a8febc6c9","https://git.kernel.org/stable/c/29eac3eca72d4c2a71122050c37cd7d8f73ac4f3","https://git.kernel.org/stable/c/aaa90844afd499c9142d0199dfda74439314c013"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56611
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM
We currently assume that there is at least one VMA in a MM, which isn't
true.
So we might end up having find_vma() return NULL, to then de-reference
NULL. So properly handle find_vma() returning NULL.
This fixes the report:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024
RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]
RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194
Code: ...
RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000
RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044
RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1
R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003
R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8
FS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709
__do_sys_migrate_pages mm/mempolicy.c:1727 [inline]
__se_sys_migrate_pages mm/mempolicy.c:1723 [inline]
__x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
[akpm@linux-foundation.org: add unlikely()] |
["https://git.kernel.org/stable/c/091c1dd2d4df6edd1beebe0e5863d4034ade9572","https://git.kernel.org/stable/c/42d9fe2adf8613f9eea1f0c2619c9e2611eae0ea","https://git.kernel.org/stable/c/a13b2b9b0b0b04612c7d81e3b3dfb485c5f7abc3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56657
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: control: Avoid WARN() for symlink errors
Using WARN() for showing the error of symlink creations don't give
more information than telling that something goes wrong, since the
usual code path is a lregister callback from each control element
creation. More badly, the use of WARN() rather confuses fuzzer as if
it were serious issues.
This patch downgrades the warning messages to use the normal dev_err()
instead of WARN(). For making it clearer, add the function name to
the prefix, too. |
["https://git.kernel.org/stable/c/36c0764474b637bbee498806485bed524cad486b","https://git.kernel.org/stable/c/b2e538a9827dd04ab5273bf4be8eb2edb84357b0","https://git.kernel.org/stable/c/d5a1ca7b59804d6779644001a878ed925a4688ca"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53224
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Move events notifier registration to be after device registration
Move pkey change work initialization and cleanup from device resources
stage to notifier stage, since this is the stage which handles this work
events.
Fix a race between the device deregistration and pkey change work by moving
MLX5_IB_STAGE_DEVICE_NOTIFIER to be after MLX5_IB_STAGE_IB_REG in order to
ensure that the notifier is deregistered before the device during cleanup.
Which ensures there are no works that are being executed after the
device has already unregistered which can cause the panic below.
BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 1 PID: 630071 Comm: kworker/1:2 Kdump: loaded Tainted: G W OE --------- --- 5.14.0-162.6.1.el9_1.x86_64 #1
Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 02/27/2023
Workqueue: events pkey_change_handler [mlx5_ib]
RIP: 0010:setup_qp+0x38/0x1f0 [mlx5_ib]
Code: ee 41 54 45 31 e4 55 89 f5 53 48 89 fb 48 83 ec 20 8b 77 08 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 48 8b 07 48 8d 4c 24 16 <4c> 8b 38 49 8b 87 80 0b 00 00 4c 89 ff 48 8b 80 08 05 00 00 8b 40
RSP: 0018:ffffbcc54068be20 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff954054494128 RCX: ffffbcc54068be36
RDX: ffff954004934000 RSI: 0000000000000001 RDI: ffff954054494128
RBP: 0000000000000023 R08: ffff954001be2c20 R09: 0000000000000001
R10: ffff954001be2c20 R11: ffff9540260133c0 R12: 0000000000000000
R13: 0000000000000023 R14: 0000000000000000 R15: ffff9540ffcb0905
FS: 0000000000000000(0000) GS:ffff9540ffc80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000010625c001 CR4: 00000000003706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
mlx5_ib_gsi_pkey_change+0x20/0x40 [mlx5_ib]
process_one_work+0x1e8/0x3c0
worker_thread+0x50/0x3b0
? rescuer_thread+0x380/0x380
kthread+0x149/0x170
? set_kthread_struct+0x50/0x50
ret_from_fork+0x22/0x30
Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) mlx5_fwctl(OE) fwctl(OE) ib_uverbs(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlx_compat(OE) psample mlxfw(OE) tls knem(OE) netconsole nfsv3 nfs_acl nfs lockd grace fscache netfs qrtr rfkill sunrpc intel_rapl_msr intel_rapl_common rapl hv_balloon hv_utils i2c_piix4 pcspkr joydev fuse ext4 mbcache jbd2 sr_mod sd_mod cdrom t10_pi sg ata_generic pci_hyperv pci_hyperv_intf hyperv_drm drm_shmem_helper drm_kms_helper hv_storvsc syscopyarea hv_netvsc sysfillrect sysimgblt hid_hyperv fb_sys_fops scsi_transport_fc hyperv_keyboard drm ata_piix crct10dif_pclmul crc32_pclmul crc32c_intel libata ghash_clmulni_intel hv_vmbus serio_raw [last unloaded: ib_core]
CR2: 0000000000000000
---[ end trace f6f8be4eae12f7bc ]--- |
["https://git.kernel.org/stable/c/542bd62b7a7f37182c9ef192c2bd25d118c144e4","https://git.kernel.org/stable/c/6b0acf6a94c31efa43fce4edc22413a3390f9c05","https://git.kernel.org/stable/c/921fcf2971a1e8d3b904ba2c2905b96f4ec3d4ad","https://git.kernel.org/stable/c/ede132a5cf559f3ab35a4c28bac4f4a6c20334d8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56557
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xfer
The AD7923 was updated to support devices with 8 channels, but the size
of tx_buf and ring_xfer was not increased accordingly, leading to a
potential buffer overflow in ad7923_update_scan_mode(). |
["https://git.kernel.org/stable/c/00663d3e000c31d0d49ef86a809f5c107c2d09cd","https://git.kernel.org/stable/c/218ecc35949129171ca39bcc0d407c8dc4cd0bbc","https://git.kernel.org/stable/c/3a4187ec454e19903fd15f6e1825a4b84e59a4cd","https://git.kernel.org/stable/c/e5cac32721997cb8bcb208a29f4598b3faf46338"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53151
|
Medium |
fixed |
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
svcrdma: Address an integer overflow
Dan Carpenter reports:
> Commit 78147ca8b4a9 ("svcrdma: Add a "parsed chunk list" data
> structure") from Jun 22, 2020 (linux-next), leads to the following
> Smatch static checker warning:
>
> net/sunrpc/xprtrdma/svc_rdma_recvfrom.c:498 xdr_check_write_chunk()
> warn: potential user controlled sizeof overflow 'segcount * 4 * 4'
>
> net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
> 488 static bool xdr_check_write_chunk(struct svc_rdma_recv_ctxt *rctxt)
> 489 {
> 490 u32 segcount;
> 491 __be32 *p;
> 492
> 493 if (xdr_stream_decode_u32(&rctxt->rc_stream, &segcount))
> ^^^^^^^^
>
> 494 return false;
> 495
> 496 /* A bogus segcount causes this buffer overflow check to fail. */
> 497 p = xdr_inline_decode(&rctxt->rc_stream,
> --> 498 segcount * rpcrdma_segment_maxsz * sizeof(*p));
>
>
> segcount is an untrusted u32. On 32bit systems anything >= SIZE_MAX / 16 will
> have an integer overflow and some those values will be accepted by
> xdr_inline_decode(). |
["https://git.kernel.org/stable/c/21e1cf688fb0397788c8dd42e1e0b08d58ac5c7b","https://git.kernel.org/stable/c/3c63d8946e578663b868cb9912dac616ea68bfd0","https://git.kernel.org/stable/c/4cbc3ba6dc2f746497cade60bcbaa82ae3696689","https://git.kernel.org/stable/c/838dd342962cef4c320632a5af48d3c31f2f9877","https://git.kernel.org/stable/c/c1f8195bf68edd2cef0f18a4cead394075a54b5a","https://git.kernel.org/stable/c/e5c440c227ecdc721f2da0dd88b6358afd1031a7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1195
|
Medium |
fixed |
|
A use-after-free flaw was found in reconn_set_ipaddr_from_hostname in fs/cifs/connect.c in the Linux kernel. The issue occurs when it forgets to set the free pointer server->hostname to NULL, leading to an invalid pointer request. |
["https://github.com/torvalds/linux/commit/153695d36ead0ccc4d0256953c751cabf673e621","https://github.com/torvalds/linux/commit/153695d36ead0ccc4d0256953c751cabf673e621"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53079
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mm/thp: fix deferred split unqueue naming and locking
Recent changes are putting more pressure on THP deferred split queues:
under load revealing long-standing races, causing list_del corruptions,
"Bad page state"s and worse (I keep BUGs in both of those, so usually
don't get to see how badly they end up without). The relevant recent
changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin,
improved swap allocation, and underused THP splitting.
Before fixing locking: rename misleading folio_undo_large_rmappable(),
which does not undo large_rmappable, to folio_unqueue_deferred_split(),
which is what it does. But that and its out-of-line __callee are mm
internals of very limited usability: add comment and WARN_ON_ONCEs to
check usage; and return a bool to say if a deferred split was unqueued,
which can then be used in WARN_ON_ONCEs around safety checks (sparing
callers the arcane conditionals in __folio_unqueue_deferred_split()).
Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all
of whose callers now call it beforehand (and if any forget then bad_page()
will tell) - except for its caller put_pages_list(), which itself no
longer has any callers (and will be deleted separately).
Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0
without checking and unqueueing a THP folio from deferred split list;
which is unfortunate, since the split_queue_lock depends on the memcg
(when memcg is enabled); so swapout has been unqueueing such THPs later,
when freeing the folio, using the pgdat's lock instead: potentially
corrupting the memcg's list. __remove_mapping() has frozen refcount to 0
here, so no problem with calling folio_unqueue_deferred_split() before
resetting memcg_data.
That goes back to 5.4 commit 87eaceb3faa5 ("mm: thp: make deferred split
shrinker memcg aware"): which included a check on swapcache before adding
to deferred queue, but no check on deferred queue before adding THP to
swapcache. That worked fine with the usual sequence of events in reclaim
(though there were a couple of rare ways in which a THP on deferred queue
could have been swapped out), but 6.12 commit dafff3f4c850 ("mm: split
underused THPs") avoids splitting underused THPs in reclaim, which makes
swapcache THPs on deferred queue commonplace.
Keep the check on swapcache before adding to deferred queue? Yes: it is
no longer essential, but preserves the existing behaviour, and is likely
to be a worthwhile optimization (vmstat showed much more traffic on the
queue under swapping load if the check was removed); update its comment.
Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changing
folio->memcg_data without checking and unqueueing a THP folio from the
deferred list, sometimes corrupting "from" memcg's list, like swapout.
Refcount is non-zero here, so folio_unqueue_deferred_split() can only be
used in a WARN_ON_ONCE to validate the fix, which must be done earlier:
mem_cgroup_move_charge_pte_range() first try to split the THP (splitting
of course unqueues), or skip it if that fails. Not ideal, but moving
charge has been requested, and khugepaged should repair the THP later:
nobody wants new custom unqueueing code just for this deprecated case.
The 87eaceb3faa5 commit did have the code to move from one deferred list
to another (but was not conscious of its unsafety while refcount non-0);
but that was removed by 5.6 commit fac0516b5534 ("mm: thp: don't need care
deferred split queue in memcg charge move path"), which argued that the
existence of a PMD mapping guarantees that the THP cannot be on a deferred
list. As above, false in rare cases, and now commonly false.
Backport to 6.11 should be straightforward. Earlier backports must take
care that other _deferred_list fixes and dependencies are included. There
is not a strong case for backports, but they can fix cornercases. |
["https://git.kernel.org/stable/c/afb1352d06b1b6b2cfd1f901c766a430c87078b3","https://git.kernel.org/stable/c/f8f931bba0f92052cf842b7e30917b1afcc77d5a","https://git.kernel.org/stable/c/fc4951c3e3358dd82ea508e893695b916c813f17"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3110
|
Medium |
fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. _rtw_init_xmit_priv in drivers/staging/r8188eu/core/rtw_xmit.c lacks check of the return value of rtw_alloc_hwxmits() and will cause the null pointer dereference. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2153055","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=f94b47c6bde624d6c07f43054087607c52054a95","https://bugzilla.redhat.com/show_bug.cgi?id=2153055","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=f94b47c6bde624d6c07f43054087607c52054a95"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26660
|
Medium |
fixed |
- 5.15.149
- 6.1.78
- 6.6.17
- 6.7.5
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Implement bounds check for stream encoder creation in DCN301
'stream_enc_regs' array is an array of dcn10_stream_enc_registers
structures. The array is initialized with four elements, corresponding
to the four calls to stream_enc_regs() in the array initializer. This
means that valid indices for this array are 0, 1, 2, and 3.
The error message 'stream_enc_regs' 4 <= 5 below, is indicating that
there is an attempt to access this array with an index of 5, which is
out of bounds. This could lead to undefined behavior
Here, eng_id is used as an index to access the stream_enc_regs array. If
eng_id is 5, this would result in an out-of-bounds access on the
stream_enc_regs array.
Thus fixing Buffer overflow error in dcn301_stream_encoder_create
reported by Smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn301/dcn301_resource.c:1011 dcn301_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5 |
["https://git.kernel.org/stable/c/42442f74314d41ddc68227047036fa3e78940054","https://git.kernel.org/stable/c/58fca355ad37dcb5f785d9095db5f748b79c5dc2","https://git.kernel.org/stable/c/a938eab9586eea31cfd129a507f552efae14d738","https://git.kernel.org/stable/c/cd9bd10c59e3c1446680514fd3097c5b00d3712d","https://git.kernel.org/stable/c/efdd665ce1a1634b8c1dad5e7f6baaef3e131d0a","https://git.kernel.org/stable/c/42442f74314d41ddc68227047036fa3e78940054","https://git.kernel.org/stable/c/58fca355ad37dcb5f785d9095db5f748b79c5dc2","https://git.kernel.org/stable/c/a938eab9586eea31cfd129a507f552efae14d738","https://git.kernel.org/stable/c/cd9bd10c59e3c1446680514fd3097c5b00d3712d","https://git.kernel.org/stable/c/efdd665ce1a1634b8c1dad5e7f6baaef3e131d0a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52631
|
Medium |
fixed |
- 5.15.149
- 6.1.78
- 6.6.17
- 6.7.5
|
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix an NULL dereference bug
The issue here is when this is called from ntfs_load_attr_list(). The
"size" comes from le32_to_cpu(attr->res.data_size) so it can't overflow
on a 64bit systems but on 32bit systems the "+ 1023" can overflow and
the result is zero. This means that the kmalloc will succeed by
returning the ZERO_SIZE_PTR and then the memcpy() will crash with an
Oops on the next line. |
["https://git.kernel.org/stable/c/686820fe141ea0220fc6fdfc7e5694f915cf64b2","https://git.kernel.org/stable/c/ae4acad41b0f93f1c26cc0fc9135bb79d8282d0b","https://git.kernel.org/stable/c/b2dd7b953c25ffd5912dda17e980e7168bebcf6c","https://git.kernel.org/stable/c/ec1bedd797588fe38fc11cba26d77bb1d9b194c6","https://git.kernel.org/stable/c/fb7bcd1722bc9bc55160378f5f99c01198fd14a7","https://git.kernel.org/stable/c/686820fe141ea0220fc6fdfc7e5694f915cf64b2","https://git.kernel.org/stable/c/ae4acad41b0f93f1c26cc0fc9135bb79d8282d0b","https://git.kernel.org/stable/c/b2dd7b953c25ffd5912dda17e980e7168bebcf6c","https://git.kernel.org/stable/c/ec1bedd797588fe38fc11cba26d77bb1d9b194c6","https://git.kernel.org/stable/c/fb7bcd1722bc9bc55160378f5f99c01198fd14a7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52641
|
Medium |
fixed |
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Add NULL ptr dereference checking at the end of attr_allocate_frame()
It is preferable to exit through the out: label because
internal debugging functions are located there. |
["https://git.kernel.org/stable/c/50545eb6cd5f7ff852a01fa29b7372524ef948cc","https://git.kernel.org/stable/c/847b68f58c212f0439c5a8101b3841f32caffccd","https://git.kernel.org/stable/c/947c3f3d31ea185ddc8e7f198873f17d36deb24c","https://git.kernel.org/stable/c/aaab47f204aaf47838241d57bf8662c8840de60a","https://git.kernel.org/stable/c/ee8db6475cb15c8122855f72ad4cfa5375af6a7b","https://git.kernel.org/stable/c/50545eb6cd5f7ff852a01fa29b7372524ef948cc","https://git.kernel.org/stable/c/847b68f58c212f0439c5a8101b3841f32caffccd","https://git.kernel.org/stable/c/947c3f3d31ea185ddc8e7f198873f17d36deb24c","https://git.kernel.org/stable/c/aaab47f204aaf47838241d57bf8662c8840de60a","https://git.kernel.org/stable/c/ee8db6475cb15c8122855f72ad4cfa5375af6a7b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49901
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
blk-mq: Fix kmemleak in blk_mq_init_allocated_queue
There is a kmemleak caused by modprobe null_blk.ko
unreferenced object 0xffff8881acb1f000 (size 1024):
comm "modprobe", pid 836, jiffies 4294971190 (age 27.068s)
hex dump (first 32 bytes):
00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff .........S......
backtrace:
[<000000004a10c249>] kmalloc_node_trace+0x22/0x60
[<00000000648f7950>] blk_mq_alloc_and_init_hctx+0x289/0x350
[<00000000af06de0e>] blk_mq_realloc_hw_ctxs+0x2fe/0x3d0
[<00000000e00c1872>] blk_mq_init_allocated_queue+0x48c/0x1440
[<00000000d16b4e68>] __blk_mq_alloc_disk+0xc8/0x1c0
[<00000000d10c98c3>] 0xffffffffc450d69d
[<00000000b9299f48>] 0xffffffffc4538392
[<0000000061c39ed6>] do_one_initcall+0xd0/0x4f0
[<00000000b389383b>] do_init_module+0x1a4/0x680
[<0000000087cf3542>] load_module+0x6249/0x7110
[<00000000beba61b8>] __do_sys_finit_module+0x140/0x200
[<00000000fdcfff51>] do_syscall_64+0x35/0x80
[<000000003c0f1f71>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
That is because q->ma_ops is set to NULL before blk_release_queue is
called.
blk_mq_init_queue_data
blk_mq_init_allocated_queue
blk_mq_realloc_hw_ctxs
for (i = 0; i < set->nr_hw_queues; i++) {
old_hctx = xa_load(&q->hctx_table, i);
if (!blk_mq_alloc_and_init_hctx(.., i, ..)) [1]
if (!old_hctx)
break;
xa_for_each_start(&q->hctx_table, j, hctx, j)
blk_mq_exit_hctx(q, set, hctx, j); [2]
if (!q->nr_hw_queues) [3]
goto err_hctxs;
err_exit:
q->mq_ops = NULL; [4]
blk_put_queue
blk_release_queue
if (queue_is_mq(q)) [5]
blk_mq_release(q);
[1]: blk_mq_alloc_and_init_hctx failed at i != 0.
[2]: The hctxs allocated by [1] are moved to q->unused_hctx_list and
will be cleaned up in blk_mq_release.
[3]: q->nr_hw_queues is 0.
[4]: Set q->mq_ops to NULL.
[5]: queue_is_mq returns false due to [4]. And blk_mq_release
will not be called. The hctxs in q->unused_hctx_list are leaked.
To fix it, call blk_release_queue in exception path. |
["https://git.kernel.org/stable/c/2dc97e15a54b7bdf457848aa8c663c98a24e58a6","https://git.kernel.org/stable/c/943f45b9399ed8b2b5190cbc797995edaa97f58f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52939
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mm: memcg: fix NULL pointer in mem_cgroup_track_foreign_dirty_slowpath()
As commit 18365225f044 ("hwpoison, memcg: forcibly uncharge LRU pages"),
hwpoison will forcibly uncharg a LRU hwpoisoned page, the folio_memcg
could be NULl, then, mem_cgroup_track_foreign_dirty_slowpath() could
occurs a NULL pointer dereference, let's do not record the foreign
writebacks for folio memcg is null in mem_cgroup_track_foreign_dirty() to
fix it. |
["https://git.kernel.org/stable/c/ac86f547ca1002aec2ef66b9e64d03f45bbbfbb9","https://git.kernel.org/stable/c/b79ba5953f6fdc5559389ad415620bffc24f024b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-53001
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/drm_vma_manager: Add drm_vma_node_allow_once()
Currently there is no easy way for a drm driver to safely check and allow
drm_vma_offset_node for a drm file just once. Allow drm drivers to call
non-refcounted version of drm_vma_node_allow() so that a driver doesn't
need to keep track of each drm_vma_node_allow() to call subsequent
drm_vma_node_revoke() to prevent memory leak. |
["https://git.kernel.org/stable/c/67444f8ca31cdaf45e0b761241ad49b1ae04bcf9","https://git.kernel.org/stable/c/899d3a3c19ac0e5da013ce34833dccb97d19b5e4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-53008
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix potential memory leaks in session setup
Make sure to free cifs_ses::auth_key.response before allocating it as
we might end up leaking memory in reconnect or mounting. |
["https://git.kernel.org/stable/c/2fe58d977ee05da5bb89ef5dc4f5bf2dc15db46f","https://git.kernel.org/stable/c/893d45394dbe4b5cbf3723c19e2ccc8b93a6ac9b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-58097
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix RCU stall while reaping monitor destination ring
While processing the monitor destination ring, MSDUs are reaped from the
link descriptor based on the corresponding buf_id.
However, sometimes the driver cannot obtain a valid buffer corresponding
to the buf_id received from the hardware. This causes an infinite loop
in the destination processing, resulting in a kernel crash.
kernel log:
ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309
ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed
ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309
ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed
Fix this by skipping the problematic buf_id and reaping the next entry,
replacing the break with the next MSDU processing.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 |
["https://git.kernel.org/stable/c/16c6c35c03ea73054a1f6d3302a4ce4a331b427d","https://git.kernel.org/stable/c/b4991fc41745645f8050506f5a8578bd11e6b378"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-37925
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
jfs: reject on-disk inodes of an unsupported type
Syzbot has reported the following BUG:
kernel BUG at fs/inode.c:668!
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 3 UID: 0 PID: 139 Comm: jfsCommit Not tainted 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
RIP: 0010:clear_inode+0x168/0x190
Code: 4c 89 f7 e8 ba fe e5 ff e9 61 ff ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 7c c1 4c 89 f7 e8 90 ff e5 ff eb b7
0b e8 01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7f
RSP: 0018:ffffc900027dfae8 EFLAGS: 00010093
RAX: ffffffff82157a87 RBX: 0000000000000001 RCX: ffff888104d4b980
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffffc900027dfc90 R08: ffffffff82157977 R09: fffff520004fbf38
R10: dffffc0000000000 R11: fffff520004fbf38 R12: dffffc0000000000
R13: ffff88811315bc00 R14: ffff88811315bda8 R15: ffff88811315bb80
FS: 0000000000000000(0000) GS:ffff888135f00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005565222e0578 CR3: 0000000026ef0000 CR4: 00000000000006f0
Call Trace:
<TASK>
? __die_body+0x5f/0xb0
? die+0x9e/0xc0
? do_trap+0x15a/0x3a0
? clear_inode+0x168/0x190
? do_error_trap+0x1dc/0x2c0
? clear_inode+0x168/0x190
? __pfx_do_error_trap+0x10/0x10
? report_bug+0x3cd/0x500
? handle_invalid_op+0x34/0x40
? clear_inode+0x168/0x190
? exc_invalid_op+0x38/0x50
? asm_exc_invalid_op+0x1a/0x20
? clear_inode+0x57/0x190
? clear_inode+0x167/0x190
? clear_inode+0x168/0x190
? clear_inode+0x167/0x190
jfs_evict_inode+0xb5/0x440
? __pfx_jfs_evict_inode+0x10/0x10
evict+0x4ea/0x9b0
? __pfx_evict+0x10/0x10
? iput+0x713/0xa50
txUpdateMap+0x931/0xb10
? __pfx_txUpdateMap+0x10/0x10
jfs_lazycommit+0x49a/0xb80
? _raw_spin_unlock_irqrestore+0x8f/0x140
? lockdep_hardirqs_on+0x99/0x150
? __pfx_jfs_lazycommit+0x10/0x10
? __pfx_default_wake_function+0x10/0x10
? __kthread_parkme+0x169/0x1d0
? __pfx_jfs_lazycommit+0x10/0x10
kthread+0x2f2/0x390
? __pfx_jfs_lazycommit+0x10/0x10
? __pfx_kthread+0x10/0x10
ret_from_fork+0x4d/0x80
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
This happens when 'clear_inode()' makes an attempt to finalize an underlying
JFS inode of unknown type. According to JFS layout description from
https://jfs.sourceforge.net/project/pub/jfslayout.pdf, inode types from 5 to
15 are reserved for future extensions and should not be encountered on a valid
filesystem. So add an extra check for valid inode type in 'copy_from_dinode()'. |
["https://git.kernel.org/stable/c/8987891c4653874d5e3f5d11f063912f4e0b58eb","https://git.kernel.org/stable/c/8c3f9a70d2d4dd6c640afe294b05c6a0a45434d9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26641
|
Medium |
fixed |
- 5.10.210
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()
syzbot found __ip6_tnl_rcv() could access unitiliazed data [1].
Call pskb_inet_may_pull() to fix this, and initialize ipv6h
variable after this call as it can change skb->head.
[1]
BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321
__INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321
ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727
__ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845
ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888
gre_rcv+0x143f/0x1870
ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438
ip6_input_finish net/ipv6/ip6_input.c:483 [inline]
NF_HOOK include/linux/netfilter.h:314 [inline]
ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492
ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586
dst_input include/net/dst.h:461 [inline]
ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79
NF_HOOK include/linux/netfilter.h:314 [inline]
ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310
__netif_receive_skb_one_core net/core/dev.c:5532 [inline]
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646
netif_receive_skb_internal net/core/dev.c:5732 [inline]
netif_receive_skb+0x58/0x660 net/core/dev.c:5791
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
call_write_iter include/linux/fs.h:2084 [inline]
new_sync_write fs/read_write.c:497 [inline]
vfs_write+0x786/0x1200 fs/read_write.c:590
ksys_write+0x20f/0x4c0 fs/read_write.c:643
__do_sys_write fs/read_write.c:655 [inline]
__se_sys_write fs/read_write.c:652 [inline]
__x64_sys_write+0x93/0xd0 fs/read_write.c:652
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at:
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
slab_alloc_node mm/slub.c:3478 [inline]
kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
__alloc_skb+0x318/0x740 net/core/skbuff.c:651
alloc_skb include/linux/skbuff.h:1286 [inline]
alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334
sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787
tun_alloc_skb drivers/net/tun.c:1531 [inline]
tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
call_write_iter include/linux/fs.h:2084 [inline]
new_sync_write fs/read_write.c:497 [inline]
vfs_write+0x786/0x1200 fs/read_write.c:590
ksys_write+0x20f/0x4c0 fs/read_write.c:643
__do_sys_write fs/read_write.c:655 [inline]
__se_sys_write fs/read_write.c:652 [inline]
__x64_sys_write+0x93/0xd0 fs/read_write.c:652
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
CPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 |
["https://git.kernel.org/stable/c/350a6640fac4b53564ec20aa3f4a0922cb0ba5e6","https://git.kernel.org/stable/c/8d975c15c0cd744000ca386247432d57b21f9df0","https://git.kernel.org/stable/c/a9bc32879a08f23cdb80a48c738017e39aea1080","https://git.kernel.org/stable/c/af6b5c50d47ab43e5272ad61935d0ed2e264d3f0","https://git.kernel.org/stable/c/c835df3bcc14858ae9b27315dd7de76370b94f3a","https://git.kernel.org/stable/c/d54e4da98bbfa8c257bdca94c49652d81d18a4d8","https://git.kernel.org/stable/c/350a6640fac4b53564ec20aa3f4a0922cb0ba5e6","https://git.kernel.org/stable/c/8d975c15c0cd744000ca386247432d57b21f9df0","https://git.kernel.org/stable/c/a9bc32879a08f23cdb80a48c738017e39aea1080","https://git.kernel.org/stable/c/af6b5c50d47ab43e5272ad61935d0ed2e264d3f0","https://git.kernel.org/stable/c/c835df3bcc14858ae9b27315dd7de76370b94f3a","https://git.kernel.org/stable/c/d54e4da98bbfa8c257bdca94c49652d81d18a4d8","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://security.netapp.com/advisory/ntap-20241108-0008/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26840
|
Medium |
fixed |
- 4.19.309
- 5.4.271
- 5.10.212
- 5.15.151
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
cachefiles: fix memory leak in cachefiles_add_cache()
The following memory leak was reported after unbinding /dev/cachefiles:
==================================================================
unreferenced object 0xffff9b674176e3c0 (size 192):
comm "cachefilesd2", pid 680, jiffies 4294881224
hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc ea38a44b):
[<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370
[<ffffffff8e917f86>] prepare_creds+0x26/0x2e0
[<ffffffffc002eeef>] cachefiles_determine_cache_security+0x1f/0x120
[<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0
[<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0
[<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520
[<ffffffff8ebc5069>] ksys_write+0x69/0xf0
[<ffffffff8f6d4662>] do_syscall_64+0x72/0x140
[<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
==================================================================
Put the reference count of cache_cred in cachefiles_daemon_unbind() to
fix the problem. And also put cache_cred in cachefiles_add_cache() error
branch to avoid memory leaks. |
["https://git.kernel.org/stable/c/037d5a949b0455540ef9aab34c10ddf54b65d285","https://git.kernel.org/stable/c/38e921616320d159336b0ffadb09e9fb4945c7c3","https://git.kernel.org/stable/c/43eccc5823732ba6daab2511ed32dfc545a666d8","https://git.kernel.org/stable/c/8b218e2f0a27a9f09428b1847b4580640b9d1e58","https://git.kernel.org/stable/c/94965be37add0983672e48ecb33cdbda92b62579","https://git.kernel.org/stable/c/9cac69912052a4def571fedf1cb9bb4ec590e25a","https://git.kernel.org/stable/c/cb5466783793e66272624cf71925ae1d1ba32083","https://git.kernel.org/stable/c/e21a2f17566cbd64926fb8f16323972f7a064444","https://git.kernel.org/stable/c/037d5a949b0455540ef9aab34c10ddf54b65d285","https://git.kernel.org/stable/c/38e921616320d159336b0ffadb09e9fb4945c7c3","https://git.kernel.org/stable/c/43eccc5823732ba6daab2511ed32dfc545a666d8","https://git.kernel.org/stable/c/8b218e2f0a27a9f09428b1847b4580640b9d1e58","https://git.kernel.org/stable/c/94965be37add0983672e48ecb33cdbda92b62579","https://git.kernel.org/stable/c/9cac69912052a4def571fedf1cb9bb4ec590e25a","https://git.kernel.org/stable/c/cb5466783793e66272624cf71925ae1d1ba32083","https://git.kernel.org/stable/c/e21a2f17566cbd64926fb8f16323972f7a064444","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3159
|
Medium |
fixed |
|
A use after free issue was discovered in driver/firewire in outbound_phy_packet_callback in the Linux Kernel. In this flaw a local attacker with special privilege may cause a use after free problem when queue_event() fails. |
["https://github.com/torvalds/linux/commit/b7c81f80246fac44077166f3e07103affe6db8ff","https://github.com/torvalds/linux/commit/b7c81f80246fac44077166f3e07103affe6db8ff"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-6238
|
Medium |
|
N/A
|
A buffer overflow vulnerability was found in the NVM Express (NVMe) driver in the Linux kernel. Only privileged user could specify a small meta buffer and let the device perform larger Direct Memory Access (DMA) into the same buffer, overwriting unrelated kernel memory, causing random kernel crashes and memory corruption. |
["https://access.redhat.com/security/cve/CVE-2023-6238","https://bugzilla.redhat.com/show_bug.cgi?id=2250834","https://access.redhat.com/security/cve/CVE-2023-6238","https://bugzilla.redhat.com/show_bug.cgi?id=2250834"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26672
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix variable 'mca_funcs' dereferenced before NULL check in 'amdgpu_mca_smu_get_mca_entry()'
Fixes the below:
drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c:377 amdgpu_mca_smu_get_mca_entry() warn: variable dereferenced before check 'mca_funcs' (see line 368)
357 int amdgpu_mca_smu_get_mca_entry(struct amdgpu_device *adev,
enum amdgpu_mca_error_type type,
358 int idx, struct mca_bank_entry *entry)
359 {
360 const struct amdgpu_mca_smu_funcs *mca_funcs =
adev->mca.mca_funcs;
361 int count;
362
363 switch (type) {
364 case AMDGPU_MCA_ERROR_TYPE_UE:
365 count = mca_funcs->max_ue_count;
mca_funcs is dereferenced here.
366 break;
367 case AMDGPU_MCA_ERROR_TYPE_CE:
368 count = mca_funcs->max_ce_count;
mca_funcs is dereferenced here.
369 break;
370 default:
371 return -EINVAL;
372 }
373
374 if (idx >= count)
375 return -EINVAL;
376
377 if (mca_funcs && mca_funcs->mca_get_mca_entry)
^^^^^^^^^
Checked too late! |
["https://git.kernel.org/stable/c/4f32504a2f85a7b40fe149436881381f48e9c0c0","https://git.kernel.org/stable/c/7b5d58c07024516c0e81b95e98f37710cf402c53","https://git.kernel.org/stable/c/4f32504a2f85a7b40fe149436881381f48e9c0c0","https://git.kernel.org/stable/c/7b5d58c07024516c0e81b95e98f37710cf402c53"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52588
|
High |
fixed |
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to tag gcing flag on page during block migration
It needs to add missing gcing flag on page during block migration,
in order to garantee migrated data be persisted during checkpoint,
otherwise out-of-order persistency between data and node may cause
data corruption after SPOR.
Similar issue was fixed by commit 2d1fe8a86bf5 ("f2fs: fix to tag
gcing flag on page during file defragment"). |
["https://git.kernel.org/stable/c/417b8a91f4e8831cadaf85c3f15c6991c1f54dde","https://git.kernel.org/stable/c/4961acdd65c956e97c1a000c82d91a8c1cdbe44b","https://git.kernel.org/stable/c/7c972c89457511007dfc933814c06786905e515c","https://git.kernel.org/stable/c/7ea0f29d9fd84905051be020c0df7d557e286136","https://git.kernel.org/stable/c/b8094c0f1aae329b1c60a275a780d6c2c9ff7aa3","https://git.kernel.org/stable/c/417b8a91f4e8831cadaf85c3f15c6991c1f54dde","https://git.kernel.org/stable/c/4961acdd65c956e97c1a000c82d91a8c1cdbe44b","https://git.kernel.org/stable/c/7c972c89457511007dfc933814c06786905e515c","https://git.kernel.org/stable/c/7ea0f29d9fd84905051be020c0df7d557e286136","https://git.kernel.org/stable/c/b8094c0f1aae329b1c60a275a780d6c2c9ff7aa3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46870
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Disable DMCUB timeout for DCN35
[Why]
DMCUB can intermittently take longer than expected to process commands.
Old ASIC policy was to continue while logging a diagnostic error - which
works fine for ASIC without IPS, but with IPS this could lead to a race
condition where we attempt to access DCN state while it's inaccessible,
leading to a system hang when the NIU port is not disabled or register
accesses that timeout and the display configuration in an undefined
state.
[How]
We need to investigate why these accesses take longer than expected, but
for now we should disable the timeout on DCN35 to avoid this race
condition. Since the waits happen only at lower interrupt levels the
risk of taking too long at higher IRQ and causing a system watchdog
timeout are minimal. |
["https://git.kernel.org/stable/c/31c254c9cd4b122a10db297124f867107a696d83","https://git.kernel.org/stable/c/7c70e60fbf4bff1123f0e8d5cb1ae71df6164d7f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50183
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance
Deleting an NPIV instance requires all fabric ndlps to be released before
an NPIV's resources can be torn down. Failure to release fabric ndlps
beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID
to complete synchronously with usage of wait_queue. |
["https://git.kernel.org/stable/c/0857b1c573c0b095aa778bb26d8b3378172471b6","https://git.kernel.org/stable/c/0a3c84f71680684c1d41abb92db05f95c09111e8","https://git.kernel.org/stable/c/0ef6e016eb53fad6dc44c3253945efb43a3486b9","https://git.kernel.org/stable/c/bbc525409bfe8e5bff12f5d18d550ab3e52cdbef"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56568
|
Medium |
fixed |
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.66
- 6.12.4
|
In the Linux kernel, the following vulnerability has been resolved:
iommu/arm-smmu: Defer probe of clients after smmu device bound
Null pointer dereference occurs due to a race between smmu
driver probe and client driver probe, when of_dma_configure()
for client is called after the iommu_device_register() for smmu driver
probe has executed but before the driver_bound() for smmu driver
has been called.
Following is how the race occurs:
T1:Smmu device probe T2: Client device probe
really_probe()
arm_smmu_device_probe()
iommu_device_register()
really_probe()
platform_dma_configure()
of_dma_configure()
of_dma_configure_id()
of_iommu_configure()
iommu_probe_device()
iommu_init_device()
arm_smmu_probe_device()
arm_smmu_get_by_fwnode()
driver_find_device_by_fwnode()
driver_find_device()
next_device()
klist_next()
/* null ptr
assigned to smmu */
/* null ptr dereference
while smmu->streamid_mask */
driver_bound()
klist_add_tail()
When this null smmu pointer is dereferenced later in
arm_smmu_probe_device, the device crashes.
Fix this by deferring the probe of the client device
until the smmu device has bound to the arm smmu driver.
[will: Add comment] |
["https://git.kernel.org/stable/c/229e6ee43d2a160a1592b83aad620d6027084aad","https://git.kernel.org/stable/c/4a9485918a042e3114890dfbe19839a1897f8b2c","https://git.kernel.org/stable/c/5018696b19bc6c021e934a8a59f4b1dd8c0ac9f8","https://git.kernel.org/stable/c/c2527d07c7e9cda2c6165d5edccf74752baac1b0","https://git.kernel.org/stable/c/dc02407ea952e20c544a078a6be2e6f008327973","https://git.kernel.org/stable/c/f8f794f387ad21c4696e5cd0626cb6f8a5f6aea5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1859
|
Medium |
|
N/A
|
A use-after-free flaw was found in xen_9pfs_front_removet in net/9p/trans_xen.c in Xen transport for 9pfs in the Linux Kernel. This flaw could allow a local attacker to crash the system due to a race problem, possibly leading to a kernel information leak. |
["https://lore.kernel.org/all/20230313090002.3308025-1-zyytlz.wz%40163.com/","https://lore.kernel.org/all/20230313090002.3308025-1-zyytlz.wz%40163.com/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-45886
|
High |
fixed |
- 4.19.285
- 5.4.246
- 5.10.183
- 5.15.116
- 6.1.33
- 6.3.7
|
An issue was discovered in the Linux kernel through 6.0.9. drivers/media/dvb-core/dvb_net.c has a .disconnect versus dvb_device_open race condition that leads to a use-after-free. |
["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4172385b0c9ac366dcab78eda48c26814b87ed1a","https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/","https://lore.kernel.org/linux-media/20221115131822.6640-3-imv4bel%40gmail.com/","https://security.netapp.com/advisory/ntap-20230113-0006/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4172385b0c9ac366dcab78eda48c26814b87ed1a","https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/","https://lore.kernel.org/linux-media/20221115131822.6640-3-imv4bel%40gmail.com/","https://security.netapp.com/advisory/ntap-20230113-0006/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26654
|
High |
fixed |
- 4.19.312
- 5.4.274
- 5.10.215
- 5.15.154
- 6.1.84
- 6.6.24
- 6.7.12
- 6.8.3
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs
The dreamcastcard->timer could schedule the spu_dma_work and the
spu_dma_work could also arm the dreamcastcard->timer.
When the snd_pcm_substream is closing, the aica_channel will be
deallocated. But it could still be dereferenced in the worker
thread. The reason is that del_timer() will return directly
regardless of whether the timer handler is running or not and
the worker could be rescheduled in the timer handler. As a result,
the UAF bug will happen. The racy situation is shown below:
(Thread 1) | (Thread 2)
snd_aicapcm_pcm_close() |
... | run_spu_dma() //worker
| mod_timer()
flush_work() |
del_timer() | aica_period_elapsed() //timer
kfree(dreamcastcard->channel) | schedule_work()
| run_spu_dma() //worker
... | dreamcastcard->channel-> //USE
In order to mitigate this bug and other possible corner cases,
call mod_timer() conditionally in run_spu_dma(), then implement
PCM sync_stop op to cancel both the timer and worker. The sync_stop
op will be called from PCM core appropriately when needed. |
["https://git.kernel.org/stable/c/051e0840ffa8ab25554d6b14b62c9ab9e4901457","https://git.kernel.org/stable/c/3c907bf56905de7d27b329afaf59c2fb35d17b04","https://git.kernel.org/stable/c/4206ad65a0ee76920041a755bd3c17c6ba59bba2","https://git.kernel.org/stable/c/61d4787692c1fccdc268ffa7a891f9c149f50901","https://git.kernel.org/stable/c/8c990221681688da34295d6d76cc2f5b963e83f5","https://git.kernel.org/stable/c/9d66ae0e7bb78b54e1e0525456c6b54e1d132046","https://git.kernel.org/stable/c/aa39e6878f61f50892ee2dd9d2176f72020be845","https://git.kernel.org/stable/c/e955e8a7f38a856fc6534ba4e6bffd4d5cc80ac3","https://git.kernel.org/stable/c/eeb2a2ca0b8de7e1c66afaf719529154e7dc60b2","https://git.kernel.org/stable/c/051e0840ffa8ab25554d6b14b62c9ab9e4901457","https://git.kernel.org/stable/c/3c907bf56905de7d27b329afaf59c2fb35d17b04","https://git.kernel.org/stable/c/4206ad65a0ee76920041a755bd3c17c6ba59bba2","https://git.kernel.org/stable/c/61d4787692c1fccdc268ffa7a891f9c149f50901","https://git.kernel.org/stable/c/8c990221681688da34295d6d76cc2f5b963e83f5","https://git.kernel.org/stable/c/9d66ae0e7bb78b54e1e0525456c6b54e1d132046","https://git.kernel.org/stable/c/aa39e6878f61f50892ee2dd9d2176f72020be845","https://git.kernel.org/stable/c/e955e8a7f38a856fc6534ba4e6bffd4d5cc80ac3","https://git.kernel.org/stable/c/eeb2a2ca0b8de7e1c66afaf719529154e7dc60b2","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-0607
|
Medium |
fixed |
|
A flaw was found in the Netfilter subsystem in the Linux kernel. The issue is in the nft_byteorder_eval() function, where the code iterates through a loop and writes to the `dst` array. On each iteration, 8 bytes are written, but `dst` is an array of u32, so each element only has space for 4 bytes. That means every iteration overwrites part of the previous element corrupting this array of u32. This flaw allows a local user to cause a denial of service or potentially break NetFilter functionality. |
["https://access.redhat.com/security/cve/CVE-2024-0607","https://bugzilla.redhat.com/show_bug.cgi?id=2258635","https://github.com/torvalds/linux/commit/c301f0981fdd3fd1ffac6836b423c4d7a8e0eb63","https://access.redhat.com/security/cve/CVE-2024-0607","https://bugzilla.redhat.com/show_bug.cgi?id=2258635","https://github.com/torvalds/linux/commit/c301f0981fdd3fd1ffac6836b423c4d7a8e0eb63","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3629
|
Low |
|
N/A
|
A vulnerability was found in Linux Kernel. It has been declared as problematic. This vulnerability affects the function vsock_connect of the file net/vmw_vsock/af_vsock.c. The manipulation leads to memory leak. The complexity of an attack is rather high. The exploitation appears to be difficult. It is recommended to apply a patch to fix this issue. VDB-211930 is the identifier assigned to this vulnerability. |
["https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=7e97cfed9929eaabc41829c395eb0d1350fccb9d","https://vuldb.com/?ctiid.211930","https://vuldb.com/?id.211930","https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=7e97cfed9929eaabc41829c395eb0d1350fccb9d","https://vuldb.com/?ctiid.211930","https://vuldb.com/?id.211930"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-0494
|
Medium |
fixed |
|
A kernel information leak flaw was identified in the scsi_ioctl function in drivers/scsi/scsi_ioctl.c in the Linux kernel. This flaw allows a local attacker with a special user privilege (CAP_SYS_ADMIN or CAP_SYS_RAWIO) to create issues with confidentiality. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2039448","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://lore.kernel.org/all/20220216084038.15635-1-tcs.kernel%40gmail.com/","https://www.debian.org/security/2022/dsa-5161","https://www.debian.org/security/2022/dsa-5173","https://bugzilla.redhat.com/show_bug.cgi?id=2039448","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://lore.kernel.org/all/20220216084038.15635-1-tcs.kernel%40gmail.com/","https://www.debian.org/security/2022/dsa-5161","https://www.debian.org/security/2022/dsa-5173"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56746
|
Medium |
fixed |
- 4.19.325
- 5.4.287
- 5.10.231
- 5.15.174
- 6.1.120
- 6.6.64
- 6.11.11
- 6.12.2
|
In the Linux kernel, the following vulnerability has been resolved:
fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()
When information such as info->screen_base is not ready, calling
sh7760fb_free_mem() does not release memory correctly. Call
dma_free_coherent() instead. |
["https://git.kernel.org/stable/c/0d3fb3b3e9d66f7b6346e3b90bc0ff48683539ce","https://git.kernel.org/stable/c/29216bb390e36daeebef66abaa02d9751330252b","https://git.kernel.org/stable/c/3dd9df8e5f34c6fc4217a7498c1fb3c352d4afc2","https://git.kernel.org/stable/c/40f4326ed05a3b3537556ff2a844958b9e779a98","https://git.kernel.org/stable/c/bad37309c8b8bf1cfc893750df0951a804009ca0","https://git.kernel.org/stable/c/d10cd53e5a7fb3b7c6f83d4d9a5ea1d97a3ed9a5","https://git.kernel.org/stable/c/d48cbfa90dce506030151915fa3346d67f964af4","https://git.kernel.org/stable/c/f4fbd70e15fafe36a7583954ce189aaf5536aeec","https://git.kernel.org/stable/c/f89d17ae2ac42931be2a0153fecbf8533280c927"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-47634
|
High |
fixed |
- 3.3
- 3.11
- 3.13
- 3.15
- 3.17
- 3.19
- 4.2
- 4.5
- 4.14.276
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
ubi: Fix race condition between ctrl_cdev_ioctl and ubi_cdev_ioctl
Hulk Robot reported a KASAN report about use-after-free:
==================================================================
BUG: KASAN: use-after-free in __list_del_entry_valid+0x13d/0x160
Read of size 8 at addr ffff888035e37d98 by task ubiattach/1385
[...]
Call Trace:
klist_dec_and_del+0xa7/0x4a0
klist_put+0xc7/0x1a0
device_del+0x4d4/0xed0
cdev_device_del+0x1a/0x80
ubi_attach_mtd_dev+0x2951/0x34b0 [ubi]
ctrl_cdev_ioctl+0x286/0x2f0 [ubi]
Allocated by task 1414:
device_add+0x60a/0x18b0
cdev_device_add+0x103/0x170
ubi_create_volume+0x1118/0x1a10 [ubi]
ubi_cdev_ioctl+0xb7f/0x1ba0 [ubi]
Freed by task 1385:
cdev_device_del+0x1a/0x80
ubi_remove_volume+0x438/0x6c0 [ubi]
ubi_cdev_ioctl+0xbf4/0x1ba0 [ubi]
[...]
==================================================================
The lock held by ctrl_cdev_ioctl is ubi_devices_mutex, but the lock held
by ubi_cdev_ioctl is ubi->device_mutex. Therefore, the two locks can be
concurrent.
ctrl_cdev_ioctl contains two operations: ubi_attach and ubi_detach.
ubi_detach is bug-free because it uses reference counting to prevent
concurrency. However, uif_init and uif_close in ubi_attach may race with
ubi_cdev_ioctl.
uif_init will race with ubi_cdev_ioctl as in the following stack.
cpu1 cpu2 cpu3
_______________________|________________________|______________________
ctrl_cdev_ioctl
ubi_attach_mtd_dev
uif_init
ubi_cdev_ioctl
ubi_create_volume
cdev_device_add
ubi_add_volume
// sysfs exist
kill_volumes
ubi_cdev_ioctl
ubi_remove_volume
cdev_device_del
// first free
ubi_free_volume
cdev_del
// double free
cdev_device_del
And uif_close will race with ubi_cdev_ioctl as in the following stack.
cpu1 cpu2 cpu3
_______________________|________________________|______________________
ctrl_cdev_ioctl
ubi_attach_mtd_dev
uif_init
ubi_cdev_ioctl
ubi_create_volume
cdev_device_add
ubi_debugfs_init_dev
//error goto out_uif;
uif_close
kill_volumes
ubi_cdev_ioctl
ubi_remove_volume
cdev_device_del
// first free
ubi_free_volume
// double free
The cause of this problem is that commit 714fb87e8bc0 make device
"available" before it becomes accessible via sysfs. Therefore, we
roll back the modification. We will fix the race condition between
ubi device creation and udev by removing ubi_get_device in
vol_attribute_show and dev_attribute_show.This avoids accessing
uninitialized ubi_devices[ubi_num].
ubi_get_device is used to prevent devices from being deleted during
sysfs execution. However, now kernfs ensures that devices will not
be deleted before all reference counting are released.
The key process is shown in the following stack.
device_del
device_remove_attrs
device_remove_groups
sysfs_remove_groups
sysfs_remove_group
remove_files
kernfs_remove_by_name
kernfs_remove_by_name_ns
__kernfs_remove
kernfs_drain |
["https://git.kernel.org/stable/c/1a3f1cf87054833242fcd0218de0481cf855f888","https://git.kernel.org/stable/c/3cbf0e392f173ba0ce425968c8374a6aa3e90f2e","https://git.kernel.org/stable/c/432b057f8e847ae5a2306515606f8d2defaca178","https://git.kernel.org/stable/c/5f9e9c223e48c264241d2f34d0bfc29e5fcb5c1b","https://git.kernel.org/stable/c/a8ecee49259f8f78d91ddb329ab2be7e6fd01974","https://git.kernel.org/stable/c/c32fe764191b8ae8b128588beb96e3718d9179d8","https://git.kernel.org/stable/c/d727fd32cbd1abf3465f607021bc9c746f17b5a8","https://git.kernel.org/stable/c/f149b1bd213820363731aa119e5011ca892a2aac"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52438
|
High |
fixed |
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.74
- 6.6.13
- 6.7.1
|
In the Linux kernel, the following vulnerability has been resolved:
binder: fix use-after-free in shinker's callback
The mmap read lock is used during the shrinker's callback, which means
that using alloc->vma pointer isn't safe as it can race with munmap().
As of commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in
munmap") the mmap lock is downgraded after the vma has been isolated.
I was able to reproduce this issue by manually adding some delays and
triggering page reclaiming through the shrinker's debug sysfs. The
following KASAN report confirms the UAF:
==================================================================
BUG: KASAN: slab-use-after-free in zap_page_range_single+0x470/0x4b8
Read of size 8 at addr ffff356ed50e50f0 by task bash/478
CPU: 1 PID: 478 Comm: bash Not tainted 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70
Hardware name: linux,dummy-virt (DT)
Call trace:
zap_page_range_single+0x470/0x4b8
binder_alloc_free_page+0x608/0xadc
__list_lru_walk_one+0x130/0x3b0
list_lru_walk_node+0xc4/0x22c
binder_shrink_scan+0x108/0x1dc
shrinker_debugfs_scan_write+0x2b4/0x500
full_proxy_write+0xd4/0x140
vfs_write+0x1ac/0x758
ksys_write+0xf0/0x1dc
__arm64_sys_write+0x6c/0x9c
Allocated by task 492:
kmem_cache_alloc+0x130/0x368
vm_area_alloc+0x2c/0x190
mmap_region+0x258/0x18bc
do_mmap+0x694/0xa60
vm_mmap_pgoff+0x170/0x29c
ksys_mmap_pgoff+0x290/0x3a0
__arm64_sys_mmap+0xcc/0x144
Freed by task 491:
kmem_cache_free+0x17c/0x3c8
vm_area_free_rcu_cb+0x74/0x98
rcu_core+0xa38/0x26d4
rcu_core_si+0x10/0x1c
__do_softirq+0x2fc/0xd24
Last potentially related work creation:
__call_rcu_common.constprop.0+0x6c/0xba0
call_rcu+0x10/0x1c
vm_area_free+0x18/0x24
remove_vma+0xe4/0x118
do_vmi_align_munmap.isra.0+0x718/0xb5c
do_vmi_munmap+0xdc/0x1fc
__vm_munmap+0x10c/0x278
__arm64_sys_munmap+0x58/0x7c
Fix this issue by performing instead a vma_lookup() which will fail to
find the vma that was isolated before the mmap lock downgrade. Note that
this option has better performance than upgrading to a mmap write lock
which would increase contention. Plus, mmap_write_trylock() has been
recently removed anyway. |
["https://git.kernel.org/stable/c/3f489c2067c5824528212b0fc18b28d51332d906","https://git.kernel.org/stable/c/8ad4d580e8aff8de2a4d57c5930fcc29f1ffd4a6","https://git.kernel.org/stable/c/9fa04c93f24138747807fe75b5591bb680098f56","https://git.kernel.org/stable/c/a49087ab93508b60d9b8add91707a22dda832869","https://git.kernel.org/stable/c/a53e15e592b4dcc91c3a3b8514e484a0bdbc53a3","https://git.kernel.org/stable/c/c8c1158ffb007197f31f9d9170cf13e4f34cbb5c","https://git.kernel.org/stable/c/e074686e993ff1be5f21b085a3b1b4275ccd5727","https://git.kernel.org/stable/c/3f489c2067c5824528212b0fc18b28d51332d906","https://git.kernel.org/stable/c/8ad4d580e8aff8de2a4d57c5930fcc29f1ffd4a6","https://git.kernel.org/stable/c/9fa04c93f24138747807fe75b5591bb680098f56","https://git.kernel.org/stable/c/a49087ab93508b60d9b8add91707a22dda832869","https://git.kernel.org/stable/c/a53e15e592b4dcc91c3a3b8514e484a0bdbc53a3","https://git.kernel.org/stable/c/c8c1158ffb007197f31f9d9170cf13e4f34cbb5c","https://git.kernel.org/stable/c/e074686e993ff1be5f21b085a3b1b4275ccd5727","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52637
|
High |
fixed |
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER)
Lock jsk->sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...)
modifies jsk->filters while receiving packets.
Following trace was seen on affected system:
==================================================================
BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
Read of size 4 at addr ffff888012144014 by task j1939/350
CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
print_report+0xd3/0x620
? kasan_complete_mode_report_info+0x7d/0x200
? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
kasan_report+0xc2/0x100
? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
__asan_load4+0x84/0xb0
j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
j1939_sk_recv+0x20b/0x320 [can_j1939]
? __kasan_check_write+0x18/0x20
? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939]
? j1939_simple_recv+0x69/0x280 [can_j1939]
? j1939_ac_recv+0x5e/0x310 [can_j1939]
j1939_can_recv+0x43f/0x580 [can_j1939]
? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
? raw_rcv+0x42/0x3c0 [can_raw]
? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
can_rcv_filter+0x11f/0x350 [can]
can_receive+0x12f/0x190 [can]
? __pfx_can_rcv+0x10/0x10 [can]
can_rcv+0xdd/0x130 [can]
? __pfx_can_rcv+0x10/0x10 [can]
__netif_receive_skb_one_core+0x13d/0x150
? __pfx___netif_receive_skb_one_core+0x10/0x10
? __kasan_check_write+0x18/0x20
? _raw_spin_lock_irq+0x8c/0xe0
__netif_receive_skb+0x23/0xb0
process_backlog+0x107/0x260
__napi_poll+0x69/0x310
net_rx_action+0x2a1/0x580
? __pfx_net_rx_action+0x10/0x10
? __pfx__raw_spin_lock+0x10/0x10
? handle_irq_event+0x7d/0xa0
__do_softirq+0xf3/0x3f8
do_softirq+0x53/0x80
</IRQ>
<TASK>
__local_bh_enable_ip+0x6e/0x70
netif_rx+0x16b/0x180
can_send+0x32b/0x520 [can]
? __pfx_can_send+0x10/0x10 [can]
? __check_object_size+0x299/0x410
raw_sendmsg+0x572/0x6d0 [can_raw]
? __pfx_raw_sendmsg+0x10/0x10 [can_raw]
? apparmor_socket_sendmsg+0x2f/0x40
? __pfx_raw_sendmsg+0x10/0x10 [can_raw]
sock_sendmsg+0xef/0x100
sock_write_iter+0x162/0x220
? __pfx_sock_write_iter+0x10/0x10
? __rtnl_unlock+0x47/0x80
? security_file_permission+0x54/0x320
vfs_write+0x6ba/0x750
? __pfx_vfs_write+0x10/0x10
? __fget_light+0x1ca/0x1f0
? __rcu_read_unlock+0x5b/0x280
ksys_write+0x143/0x170
? __pfx_ksys_write+0x10/0x10
? __kasan_check_read+0x15/0x20
? fpregs_assert_state_consistent+0x62/0x70
__x64_sys_write+0x47/0x60
do_syscall_64+0x60/0x90
? do_syscall_64+0x6d/0x90
? irqentry_exit+0x3f/0x50
? exc_page_fault+0x79/0xf0
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Allocated by task 348:
kasan_save_stack+0x2a/0x50
kasan_set_track+0x29/0x40
kasan_save_alloc_info+0x1f/0x30
__kasan_kmalloc+0xb5/0xc0
__kmalloc_node_track_caller+0x67/0x160
j1939_sk_setsockopt+0x284/0x450 [can_j1939]
__sys_setsockopt+0x15c/0x2f0
__x64_sys_setsockopt+0x6b/0x80
do_syscall_64+0x60/0x90
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Freed by task 349:
kasan_save_stack+0x2a/0x50
kasan_set_track+0x29/0x40
kasan_save_free_info+0x2f/0x50
__kasan_slab_free+0x12e/0x1c0
__kmem_cache_free+0x1b9/0x380
kfree+0x7a/0x120
j1939_sk_setsockopt+0x3b2/0x450 [can_j1939]
__sys_setsockopt+0x15c/0x2f0
__x64_sys_setsockopt+0x6b/0x80
do_syscall_64+0x60/0x90
entry_SYSCALL_64_after_hwframe+0x6e/0xd8 |
["https://git.kernel.org/stable/c/08de58abedf6e69396e1207e4f99ef8904b2b532","https://git.kernel.org/stable/c/41ccb5bcbf03f02d820bc6ea8390811859f558f8","https://git.kernel.org/stable/c/4dd684d4bb3cd5454e0bf6e2a1bdfbd5c9c872ed","https://git.kernel.org/stable/c/978e50ef8c38dc71bd14d1b0143d554ff5d188ba","https://git.kernel.org/stable/c/efe7cf828039aedb297c1f9920b638fffee6aabc","https://git.kernel.org/stable/c/f84e7534457dcd7835be743517c35378bb4e7c50","https://git.kernel.org/stable/c/fc74b9cb789cae061bbca7b203a3842e059f6b5d","https://git.kernel.org/stable/c/08de58abedf6e69396e1207e4f99ef8904b2b532","https://git.kernel.org/stable/c/41ccb5bcbf03f02d820bc6ea8390811859f558f8","https://git.kernel.org/stable/c/4dd684d4bb3cd5454e0bf6e2a1bdfbd5c9c872ed","https://git.kernel.org/stable/c/978e50ef8c38dc71bd14d1b0143d554ff5d188ba","https://git.kernel.org/stable/c/efe7cf828039aedb297c1f9920b638fffee6aabc","https://git.kernel.org/stable/c/f84e7534457dcd7835be743517c35378bb4e7c50","https://git.kernel.org/stable/c/fc74b9cb789cae061bbca7b203a3842e059f6b5d","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26598
|
High |
fixed |
- 5.4.269
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache
There is a potential UAF scenario in the case of an LPI translation
cache hit racing with an operation that invalidates the cache, such
as a DISCARD ITS command. The root of the problem is that
vgic_its_check_cache() does not elevate the refcount on the vgic_irq
before dropping the lock that serializes refcount changes.
Have vgic_its_check_cache() raise the refcount on the returned vgic_irq
and add the corresponding decrement after queueing the interrupt. |
["https://git.kernel.org/stable/c/12c2759ab1343c124ed46ba48f27bd1ef5d2dff4","https://git.kernel.org/stable/c/65b201bf3e9af1b0254243a5881390eda56f72d1","https://git.kernel.org/stable/c/ad362fe07fecf0aba839ff2cc59a3617bd42c33f","https://git.kernel.org/stable/c/ba7be666740847d967822bed15500656b26bc703","https://git.kernel.org/stable/c/d04acadb6490aa3314f9c9e087691e55de153b88","https://git.kernel.org/stable/c/dba788e25f05209adf2b0175eb1691dc89fb1ba6","https://git.kernel.org/stable/c/dd3956a1b3dd11f46488c928cb890d6937d1ca80","https://git.kernel.org/stable/c/12c2759ab1343c124ed46ba48f27bd1ef5d2dff4","https://git.kernel.org/stable/c/65b201bf3e9af1b0254243a5881390eda56f72d1","https://git.kernel.org/stable/c/ad362fe07fecf0aba839ff2cc59a3617bd42c33f","https://git.kernel.org/stable/c/ba7be666740847d967822bed15500656b26bc703","https://git.kernel.org/stable/c/d04acadb6490aa3314f9c9e087691e55de153b88","https://git.kernel.org/stable/c/dba788e25f05209adf2b0175eb1691dc89fb1ba6","https://git.kernel.org/stable/c/dd3956a1b3dd11f46488c928cb890d6937d1ca80","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52475
|
High |
fixed |
- 4.14.328
- 4.19.297
- 5.4.259
- 5.10.199
- 5.15.136
- 6.1.59
- 6.5.8
|
In the Linux kernel, the following vulnerability has been resolved:
Input: powermate - fix use-after-free in powermate_config_complete
syzbot has found a use-after-free bug [1] in the powermate driver. This
happens when the device is disconnected, which leads to a memory free from
the powermate_device struct. When an asynchronous control message
completes after the kfree and its callback is invoked, the lock does not
exist anymore and hence the bug.
Use usb_kill_urb() on pm->config to cancel any in-progress requests upon
device disconnection.
[1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e |
["https://git.kernel.org/stable/c/2efe67c581a2a6122b328d4bb6f21b3f36f40d46","https://git.kernel.org/stable/c/5aa514100aaf59868d745196258269a16737c7bd","https://git.kernel.org/stable/c/5c15c60e7be615f05a45cd905093a54b11f461bc","https://git.kernel.org/stable/c/67cace72606baf1758fd60feb358f4c6be92e1cc","https://git.kernel.org/stable/c/6a4a396386404e62fb59bc3bde48871a64a82b4f","https://git.kernel.org/stable/c/8677575c4f39d65bf0d719b5d20e8042e550ccb9","https://git.kernel.org/stable/c/cd2fbfd8b922b7fdd50732e47d797754ab59cb06","https://git.kernel.org/stable/c/e528b1b9d60743e0b26224e3fe7aa74c24b8b2f8","https://git.kernel.org/stable/c/2efe67c581a2a6122b328d4bb6f21b3f36f40d46","https://git.kernel.org/stable/c/5aa514100aaf59868d745196258269a16737c7bd","https://git.kernel.org/stable/c/5c15c60e7be615f05a45cd905093a54b11f461bc","https://git.kernel.org/stable/c/67cace72606baf1758fd60feb358f4c6be92e1cc","https://git.kernel.org/stable/c/6a4a396386404e62fb59bc3bde48871a64a82b4f","https://git.kernel.org/stable/c/8677575c4f39d65bf0d719b5d20e8042e550ccb9","https://git.kernel.org/stable/c/cd2fbfd8b922b7fdd50732e47d797754ab59cb06","https://git.kernel.org/stable/c/e528b1b9d60743e0b26224e3fe7aa74c24b8b2f8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26883
|
High |
fixed |
- 4.19.311
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix stackmap overflow check on 32-bit arches
The stackmap code relies on roundup_pow_of_two() to compute the number
of hash buckets, and contains an overflow check by checking if the
resulting value is 0. However, on 32-bit arches, the roundup code itself
can overflow by doing a 32-bit left-shift of an unsigned long value,
which is undefined behaviour, so it is not guaranteed to truncate
neatly. This was triggered by syzbot on the DEVMAP_HASH type, which
contains the same check, copied from the hashtab code.
The commit in the fixes tag actually attempted to fix this, but the fix
did not account for the UB, so the fix only works on CPUs where an
overflow does result in a neat truncation to zero, which is not
guaranteed. Checking the value before rounding does not have this
problem. |
["https://git.kernel.org/stable/c/0971126c8164abe2004b8536b49690a0d6005b0a","https://git.kernel.org/stable/c/15641007df0f0d35fa28742b25c2a7db9dcd6895","https://git.kernel.org/stable/c/21e5fa4688e1a4d3db6b72216231b24232f75c1d","https://git.kernel.org/stable/c/43f798b9036491fb014b55dd61c4c5c3193267d0","https://git.kernel.org/stable/c/7070b274c7866a4c5036f8d54fcaf315c64ac33a","https://git.kernel.org/stable/c/7a4b21250bf79eef26543d35bd390448646c536b","https://git.kernel.org/stable/c/ca1f06e72dec41ae4f76e7b1a8a97265447b46ae","https://git.kernel.org/stable/c/d0e214acc59145ce25113f617311aa79dda39cb3","https://git.kernel.org/stable/c/f06899582ccee09bd85d0696290e3eaca9aa042d","https://git.kernel.org/stable/c/0971126c8164abe2004b8536b49690a0d6005b0a","https://git.kernel.org/stable/c/15641007df0f0d35fa28742b25c2a7db9dcd6895","https://git.kernel.org/stable/c/21e5fa4688e1a4d3db6b72216231b24232f75c1d","https://git.kernel.org/stable/c/43f798b9036491fb014b55dd61c4c5c3193267d0","https://git.kernel.org/stable/c/7070b274c7866a4c5036f8d54fcaf315c64ac33a","https://git.kernel.org/stable/c/7a4b21250bf79eef26543d35bd390448646c536b","https://git.kernel.org/stable/c/ca1f06e72dec41ae4f76e7b1a8a97265447b46ae","https://git.kernel.org/stable/c/d0e214acc59145ce25113f617311aa79dda39cb3","https://git.kernel.org/stable/c/f06899582ccee09bd85d0696290e3eaca9aa042d","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52602
|
High |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix slab-out-of-bounds Read in dtSearch
Currently while searching for current page in the sorted entry table
of the page there is a out of bound access. Added a bound check to fix
the error.
Dave:
Set return code to -EIO |
["https://git.kernel.org/stable/c/1b9d6828589d57f94a23fb1c46112cda39d7efdb","https://git.kernel.org/stable/c/1c40ca3d39d769931b28295b3145c25f1decf5a6","https://git.kernel.org/stable/c/6c6a96c3d74df185ee344977d46944d6f33bb4dd","https://git.kernel.org/stable/c/7110650b85dd2f1cee819acd1345a9013a1a62f7","https://git.kernel.org/stable/c/bff9d4078a232c01e42e9377d005fb2f4d31a472","https://git.kernel.org/stable/c/cab0c265ba182fd266c2aa3c69d7e40640a7f612","https://git.kernel.org/stable/c/ce8bc22e948634a5c0a3fa58a179177d0e3f3950","https://git.kernel.org/stable/c/fa5492ee89463a7590a1449358002ff7ef63529f","https://git.kernel.org/stable/c/1b9d6828589d57f94a23fb1c46112cda39d7efdb","https://git.kernel.org/stable/c/1c40ca3d39d769931b28295b3145c25f1decf5a6","https://git.kernel.org/stable/c/6c6a96c3d74df185ee344977d46944d6f33bb4dd","https://git.kernel.org/stable/c/7110650b85dd2f1cee819acd1345a9013a1a62f7","https://git.kernel.org/stable/c/bff9d4078a232c01e42e9377d005fb2f4d31a472","https://git.kernel.org/stable/c/cab0c265ba182fd266c2aa3c69d7e40640a7f612","https://git.kernel.org/stable/c/ce8bc22e948634a5c0a3fa58a179177d0e3f3950","https://git.kernel.org/stable/c/fa5492ee89463a7590a1449358002ff7ef63529f","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-22705
|
High |
fixed |
|
An issue was discovered in ksmbd in the Linux kernel before 6.6.10. smb2_get_data_area_len in fs/smb/server/smb2misc.c can cause an smb_strndup_from_utf16 out-of-bounds access because the relationship between Name data and CreateContexts data is mishandled. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.10","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d10c77873ba1e9e6b91905018e29e196fd5f863d","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.10","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d10c77873ba1e9e6b91905018e29e196fd5f863d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26852
|
High |
fixed |
- 4.19.310
- 5.4.272
- 5.10.213
- 5.15.152
- 6.1.82
- 6.6.22
- 6.7.10
|
In the Linux kernel, the following vulnerability has been resolved:
net/ipv6: avoid possible UAF in ip6_route_mpath_notify()
syzbot found another use-after-free in ip6_route_mpath_notify() [1]
Commit f7225172f25a ("net/ipv6: prevent use after free in
ip6_route_mpath_notify") was not able to fix the root cause.
We need to defer the fib6_info_release() calls after
ip6_route_mpath_notify(), in the cleanup phase.
[1]
BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0
Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037
CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x167/0x540 mm/kasan/report.c:488
kasan_report+0x142/0x180 mm/kasan/report.c:601
rt6_fill_node+0x1460/0x1ac0
inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184
ip6_route_mpath_notify net/ipv6/route.c:5198 [inline]
ip6_route_multipath_add net/ipv6/route.c:5404 [inline]
inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517
rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597
netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x221/0x270 net/socket.c:745
____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
___sys_sendmsg net/socket.c:2638 [inline]
__sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
do_syscall_64+0xf9/0x240
entry_SYSCALL_64_after_hwframe+0x6f/0x77
RIP: 0033:0x7f73dd87dda9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9
RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005
RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858
</TASK>
Allocated by task 23037:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
poison_kmalloc_redzone mm/kasan/common.c:372 [inline]
__kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389
kasan_kmalloc include/linux/kasan.h:211 [inline]
__do_kmalloc_node mm/slub.c:3981 [inline]
__kmalloc+0x22e/0x490 mm/slub.c:3994
kmalloc include/linux/slab.h:594 [inline]
kzalloc include/linux/slab.h:711 [inline]
fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155
ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758
ip6_route_multipath_add net/ipv6/route.c:5298 [inline]
inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517
rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597
netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x221/0x270 net/socket.c:745
____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
___sys_sendmsg net/socket.c:2638 [inline]
__sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
do_syscall_64+0xf9/0x240
entry_SYSCALL_64_after_hwframe+0x6f/0x77
Freed by task 16:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640
poison_slab_object+0xa6/0xe0 m
---truncated--- |
["https://git.kernel.org/stable/c/31ea5bcc7d4cd1423de6be327a2c034725704136","https://git.kernel.org/stable/c/394334fe2ae3b9f1e2332b873857e84cb28aac18","https://git.kernel.org/stable/c/61b34f73cdbdb8eaf9ea12e9e2eb3b29716c4dda","https://git.kernel.org/stable/c/664f9c647260cc9d68b4e31d9899530d89dd045e","https://git.kernel.org/stable/c/685f7d531264599b3f167f1e94bbd22f120e5fab","https://git.kernel.org/stable/c/79ce2e54cc0ae366f45516c00bf1b19aa43e9abe","https://git.kernel.org/stable/c/cae3303257950d03ffec2df4a45e836f10d26c24","https://git.kernel.org/stable/c/ed883060c38721ed828061f6c0c30e5147326c9a","https://git.kernel.org/stable/c/31ea5bcc7d4cd1423de6be327a2c034725704136","https://git.kernel.org/stable/c/394334fe2ae3b9f1e2332b873857e84cb28aac18","https://git.kernel.org/stable/c/61b34f73cdbdb8eaf9ea12e9e2eb3b29716c4dda","https://git.kernel.org/stable/c/664f9c647260cc9d68b4e31d9899530d89dd045e","https://git.kernel.org/stable/c/685f7d531264599b3f167f1e94bbd22f120e5fab","https://git.kernel.org/stable/c/79ce2e54cc0ae366f45516c00bf1b19aa43e9abe","https://git.kernel.org/stable/c/cae3303257950d03ffec2df4a45e836f10d26c24","https://git.kernel.org/stable/c/ed883060c38721ed828061f6c0c30e5147326c9a","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52594
|
High |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: Fix potential array-index-out-of-bounds read in ath9k_htc_txstatus()
Fix an array-index-out-of-bounds read in ath9k_htc_txstatus(). The bug
occurs when txs->cnt, data from a URB provided by a USB device, is
bigger than the size of the array txs->txstatus, which is
HTC_MAX_TX_STATUS. WARN_ON() already checks it, but there is no bug
handling code after the check. Make the function return if that is the
case.
Found by a modified version of syzkaller.
UBSAN: array-index-out-of-bounds in htc_drv_txrx.c
index 13 is out of range for type '__wmi_event_txstatus [12]'
Call Trace:
ath9k_htc_txstatus
ath9k_wmi_event_tasklet
tasklet_action_common
__do_softirq
irq_exit_rxu
sysvec_apic_timer_interrupt |
["https://git.kernel.org/stable/c/25c6f49ef59b7a9b80a3f7ab9e95268a1b01a234","https://git.kernel.org/stable/c/2adc886244dff60f948497b59affb6c6ebb3c348","https://git.kernel.org/stable/c/84770a996ad8d7f121ff2fb5a8d149aad52d64c1","https://git.kernel.org/stable/c/9003fa9a0198ce004b30738766c67eb7373479c9","https://git.kernel.org/stable/c/be609c7002dd4504b15b069cb7582f4c778548d1","https://git.kernel.org/stable/c/e4f4bac7d3b64eb75f70cd3345712de6f68a215d","https://git.kernel.org/stable/c/f11f0fd1ad6c11ae7856d4325fe9d05059767225","https://git.kernel.org/stable/c/f44f073c78112ff921a220d01b86d09f2ace59bc","https://git.kernel.org/stable/c/25c6f49ef59b7a9b80a3f7ab9e95268a1b01a234","https://git.kernel.org/stable/c/2adc886244dff60f948497b59affb6c6ebb3c348","https://git.kernel.org/stable/c/84770a996ad8d7f121ff2fb5a8d149aad52d64c1","https://git.kernel.org/stable/c/9003fa9a0198ce004b30738766c67eb7373479c9","https://git.kernel.org/stable/c/be609c7002dd4504b15b069cb7582f4c778548d1","https://git.kernel.org/stable/c/e4f4bac7d3b64eb75f70cd3345712de6f68a215d","https://git.kernel.org/stable/c/f11f0fd1ad6c11ae7856d4325fe9d05059767225","https://git.kernel.org/stable/c/f44f073c78112ff921a220d01b86d09f2ace59bc","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52600
|
High |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix uaf in jfs_evict_inode
When the execution of diMount(ipimap) fails, the object ipimap that has been
released may be accessed in diFreeSpecial(). Asynchronous ipimap release occurs
when rcu_core() calls jfs_free_node().
Therefore, when diMount(ipimap) fails, sbi->ipimap should not be initialized as
ipimap. |
["https://git.kernel.org/stable/c/1696d6d7d4a1b373e96428d0fe1166bd7c3c795e","https://git.kernel.org/stable/c/32e8f2d95528d45828c613417cb2827d866cbdce","https://git.kernel.org/stable/c/81b4249ef37297fb17ba102a524039a05c6c5d35","https://git.kernel.org/stable/c/8e44dc3f96e903815dab1d74fff8faafdc6feb61","https://git.kernel.org/stable/c/93df0a2a0b3cde2d7ab3a52ed46ea1d6d4aaba5f","https://git.kernel.org/stable/c/bacdaa04251382d7efd4f09f9a0686bfcc297e2e","https://git.kernel.org/stable/c/bc6ef64dbe71136f327d63b2b9071b828af2c2a8","https://git.kernel.org/stable/c/e0e1958f4c365e380b17ccb35617345b31ef7bf3","https://git.kernel.org/stable/c/1696d6d7d4a1b373e96428d0fe1166bd7c3c795e","https://git.kernel.org/stable/c/32e8f2d95528d45828c613417cb2827d866cbdce","https://git.kernel.org/stable/c/81b4249ef37297fb17ba102a524039a05c6c5d35","https://git.kernel.org/stable/c/8e44dc3f96e903815dab1d74fff8faafdc6feb61","https://git.kernel.org/stable/c/93df0a2a0b3cde2d7ab3a52ed46ea1d6d4aaba5f","https://git.kernel.org/stable/c/bacdaa04251382d7efd4f09f9a0686bfcc297e2e","https://git.kernel.org/stable/c/bc6ef64dbe71136f327d63b2b9071b828af2c2a8","https://git.kernel.org/stable/c/e0e1958f4c365e380b17ccb35617345b31ef7bf3","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52464
|
High |
fixed |
- 4.19.306
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
EDAC/thunderx: Fix possible out-of-bounds string access
Enabling -Wstringop-overflow globally exposes a warning for a common bug
in the usage of strncat():
drivers/edac/thunderx_edac.c: In function 'thunderx_ocx_com_threaded_isr':
drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size [-Werror=stringop-overflow=]
1136 | strncat(msg, other, OCX_MESSAGE_SIZE);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...
1145 | strncat(msg, other, OCX_MESSAGE_SIZE);
...
1150 | strncat(msg, other, OCX_MESSAGE_SIZE);
...
Apparently the author of this driver expected strncat() to behave the
way that strlcat() does, which uses the size of the destination buffer
as its third argument rather than the length of the source buffer. The
result is that there is no check on the size of the allocated buffer.
Change it to strlcat().
[ bp: Trim compiler output, fixup commit message. ] |
["https://git.kernel.org/stable/c/426fae93c01dffa379225eb2bd4d3cdc42c6eec5","https://git.kernel.org/stable/c/475c58e1a471e9b873e3e39958c64a2d278275c8","https://git.kernel.org/stable/c/5da3b6e7196f0b4f3728e4e25eb20233a9ddfaf6","https://git.kernel.org/stable/c/6aa7865ba7ff7f0ede0035180fb3b9400ceb405a","https://git.kernel.org/stable/c/700cf4bead80fac994dcc43ae1ca5d86d8959b21","https://git.kernel.org/stable/c/71c17ee02538802ceafc830f0736aa35b564e601","https://git.kernel.org/stable/c/9dbac9fdae6e3b411fc4c3fca3bf48f70609c398","https://git.kernel.org/stable/c/e1c86511241588efffaa49556196f09a498d5057","https://git.kernel.org/stable/c/426fae93c01dffa379225eb2bd4d3cdc42c6eec5","https://git.kernel.org/stable/c/475c58e1a471e9b873e3e39958c64a2d278275c8","https://git.kernel.org/stable/c/5da3b6e7196f0b4f3728e4e25eb20233a9ddfaf6","https://git.kernel.org/stable/c/6aa7865ba7ff7f0ede0035180fb3b9400ceb405a","https://git.kernel.org/stable/c/700cf4bead80fac994dcc43ae1ca5d86d8959b21","https://git.kernel.org/stable/c/71c17ee02538802ceafc830f0736aa35b564e601","https://git.kernel.org/stable/c/9dbac9fdae6e3b411fc4c3fca3bf48f70609c398","https://git.kernel.org/stable/c/e1c86511241588efffaa49556196f09a498d5057","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52642
|
High |
fixed |
- 5.10.210
- 5.15.149
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
media: rc: bpf attach/detach requires write permission
Note that bpf attach/detach also requires CAP_NET_ADMIN. |
["https://git.kernel.org/stable/c/6a9d552483d50953320b9d3b57abdee8d436f23f","https://git.kernel.org/stable/c/93136132d1b5792bf44151e3494ae3691cd738e8","https://git.kernel.org/stable/c/93d8109bf182510629bbefc8cd45296d2393987f","https://git.kernel.org/stable/c/9f6087851ec6dce5b15f694aeaf3e8ec8243224e","https://git.kernel.org/stable/c/caf2da1d4562de4e35eedec0be2b7f1ee25d83be","https://git.kernel.org/stable/c/d98210108e7b2ff64b332b0a3541c8ad6a0617b0","https://git.kernel.org/stable/c/6a9d552483d50953320b9d3b57abdee8d436f23f","https://git.kernel.org/stable/c/93136132d1b5792bf44151e3494ae3691cd738e8","https://git.kernel.org/stable/c/93d8109bf182510629bbefc8cd45296d2393987f","https://git.kernel.org/stable/c/9f6087851ec6dce5b15f694aeaf3e8ec8243224e","https://git.kernel.org/stable/c/caf2da1d4562de4e35eedec0be2b7f1ee25d83be","https://git.kernel.org/stable/c/d98210108e7b2ff64b332b0a3541c8ad6a0617b0","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52612
|
High |
fixed |
- 4.19.306
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
crypto: scomp - fix req->dst buffer overflow
The req->dst buffer size should be checked before copying from the
scomp_scratch->dst to avoid req->dst buffer overflow problem. |
["https://git.kernel.org/stable/c/1142d65c5b881590962ad763f94505b6dd67d2fe","https://git.kernel.org/stable/c/4518dc468cdd796757190515a9be7408adc8911e","https://git.kernel.org/stable/c/4df0c942d04a67df174195ad8082f6e30e7f71a5","https://git.kernel.org/stable/c/71c6670f9f032ec67d8f4e3f8db4646bf5a62883","https://git.kernel.org/stable/c/744e1885922a9943458954cfea917b31064b4131","https://git.kernel.org/stable/c/7d9e5bed036a7f9e2062a137e97e3c1e77fb8759","https://git.kernel.org/stable/c/a5f2f91b3fd7387e5102060809316a0f8f0bc625","https://git.kernel.org/stable/c/e0e3f4a18784182cfe34e20c00eca11e78d53e76","https://git.kernel.org/stable/c/1142d65c5b881590962ad763f94505b6dd67d2fe","https://git.kernel.org/stable/c/4518dc468cdd796757190515a9be7408adc8911e","https://git.kernel.org/stable/c/4df0c942d04a67df174195ad8082f6e30e7f71a5","https://git.kernel.org/stable/c/71c6670f9f032ec67d8f4e3f8db4646bf5a62883","https://git.kernel.org/stable/c/744e1885922a9943458954cfea917b31064b4131","https://git.kernel.org/stable/c/7d9e5bed036a7f9e2062a137e97e3c1e77fb8759","https://git.kernel.org/stable/c/a5f2f91b3fd7387e5102060809316a0f8f0bc625","https://git.kernel.org/stable/c/e0e3f4a18784182cfe34e20c00eca11e78d53e76","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52445
|
High |
fixed |
- 4.19.306
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
media: pvrusb2: fix use after free on context disconnection
Upon module load, a kthread is created targeting the
pvr2_context_thread_func function, which may call pvr2_context_destroy
and thus call kfree() on the context object. However, that might happen
before the usb hub_event handler is able to notify the driver. This
patch adds a sanity check before the invalid read reported by syzbot,
within the context disconnection call stack. |
["https://git.kernel.org/stable/c/2cf0005d315549b8d2b940ff96a66c2a889aa795","https://git.kernel.org/stable/c/30773ea47d41773f9611ffb4ebc9bda9d19a9e7e","https://git.kernel.org/stable/c/3233d8bf7893550045682192cb227af7fa3defeb","https://git.kernel.org/stable/c/437b5f57732bb4cc32cc9f8895d2010ee9ff521c","https://git.kernel.org/stable/c/47aa8fcd5e8b5563af4042a00f25ba89bef8f33d","https://git.kernel.org/stable/c/ded85b0c0edd8f45fec88783d7555a5b982449c1","https://git.kernel.org/stable/c/ec3634ebe23fc3c44ebc67c6d25917300bc68c08","https://git.kernel.org/stable/c/ec36c134dd020d28e312c2f1766f85525e747aab","https://git.kernel.org/stable/c/2cf0005d315549b8d2b940ff96a66c2a889aa795","https://git.kernel.org/stable/c/30773ea47d41773f9611ffb4ebc9bda9d19a9e7e","https://git.kernel.org/stable/c/3233d8bf7893550045682192cb227af7fa3defeb","https://git.kernel.org/stable/c/437b5f57732bb4cc32cc9f8895d2010ee9ff521c","https://git.kernel.org/stable/c/47aa8fcd5e8b5563af4042a00f25ba89bef8f33d","https://git.kernel.org/stable/c/ded85b0c0edd8f45fec88783d7555a5b982449c1","https://git.kernel.org/stable/c/ec3634ebe23fc3c44ebc67c6d25917300bc68c08","https://git.kernel.org/stable/c/ec36c134dd020d28e312c2f1766f85525e747aab","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52599
|
High |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix array-index-out-of-bounds in diNewExt
[Syz report]
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_imap.c:2360:2
index -878706688 is out of range for type 'struct iagctl[128]'
CPU: 1 PID: 5065 Comm: syz-executor282 Not tainted 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
ubsan_epilogue lib/ubsan.c:217 [inline]
__ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348
diNewExt+0x3cf3/0x4000 fs/jfs/jfs_imap.c:2360
diAllocExt fs/jfs/jfs_imap.c:1949 [inline]
diAllocAG+0xbe8/0x1e50 fs/jfs/jfs_imap.c:1666
diAlloc+0x1d3/0x1760 fs/jfs/jfs_imap.c:1587
ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56
jfs_mkdir+0x1c5/0xb90 fs/jfs/namei.c:225
vfs_mkdir+0x2f1/0x4b0 fs/namei.c:4106
do_mkdirat+0x264/0x3a0 fs/namei.c:4129
__do_sys_mkdir fs/namei.c:4149 [inline]
__se_sys_mkdir fs/namei.c:4147 [inline]
__x64_sys_mkdir+0x6e/0x80 fs/namei.c:4147
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x45/0x110 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x63/0x6b
RIP: 0033:0x7fcb7e6a0b57
Code: ff ff 77 07 31 c0 c3 0f 1f 40 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 b8 53 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffd83023038 EFLAGS: 00000286 ORIG_RAX: 0000000000000053
RAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 00007fcb7e6a0b57
RDX: 00000000000a1020 RSI: 00000000000001ff RDI: 0000000020000140
RBP: 0000000020000140 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000286 R12: 00007ffd830230d0
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[Analysis]
When the agstart is too large, it can cause agno overflow.
[Fix]
After obtaining agno, if the value is invalid, exit the subsequent process.
Modified the test from agno > MAXAG to agno >= MAXAG based on linux-next
report by kernel test robot (Dan Carpenter). |
["https://git.kernel.org/stable/c/3537f92cd22c672db97fae6997481e678ad14641","https://git.kernel.org/stable/c/49f9637aafa6e63ba686c13cb8549bf5e6920402","https://git.kernel.org/stable/c/5a6660139195f5e2fbbda459eeecb8788f3885fe","https://git.kernel.org/stable/c/6996d43b14486f4a6655b10edc541ada1b580b4b","https://git.kernel.org/stable/c/6aa30020879042d46df9f747e4f0a486eea6fe98","https://git.kernel.org/stable/c/de6a91aed1e0b1a23e9c11e7d7557f088eeeb017","https://git.kernel.org/stable/c/e2b77d107b33bb31c8b1f5c4cb8f277b23728f1e","https://git.kernel.org/stable/c/f423528488e4f9606cef858eceea210bf1163f41","https://git.kernel.org/stable/c/3537f92cd22c672db97fae6997481e678ad14641","https://git.kernel.org/stable/c/49f9637aafa6e63ba686c13cb8549bf5e6920402","https://git.kernel.org/stable/c/5a6660139195f5e2fbbda459eeecb8788f3885fe","https://git.kernel.org/stable/c/6996d43b14486f4a6655b10edc541ada1b580b4b","https://git.kernel.org/stable/c/6aa30020879042d46df9f747e4f0a486eea6fe98","https://git.kernel.org/stable/c/de6a91aed1e0b1a23e9c11e7d7557f088eeeb017","https://git.kernel.org/stable/c/e2b77d107b33bb31c8b1f5c4cb8f277b23728f1e","https://git.kernel.org/stable/c/f423528488e4f9606cef858eceea210bf1163f41","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49168
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not clean up repair bio if submit fails
The submit helper will always run bio_endio() on the bio if it fails to
submit, so cleaning up the bio just leads to a variety of use-after-free
and NULL pointer dereference bugs because we race with the endio
function that is cleaning up the bio. Instead just return BLK_STS_OK as
the repair function has to continue to process the rest of the pages,
and the endio for the repair bio will do the appropriate cleanup for the
page that it was given. |
["https://git.kernel.org/stable/c/7170875083254b51fcc5d67f96640977083f481e","https://git.kernel.org/stable/c/8cbc3001a3264d998d6b6db3e23f935c158abd4d","https://git.kernel.org/stable/c/d1cb11fb45ebbb1e7dfe5e9038b32ea72c184b14","https://git.kernel.org/stable/c/e76c78c48902dae6fa612749f59162bca0a79e0b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49328
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mt76: fix use-after-free by removing a non-RCU wcid pointer
Fixes an issue caught by KASAN about use-after-free in mt76_txq_schedule
by protecting mtxq->wcid with rcu_lock between mt76_txq_schedule and
sta_info_[alloc, free].
[18853.876689] ==================================================================
[18853.876751] BUG: KASAN: use-after-free in mt76_txq_schedule+0x204/0xaf8 [mt76]
[18853.876773] Read of size 8 at addr ffffffaf989a2138 by task mt76-tx phy0/883
[18853.876786]
[18853.876810] CPU: 5 PID: 883 Comm: mt76-tx phy0 Not tainted 5.10.100-fix-510-56778d365941-kasan #5 0b01fbbcf41a530f52043508fec2e31a4215
[18853.876840] Call trace:
[18853.876861] dump_backtrace+0x0/0x3ec
[18853.876878] show_stack+0x20/0x2c
[18853.876899] dump_stack+0x11c/0x1ac
[18853.876918] print_address_description+0x74/0x514
[18853.876934] kasan_report+0x134/0x174
[18853.876948] __asan_report_load8_noabort+0x44/0x50
[18853.876976] mt76_txq_schedule+0x204/0xaf8 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2]
[18853.877002] mt76_txq_schedule_all+0x2c/0x48 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2]
[18853.877030] mt7921_tx_worker+0xa0/0x1cc [mt7921_common f0875ebac9d7b4754e1010549e7db50fbd90a047]
[18853.877054] __mt76_worker_fn+0x190/0x22c [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2]
[18853.877071] kthread+0x2f8/0x3b8
[18853.877087] ret_from_fork+0x10/0x30
[18853.877098]
[18853.877112] Allocated by task 941:
[18853.877131] kasan_save_stack+0x38/0x68
[18853.877147] __kasan_kmalloc+0xd4/0xfc
[18853.877163] kasan_kmalloc+0x10/0x1c
[18853.877177] __kmalloc+0x264/0x3c4
[18853.877294] sta_info_alloc+0x460/0xf88 [mac80211]
[18853.877410] ieee80211_prep_connection+0x204/0x1ee0 [mac80211]
[18853.877523] ieee80211_mgd_auth+0x6c4/0xa4c [mac80211]
[18853.877635] ieee80211_auth+0x20/0x2c [mac80211]
[18853.877733] rdev_auth+0x7c/0x438 [cfg80211]
[18853.877826] cfg80211_mlme_auth+0x26c/0x390 [cfg80211]
[18853.877919] nl80211_authenticate+0x6d4/0x904 [cfg80211]
[18853.877938] genl_rcv_msg+0x748/0x93c
[18853.877954] netlink_rcv_skb+0x160/0x2a8
[18853.877969] genl_rcv+0x3c/0x54
[18853.877985] netlink_unicast_kernel+0x104/0x1ec
[18853.877999] netlink_unicast+0x178/0x268
[18853.878015] netlink_sendmsg+0x3cc/0x5f0
[18853.878030] sock_sendmsg+0xb4/0xd8
[18853.878043] ____sys_sendmsg+0x2f8/0x53c
[18853.878058] ___sys_sendmsg+0xe8/0x150
[18853.878071] __sys_sendmsg+0xc4/0x1f4
[18853.878087] __arm64_compat_sys_sendmsg+0x88/0x9c
[18853.878101] el0_svc_common+0x1b4/0x390
[18853.878115] do_el0_svc_compat+0x8c/0xdc
[18853.878131] el0_svc_compat+0x10/0x1c
[18853.878146] el0_sync_compat_handler+0xa8/0xcc
[18853.878161] el0_sync_compat+0x188/0x1c0
[18853.878171]
[18853.878183] Freed by task 10927:
[18853.878200] kasan_save_stack+0x38/0x68
[18853.878215] kasan_set_track+0x28/0x3c
[18853.878228] kasan_set_free_info+0x24/0x48
[18853.878244] __kasan_slab_free+0x11c/0x154
[18853.878259] kasan_slab_free+0x14/0x24
[18853.878273] slab_free_freelist_hook+0xac/0x1b0
[18853.878287] kfree+0x104/0x390
[18853.878402] sta_info_free+0x198/0x210 [mac80211]
[18853.878515] __sta_info_destroy_part2+0x230/0x2d4 [mac80211]
[18853.878628] __sta_info_flush+0x300/0x37c [mac80211]
[18853.878740] ieee80211_set_disassoc+0x2cc/0xa7c [mac80211]
[18853.878851] ieee80211_mgd_deauth+0x4a4/0x10a0 [mac80211]
[18853.878962] ieee80211_deauth+0x20/0x2c [mac80211]
[18853.879057] rdev_deauth+0x7c/0x438 [cfg80211]
[18853.879150] cfg80211_mlme_deauth+0x274/0x414 [cfg80211]
[18853.879243] cfg80211_mlme_down+0xe4/0x118 [cfg80211]
[18853.879335] cfg80211_disconnect+0x218/0x2d8 [cfg80211]
[18853.879427] __cfg80211_leave+0x17c/0x240 [cfg80211]
[18853.879519] cfg80211_leave+0x3c/0x58 [cfg80211]
[18853.879611] wiphy_suspend+0xdc/0x200 [cfg80211]
[18853.879628] dpm_run_callback+0x58/0x408
[18853.879642] __device_suspend+0x4cc/0x864
[18853.879658] async_suspend+0x34/0xf4
[18
---truncated--- |
["https://git.kernel.org/stable/c/4448327b41738dbfcda680eb4935ff835568f468","https://git.kernel.org/stable/c/51fb1278aa57ae0fc54adaa786e1965362bed4fb","https://git.kernel.org/stable/c/d5f77f1dbb59feae81f88e44551e8e1d8a802d9a","https://git.kernel.org/stable/c/e55bcdd0bf34a8b10d45ce80ebb3164c5292a17d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26754
|
High |
fixed |
- 4.19.308
- 5.4.270
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()
The gtp_net_ops pernet operations structure for the subsystem must be
registered before registering the generic netlink family.
Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:
general protection fault, probably for non-canonical address
0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014
RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp]
Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86
df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74
RSP: 0018:ffff888014107220 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000
FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
<TASK>
? show_regs+0x90/0xa0
? die_addr+0x50/0xd0
? exc_general_protection+0x148/0x220
? asm_exc_general_protection+0x22/0x30
? gtp_genl_dump_pdp+0x1be/0x800 [gtp]
? __alloc_skb+0x1dd/0x350
? __pfx___alloc_skb+0x10/0x10
genl_dumpit+0x11d/0x230
netlink_dump+0x5b9/0xce0
? lockdep_hardirqs_on_prepare+0x253/0x430
? __pfx_netlink_dump+0x10/0x10
? kasan_save_track+0x10/0x40
? __kasan_kmalloc+0x9b/0xa0
? genl_start+0x675/0x970
__netlink_dump_start+0x6fc/0x9f0
genl_family_rcv_msg_dumpit+0x1bb/0x2d0
? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10
? genl_op_from_small+0x2a/0x440
? cap_capable+0x1d0/0x240
? __pfx_genl_start+0x10/0x10
? __pfx_genl_dumpit+0x10/0x10
? __pfx_genl_done+0x10/0x10
? security_capable+0x9d/0xe0 |
["https://git.kernel.org/stable/c/136cfaca22567a03bbb3bf53a43d8cb5748b80ec","https://git.kernel.org/stable/c/2e534fd15e5c2ca15821c897352cf0e8a3e30dca","https://git.kernel.org/stable/c/3963f16cc7643b461271989b712329520374ad2a","https://git.kernel.org/stable/c/5013bd54d283eda5262c9ae3bcc966d01daf8576","https://git.kernel.org/stable/c/a576308800be28f2eaa099e7caad093b97d66e77","https://git.kernel.org/stable/c/ba6b8b02a3314e62571a540efa96560888c5f03e","https://git.kernel.org/stable/c/f0ecdfa679189d26aedfe24212d4e69e42c2c861","https://git.kernel.org/stable/c/f8cbd1791900b5d96466eede8e9439a5b9ca4de7","https://git.kernel.org/stable/c/136cfaca22567a03bbb3bf53a43d8cb5748b80ec","https://git.kernel.org/stable/c/2e534fd15e5c2ca15821c897352cf0e8a3e30dca","https://git.kernel.org/stable/c/3963f16cc7643b461271989b712329520374ad2a","https://git.kernel.org/stable/c/5013bd54d283eda5262c9ae3bcc966d01daf8576","https://git.kernel.org/stable/c/a576308800be28f2eaa099e7caad093b97d66e77","https://git.kernel.org/stable/c/ba6b8b02a3314e62571a540efa96560888c5f03e","https://git.kernel.org/stable/c/f0ecdfa679189d26aedfe24212d4e69e42c2c861","https://git.kernel.org/stable/c/f8cbd1791900b5d96466eede8e9439a5b9ca4de7","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52439
|
High |
fixed |
- 4.19.306
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.74
- 6.6.13
- 6.7.1
|
In the Linux kernel, the following vulnerability has been resolved:
uio: Fix use-after-free in uio_open
core-1 core-2
-------------------------------------------------------
uio_unregister_device uio_open
idev = idr_find()
device_unregister(&idev->dev)
put_device(&idev->dev)
uio_device_release
get_device(&idev->dev)
kfree(idev)
uio_free_minor(minor)
uio_release
put_device(&idev->dev)
kfree(idev)
-------------------------------------------------------
In the core-1 uio_unregister_device(), the device_unregister will kfree
idev when the idev->dev kobject ref is 1. But after core-1
device_unregister, put_device and before doing kfree, the core-2 may
get_device. Then:
1. After core-1 kfree idev, the core-2 will do use-after-free for idev.
2. When core-2 do uio_release and put_device, the idev will be double
freed.
To address this issue, we can get idev atomic & inc idev reference with
minor_lock. |
["https://git.kernel.org/stable/c/0c9ae0b8605078eafc3bea053cc78791e97ba2e2","https://git.kernel.org/stable/c/17a8519cb359c3b483fb5c7367efa9a8a508bdea","https://git.kernel.org/stable/c/3174e0f7de1ba392dc191625da83df02d695b60c","https://git.kernel.org/stable/c/35f102607054faafe78d2a6994b18d5d9d6e92ad","https://git.kernel.org/stable/c/5cf604ee538ed0c467abe3b4cda5308a6398f0f7","https://git.kernel.org/stable/c/5e0be1229ae199ebb90b33102f74a0f22d152570","https://git.kernel.org/stable/c/913205930da6213305616ac539447702eaa85e41","https://git.kernel.org/stable/c/e93da893d52d82d57fc0db2ca566024e0f26ff50","https://git.kernel.org/stable/c/0c9ae0b8605078eafc3bea053cc78791e97ba2e2","https://git.kernel.org/stable/c/17a8519cb359c3b483fb5c7367efa9a8a508bdea","https://git.kernel.org/stable/c/3174e0f7de1ba392dc191625da83df02d695b60c","https://git.kernel.org/stable/c/35f102607054faafe78d2a6994b18d5d9d6e92ad","https://git.kernel.org/stable/c/5cf604ee538ed0c467abe3b4cda5308a6398f0f7","https://git.kernel.org/stable/c/5e0be1229ae199ebb90b33102f74a0f22d152570","https://git.kernel.org/stable/c/913205930da6213305616ac539447702eaa85e41","https://git.kernel.org/stable/c/e93da893d52d82d57fc0db2ca566024e0f26ff50","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://security.netapp.com/advisory/ntap-20241227-0006/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42071
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ionic: use dev_consume_skb_any outside of napi
If we're not in a NAPI softirq context, we need to be careful
about how we call napi_consume_skb(), specifically we need to
call it with budget==0 to signal to it that we're not in a
safe context.
This was found while running some configuration stress testing
of traffic and a change queue config loop running, and this
curious note popped out:
[ 4371.402645] BUG: using smp_processor_id() in preemptible [00000000] code: ethtool/20545
[ 4371.402897] caller is napi_skb_cache_put+0x16/0x80
[ 4371.403120] CPU: 25 PID: 20545 Comm: ethtool Kdump: loaded Tainted: G OE 6.10.0-rc3-netnext+ #8
[ 4371.403302] Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 01/23/2021
[ 4371.403460] Call Trace:
[ 4371.403613] <TASK>
[ 4371.403758] dump_stack_lvl+0x4f/0x70
[ 4371.403904] check_preemption_disabled+0xc1/0xe0
[ 4371.404051] napi_skb_cache_put+0x16/0x80
[ 4371.404199] ionic_tx_clean+0x18a/0x240 [ionic]
[ 4371.404354] ionic_tx_cq_service+0xc4/0x200 [ionic]
[ 4371.404505] ionic_tx_flush+0x15/0x70 [ionic]
[ 4371.404653] ? ionic_lif_qcq_deinit.isra.23+0x5b/0x70 [ionic]
[ 4371.404805] ionic_txrx_deinit+0x71/0x190 [ionic]
[ 4371.404956] ionic_reconfigure_queues+0x5f5/0xff0 [ionic]
[ 4371.405111] ionic_set_ringparam+0x2e8/0x3e0 [ionic]
[ 4371.405265] ethnl_set_rings+0x1f1/0x300
[ 4371.405418] ethnl_default_set_doit+0xbb/0x160
[ 4371.405571] genl_family_rcv_msg_doit+0xff/0x130
[...]
I found that ionic_tx_clean() calls napi_consume_skb() which calls
napi_skb_cache_put(), but before that last call is the note
/* Zero budget indicate non-NAPI context called us, like netpoll */
and
DEBUG_NET_WARN_ON_ONCE(!in_softirq());
Those are pretty big hints that we're doing it wrong. We can pass a
context hint down through the calls to let ionic_tx_clean() know what
we're doing so it can call napi_consume_skb() correctly. |
["https://git.kernel.org/stable/c/84b767f9e34fdb143c09e66a2a20722fc2921821","https://git.kernel.org/stable/c/ef7646ed49fff962e97b276f4ab91327a67eeb5a","https://git.kernel.org/stable/c/84b767f9e34fdb143c09e66a2a20722fc2921821","https://git.kernel.org/stable/c/ef7646ed49fff962e97b276f4ab91327a67eeb5a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-47637
|
Medium |
fixed |
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
ubifs: Fix deadlock in concurrent rename whiteout and inode writeback
Following hung tasks:
[ 77.028764] task:kworker/u8:4 state:D stack: 0 pid: 132
[ 77.028820] Call Trace:
[ 77.029027] schedule+0x8c/0x1b0
[ 77.029067] mutex_lock+0x50/0x60
[ 77.029074] ubifs_write_inode+0x68/0x1f0 [ubifs]
[ 77.029117] __writeback_single_inode+0x43c/0x570
[ 77.029128] writeback_sb_inodes+0x259/0x740
[ 77.029148] wb_writeback+0x107/0x4d0
[ 77.029163] wb_workfn+0x162/0x7b0
[ 92.390442] task:aa state:D stack: 0 pid: 1506
[ 92.390448] Call Trace:
[ 92.390458] schedule+0x8c/0x1b0
[ 92.390461] wb_wait_for_completion+0x82/0xd0
[ 92.390469] __writeback_inodes_sb_nr+0xb2/0x110
[ 92.390472] writeback_inodes_sb_nr+0x14/0x20
[ 92.390476] ubifs_budget_space+0x705/0xdd0 [ubifs]
[ 92.390503] do_rename.cold+0x7f/0x187 [ubifs]
[ 92.390549] ubifs_rename+0x8b/0x180 [ubifs]
[ 92.390571] vfs_rename+0xdb2/0x1170
[ 92.390580] do_renameat2+0x554/0x770
, are caused by concurrent rename whiteout and inode writeback processes:
rename_whiteout(Thread 1) wb_workfn(Thread2)
ubifs_rename
do_rename
lock_4_inodes (Hold ui_mutex)
ubifs_budget_space
make_free_space
shrink_liability
__writeback_inodes_sb_nr
bdi_split_work_to_wbs (Queue new wb work)
wb_do_writeback(wb work)
__writeback_single_inode
ubifs_write_inode
LOCK(ui_mutex)
↑
wb_wait_for_completion (Wait wb work) <-- deadlock!
Reproducer (Detail program in [Link]):
1. SYS_renameat2("/mp/dir/file", "/mp/dir/whiteout", RENAME_WHITEOUT)
2. Consume out of space before kernel(mdelay) doing budget for whiteout
Fix it by doing whiteout space budget before locking ubifs inodes.
BTW, it also fixes wrong goto tag 'out_release' in whiteout budget
error handling path(It should at least recover dir i_size and unlock
4 ubifs inodes). |
["https://git.kernel.org/stable/c/37bdf1ad592555ecda1d55b89f6e393e4c0589d1","https://git.kernel.org/stable/c/70e9090acc32348cedc5def0cd6d5c126efc97b9","https://git.kernel.org/stable/c/83e42a78428fc354f5e2049935b84c8d8d29b787","https://git.kernel.org/stable/c/8b278c8dcfb565cb65eceb62a38cbf7a7c326db5","https://git.kernel.org/stable/c/9dddc8211430fb851ddf0b168e3a00c6f66cc185","https://git.kernel.org/stable/c/afd427048047e8efdedab30e8888044e2be5aa9c","https://git.kernel.org/stable/c/c58af8564a7b08757173009030b74baf4b2b762b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49305
|
Medium |
fixed |
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
drivers: staging: rtl8192u: Fix deadlock in ieee80211_beacons_stop()
There is a deadlock in ieee80211_beacons_stop(), which is shown below:
(Thread 1) | (Thread 2)
| ieee80211_send_beacon()
ieee80211_beacons_stop() | mod_timer()
spin_lock_irqsave() //(1) | (wait a time)
... | ieee80211_send_beacon_cb()
del_timer_sync() | spin_lock_irqsave() //(2)
(wait timer to stop) | ...
We hold ieee->beacon_lock in position (1) of thread 1 and use
del_timer_sync() to wait timer to stop, but timer handler
also need ieee->beacon_lock in position (2) of thread 2.
As a result, ieee80211_beacons_stop() will block forever.
This patch extracts del_timer_sync() from the protection of
spin_lock_irqsave(), which could let timer handler to obtain
the needed lock. |
["https://git.kernel.org/stable/c/042915c1bfedd684c1d98a841794ee203200571a","https://git.kernel.org/stable/c/1fbe033c52480f7954c057510040fa6286c4ea25","https://git.kernel.org/stable/c/66f769762f65d957f688f3258755c6ec410bf710","https://git.kernel.org/stable/c/806c7b53414934ba2a39449b31fd1a038e500273","https://git.kernel.org/stable/c/b34cb54923a6e5ddefbaf358c85c922c6ab456e2","https://git.kernel.org/stable/c/b465bb2ebf666116c1ac745cb80c65154dc0d27e","https://git.kernel.org/stable/c/ffc9cab7243f8151be37966301307bfd3cda2db3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49316
|
Medium |
fixed |
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
NFSv4: Don't hold the layoutget locks across multiple RPC calls
When doing layoutget as part of the open() compound, we have to be
careful to release the layout locks before we can call any further RPC
calls, such as setattr(). The reason is that those calls could trigger
a recall, which could deadlock. |
["https://git.kernel.org/stable/c/08d7a26d115cc7892668baa9750f64bd8baca29b","https://git.kernel.org/stable/c/0ee5b9644f06b4d3cdcd9544f43f63312e425a4c","https://git.kernel.org/stable/c/6949493884fe88500de4af182588e071cf1544ee","https://git.kernel.org/stable/c/6b3fc1496e7227cd6a39a80bbfb7588ef7c7a010","https://git.kernel.org/stable/c/a2b3be930e79cc5d9d829f158e31172b2043f0cd","https://git.kernel.org/stable/c/d4c2a041ed3ba114502d5ed6ace5b1a48d637a8e","https://git.kernel.org/stable/c/ea759ae0a9ae5acee677d722129710ac89cc59c1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49322
|
Medium |
fixed |
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix sleeping function called from invalid context on RT kernel
When setting bootparams="trace_event=initcall:initcall_start tp_printk=1" in the
cmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the
atomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel,
these locks are replaced with sleepable rt-spinlock, so the stack calltrace will
be triggered.
Fix it by raw_spin_lock_irqsave when PREEMPT_RT and "trace_event=initcall:initcall_start
tp_printk=1" enabled.
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0
preempt_count: 2, expected: 0
RCU nest depth: 0, expected: 0
Preemption disabled at:
[<ffffffff8992303e>] try_to_wake_up+0x7e/0xba0
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.1-rt17+ #19 34c5812404187a875f32bee7977f7367f9679ea7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x60/0x8c
dump_stack+0x10/0x12
__might_resched.cold+0x11d/0x155
rt_spin_lock+0x40/0x70
trace_event_buffer_commit+0x2fa/0x4c0
? map_vsyscall+0x93/0x93
trace_event_raw_event_initcall_start+0xbe/0x110
? perf_trace_initcall_finish+0x210/0x210
? probe_sched_wakeup+0x34/0x40
? ttwu_do_wakeup+0xda/0x310
? trace_hardirqs_on+0x35/0x170
? map_vsyscall+0x93/0x93
do_one_initcall+0x217/0x3c0
? trace_event_raw_event_initcall_level+0x170/0x170
? push_cpu_stop+0x400/0x400
? cblist_init_generic+0x241/0x290
kernel_init_freeable+0x1ac/0x347
? _raw_spin_unlock_irq+0x65/0x80
? rest_init+0xf0/0xf0
kernel_init+0x1e/0x150
ret_from_fork+0x22/0x30
</TASK> |
["https://git.kernel.org/stable/c/12025abdc8539ed9d5014e2d647a3fd1bd3de5cd","https://git.kernel.org/stable/c/1788e6dbb61286215442b1af99e51405a6206762","https://git.kernel.org/stable/c/40f9fde06b25884baa0c4bd138b909a9b67218b4","https://git.kernel.org/stable/c/43bfc4dccc416c964b53cbdc430e814f8b6f770b","https://git.kernel.org/stable/c/48c6ee7d6c614f09b2c8553a95eefef6ecf196e0","https://git.kernel.org/stable/c/9abf3db8bdb63ab545034148ef2118f4d088ca59","https://git.kernel.org/stable/c/9b534640a2c6a8d88168febc82ec6d161184f2ec","https://git.kernel.org/stable/c/be1f323fb9d9b14a505ca22d742d321769454de1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49371
|
Medium |
fixed |
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
driver core: fix deadlock in __device_attach
In __device_attach function, The lock holding logic is as follows:
...
__device_attach
device_lock(dev) // get lock dev
async_schedule_dev(__device_attach_async_helper, dev); // func
async_schedule_node
async_schedule_node_domain(func)
entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);
/* when fail or work limit, sync to execute func, but
__device_attach_async_helper will get lock dev as
well, which will lead to A-A deadlock. */
if (!entry || atomic_read(&entry_count) > MAX_WORK) {
func;
else
queue_work_node(node, system_unbound_wq, &entry->work)
device_unlock(dev)
As shown above, when it is allowed to do async probes, because of
out of memory or work limit, async work is not allowed, to do
sync execute instead. it will lead to A-A deadlock because of
__device_attach_async_helper getting lock dev.
To fix the deadlock, move the async_schedule_dev outside device_lock,
as we can see, in async_schedule_node_domain, the parameter of
queue_work_node is system_unbound_wq, so it can accept concurrent
operations. which will also not change the code logic, and will
not lead to deadlock. |
["https://git.kernel.org/stable/c/34fdd9b7def9d2fcb71bb7b0bc4848dd7313767e","https://git.kernel.org/stable/c/36ee9ffca8ef56c302f2855c4a5fccf61c0c1ada","https://git.kernel.org/stable/c/593b595332bd2d65e1a5c1ae7897996c157f5468","https://git.kernel.org/stable/c/b232b02bf3c205b13a26dcec08e53baddd8e59ed","https://git.kernel.org/stable/c/d53a227bfcd5160ce1b61d9954901968a20651e7","https://git.kernel.org/stable/c/df6de52b80aa3b46f5ac804412355ffe2e1df93e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21820
|
Medium |
fixed |
- 6.1.129
- 6.6.78
- 6.12.14
- 6.13.3
|
In the Linux kernel, the following vulnerability has been resolved:
tty: xilinx_uartps: split sysrq handling
lockdep detects the following circular locking dependency:
CPU 0 CPU 1
========================== ============================
cdns_uart_isr() printk()
uart_port_lock(port) console_lock()
cdns_uart_console_write()
if (!port->sysrq)
uart_port_lock(port)
uart_handle_break()
port->sysrq = ...
uart_handle_sysrq_char()
printk()
console_lock()
The fixed commit attempts to avoid this situation by only taking the
port lock in cdns_uart_console_write if port->sysrq unset. However, if
(as shown above) cdns_uart_console_write runs before port->sysrq is set,
then it will try to take the port lock anyway. This may result in a
deadlock.
Fix this by splitting sysrq handling into two parts. We use the prepare
helper under the port lock and defer handling until we release the lock. |
["https://git.kernel.org/stable/c/4410dba9807a17a93f649a9f5870ceaf30a675a3","https://git.kernel.org/stable/c/8ea0e7b3d7b8f2f0fc9db491ff22a0abe120801c","https://git.kernel.org/stable/c/9b88a7c4584ba67267a051069b8abe44fc9595b2","https://git.kernel.org/stable/c/b06f388994500297bb91be60ffaf6825ecfd2afe","https://git.kernel.org/stable/c/de5bd24197bd9ee37ec1e379a3d882bbd15c5065","https://git.kernel.org/stable/c/e22a97700901ba5e8bf8db68056a0d50f9440cae"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49309
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drivers: staging: rtl8723bs: Fix deadlock in rtw_surveydone_event_callback()
There is a deadlock in rtw_surveydone_event_callback(),
which is shown below:
(Thread 1) | (Thread 2)
| _set_timer()
rtw_surveydone_event_callback()| mod_timer()
spin_lock_bh() //(1) | (wait a time)
... | rtw_scan_timeout_handler()
del_timer_sync() | spin_lock_bh() //(2)
(wait timer to stop) | ...
We hold pmlmepriv->lock in position (1) of thread 1 and use
del_timer_sync() to wait timer to stop, but timer handler
also need pmlmepriv->lock in position (2) of thread 2.
As a result, rtw_surveydone_event_callback() will block forever.
This patch extracts del_timer_sync() from the protection of
spin_lock_bh(), which could let timer handler to obtain
the needed lock. What`s more, we change spin_lock_bh() in
rtw_scan_timeout_handler() to spin_lock_irq(). Otherwise,
spin_lock_bh() will also cause deadlock() in timer handler. |
["https://git.kernel.org/stable/c/2c41f5c341853f84b7bc2f32605d4e2782e8c279","https://git.kernel.org/stable/c/c84e5c819600ee0628f61b33d145258ae0f3d7a7","https://git.kernel.org/stable/c/cc7ad0d77b51c872d629bcd98aea463a3c4109e7","https://git.kernel.org/stable/c/ce129d3efd181da5fd56f4360cc8827122afa67e","https://git.kernel.org/stable/c/f89f6c3ebf69623b8ea48200bd690e9e210335a1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49327
|
Medium |
fixed |
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
bcache: avoid journal no-space deadlock by reserving 1 journal bucket
The journal no-space deadlock was reported time to time. Such deadlock
can happen in the following situation.
When all journal buckets are fully filled by active jset with heavy
write I/O load, the cache set registration (after a reboot) will load
all active jsets and inserting them into the btree again (which is
called journal replay). If a journaled bkey is inserted into a btree
node and results btree node split, new journal request might be
triggered. For example, the btree grows one more level after the node
split, then the root node record in cache device super block will be
upgrade by bch_journal_meta() from bch_btree_set_root(). But there is no
space in journal buckets, the journal replay has to wait for new journal
bucket to be reclaimed after at least one journal bucket replayed. This
is one example that how the journal no-space deadlock happens.
The solution to avoid the deadlock is to reserve 1 journal bucket in
run time, and only permit the reserved journal bucket to be used during
cache set registration procedure for things like journal replay. Then
the journal space will never be fully filled, there is no chance for
journal no-space deadlock to happen anymore.
This patch adds a new member "bool do_reserve" in struct journal, it is
inititalized to 0 (false) when struct journal is allocated, and set to
1 (true) by bch_journal_space_reserve() when all initialization done in
run_cache_set(). In the run time when journal_reclaim() tries to
allocate a new journal bucket, free_journal_buckets() is called to check
whether there are enough free journal buckets to use. If there is only
1 free journal bucket and journal->do_reserve is 1 (true), the last
bucket is reserved and free_journal_buckets() will return 0 to indicate
no free journal bucket. Then journal_reclaim() will give up, and try
next time to see whetheer there is free journal bucket to allocate. By
this method, there is always 1 jouranl bucket reserved in run time.
During the cache set registration, journal->do_reserve is 0 (false), so
the reserved journal bucket can be used to avoid the no-space deadlock. |
["https://git.kernel.org/stable/c/1dda32aed6f62c163f38ff947ef5b3360e329159","https://git.kernel.org/stable/c/32feee36c30ea06e38ccb8ae6e5c44c6eec790a6","https://git.kernel.org/stable/c/5607652823ac65e2c6885e73bd46d5a4f9a20363","https://git.kernel.org/stable/c/59afd4f287900c8187e968a4153ed35e6b48efce","https://git.kernel.org/stable/c/6332ea3e35efa12dc08f0cbf5faea5e6e8eb0497"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49446
|
Medium |
fixed |
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
nvdimm: Fix firmware activation deadlock scenarios
Lockdep reports the following deadlock scenarios for CXL root device
power-management, device_prepare(), operations, and device_shutdown()
operations for 'nd_region' devices:
Chain exists of:
&nvdimm_region_key --> &nvdimm_bus->reconfig_mutex --> system_transition_mutex
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(system_transition_mutex);
lock(&nvdimm_bus->reconfig_mutex);
lock(system_transition_mutex);
lock(&nvdimm_region_key);
Chain exists of:
&cxl_nvdimm_bridge_key --> acpi_scan_lock --> &cxl_root_key
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&cxl_root_key);
lock(acpi_scan_lock);
lock(&cxl_root_key);
lock(&cxl_nvdimm_bridge_key);
These stem from holding nvdimm_bus_lock() over hibernate_quiet_exec()
which walks the entire system device topology taking device_lock() along
the way. The nvdimm_bus_lock() is protecting against unregistration,
multiple simultaneous ops callers, and preventing activate_show() from
racing activate_store(). For the first 2, the lock is redundant.
Unregistration already flushes all ops users, and sysfs already prevents
multiple threads to be active in an ops handler at the same time. For
the last userspace should already be waiting for its last
activate_store() to complete, and does not need activate_show() to flush
the write side, so this lock usage can be deleted in these attributes. |
["https://git.kernel.org/stable/c/2f97ebc58d5fc83ca1528cd553fa725472ab3ca8","https://git.kernel.org/stable/c/2fd853fdb40afc052de338693df1372f2ead7be7","https://git.kernel.org/stable/c/641649f31e20df630310f5c22f26c071acc676d4","https://git.kernel.org/stable/c/ceb924ee16b2c8e48dcac3d9ad6be01c40b5a228","https://git.kernel.org/stable/c/e6829d1bd3c4b58296ee9e412f7ed4d6cb390192"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3707
|
Medium |
fixed |
|
A double-free memory flaw was found in the Linux kernel. The Intel GVT-g graphics driver triggers VGA card system resource overload, causing a fail in the intel_gvt_dma_map_guest_page function. This issue could allow a local user to crash the system. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2137979","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20221007013708.1946061-1-zyytlz.wz%40163.com/","https://bugzilla.redhat.com/show_bug.cgi?id=2137979","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20221007013708.1946061-1-zyytlz.wz%40163.com/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-4127
|
Medium |
fixed |
|
A NULL pointer dereference issue was discovered in the Linux kernel in io_files_update_with_index_alloc. A local user could use this flaw to potentially crash the system causing a denial of service. |
["https://github.com/torvalds/linux/commit/d785a773bed966a75ca1f11d108ae1897189975b","https://lore.kernel.org/all/d5a19c1e-9968-e22e-5917-c3139c5e7e89%40kernel.dk/","https://github.com/torvalds/linux/commit/d785a773bed966a75ca1f11d108ae1897189975b","https://lore.kernel.org/all/d5a19c1e-9968-e22e-5917-c3139c5e7e89%40kernel.dk/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1095
|
Medium |
fixed |
|
In nf_tables_updtable, if nf_tables_table_enable returns an error, nft_trans_destroy is called to free the transaction object. nft_trans_destroy() calls list_del(), but the transaction was never placed on a list -- the list head is all zeroes, this results in a NULL pointer dereference. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2173973","https://github.com/torvalds/linux/commit/580077855a40741cf511766129702d97ff02f4d9","https://bugzilla.redhat.com/show_bug.cgi?id=2173973","https://github.com/torvalds/linux/commit/580077855a40741cf511766129702d97ff02f4d9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-2905
|
Medium |
fixed |
|
An out-of-bounds memory read flaw was found in the Linux kernel's BPF subsystem in how a user calls the bpf_tail_call function with a key larger than the max_entries of the map. This flaw allows a local user to gain unauthorized access to data. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2121800","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/bpf/984b37f9fdf7ac36831d2137415a4a915744c1b6.1661462653.git.daniel%40iogearbox.net/","https://bugzilla.redhat.com/show_bug.cgi?id=2121800","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/bpf/984b37f9fdf7ac36831d2137415a4a915744c1b6.1661462653.git.daniel%40iogearbox.net/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-47632
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
powerpc/set_memory: Avoid spinlock recursion in change_page_attr()
Commit 1f9ad21c3b38 ("powerpc/mm: Implement set_memory() routines")
included a spin_lock() to change_page_attr() in order to
safely perform the three step operations. But then
commit 9f7853d7609d ("powerpc/mm: Fix set_memory_*() against
concurrent accesses") modify it to use pte_update() and do
the operation safely against concurrent access.
In the meantime, Maxime reported some spinlock recursion.
[ 15.351649] BUG: spinlock recursion on CPU#0, kworker/0:2/217
[ 15.357540] lock: init_mm+0x3c/0x420, .magic: dead4ead, .owner: kworker/0:2/217, .owner_cpu: 0
[ 15.366563] CPU: 0 PID: 217 Comm: kworker/0:2 Not tainted 5.15.0+ #523
[ 15.373350] Workqueue: events do_free_init
[ 15.377615] Call Trace:
[ 15.380232] [e4105ac0] [800946a4] do_raw_spin_lock+0xf8/0x120 (unreliable)
[ 15.387340] [e4105ae0] [8001f4ec] change_page_attr+0x40/0x1d4
[ 15.393413] [e4105b10] [801424e0] __apply_to_page_range+0x164/0x310
[ 15.400009] [e4105b60] [80169620] free_pcp_prepare+0x1e4/0x4a0
[ 15.406045] [e4105ba0] [8016c5a0] free_unref_page+0x40/0x2b8
[ 15.411979] [e4105be0] [8018724c] kasan_depopulate_vmalloc_pte+0x6c/0x94
[ 15.418989] [e4105c00] [801424e0] __apply_to_page_range+0x164/0x310
[ 15.425451] [e4105c50] [80187834] kasan_release_vmalloc+0xbc/0x134
[ 15.431898] [e4105c70] [8015f7a8] __purge_vmap_area_lazy+0x4e4/0xdd8
[ 15.438560] [e4105d30] [80160d10] _vm_unmap_aliases.part.0+0x17c/0x24c
[ 15.445283] [e4105d60] [801642d0] __vunmap+0x2f0/0x5c8
[ 15.450684] [e4105db0] [800e32d0] do_free_init+0x68/0x94
[ 15.456181] [e4105dd0] [8005d094] process_one_work+0x4bc/0x7b8
[ 15.462283] [e4105e90] [8005d614] worker_thread+0x284/0x6e8
[ 15.468227] [e4105f00] [8006aaec] kthread+0x1f0/0x210
[ 15.473489] [e4105f40] [80017148] ret_from_kernel_thread+0x14/0x1c
Remove the read / modify / write sequence to make the operation atomic
and remove the spin_lock() in change_page_attr().
To do the operation atomically, we can't use pte modification helpers
anymore. Because all platforms have different combination of bits, it
is not easy to use those bits directly. But all have the
_PAGE_KERNEL_{RO/ROX/RW/RWX} set of flags. All we need it to compare
two sets to know which bits are set or cleared.
For instance, by comparing _PAGE_KERNEL_ROX and _PAGE_KERNEL_RO you
know which bit gets cleared and which bit get set when changing exec
permission. |
["https://git.kernel.org/stable/c/6def4eaf0391f24be541633a954c0e4876858b1e","https://git.kernel.org/stable/c/6ebe5ca2cbe438a688f2ae238ef5a0b0b5f3468a","https://git.kernel.org/stable/c/96917107e67846f1d959ed03be281048efad14c5","https://git.kernel.org/stable/c/a4c182ecf33584b9b2d1aa9dad073014a504c01f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49311
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drivers: staging: rtl8192bs: Fix deadlock in rtw_joinbss_event_prehandle()
There is a deadlock in rtw_joinbss_event_prehandle(), which is shown
below:
(Thread 1) | (Thread 2)
| _set_timer()
rtw_joinbss_event_prehandle()| mod_timer()
spin_lock_bh() //(1) | (wait a time)
... | _rtw_join_timeout_handler()
del_timer_sync() | spin_lock_bh() //(2)
(wait timer to stop) | ...
We hold pmlmepriv->lock in position (1) of thread 1 and
use del_timer_sync() to wait timer to stop, but timer handler
also need pmlmepriv->lock in position (2) of thread 2.
As a result, rtw_joinbss_event_prehandle() will block forever.
This patch extracts del_timer_sync() from the protection of
spin_lock_bh(), which could let timer handler to obtain
the needed lock. What`s more, we change spin_lock_bh() to
spin_lock_irq() in _rtw_join_timeout_handler() in order to
prevent deadlock. |
["https://git.kernel.org/stable/c/041879b12ddb0c6c83ed9c0bdd10dc82a056f2fc","https://git.kernel.org/stable/c/1f6c99b94ca3caad346876b3e22e3ca3d25bc8ee","https://git.kernel.org/stable/c/ae60744d5fad840b9d056d35b4b652d95e755846","https://git.kernel.org/stable/c/eca9748d9267a38d532464e3305a38629e9c35a9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49536
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix SCSI I/O completion and abort handler deadlock
During stress I/O tests with 500+ vports, hard LOCKUP call traces are
observed.
CPU A:
native_queued_spin_lock_slowpath+0x192
_raw_spin_lock_irqsave+0x32
lpfc_handle_fcp_err+0x4c6
lpfc_fcp_io_cmd_wqe_cmpl+0x964
lpfc_sli4_fp_handle_cqe+0x266
__lpfc_sli4_process_cq+0x105
__lpfc_sli4_hba_process_cq+0x3c
lpfc_cq_poll_hdler+0x16
irq_poll_softirq+0x76
__softirqentry_text_start+0xe4
irq_exit+0xf7
do_IRQ+0x7f
CPU B:
native_queued_spin_lock_slowpath+0x5b
_raw_spin_lock+0x1c
lpfc_abort_handler+0x13e
scmd_eh_abort_handler+0x85
process_one_work+0x1a7
worker_thread+0x30
kthread+0x112
ret_from_fork+0x1f
Diagram of lockup:
CPUA CPUB
---- ----
lpfc_cmd->buf_lock
phba->hbalock
lpfc_cmd->buf_lock
phba->hbalock
Fix by reordering the taking of the lpfc_cmd->buf_lock and phba->hbalock in
lpfc_abort_handler routine so that it tries to take the lpfc_cmd->buf_lock
first before phba->hbalock. |
["https://git.kernel.org/stable/c/03cbbd7c2f5ee288f648f4aeedc765a181188553","https://git.kernel.org/stable/c/0c4eed901285b9cae36a622f32bea3e92490da6c","https://git.kernel.org/stable/c/21c0d469349957b5dc811c41200a2a998996ca8d","https://git.kernel.org/stable/c/7625e81de2164a082810e1f27547d388406da610"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49542
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Move cfg_log_verbose check before calling lpfc_dmp_dbg()
In an attempt to log message 0126 with LOG_TRACE_EVENT, the following hard
lockup call trace hangs the system.
Call Trace:
_raw_spin_lock_irqsave+0x32/0x40
lpfc_dmp_dbg.part.32+0x28/0x220 [lpfc]
lpfc_cmpl_els_fdisc+0x145/0x460 [lpfc]
lpfc_sli_cancel_jobs+0x92/0xd0 [lpfc]
lpfc_els_flush_cmd+0x43c/0x670 [lpfc]
lpfc_els_flush_all_cmd+0x37/0x60 [lpfc]
lpfc_sli4_async_event_proc+0x956/0x1720 [lpfc]
lpfc_do_work+0x1485/0x1d70 [lpfc]
kthread+0x112/0x130
ret_from_fork+0x1f/0x40
Kernel panic - not syncing: Hard LOCKUP
The same CPU tries to claim the phba->port_list_lock twice.
Move the cfg_log_verbose checks as part of the lpfc_printf_vlog() and
lpfc_printf_log() macros before calling lpfc_dmp_dbg(). There is no need
to take the phba->port_list_lock within lpfc_dmp_dbg(). |
["https://git.kernel.org/stable/c/09c772557a4fd9490fed1bfb133268313ea22213","https://git.kernel.org/stable/c/271725e4028559ae7974d762a8467dc9de412f2e","https://git.kernel.org/stable/c/cc6501afccec55b8b6c90584cbf71f1fefa77d1e","https://git.kernel.org/stable/c/e294647b1aed4247fe52851f3a3b2b19ae906228"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49475
|
Medium |
fixed |
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
spi: spi-fsl-qspi: check return value after calling platform_get_resource_byname()
It will cause null-ptr-deref if platform_get_resource_byname() returns NULL,
we need check the return value. |
["https://git.kernel.org/stable/c/10f537219629769498ecb8515e096be213224c24","https://git.kernel.org/stable/c/33dda87d04598ac5d9a849218a373443f7d3de66","https://git.kernel.org/stable/c/560dcbe1c7a78f597f2167371ebdbe2bca3d0735","https://git.kernel.org/stable/c/9d9c84825c3ec359b165c762a424cfdefe87fdd7","https://git.kernel.org/stable/c/a2b331ac11e1cac56f5b7d367e9f3c5796deaaed"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49304
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
drivers: tty: serial: Fix deadlock in sa1100_set_termios()
There is a deadlock in sa1100_set_termios(), which is shown
below:
(Thread 1) | (Thread 2)
| sa1100_enable_ms()
sa1100_set_termios() | mod_timer()
spin_lock_irqsave() //(1) | (wait a time)
... | sa1100_timeout()
del_timer_sync() | spin_lock_irqsave() //(2)
(wait timer to stop) | ...
We hold sport->port.lock in position (1) of thread 1 and
use del_timer_sync() to wait timer to stop, but timer handler
also need sport->port.lock in position (2) of thread 2. As a result,
sa1100_set_termios() will block forever.
This patch moves del_timer_sync() before spin_lock_irqsave()
in order to prevent the deadlock. |
["https://git.kernel.org/stable/c/0976808d0d171ec837d4bd3e9f4ad4a00ab703b8","https://git.kernel.org/stable/c/09a5958a2452ad22d0cb638711ef34ea1863a829","https://git.kernel.org/stable/c/2cbfc38df580bff5b2fe19f21c1a7520efcc4b3b","https://git.kernel.org/stable/c/34d91e555e5582cffdbcbb75517bc9217866823e","https://git.kernel.org/stable/c/553213432ef0c295becdc08c0207d2094468f673","https://git.kernel.org/stable/c/62b2caef400c1738b6d22f636c628d9f85cd4c4c","https://git.kernel.org/stable/c/6e2273eefab54a521d9c59efb6e1114e742bdf41","https://git.kernel.org/stable/c/85e20f8bd31a46d8c60103d0274a8ebe8f47f2b2","https://git.kernel.org/stable/c/920f0ae7a129ffee98a106e3bbdfd61a2a59e939"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49313
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
drivers: usb: host: Fix deadlock in oxu_bus_suspend()
There is a deadlock in oxu_bus_suspend(), which is shown below:
(Thread 1) | (Thread 2)
| timer_action()
oxu_bus_suspend() | mod_timer()
spin_lock_irq() //(1) | (wait a time)
... | oxu_watchdog()
del_timer_sync() | spin_lock_irq() //(2)
(wait timer to stop) | ...
We hold oxu->lock in position (1) of thread 1, and use
del_timer_sync() to wait timer to stop, but timer handler
also need oxu->lock in position (2) of thread 2. As a result,
oxu_bus_suspend() will block forever.
This patch extracts del_timer_sync() from the protection of
spin_lock_irq(), which could let timer handler to obtain
the needed lock. |
["https://git.kernel.org/stable/c/2dcec0bc142be2096af71a5703d63237127db204","https://git.kernel.org/stable/c/4187b291a76664a3c03d3f0d9bfadc8322881868","https://git.kernel.org/stable/c/4d378f2ae58138d4c55684e1d274e7dd94aa6524","https://git.kernel.org/stable/c/9b58d255f27b0ed6a2e43208960864d67579db58","https://git.kernel.org/stable/c/a3d380188bde8900c3f604e82b56572896499124","https://git.kernel.org/stable/c/b97aae8b43b718314012e8170b7e03dbfd2e7677","https://git.kernel.org/stable/c/d888753872190abd18f68a7d77b9c7c367f0a7ab","https://git.kernel.org/stable/c/f8242044c91cafbba9e320b0fb31abf2429a3221","https://git.kernel.org/stable/c/ffe9440d698274c6462d2e304562c6ddfc8c84df"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49315
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
drivers: staging: rtl8192e: Fix deadlock in rtllib_beacons_stop()
There is a deadlock in rtllib_beacons_stop(), which is shown
below:
(Thread 1) | (Thread 2)
| rtllib_send_beacon()
rtllib_beacons_stop() | mod_timer()
spin_lock_irqsave() //(1) | (wait a time)
... | rtllib_send_beacon_cb()
del_timer_sync() | spin_lock_irqsave() //(2)
(wait timer to stop) | ...
We hold ieee->beacon_lock in position (1) of thread 1 and
use del_timer_sync() to wait timer to stop, but timer handler
also need ieee->beacon_lock in position (2) of thread 2.
As a result, rtllib_beacons_stop() will block forever.
This patch extracts del_timer_sync() from the protection of
spin_lock_irqsave(), which could let timer handler to obtain
the needed lock. |
["https://git.kernel.org/stable/c/08bacf871c019163ccd1389d0bc957a43324967a","https://git.kernel.org/stable/c/0f69d7d5e918aa43423d86bd17ddb11b1b5e8ada","https://git.kernel.org/stable/c/381045dc64d23a2229c47c5524c06bfc33d34446","https://git.kernel.org/stable/c/4681129fda9e8555392eaaadb239ec6a6e2b3e12","https://git.kernel.org/stable/c/46c861009bf437a18417df24cea0d181741b7d72","https://git.kernel.org/stable/c/64b05fa212c7e4d057676e8b7e7120c6eb2f615b","https://git.kernel.org/stable/c/9b6bdbd9337de3917945847bde262a34a87a6303","https://git.kernel.org/stable/c/fef451f0fbbe85dbd2962b18379d02e2965610db","https://git.kernel.org/stable/c/ffd4c4d5293e4985092ea45ba21cad9326e2e434"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-2785
|
Medium |
fixed |
|
There exists an arbitrary memory read within the Linux Kernel BPF - Constants provided to fill pointers in structs passed in to bpf_sys_bpf are not verified and can point anywhere, including memory not owned by BPF. An attacker with CAP_BPF can arbitrarily read memory from anywhere on the system. We recommend upgrading past commit 86f44fcec22c |
["https://git.kernel.org/bpf/bpf/c/86f44fcec22c","https://lore.kernel.org/bpf/20220816205517.682470-1-zhuyifei%40google.com/T/#t","https://git.kernel.org/bpf/bpf/c/86f44fcec22c","https://lore.kernel.org/bpf/20220816205517.682470-1-zhuyifei%40google.com/T/#t"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-3847
|
High |
|
N/A
|
An unauthorized access to the execution of the setuid file with capabilities flaw in the Linux kernel OverlayFS subsystem was found in the way user copying a capable file from a nosuid mount into another mount. A local user could use this flaw to escalate their privileges on the system. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2009704","https://www.openwall.com/lists/oss-security/2021/10/14/3","https://bugzilla.redhat.com/show_bug.cgi?id=2009704","https://www.openwall.com/lists/oss-security/2021/10/14/3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-28390
|
High |
|
N/A
|
ems_usb_start_xmit in drivers/net/can/usb/ems_usb.c in the Linux kernel through 5.17.1 has a double free. |
["https://github.com/torvalds/linux/commit/c70222752228a62135cee3409dccefd494a24646","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6IHHC455LMSJNG4CSZ5CEAHYWY2DE5YW/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LAWC35TO642FOP3UCA3C6IF7NAUFOVZ6/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XFMPUI3WI4U2F7ONHRW36WDY4ZE7LGGT/","https://security.netapp.com/advisory/ntap-20220513-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173","https://github.com/torvalds/linux/commit/c70222752228a62135cee3409dccefd494a24646","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6IHHC455LMSJNG4CSZ5CEAHYWY2DE5YW/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LAWC35TO642FOP3UCA3C6IF7NAUFOVZ6/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XFMPUI3WI4U2F7ONHRW36WDY4ZE7LGGT/","https://security.netapp.com/advisory/ntap-20220513-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-2194
|
Medium |
fixed |
|
An out-of-bounds write vulnerability was found in the Linux kernel's SLIMpro I2C device driver. The userspace "data->block[0]" variable was not capped to a number between 0-255 and was used as the size of a memcpy, possibly writing beyond the end of dma_buffer. This flaw could allow a local privileged user to crash the system or potentially achieve code execution. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2188396","https://github.com/torvalds/linux/commit/92fbb6d1296f","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://bugzilla.redhat.com/show_bug.cgi?id=2188396","https://github.com/torvalds/linux/commit/92fbb6d1296f","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50057
|
Low |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: tipd: Free IRQ only if it was requested before
In polling mode, if no IRQ was requested there is no need to free it.
Call devm_free_irq() only if client->irq is set. This fixes the warning
caused by the tps6598x module removal:
WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c
...
...
Call trace:
devm_free_irq+0x80/0x8c
tps6598x_remove+0x28/0x88 [tps6598x]
i2c_device_remove+0x2c/0x9c
device_remove+0x4c/0x80
device_release_driver_internal+0x1cc/0x228
driver_detach+0x50/0x98
bus_remove_driver+0x6c/0xbc
driver_unregister+0x30/0x60
i2c_del_driver+0x54/0x64
tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x]
__arm64_sys_delete_module+0x184/0x264
invoke_syscall+0x48/0x110
el0_svc_common.constprop.0+0xc8/0xe8
do_el0_svc+0x20/0x2c
el0_svc+0x28/0x98
el0t_64_sync_handler+0x13c/0x158
el0t_64_sync+0x190/0x194 |
["https://git.kernel.org/stable/c/4d4b23c119542fbaed2a16794d3801cb4806ea02","https://git.kernel.org/stable/c/b72bf5cade51ba4055c8a8998d275e72e6b521ce","https://git.kernel.org/stable/c/db63d9868f7f310de44ba7bea584e2454f8b4ed0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3533
|
Medium |
fixed |
|
A vulnerability was found in Linux Kernel. It has been rated as problematic. This issue affects the function parse_usdt_arg of the file tools/lib/bpf/usdt.c of the component BPF. The manipulation of the argument reg_name leads to memory leak. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211031. |
["https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=0dc9254e03704c75f2ebc9cbef2ce4de83fba603","https://vuldb.com/?id.211031","https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=0dc9254e03704c75f2ebc9cbef2ce4de83fba603","https://vuldb.com/?id.211031"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3355
|
Medium |
fixed |
|
A NULL pointer dereference flaw was found in the Linux kernel's drivers/gpu/drm/msm/msm_gem_submit.c code in the submit_lookup_cmds function, which fails because it lacks a check of the return value of kmalloc(). This issue allows a local user to crash the system. |
["https://access.redhat.com/security/cve/CVE-2023-3355","https://bugzilla.redhat.com/show_bug.cgi?id=2217820","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d839f0811a31322c087a859c2b181e2383daa7be","https://access.redhat.com/security/cve/CVE-2023-3355","https://bugzilla.redhat.com/show_bug.cgi?id=2217820","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d839f0811a31322c087a859c2b181e2383daa7be"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3543
|
Medium |
fixed |
|
A vulnerability, which was classified as problematic, has been found in Linux Kernel. This issue affects the function unix_sock_destructor/unix_release_sock of the file net/unix/af_unix.c of the component BPF. The manipulation leads to memory leak. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211043. |
["https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=7a62ed61367b8fd01bae1e18e30602c25060d824","https://vuldb.com/?id.211043","https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=7a62ed61367b8fd01bae1e18e30602c25060d824","https://vuldb.com/?id.211043"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48502
|
High |
fixed |
|
An issue was discovered in the Linux kernel before 6.2. The ntfs3 subsystem does not properly check for correctness during disk reads, leading to an out-of-bounds read in ntfs_set_ea in fs/ntfs3/xattr.c. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e8235d28f3a0e9eda9f02ff67ee566d5f42b66b","https://security.netapp.com/advisory/ntap-20230703-0004/","https://syzkaller.appspot.com/bug?extid=8778f030156c6cd16d72","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e8235d28f3a0e9eda9f02ff67ee566d5f42b66b","https://security.netapp.com/advisory/ntap-20230703-0004/","https://syzkaller.appspot.com/bug?extid=8778f030156c6cd16d72"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26669
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net/sched: flower: Fix chain template offload
When a qdisc is deleted from a net device the stack instructs the
underlying driver to remove its flow offload callback from the
associated filter block using the 'FLOW_BLOCK_UNBIND' command. The stack
then continues to replay the removal of the filters in the block for
this driver by iterating over the chains in the block and invoking the
'reoffload' operation of the classifier being used. In turn, the
classifier in its 'reoffload' operation prepares and emits a
'FLOW_CLS_DESTROY' command for each filter.
However, the stack does not do the same for chain templates and the
underlying driver never receives a 'FLOW_CLS_TMPLT_DESTROY' command when
a qdisc is deleted. This results in a memory leak [1] which can be
reproduced using [2].
Fix by introducing a 'tmplt_reoffload' operation and have the stack
invoke it with the appropriate arguments as part of the replay.
Implement the operation in the sole classifier that supports chain
templates (flower) by emitting the 'FLOW_CLS_TMPLT_{CREATE,DESTROY}'
command based on whether a flow offload callback is being bound to a
filter block or being unbound from one.
As far as I can tell, the issue happens since cited commit which
reordered tcf_block_offload_unbind() before tcf_block_flush_all_chains()
in __tcf_block_put(). The order cannot be reversed as the filter block
is expected to be freed after flushing all the chains.
[1]
unreferenced object 0xffff888107e28800 (size 2048):
comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s)
hex dump (first 32 bytes):
b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff ..|......[......
01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................
backtrace:
[<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320
[<ffffffff81ab374e>] __kmalloc+0x4e/0x90
[<ffffffff832aec6d>] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0
[<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180
[<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280
[<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340
[<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0
[<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170
[<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0
[<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440
[<ffffffff83ac6270>] netlink_unicast+0x540/0x820
[<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0
[<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80
[<ffffffff8379d29a>] ___sys_sendmsg+0x13a/0x1e0
[<ffffffff8379d50c>] __sys_sendmsg+0x11c/0x1f0
[<ffffffff843b9ce0>] do_syscall_64+0x40/0xe0
unreferenced object 0xffff88816d2c0400 (size 1024):
comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s)
hex dump (first 32 bytes):
40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00 @.......W.8.....
10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff ..,m......,m....
backtrace:
[<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320
[<ffffffff81ab36c1>] __kmalloc_node+0x51/0x90
[<ffffffff81a8ed96>] kvmalloc_node+0xa6/0x1f0
[<ffffffff82827d03>] bucket_table_alloc.isra.0+0x83/0x460
[<ffffffff82828d2b>] rhashtable_init+0x43b/0x7c0
[<ffffffff832aed48>] mlxsw_sp_acl_ruleset_get+0x428/0x7a0
[<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180
[<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280
[<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340
[<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0
[<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170
[<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0
[<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440
[<ffffffff83ac6270>] netlink_unicast+0x540/0x820
[<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0
[<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80
[2]
# tc qdisc add dev swp1 clsact
# tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32
# tc qdisc del dev
---truncated--- |
["https://git.kernel.org/stable/c/32f2a0afa95fae0d1ceec2ff06e0e816939964b8","https://git.kernel.org/stable/c/9ed46144cff3598a5cf79955630e795ff9af5b97","https://git.kernel.org/stable/c/c04709b2cc99ae31c346f79f0211752d7b74df01","https://git.kernel.org/stable/c/32f2a0afa95fae0d1ceec2ff06e0e816939964b8","https://git.kernel.org/stable/c/9ed46144cff3598a5cf79955630e795ff9af5b97","https://git.kernel.org/stable/c/c04709b2cc99ae31c346f79f0211752d7b74df01"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1838
|
High |
fixed |
- 4.14.317
- 4.19.245
- 5.4.196
- 5.10.118
- 5.15.42
- 5.17.10
|
A use-after-free flaw was found in vhost_net_set_backend in drivers/vhost/net.c in virtio network subcomponent in the Linux kernel due to a double fget. This flaw could allow a local attacker to crash the system, and could even lead to a kernel information leak problem. |
["https://lore.kernel.org/netdev/20220516084213.26854-1-jasowang%40redhat.com/T/","https://security.netapp.com/advisory/ntap-20230517-0003/","https://lore.kernel.org/netdev/20220516084213.26854-1-jasowang%40redhat.com/T/","https://security.netapp.com/advisory/ntap-20230517-0003/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-0168
|
Medium |
fixed |
|
A denial of service (DOS) issue was found in the Linux kernel’s smb2_ioctl_query_info function in the fs/cifs/smb2ops.c Common Internet File System (CIFS) due to an incorrect return from the memdup_user function. This flaw allows a local, privileged (CAP_SYS_ADMIN) attacker to crash the system. |
["https://access.redhat.com/security/cve/CVE-2022-0168","https://bugzilla.redhat.com/show_bug.cgi?id=2037386","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6f5e358452479fa8a773b5c6ccc9e4ec5a20880","https://access.redhat.com/security/cve/CVE-2022-0168","https://bugzilla.redhat.com/show_bug.cgi?id=2037386","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6f5e358452479fa8a773b5c6ccc9e4ec5a20880"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-45884
|
High |
|
N/A
|
An issue was discovered in the Linux kernel through 6.0.9. drivers/media/dvb-core/dvbdev.c has a use-after-free, related to dvb_register_device dynamically allocating fops. |
["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=627bb528b086b4136315c25d6a447a98ea9448d3","https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/","https://lore.kernel.org/linux-media/20221115131822.6640-4-imv4bel%40gmail.com/","https://security.netapp.com/advisory/ntap-20230113-0006/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=627bb528b086b4136315c25d6a447a98ea9448d3","https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/","https://lore.kernel.org/linux-media/20221115131822.6640-4-imv4bel%40gmail.com/","https://security.netapp.com/advisory/ntap-20230113-0006/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-45885
|
High |
|
N/A
|
An issue was discovered in the Linux kernel through 6.0.9. drivers/media/dvb-core/dvb_frontend.c has a race condition that can cause a use-after-free when a device is disconnected. |
["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6769a0b7ee0c3b31e1b22c3fadff2bfb642de23f","https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/","https://lore.kernel.org/linux-media/20221115131822.6640-2-imv4bel%40gmail.com/","https://security.netapp.com/advisory/ntap-20230113-0006/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6769a0b7ee0c3b31e1b22c3fadff2bfb642de23f","https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/","https://lore.kernel.org/linux-media/20221115131822.6640-2-imv4bel%40gmail.com/","https://security.netapp.com/advisory/ntap-20230113-0006/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-35827
|
High |
fixed |
|
An issue was discovered in the Linux kernel through 6.3.8. A use-after-free was found in ravb_remove in drivers/net/ethernet/renesas/ravb_main.c. |
["https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://lore.kernel.org/lkml/cca0b40b-d6f8-54c7-1e46-83cb62d0a2f1%40huawei.com/T/","https://security.netapp.com/advisory/ntap-20230803-0003/","https://www.spinics.net/lists/netdev/msg886947.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://lore.kernel.org/lkml/cca0b40b-d6f8-54c7-1e46-83cb62d0a2f1%40huawei.com/T/","https://security.netapp.com/advisory/ntap-20230803-0003/","https://www.spinics.net/lists/netdev/msg886947.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52586
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dpu: Add mutex lock in control vblank irq
Add a mutex lock to control vblank irq to synchronize vblank
enable/disable operations happening from different threads to prevent
race conditions while registering/unregistering the vblank irq callback.
v4: -Removed vblank_ctl_lock from dpu_encoder_virt, so it is only a
parameter of dpu_encoder_phys.
-Switch from atomic refcnt to a simple int counter as mutex has
now been added
v3: Mistakenly did not change wording in last version. It is done now.
v2: Slightly changed wording of commit message
Patchwork: https://patchwork.freedesktop.org/patch/571854/ |
["https://git.kernel.org/stable/c/14f109bf74dd67e1d0469fed859c8e506b0df53f","https://git.kernel.org/stable/c/45284ff733e4caf6c118aae5131eb7e7cf3eea5a","https://git.kernel.org/stable/c/14f109bf74dd67e1d0469fed859c8e506b0df53f","https://git.kernel.org/stable/c/45284ff733e4caf6c118aae5131eb7e7cf3eea5a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-6531
|
High |
fixed |
|
A use-after-free flaw was found in the Linux Kernel due to a race problem in the unix garbage collector's deletion of SKB races with unix_stream_read_generic() on the socket that the SKB is queued on. |
["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/security/cve/CVE-2023-6531","https://bugzilla.redhat.com/show_bug.cgi?id=2253034","https://lore.kernel.org/all/c716c88321939156909cfa1bd8b0faaf1c804103.1701868795.git.asml.silence@gmail.com/","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/security/cve/CVE-2023-6531","https://bugzilla.redhat.com/show_bug.cgi?id=2253034","https://lore.kernel.org/all/c716c88321939156909cfa1bd8b0faaf1c804103.1701868795.git.asml.silence@gmail.com/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-7192
|
Medium |
fixed |
|
A memory leak problem was found in ctnetlink_create_conntrack in net/netfilter/nf_conntrack_netlink.c in the Linux Kernel. This issue may allow a local attacker with CAP_NET_ADMIN privileges to cause a denial of service (DoS) attack due to a refcount overflow. |
["https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:1188","https://access.redhat.com/errata/RHSA-2024:1250","https://access.redhat.com/errata/RHSA-2024:1306","https://access.redhat.com/errata/RHSA-2024:1367","https://access.redhat.com/errata/RHSA-2024:1382","https://access.redhat.com/errata/RHSA-2024:1404","https://access.redhat.com/errata/RHSA-2024:2006","https://access.redhat.com/errata/RHSA-2024:2008","https://access.redhat.com/security/cve/CVE-2023-7192","https://bugzilla.redhat.com/show_bug.cgi?id=2256279","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=ac4893980bbe79ce383daf9a0885666a30fe4c83","https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:1188","https://access.redhat.com/errata/RHSA-2024:1250","https://access.redhat.com/errata/RHSA-2024:1306","https://access.redhat.com/errata/RHSA-2024:1367","https://access.redhat.com/errata/RHSA-2024:1382","https://access.redhat.com/errata/RHSA-2024:1404","https://access.redhat.com/errata/RHSA-2024:2006","https://access.redhat.com/errata/RHSA-2024:2008","https://access.redhat.com/security/cve/CVE-2023-7192","https://bugzilla.redhat.com/show_bug.cgi?id=2256279","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=ac4893980bbe79ce383daf9a0885666a30fe4c83"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-28389
|
Medium |
|
N/A
|
mcba_usb_start_xmit in drivers/net/can/usb/mcba_usb.c in the Linux kernel through 5.17.1 has a double free. |
["https://github.com/torvalds/linux/commit/04c9b00ba83594a29813d6b1fb8fdc93a3915174","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6IHHC455LMSJNG4CSZ5CEAHYWY2DE5YW/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LAWC35TO642FOP3UCA3C6IF7NAUFOVZ6/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XFMPUI3WI4U2F7ONHRW36WDY4ZE7LGGT/","https://security.netapp.com/advisory/ntap-20220513-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173","https://github.com/torvalds/linux/commit/04c9b00ba83594a29813d6b1fb8fdc93a3915174","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6IHHC455LMSJNG4CSZ5CEAHYWY2DE5YW/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LAWC35TO642FOP3UCA3C6IF7NAUFOVZ6/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XFMPUI3WI4U2F7ONHRW36WDY4ZE7LGGT/","https://security.netapp.com/advisory/ntap-20220513-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-45402
|
Medium |
fixed |
|
The check_alu_op() function in kernel/bpf/verifier.c in the Linux kernel through v5.16-rc5 did not properly update bounds while handling the mov32 instruction, which allows local users to obtain potentially sensitive address information, aka a "pointer leak." |
["https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=3cf2b61eb06765e27fec6799292d9fb46d0b7e60","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=b1a7288dedc6caf9023f2676b4f5ed34cf0d4029","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=e572ff80f05c33cd0cb4860f864f5c9c044280b6","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=3cf2b61eb06765e27fec6799292d9fb46d0b7e60","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=b1a7288dedc6caf9023f2676b4f5ed34cf0d4029","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=e572ff80f05c33cd0cb4860f864f5c9c044280b6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49863
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()
Since commit 3f8ca2e115e5 ("vhost/scsi: Extract common handling code
from control queue handler") a null pointer dereference bug can be
triggered when guest sends an SCSI AN request.
In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with
`&v_req.tmf.lun[1]` within a switch-case block and is then passed to
vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for
a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is
set to NULL in this branch. Later, in vhost_scsi_get_req(),
`vc->target` is dereferenced without being checked, leading to a null
pointer dereference bug. This bug can be triggered from guest.
When this bug occurs, the vhost_worker process is killed while holding
`vq->mutex` and the corresponding tpg will remain occupied
indefinitely.
Below is the KASAN report:
Oops: general protection fault, probably for non-canonical address
0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1
Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS
1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:vhost_scsi_get_req+0x165/0x3a0
Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00
48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6
04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00
RSP: 0018:ffff888017affb50 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8
RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000
FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0
Call Trace:
<TASK>
? show_regs+0x86/0xa0
? die_addr+0x4b/0xd0
? exc_general_protection+0x163/0x260
? asm_exc_general_protection+0x27/0x30
? vhost_scsi_get_req+0x165/0x3a0
vhost_scsi_ctl_handle_vq+0x2a4/0xca0
? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10
? __switch_to+0x721/0xeb0
? __schedule+0xda5/0x5710
? __kasan_check_write+0x14/0x30
? _raw_spin_lock+0x82/0xf0
vhost_scsi_ctl_handle_kick+0x52/0x90
vhost_run_work_list+0x134/0x1b0
vhost_task_fn+0x121/0x350
...
</TASK>
---[ end trace 0000000000000000 ]---
Let's add a check in vhost_scsi_get_req.
[whitespace fixes] |
["https://git.kernel.org/stable/c/00fb5b23e1c9cdbe496f5cd6b40367cb895f6c93","https://git.kernel.org/stable/c/221af82f606d928ccef19a16d35633c63026f1be","https://git.kernel.org/stable/c/25613e6d9841a1f9fb985be90df921fa99f800de","https://git.kernel.org/stable/c/46128370a72c431df733af5ebb065c4d48c9ad39","https://git.kernel.org/stable/c/61517f33e76d2c5247c1e61e668693afe5b67e6f","https://git.kernel.org/stable/c/6592347f06e2b19a624270a85ad4b3ae48c3b241","https://git.kernel.org/stable/c/ace9c778a214da9c98d7b69d904d1b0816f4f681"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50153
|
Medium |
fixed |
- 5.15.170
- 6.1.115
- 6.6.59
- 6.11.6
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: core: Fix null-ptr-deref in target_alloc_device()
There is a null-ptr-deref issue reported by KASAN:
BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod]
...
kasan_report+0xb9/0xf0
target_alloc_device+0xbc4/0xbe0 [target_core_mod]
core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod]
target_core_init_configfs+0x205/0x420 [target_core_mod]
do_one_initcall+0xdd/0x4e0
...
entry_SYSCALL_64_after_hwframe+0x76/0x7e
In target_alloc_device(), if allocing memory for dev queues fails, then
dev will be freed by dev->transport->free_device(), but dev->transport
is not initialized at that time, which will lead to a null pointer
reference problem.
Fixing this bug by freeing dev with hba->backend->ops->free_device(). |
["https://git.kernel.org/stable/c/14a6a2adb440e4ae97bee73b2360946bd033dadd","https://git.kernel.org/stable/c/39e02fa90323243187c91bb3e8f2f5f6a9aacfc7","https://git.kernel.org/stable/c/895ab729425ef9bf3b6d2f8d0853abe64896f314","https://git.kernel.org/stable/c/8c1e6717f60d31f8af3937c23c4f1498529584e1","https://git.kernel.org/stable/c/b80e9bc85bd9af378e7eac83e15dd129557bbdb6","https://git.kernel.org/stable/c/fca6caeb4a61d240f031914413fcc69534f6dc03"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3357
|
Medium |
|
N/A
|
A NULL pointer dereference flaw was found in the Linux kernel AMD Sensor Fusion Hub driver. This flaw allows a local user to crash the system. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=53ffa6a9f83b2170c60591da1ead8791d5a42e81","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=53ffa6a9f83b2170c60591da1ead8791d5a42e81"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49123
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ath11k: Fix frames flush failure caused by deadlock
We are seeing below warnings:
kernel: [25393.301506] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0
kernel: [25398.421509] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0
kernel: [25398.421831] ath11k_pci 0000:01:00.0: dropping mgmt frame for vdev 0, is_started 0
this means ath11k fails to flush mgmt. frames because wmi_mgmt_tx_work
has no chance to run in 5 seconds.
By setting /proc/sys/kernel/hung_task_timeout_secs to 20 and increasing
ATH11K_FLUSH_TIMEOUT to 50 we get below warnings:
kernel: [ 120.763160] INFO: task wpa_supplicant:924 blocked for more than 20 seconds.
kernel: [ 120.763169] Not tainted 5.10.90 #12
kernel: [ 120.763177] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kernel: [ 120.763186] task:wpa_supplicant state:D stack: 0 pid: 924 ppid: 1 flags:0x000043a0
kernel: [ 120.763201] Call Trace:
kernel: [ 120.763214] __schedule+0x785/0x12fa
kernel: [ 120.763224] ? lockdep_hardirqs_on_prepare+0xe2/0x1bb
kernel: [ 120.763242] schedule+0x7e/0xa1
kernel: [ 120.763253] schedule_timeout+0x98/0xfe
kernel: [ 120.763266] ? run_local_timers+0x4a/0x4a
kernel: [ 120.763291] ath11k_mac_flush_tx_complete+0x197/0x2b1 [ath11k 13c3a9bf37790f4ac8103b3decf7ab4008ac314a]
kernel: [ 120.763306] ? init_wait_entry+0x2e/0x2e
kernel: [ 120.763343] __ieee80211_flush_queues+0x167/0x21f [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]
kernel: [ 120.763378] __ieee80211_recalc_idle+0x105/0x125 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]
kernel: [ 120.763411] ieee80211_recalc_idle+0x14/0x27 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]
kernel: [ 120.763441] ieee80211_free_chanctx+0x77/0xa2 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]
kernel: [ 120.763473] __ieee80211_vif_release_channel+0x100/0x131 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]
kernel: [ 120.763540] ieee80211_vif_release_channel+0x66/0x81 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]
kernel: [ 120.763572] ieee80211_destroy_auth_data+0xa3/0xe6 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]
kernel: [ 120.763612] ieee80211_mgd_deauth+0x178/0x29b [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]
kernel: [ 120.763654] cfg80211_mlme_deauth+0x1a8/0x22c [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]
kernel: [ 120.763697] nl80211_deauthenticate+0xfa/0x123 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]
kernel: [ 120.763715] genl_rcv_msg+0x392/0x3c2
kernel: [ 120.763750] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]
kernel: [ 120.763782] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]
kernel: [ 120.763802] ? genl_rcv+0x36/0x36
kernel: [ 120.763814] netlink_rcv_skb+0x89/0xf7
kernel: [ 120.763829] genl_rcv+0x28/0x36
kernel: [ 120.763840] netlink_unicast+0x179/0x24b
kernel: [ 120.763854] netlink_sendmsg+0x393/0x401
kernel: [ 120.763872] sock_sendmsg+0x72/0x76
kernel: [ 120.763886] ____sys_sendmsg+0x170/0x1e6
kernel: [ 120.763897] ? copy_msghdr_from_user+0x7a/0xa2
kernel: [ 120.763914] ___sys_sendmsg+0x95/0xd1
kernel: [ 120.763940] __sys_sendmsg+0x85/0xbf
kernel: [ 120.763956] do_syscall_64+0x43/0x55
kernel: [ 120.763966] entry_SYSCALL_64_after_hwframe+0x44/0xa9
kernel: [ 120.763977] RIP: 0033:0x79089f3fcc83
kernel: [ 120.763986] RSP: 002b:00007ffe604f0508 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
kernel: [ 120.763997] RAX: ffffffffffffffda RBX: 000059b40e987690 RCX: 000079089f3fcc83
kernel: [ 120.764006] RDX: 0000000000000000 RSI: 00007ffe604f0558 RDI: 0000000000000009
kernel: [ 120.764014] RBP: 00007ffe604f0540 R08: 0000000000000004 R09: 0000000000400000
kernel: [ 120.764023] R10: 00007ffe604f0638 R11: 0000000000000246 R12: 000059b40ea04980
kernel: [ 120.764032] R13: 00007ffe604
---truncated--- |
["https://git.kernel.org/stable/c/261b07519518bd14cb168b287b17e1d195f8d0c8","https://git.kernel.org/stable/c/33e723dc054edfc94da90eecca3b72cb424ce4a3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49296
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix possible deadlock when holding Fwb to get inline_data
1, mount with wsync.
2, create a file with O_RDWR, and the request was sent to mds.0:
ceph_atomic_open()-->
ceph_mdsc_do_request(openc)
finish_open(file, dentry, ceph_open)-->
ceph_open()-->
ceph_init_file()-->
ceph_init_file_info()-->
ceph_uninline_data()-->
{
...
if (inline_version == 1 || /* initial version, no data */
inline_version == CEPH_INLINE_NONE)
goto out_unlock;
...
}
The inline_version will be 1, which is the initial version for the
new create file. And here the ci->i_inline_version will keep with 1,
it's buggy.
3, buffer write to the file immediately:
ceph_write_iter()-->
ceph_get_caps(file, need=Fw, want=Fb, ...);
generic_perform_write()-->
a_ops->write_begin()-->
ceph_write_begin()-->
netfs_write_begin()-->
netfs_begin_read()-->
netfs_rreq_submit_slice()-->
netfs_read_from_server()-->
rreq->netfs_ops->issue_read()-->
ceph_netfs_issue_read()-->
{
...
if (ci->i_inline_version != CEPH_INLINE_NONE &&
ceph_netfs_issue_op_inline(subreq))
return;
...
}
ceph_put_cap_refs(ci, Fwb);
The ceph_netfs_issue_op_inline() will send a getattr(Fsr) request to
mds.1.
4, then the mds.1 will request the rd lock for CInode::filelock from
the auth mds.0, the mds.0 will do the CInode::filelock state transation
from excl --> sync, but it need to revoke the Fxwb caps back from the
clients.
While the kernel client has aleady held the Fwb caps and waiting for
the getattr(Fsr).
It's deadlock!
URL: https://tracker.ceph.com/issues/55377 |
["https://git.kernel.org/stable/c/292b7a7275ce535a1abfa4dd0b2e586162aaae1e","https://git.kernel.org/stable/c/825978fd6a0defc3c29d8a38b6cea76a0938d21e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49303
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drivers: staging: rtl8192eu: Fix deadlock in rtw_joinbss_event_prehandle
There is a deadlock in rtw_joinbss_event_prehandle(), which is shown below:
(Thread 1) | (Thread 2)
| _set_timer()
rtw_joinbss_event_prehandle()| mod_timer()
spin_lock_bh() //(1) | (wait a time)
... | rtw_join_timeout_handler()
| _rtw_join_timeout_handler()
del_timer_sync() | spin_lock_bh() //(2)
(wait timer to stop) | ...
We hold pmlmepriv->lock in position (1) of thread 1 and
use del_timer_sync() to wait timer to stop, but timer handler
also need pmlmepriv->lock in position (2) of thread 2.
As a result, rtw_joinbss_event_prehandle() will block forever.
This patch extracts del_timer_sync() from the protection of
spin_lock_bh(), which could let timer handler to obtain
the needed lock. What`s more, we change spin_lock_bh() to
spin_lock_irq() in _rtw_join_timeout_handler() in order to
prevent deadlock. |
["https://git.kernel.org/stable/c/0fcddf9c7c10202946d5b19409efbdff744fba88","https://git.kernel.org/stable/c/25cf414b0610fea29d8e045f315648d9007c9a46"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49496
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
media: mediatek: vcodec: prevent kernel crash when rmmod mtk-vcodec-dec.ko
If the driver support subdev mode, the parameter "dev->pm.dev" will be
NULL in mtk_vcodec_dec_remove. Kernel will crash when try to rmmod
mtk-vcodec-dec.ko.
[ 4380.702726] pc : do_raw_spin_trylock+0x4/0x80
[ 4380.707075] lr : _raw_spin_lock_irq+0x90/0x14c
[ 4380.711509] sp : ffff80000819bc10
[ 4380.714811] x29: ffff80000819bc10 x28: ffff3600c03e4000 x27: 0000000000000000
[ 4380.721934] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
[ 4380.729057] x23: ffff3600c0f34930 x22: ffffd5e923549000 x21: 0000000000000220
[ 4380.736179] x20: 0000000000000208 x19: ffffd5e9213e8ebc x18: 0000000000000020
[ 4380.743298] x17: 0000002000000000 x16: ffffd5e9213e8e90 x15: 696c346f65646976
[ 4380.750420] x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000040
[ 4380.757542] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
[ 4380.764664] x8 : 0000000000000000 x7 : ffff3600c7273ae8 x6 : ffffd5e9213e8ebc
[ 4380.771786] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000
[ 4380.778908] x2 : 0000000000000000 x1 : ffff3600c03e4000 x0 : 0000000000000208
[ 4380.786031] Call trace:
[ 4380.788465] do_raw_spin_trylock+0x4/0x80
[ 4380.792462] __pm_runtime_disable+0x2c/0x1b0
[ 4380.796723] mtk_vcodec_dec_remove+0x5c/0xa0 [mtk_vcodec_dec]
[ 4380.802466] platform_remove+0x2c/0x60
[ 4380.806204] __device_release_driver+0x194/0x250
[ 4380.810810] driver_detach+0xc8/0x15c
[ 4380.814462] bus_remove_driver+0x5c/0xb0
[ 4380.818375] driver_unregister+0x34/0x64
[ 4380.822288] platform_driver_unregister+0x18/0x24
[ 4380.826979] mtk_vcodec_dec_driver_exit+0x1c/0x888 [mtk_vcodec_dec]
[ 4380.833240] __arm64_sys_delete_module+0x190/0x224
[ 4380.838020] invoke_syscall+0x48/0x114
[ 4380.841760] el0_svc_common.constprop.0+0x60/0x11c
[ 4380.846540] do_el0_svc+0x28/0x90
[ 4380.849844] el0_svc+0x4c/0x100
[ 4380.852975] el0t_64_sync_handler+0xec/0xf0
[ 4380.857148] el0t_64_sync+0x190/0x194
[ 4380.860801] Code: 94431515 17ffffca d503201f d503245f (b9400004) |
["https://git.kernel.org/stable/c/1fa37b00dc55a061a3eb82e378849862b4aeca9d","https://git.kernel.org/stable/c/c10c0086db688c95bb4e0e378e523818dff1551d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49531
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
loop: implement ->free_disk
Ensure that the lo_device which is stored in the gendisk private
data is valid until the gendisk is freed. Currently the loop driver
uses a lot of effort to make sure a device is not freed when it is
still in use, but to to fix a potential deadlock this will be relaxed
a bit soon. |
["https://git.kernel.org/stable/c/aadd1443aae7fe8956e3b11157827067f034406a","https://git.kernel.org/stable/c/d2c7f56f8b5256d57f9e3fc7794c31361d43bdd9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49746
|
Medium |
fixed |
- 4.19.272
- 5.4.231
- 5.10.167
- 5.15.92
- 6.1.10
|
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: imx-sdma: Fix a possible memory leak in sdma_transfer_init
If the function sdma_load_context() fails, the sdma_desc will be
freed, but the allocated desc->bd is forgot to be freed.
We already met the sdma_load_context() failure case and the log as
below:
[ 450.699064] imx-sdma 30bd0000.dma-controller: Timeout waiting for CH0 ready
...
In this case, the desc->bd will not be freed without this change. |
["https://git.kernel.org/stable/c/1417f59ac0b02130ee56c0c50794b9b257be3d17","https://git.kernel.org/stable/c/43acd767bd90c5d4172ce7fee5d9007a9a08dea9","https://git.kernel.org/stable/c/80ee99e52936b2c04cc37b17a14b2ae2f9d282ac","https://git.kernel.org/stable/c/bd0050b7ffa87c7b260d563646af612f4112a778","https://git.kernel.org/stable/c/ce4745a6b8016fae74c95dcd457d4ceef7d98af1","https://git.kernel.org/stable/c/dbe634ce824329d8f14079c3e9f8f11670894bec"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49751
|
Medium |
fixed |
- 4.14.305
- 4.19.272
- 5.4.231
- 5.10.166
- 5.15.91
- 6.1.9
|
In the Linux kernel, the following vulnerability has been resolved:
w1: fix WARNING after calling w1_process()
I got the following WARNING message while removing driver(ds2482):
------------[ cut here ]------------
do not call blocking ops when !TASK_RUNNING; state=1 set at [<000000002d50bfb6>] w1_process+0x9e/0x1d0 [wire]
WARNING: CPU: 0 PID: 262 at kernel/sched/core.c:9817 __might_sleep+0x98/0xa0
CPU: 0 PID: 262 Comm: w1_bus_master1 Tainted: G N 6.1.0-rc3+ #307
RIP: 0010:__might_sleep+0x98/0xa0
Call Trace:
exit_signals+0x6c/0x550
do_exit+0x2b4/0x17e0
kthread_exit+0x52/0x60
kthread+0x16d/0x1e0
ret_from_fork+0x1f/0x30
The state of task is set to TASK_INTERRUPTIBLE in loop in w1_process(),
set it to TASK_RUNNING when it breaks out of the loop to avoid the
warning. |
["https://git.kernel.org/stable/c/190b5c3bbd5df685bb1063bda048831d72b8f1d4","https://git.kernel.org/stable/c/216f35db6ec6a667cd9db4838d657c1d2f4684da","https://git.kernel.org/stable/c/276052159ba94d4d9f5b453fb4707d6798c6b845","https://git.kernel.org/stable/c/36225a7c72e9e3e1ce4001b6ce72849f5c9a2d3b","https://git.kernel.org/stable/c/89c62cee5d4d65ac75d99b5f986f7f94290e888f","https://git.kernel.org/stable/c/bccd6df4c177b1ad766f16565ccc298653d027d0","https://git.kernel.org/stable/c/cfc7462ff824ed6718ed0272ee9aae88e20d469a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49757
|
Medium |
fixed |
- 4.14.305
- 4.19.272
- 5.4.231
- 5.10.166
- 5.15.91
- 6.1.9
|
In the Linux kernel, the following vulnerability has been resolved:
EDAC/highbank: Fix memory leak in highbank_mc_probe()
When devres_open_group() fails, it returns -ENOMEM without freeing memory
allocated by edac_mc_alloc().
Call edac_mc_free() on the error handling path to avoid a memory leak.
[ bp: Massage commit message. ] |
["https://git.kernel.org/stable/c/0db40e23b56d217eebd385bebb64057ef764b2c7","https://git.kernel.org/stable/c/329fbd260352a7b9a83781d8b8bd96f95844a51f","https://git.kernel.org/stable/c/8d23f5d25264beb223ee79cdb530b88c237719fc","https://git.kernel.org/stable/c/b7863ef8a8f0fee96b4eb41211f4918c0e047253","https://git.kernel.org/stable/c/caffa7fed1397d1395052272c93900176de86557","https://git.kernel.org/stable/c/e7a293658c20a7945014570e1921bf7d25d68a36","https://git.kernel.org/stable/c/f1b3e23ed8df87d779ee86ac37f379e79a24169a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49853
|
Medium |
fixed |
- 4.9.334
- 4.14.300
- 4.19.267
- 5.4.225
- 5.10.155
- 5.15.79
- 6.0.9
|
In the Linux kernel, the following vulnerability has been resolved:
net: macvlan: fix memory leaks of macvlan_common_newlink
kmemleak reports memory leaks in macvlan_common_newlink, as follows:
ip link add link eth0 name .. type macvlan mode source macaddr add
<MAC-ADDR>
kmemleak reports:
unreferenced object 0xffff8880109bb140 (size 64):
comm "ip", pid 284, jiffies 4294986150 (age 430.108s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 b8 aa 5a 12 80 88 ff ff ..........Z.....
80 1b fa 0d 80 88 ff ff 1e ff ac af c7 c1 6b 6b ..............kk
backtrace:
[<ffffffff813e06a7>] kmem_cache_alloc_trace+0x1c7/0x300
[<ffffffff81b66025>] macvlan_hash_add_source+0x45/0xc0
[<ffffffff81b66a67>] macvlan_changelink_sources+0xd7/0x170
[<ffffffff81b6775c>] macvlan_common_newlink+0x38c/0x5a0
[<ffffffff81b6797e>] macvlan_newlink+0xe/0x20
[<ffffffff81d97f8f>] __rtnl_newlink+0x7af/0xa50
[<ffffffff81d98278>] rtnl_newlink+0x48/0x70
...
In the scenario where the macvlan mode is configured as 'source',
macvlan_changelink_sources() will be execured to reconfigure list of
remote source mac addresses, at the same time, if register_netdevice()
return an error, the resource generated by macvlan_changelink_sources()
is not cleaned up.
Using this patch, in the case of an error, it will execute
macvlan_flush_sources() to ensure that the resource is cleaned up. |
["https://git.kernel.org/stable/c/21d3a8b6a1e39e7529ce9de07316ee13a63f305b","https://git.kernel.org/stable/c/23569b5652ee8e8e55a12f7835f59af6f3cefc30","https://git.kernel.org/stable/c/685e73e3f7a9fb75cbf049a9d0b7c45cc6b57b2e","https://git.kernel.org/stable/c/956e0216a19994443c90ba2ea6b0b284c9c4f9cb","https://git.kernel.org/stable/c/9ea003c4671b2fc455320ecf6d4a43b0a3c1878a","https://git.kernel.org/stable/c/9f288e338be206713d79b29144c27fca4503c39b","https://git.kernel.org/stable/c/a81b44d1df1f07f00c0dcc0a0b3d2fa24a46289e","https://git.kernel.org/stable/c/a8d67367ab33604326cc37ab44fd1801bf5691ba"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49861
|
Medium |
fixed |
- 4.9.334
- 4.14.300
- 4.19.267
- 5.4.225
- 5.10.155
- 5.15.79
- 6.0.9
|
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: mv_xor_v2: Fix a resource leak in mv_xor_v2_remove()
A clk_prepare_enable() call in the probe is not balanced by a corresponding
clk_disable_unprepare() in the remove function.
Add the missing call. |
["https://git.kernel.org/stable/c/04f2cc56d80a1ac058045a7835c5bfd910f17863","https://git.kernel.org/stable/c/081195d17a0c4c636da2b869bd5809d42e8cbb13","https://git.kernel.org/stable/c/0b7ee3d50f32d277bf024b4ddb4de54da43a3025","https://git.kernel.org/stable/c/1d84887327659c58a6637060ac8c50c3a952a163","https://git.kernel.org/stable/c/20479886b40c0ed4864a5fc8490a1f6b70cccf1b","https://git.kernel.org/stable/c/4b6641c3a2ba95ddcfecec263b4a5e572a4b0641","https://git.kernel.org/stable/c/992e966caf57e00855edbd79f19d911809732a69","https://git.kernel.org/stable/c/a1cb72e20a64a3c83f9b4ee993fbf97e4c1d7714"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49862
|
Medium |
fixed |
- 4.5
- 4.9.334
- 4.14.300
- 4.19.267
- 5.4.225
- 5.10.155
- 5.15.79
- 6.0.9
|
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix the msg->req tlv len check in tipc_nl_compat_name_table_dump_header
This is a follow-up for commit 974cb0e3e7c9 ("tipc: fix uninit-value
in tipc_nl_compat_name_table_dump") where it should have type casted
sizeof(..) to int to work when TLV_GET_DATA_LEN() returns a negative
value.
syzbot reported a call trace because of it:
BUG: KMSAN: uninit-value in ...
tipc_nl_compat_name_table_dump+0x841/0xea0 net/tipc/netlink_compat.c:934
__tipc_nl_compat_dumpit+0xab2/0x1320 net/tipc/netlink_compat.c:238
tipc_nl_compat_dumpit+0x991/0xb50 net/tipc/netlink_compat.c:321
tipc_nl_compat_recv+0xb6e/0x1640 net/tipc/netlink_compat.c:1324
genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]
genl_family_rcv_msg net/netlink/genetlink.c:775 [inline]
genl_rcv_msg+0x103f/0x1260 net/netlink/genetlink.c:792
netlink_rcv_skb+0x3a5/0x6c0 net/netlink/af_netlink.c:2501
genl_rcv+0x3c/0x50 net/netlink/genetlink.c:803
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg net/socket.c:734 [inline] |
["https://git.kernel.org/stable/c/082707d3df191bf5bb8801d43e4ce3dea39ca173","https://git.kernel.org/stable/c/1c075b192fe41030457cd4a5f7dea730412bca40","https://git.kernel.org/stable/c/301caa06091af4d5cf056ac8249cbda4e6029c6a","https://git.kernel.org/stable/c/36769b9477491a7af6635863bd950309c1e1b96c","https://git.kernel.org/stable/c/55a253a6753a603e80b95932ca971ba514aa6ce7","https://git.kernel.org/stable/c/6cee2c60bd168279852ac7dbe54c2b70d1028644","https://git.kernel.org/stable/c/a0ead1d648df9c456baec832b494513ef405949a","https://git.kernel.org/stable/c/f31dd158580940938f77514b87337a777520185a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49871
|
Medium |
fixed |
- 4.19.267
- 5.4.225
- 5.10.155
- 5.15.79
- 6.0.9
|
In the Linux kernel, the following vulnerability has been resolved:
net: tun: Fix memory leaks of napi_get_frags
kmemleak reports after running test_progs:
unreferenced object 0xffff8881b1672dc0 (size 232):
comm "test_progs", pid 394388, jiffies 4354712116 (age 841.975s)
hex dump (first 32 bytes):
e0 84 d7 a8 81 88 ff ff 80 2c 67 b1 81 88 ff ff .........,g.....
00 40 c5 9b 81 88 ff ff 00 00 00 00 00 00 00 00 .@..............
backtrace:
[<00000000c8f01748>] napi_skb_cache_get+0xd4/0x150
[<0000000041c7fc09>] __napi_build_skb+0x15/0x50
[<00000000431c7079>] __napi_alloc_skb+0x26e/0x540
[<000000003ecfa30e>] napi_get_frags+0x59/0x140
[<0000000099b2199e>] tun_get_user+0x183d/0x3bb0 [tun]
[<000000008a5adef0>] tun_chr_write_iter+0xc0/0x1b1 [tun]
[<0000000049993ff4>] do_iter_readv_writev+0x19f/0x320
[<000000008f338ea2>] do_iter_write+0x135/0x630
[<000000008a3377a4>] vfs_writev+0x12e/0x440
[<00000000a6b5639a>] do_writev+0x104/0x280
[<00000000ccf065d8>] do_syscall_64+0x3b/0x90
[<00000000d776e329>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
The issue occurs in the following scenarios:
tun_get_user()
napi_gro_frags()
napi_frags_finish()
case GRO_NORMAL:
gro_normal_one()
list_add_tail(&skb->list, &napi->rx_list);
<-- While napi->rx_count < READ_ONCE(gro_normal_batch),
<-- gro_normal_list() is not called, napi->rx_list is not empty
<-- not ask to complete the gro work, will cause memory leaks in
<-- following tun_napi_del()
...
tun_napi_del()
netif_napi_del()
__netif_napi_del()
<-- &napi->rx_list is not empty, which caused memory leaks
To fix, add napi_complete() after napi_gro_frags(). |
["https://git.kernel.org/stable/c/1118b2049d77ca0b505775fc1a8d1909cf19a7ec","https://git.kernel.org/stable/c/223ef6a94e52331a6a7ef31e59921e0e82d2d40a","https://git.kernel.org/stable/c/3401f964028ac941425b9b2c8ff8a022539ef44a","https://git.kernel.org/stable/c/8b12a020b20a78f62bedc50f26db3bf4fadf8cb9","https://git.kernel.org/stable/c/a4f73f6adc53fd7a3f9771cbc89a03ef39b0b755","https://git.kernel.org/stable/c/d7569302a7a52a9305d2fb054df908ff985553bb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49874
|
Medium |
fixed |
- 4.9.334
- 4.14.300
- 4.19.267
- 5.4.225
- 5.10.155
- 5.15.79
- 6.0.9
|
In the Linux kernel, the following vulnerability has been resolved:
HID: hyperv: fix possible memory leak in mousevsc_probe()
If hid_add_device() returns error, it should call hid_destroy_device()
to free hid_dev which is allocated in hid_allocate_device(). |
["https://git.kernel.org/stable/c/249b743801c00542e9324f87b380032e957a43e8","https://git.kernel.org/stable/c/5ad95d71344b7ffec360d62591633b3c465dc049","https://git.kernel.org/stable/c/5f3aba6566b866f5b0a4916f0b2e8a6ae66a6451","https://git.kernel.org/stable/c/8597b59e3d22b27849bd3e4f92a3d466774bfb04","https://git.kernel.org/stable/c/a6d2fb1874c52ace1f5cf1966ee558829c5c19b6","https://git.kernel.org/stable/c/b5bcb94b0954a026bbd671741fdb00e7141f9c91","https://git.kernel.org/stable/c/e29289d0d8193fca6d2c1f0a1de75cfc80edec00","https://git.kernel.org/stable/c/ed75d1a1c31a0cae8ecc8bcea710b25c0be68da0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49880
|
Medium |
fixed |
- 4.9.333
- 4.14.299
- 4.19.265
- 5.4.224
- 5.10.154
- 5.15.78
- 6.0.8
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix warning in 'ext4_da_release_space'
Syzkaller report issue as follows:
EXT4-fs (loop0): Free/Dirty block details
EXT4-fs (loop0): free_blocks=0
EXT4-fs (loop0): dirty_blocks=0
EXT4-fs (loop0): Block reservation details
EXT4-fs (loop0): i_reserved_data_blocks=0
EXT4-fs warning (device loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 with only 0 reserved data blocks
------------[ cut here ]------------
WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524
Modules linked in:
CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Workqueue: writeback wb_workfn (flush-7:0)
RIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528
RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296
RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00
RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000
RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5
R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000
R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740
FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
ext4_es_remove_extent+0x1ab/0x260 fs/ext4/extents_status.c:1461
mpage_release_unused_pages+0x24d/0xef0 fs/ext4/inode.c:1589
ext4_writepages+0x12eb/0x3be0 fs/ext4/inode.c:2852
do_writepages+0x3c3/0x680 mm/page-writeback.c:2469
__writeback_single_inode+0xd1/0x670 fs/fs-writeback.c:1587
writeback_sb_inodes+0xb3b/0x18f0 fs/fs-writeback.c:1870
wb_writeback+0x41f/0x7b0 fs/fs-writeback.c:2044
wb_do_writeback fs/fs-writeback.c:2187 [inline]
wb_workfn+0x3cb/0xef0 fs/fs-writeback.c:2227
process_one_work+0x877/0xdb0 kernel/workqueue.c:2289
worker_thread+0xb14/0x1330 kernel/workqueue.c:2436
kthread+0x266/0x300 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
</TASK>
Above issue may happens as follows:
ext4_da_write_begin
ext4_create_inline_data
ext4_clear_inode_flag(inode, EXT4_INODE_EXTENTS);
ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA);
__ext4_ioctl
ext4_ext_migrate -> will lead to eh->eh_entries not zero, and set extent flag
ext4_da_write_begin
ext4_da_convert_inline_data_to_extent
ext4_da_write_inline_data_begin
ext4_da_map_blocks
ext4_insert_delayed_block
if (!ext4_es_scan_clu(inode, &ext4_es_is_delonly, lblk))
if (!ext4_es_scan_clu(inode, &ext4_es_is_mapped, lblk))
ext4_clu_mapped(inode, EXT4_B2C(sbi, lblk)); -> will return 1
allocated = true;
ext4_es_insert_delayed_block(inode, lblk, allocated);
ext4_writepages
mpage_map_and_submit_extent(handle, &mpd, &give_up_on_write); -> return -ENOSPC
mpage_release_unused_pages(&mpd, give_up_on_write); -> give_up_on_write == 1
ext4_es_remove_extent
ext4_da_release_space(inode, reserved);
if (unlikely(to_free > ei->i_reserved_data_blocks))
-> to_free == 1 but ei->i_reserved_data_blocks == 0
-> then trigger warning as above
To solve above issue, forbid inode do migrate which has inline data. |
["https://git.kernel.org/stable/c/0a43c015e98121c91a76154edf42280ce1a8a883","https://git.kernel.org/stable/c/0de5ee103747fd3a24f1c010c79caabe35e8f0bb","https://git.kernel.org/stable/c/1b8f787ef547230a3249bcf897221ef0cc78481b","https://git.kernel.org/stable/c/5370b965b7a945bb8f48b9ee23d83a76a947902e","https://git.kernel.org/stable/c/72743d5598b9096950bbfd6a9b7f173d156eea97","https://git.kernel.org/stable/c/890d738f569fa9412b70ba09f15407f17a52da20","https://git.kernel.org/stable/c/89bee03d2fb8c54119b38ac6c24e7d60fae036b6","https://git.kernel.org/stable/c/c3bf1e95cfa7d950dc3c064d0c2e3d06b427bc63"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49881
|
Medium |
fixed |
- 4.19.267
- 5.4.225
- 5.10.155
- 5.15.79
- 6.0.9
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: fix memory leak in query_regdb_file()
In the function query_regdb_file() the alpha2 parameter is duplicated
using kmemdup() and subsequently freed in regdb_fw_cb(). However,
request_firmware_nowait() can fail without calling regdb_fw_cb() and
thus leak memory. |
["https://git.kernel.org/stable/c/0ede1a988299e95d54bd89551fd635980572e920","https://git.kernel.org/stable/c/219446396786330937bcd382a7bc4ccd767383bc","https://git.kernel.org/stable/c/38c9fa2cc6bf4b6e1a74057aef8b5cffd23d3264","https://git.kernel.org/stable/c/57b962e627ec0ae53d4d16d7bd1033e27e67677a","https://git.kernel.org/stable/c/e1e12180321f416d83444f2cdc9259e0f5093d35","https://git.kernel.org/stable/c/e9b5a4566d5bc71cc901be50d1fa24da00613120"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49890
|
Medium |
fixed |
- 4.14.299
- 4.19.265
- 5.4.224
- 5.10.154
- 5.15.78
- 6.0.8
|
In the Linux kernel, the following vulnerability has been resolved:
capabilities: fix potential memleak on error path from vfs_getxattr_alloc()
In cap_inode_getsecurity(), we will use vfs_getxattr_alloc() to
complete the memory allocation of tmpbuf, if we have completed
the memory allocation of tmpbuf, but failed to call handler->get(...),
there will be a memleak in below logic:
|-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...)
| /* ^^^ alloc for tmpbuf */
|-- value = krealloc(*xattr_value, error + 1, flags)
| /* ^^^ alloc memory */
|-- error = handler->get(handler, ...)
| /* error! */
|-- *xattr_value = value
| /* xattr_value is &tmpbuf (memory leak!) */
So we will try to free(tmpbuf) after vfs_getxattr_alloc() fails to fix it.
[PM: subject line and backtrace tweaks] |
["https://git.kernel.org/stable/c/0c3e6288da650d1ec911a259c77bc2d88e498603","https://git.kernel.org/stable/c/2de8eec8afb75792440b8900a01d52b8f6742fd1","https://git.kernel.org/stable/c/6bb00eb21c0fbf18e5d3538c9ff0cf63fd0ace85","https://git.kernel.org/stable/c/7480aeff0093d8c54377553ec6b31110bea37b4d","https://git.kernel.org/stable/c/8cf0a1bc12870d148ae830a4ba88cfdf0e879cee","https://git.kernel.org/stable/c/90577bcc01c4188416a47269f8433f70502abe98","https://git.kernel.org/stable/c/cdf01c807e974048c43c7fd3ca574f6086a57906"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49915
|
Medium |
fixed |
- 4.9.333
- 4.14.299
- 4.19.265
- 5.4.224
- 5.10.154
- 5.15.78
- 6.0.8
|
In the Linux kernel, the following vulnerability has been resolved:
mISDN: fix possible memory leak in mISDN_register_device()
Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's
bus_id string array"), the name of device is allocated dynamically,
add put_device() to give up the reference, so that the name can be
freed in kobject_cleanup() when the refcount is 0.
Set device class before put_device() to avoid null release() function
WARN message in device_release(). |
["https://git.kernel.org/stable/c/029d5b7688a2f3a86f2a3be5a6ba9cc968c80e41","https://git.kernel.org/stable/c/080aabfb29b2ee9cbb8894a1d039651943d3773e","https://git.kernel.org/stable/c/0d4e91efcaee081e919b3c50e875ecbb84290e41","https://git.kernel.org/stable/c/2ff6b669523d3b3d253a044fa9636a67d0694995","https://git.kernel.org/stable/c/a636fc5a7cabd05699b5692ad838c2c7a3abec7b","https://git.kernel.org/stable/c/d1d1aede313eb2b9a84afd60ff6cfb7c33631e0e","https://git.kernel.org/stable/c/e77d213843e67b4373285712699b692f9c743f61","https://git.kernel.org/stable/c/e7d1d4d9ac0dfa40be4c2c8abd0731659869b297"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49922
|
Medium |
fixed |
- 4.9.333
- 4.14.299
- 4.19.265
- 5.4.224
- 5.10.154
- 5.15.78
- 6.0.8
|
In the Linux kernel, the following vulnerability has been resolved:
nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send()
nfcmrvl_i2c_nci_send() will be called by nfcmrvl_nci_send(), and skb
should be freed in nfcmrvl_i2c_nci_send(). However, nfcmrvl_nci_send()
will only free skb when i2c_master_send() return >=0, which means skb
will memleak when i2c_master_send() failed. Free skb no matter whether
i2c_master_send() succeeds. |
["https://git.kernel.org/stable/c/52438e734c1566f5e2bcd9a065d2d65e306c0555","https://git.kernel.org/stable/c/5dfdac5e3f8db5f4445228c44f64091045644a3b","https://git.kernel.org/stable/c/825656ae61e73ddc05f585e6258d284c87064b10","https://git.kernel.org/stable/c/92a1df9c6da20c02cf9872f8b025a66ddb307aeb","https://git.kernel.org/stable/c/93d904a734a74c54d945a9884b4962977f1176cd","https://git.kernel.org/stable/c/c8e7d4a1166f063703955f1b2e765a6db5bf1771","https://git.kernel.org/stable/c/dd0ee55ead91fbb16889dbe7ff0b0f7c9e4e849d","https://git.kernel.org/stable/c/f30060efcf18883748a0541aa41acef183cd9c0e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49926
|
Medium |
fixed |
- 4.14.299
- 4.19.265
- 5.4.224
- 5.10.154
- 5.15.78
- 6.0.8
|
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: Fix possible memory leaks in dsa_loop_init()
kmemleak reported memory leaks in dsa_loop_init():
kmemleak: 12 new suspected memory leaks
unreferenced object 0xffff8880138ce000 (size 2048):
comm "modprobe", pid 390, jiffies 4295040478 (age 238.976s)
backtrace:
[<000000006a94f1d5>] kmalloc_trace+0x26/0x60
[<00000000a9c44622>] phy_device_create+0x5d/0x970
[<00000000d0ee2afc>] get_phy_device+0xf3/0x2b0
[<00000000dca0c71f>] __fixed_phy_register.part.0+0x92/0x4e0
[<000000008a834798>] fixed_phy_register+0x84/0xb0
[<0000000055223fcb>] dsa_loop_init+0xa9/0x116 [dsa_loop]
...
There are two reasons for memleak in dsa_loop_init().
First, fixed_phy_register() create and register phy_device:
fixed_phy_register()
get_phy_device()
phy_device_create() # freed by phy_device_free()
phy_device_register() # freed by phy_device_remove()
But fixed_phy_unregister() only calls phy_device_remove().
So the memory allocated in phy_device_create() is leaked.
Second, when mdio_driver_register() fail in dsa_loop_init(),
it just returns and there is no cleanup for phydevs.
Fix the problems by catching the error of mdio_driver_register()
in dsa_loop_init(), then calling both fixed_phy_unregister() and
phy_device_free() to release phydevs.
Also add a function for phydevs cleanup to avoid duplacate. |
["https://git.kernel.org/stable/c/37a098fc9b42bd7fce66764866aa514639667b6e","https://git.kernel.org/stable/c/4d2024b138d9f7b02ae13ee997fd3a71e9e46254","https://git.kernel.org/stable/c/633efc8b3dc96f56f5a57f2a49764853a2fa3f50","https://git.kernel.org/stable/c/935b4beb724946a37cebf97191592d4879d3a3a3","https://git.kernel.org/stable/c/9f555b1584fc2d5d16ee3c4d9438e93ac7c502c7","https://git.kernel.org/stable/c/bbc5d7b46a729bfcbb5544f6612b7a67dd4f4d6f","https://git.kernel.org/stable/c/d593e1ede655b74c42e4e4fe285ea64aee96fb5c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49927
|
Medium |
fixed |
- 4.9.333
- 4.14.299
- 4.19.265
- 5.4.224
- 5.10.154
- 5.15.78
- 6.0.8
|
In the Linux kernel, the following vulnerability has been resolved:
nfs4: Fix kmemleak when allocate slot failed
If one of the slot allocate failed, should cleanup all the other
allocated slots, otherwise, the allocated slots will leak:
unreferenced object 0xffff8881115aa100 (size 64):
comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s)
hex dump (first 32 bytes):
00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000007a4c434a>] nfs4_find_or_create_slot+0x8e/0x130
[<000000005472a39c>] nfs4_realloc_slot_table+0x23f/0x270
[<00000000cd8ca0eb>] nfs40_init_client+0x4a/0x90
[<00000000128486db>] nfs4_init_client+0xce/0x270
[<000000008d2cacad>] nfs4_set_client+0x1a2/0x2b0
[<000000000e593b52>] nfs4_create_server+0x300/0x5f0
[<00000000e4425dd2>] nfs4_try_get_tree+0x65/0x110
[<00000000d3a6176f>] vfs_get_tree+0x41/0xf0
[<0000000016b5ad4c>] path_mount+0x9b3/0xdd0
[<00000000494cae71>] __x64_sys_mount+0x190/0x1d0
[<000000005d56bdec>] do_syscall_64+0x35/0x80
[<00000000687c9ae4>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 |
["https://git.kernel.org/stable/c/24641993a7dce6b1628645f4e1d97ca06c9f765d","https://git.kernel.org/stable/c/45aea4fbf61e205649c29200726b9f45c1718a67","https://git.kernel.org/stable/c/7e8436728e22181c3f12a5dbabd35ed3a8b8c593","https://git.kernel.org/stable/c/84b5cb476903003ae9ca88f32b57ff0eaefa6d4c","https://git.kernel.org/stable/c/86ce0e93cf6fb4d0c447323ac66577c642628b9d","https://git.kernel.org/stable/c/925cb538bd5851154602818dc80bf4b4d924c127","https://git.kernel.org/stable/c/aae35a0c8a775fa4afa6a4e7dab3f936f1f89bbb","https://git.kernel.org/stable/c/db333ae981fb8843c383aa7dbf62cc682597d401"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52979
|
Medium |
fixed |
- 4.5
- 4.10
- 4.14.306
- 4.19.273
- 5.4.232
- 5.10.168
- 5.15.93
- 6.1.11
|
In the Linux kernel, the following vulnerability has been resolved:
squashfs: harden sanity check in squashfs_read_xattr_id_table
While mounting a corrupted filesystem, a signed integer '*xattr_ids' can
become less than zero. This leads to the incorrect computation of 'len'
and 'indexes' values which can cause null-ptr-deref in copy_bio_to_actor()
or out-of-bounds accesses in the next sanity checks inside
squashfs_read_xattr_id_table().
Found by Linux Verification Center (linuxtesting.org) with Syzkaller. |
["https://git.kernel.org/stable/c/29e774dcb27116c06b9c57b1f1f14a1623738989","https://git.kernel.org/stable/c/72e544b1b28325fe78a4687b980871a7e4101f76","https://git.kernel.org/stable/c/b30a74f83265c24d1d0842c6c3928cd2e775a3fb","https://git.kernel.org/stable/c/b7398efe24a965cf3937b716c0b1011c201c5d6e","https://git.kernel.org/stable/c/cf5d6612092408157db6bb500c70bf6d67c40fbc","https://git.kernel.org/stable/c/db76fc535fbdfbf29fd0b93e49627537ad794c8c","https://git.kernel.org/stable/c/de2785aa3448d1ee7be3ab47fd4a873025f1b3d7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52989
|
Medium |
fixed |
- 4.14.306
- 4.19.273
- 5.4.232
- 5.10.168
- 5.15.93
- 6.1.11
|
In the Linux kernel, the following vulnerability has been resolved:
firewire: fix memory leak for payload of request subaction to IEC 61883-1 FCP region
This patch is fix for Linux kernel v2.6.33 or later.
For request subaction to IEC 61883-1 FCP region, Linux FireWire subsystem
have had an issue of use-after-free. The subsystem allows multiple
user space listeners to the region, while data of the payload was likely
released before the listeners execute read(2) to access to it for copying
to user space.
The issue was fixed by a commit 281e20323ab7 ("firewire: core: fix
use-after-free regression in FCP handler"). The object of payload is
duplicated in kernel space for each listener. When the listener executes
ioctl(2) with FW_CDEV_IOC_SEND_RESPONSE request, the object is going to
be released.
However, it causes memory leak since the commit relies on call of
release_request() in drivers/firewire/core-cdev.c. Against the
expectation, the function is never called due to the design of
release_client_resource(). The function delegates release task
to caller when called with non-NULL fourth argument. The implementation
of ioctl_send_response() is the case. It should release the object
explicitly.
This commit fixes the bug. |
["https://git.kernel.org/stable/c/356ff89acdbe6a66019154bc7eb2d300f5b15103","https://git.kernel.org/stable/c/531390a243ef47448f8bad01c186c2787666bf4d","https://git.kernel.org/stable/c/53785fd9b315583cf029e39f72b73d23704a2253","https://git.kernel.org/stable/c/5f4543c9382ae2d5062f6aa4fecae0c9258d0b0e","https://git.kernel.org/stable/c/b2cd3947d116bb9ba7ff097b5fc747a8956764db","https://git.kernel.org/stable/c/c8bdc88216f09cb7387fedbdf613524367328616","https://git.kernel.org/stable/c/d5a2dcee53fa6e6e2822f93cb3f1b0cd23163bee"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-53015
|
Medium |
fixed |
- 4.14.305
- 4.19.272
- 5.4.231
- 5.10.166
- 5.15.91
- 6.1.9
|
In the Linux kernel, the following vulnerability has been resolved:
HID: betop: check shape of output reports
betopff_init() only checks the total sum of the report counts for each
report field to be at least 4, but hid_betopff_play() expects 4 report
fields.
A device advertising an output report with one field and 4 report counts
would pass the check but crash the kernel with a NULL pointer dereference
in hid_betopff_play(). |
["https://git.kernel.org/stable/c/07bc32e53c7bd5c91472cc485231ef6274db9b76","https://git.kernel.org/stable/c/1a2a47b85cab50a3c146731bfeaf2d860f5344ee","https://git.kernel.org/stable/c/28fc6095da22dc88433d79578ae1c495ebe8ca43","https://git.kernel.org/stable/c/3782c0d6edf658b71354a64d60aa7a296188fc90","https://git.kernel.org/stable/c/7317326f685824c7c29bd80841fd18041af6bb73","https://git.kernel.org/stable/c/d3065cc56221d1a5eda237e94eaf2a627b88ab79","https://git.kernel.org/stable/c/dbab4dba400d6ea9a9697fbbd287adbf7db1dac4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-22007
|
Medium |
fixed |
- 6.1.132
- 6.6.85
- 6.12.21
- 6.13.9
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix error code in chan_alloc_skb_cb()
The chan_alloc_skb_cb() function is supposed to return error pointers on
error. Returning NULL will lead to a NULL dereference. |
["https://git.kernel.org/stable/c/1bd68db7beb426ab5a45d81516ed9611284affc8","https://git.kernel.org/stable/c/72d061ee630d0dbb45c2920d8d19b3861c413e54","https://git.kernel.org/stable/c/761b7c36addd22c7e6ceb05caaadc3b062d99faa","https://git.kernel.org/stable/c/76304cba8cba12bb10d89d016c28403a2dd89a29","https://git.kernel.org/stable/c/788ae2ae4cf484e248b5bc29211c7ac6510e3e92","https://git.kernel.org/stable/c/a78692ec0d1e17a96b09f2349a028878f5b305e4","https://git.kernel.org/stable/c/b3d607e36fef4bd05fb938a8a868ff70e9fedbe2","https://git.kernel.org/stable/c/ecd06ad0823a90b4420c377ef8917e44e23ee841"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49845
|
Medium |
fixed |
- 5.4.225
- 5.10.155
- 5.15.79
- 6.0.9
|
In the Linux kernel, the following vulnerability has been resolved:
can: j1939: j1939_send_one(): fix missing CAN header initialization
The read access to struct canxl_frame::len inside of a j1939 created
skbuff revealed a missing initialization of reserved and later filled
elements in struct can_frame.
This patch initializes the 8 byte CAN header with zero. |
["https://git.kernel.org/stable/c/2719f82ad5d8199cf5f346ea8bb3998ad5323b72","https://git.kernel.org/stable/c/3eb3d283e8579a22b81dd2ac3987b77465b2a22f","https://git.kernel.org/stable/c/69e86c6268d59ceddd0abe9ae8f1f5296f316c3c","https://git.kernel.org/stable/c/d0513b095e1ef1469718564dec3fb3348556d0a8","https://git.kernel.org/stable/c/f8e0edeaa0f2b860bdbbf0aafb4492533043d650"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49863
|
Medium |
fixed |
- 5.4.225
- 5.10.155
- 5.15.79
- 6.0.9
|
In the Linux kernel, the following vulnerability has been resolved:
can: af_can: fix NULL pointer dereference in can_rx_register()
It causes NULL pointer dereference when testing as following:
(a) use syscall(__NR_socket, 0x10ul, 3ul, 0) to create netlink socket.
(b) use syscall(__NR_sendmsg, ...) to create bond link device and vxcan
link device, and bind vxcan device to bond device (can also use
ifenslave command to bind vxcan device to bond device).
(c) use syscall(__NR_socket, 0x1dul, 3ul, 1) to create CAN socket.
(d) use syscall(__NR_bind, ...) to bind the bond device to CAN socket.
The bond device invokes the can-raw protocol registration interface to
receive CAN packets. However, ml_priv is not allocated to the dev,
dev_rcv_lists is assigned to NULL in can_rx_register(). In this case,
it will occur the NULL pointer dereference issue.
The following is the stack information:
BUG: kernel NULL pointer dereference, address: 0000000000000008
PGD 122a4067 P4D 122a4067 PUD 1223c067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
RIP: 0010:can_rx_register+0x12d/0x1e0
Call Trace:
<TASK>
raw_enable_filters+0x8d/0x120
raw_enable_allfilters+0x3b/0x130
raw_bind+0x118/0x4f0
__sys_bind+0x163/0x1a0
__x64_sys_bind+0x1e/0x30
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
</TASK> |
["https://git.kernel.org/stable/c/261178a1c2623077d62e374a75c195e6c99a6f05","https://git.kernel.org/stable/c/8aa59e355949442c408408c2d836e561794c40a1","https://git.kernel.org/stable/c/a8055677b054bc2bb78beb1080fdc2dc5158c2fe","https://git.kernel.org/stable/c/afab4655750fcb3fca359bc7d7214e3d634cdf9c","https://git.kernel.org/stable/c/d68fa77ee3d03bad6fe84e89759ddf7005f9e9c6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49869
|
Medium |
fixed |
- 5.4.225
- 5.10.155
- 5.15.79
- 6.0.9
|
In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Fix possible crash in bnxt_hwrm_set_coal()
During the error recovery sequence, the rtnl_lock is not held for the
entire duration and some datastructures may be freed during the sequence.
Check for the BNXT_STATE_OPEN flag instead of netif_running() to ensure
that the device is fully operational before proceeding to reconfigure
the coalescing settings.
This will fix a possible crash like this:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
PGD 0 P4D 0
Oops: 0000 [#1] SMP NOPTI
CPU: 10 PID: 181276 Comm: ethtool Kdump: loaded Tainted: G IOE --------- - - 4.18.0-348.el8.x86_64 #1
Hardware name: Dell Inc. PowerEdge R740/0F9N89, BIOS 2.3.10 08/15/2019
RIP: 0010:bnxt_hwrm_set_coal+0x1fb/0x2a0 [bnxt_en]
Code: c2 66 83 4e 22 08 66 89 46 1c e8 10 cb 00 00 41 83 c6 01 44 39 b3 68 01 00 00 0f 8e a3 00 00 00 48 8b 93 c8 00 00 00 49 63 c6 <48> 8b 2c c2 48 8b 85 b8 02 00 00 48 85 c0 74 2e 48 8b 74 24 08 f6
RSP: 0018:ffffb11c8dcaba50 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8d168a8b0ac0 RCX: 00000000000000c5
RDX: 0000000000000000 RSI: ffff8d162f72c000 RDI: ffff8d168a8b0b28
RBP: 0000000000000000 R08: b6e1f68a12e9a7eb R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000037 R12: ffff8d168a8b109c
R13: ffff8d168a8b10aa R14: 0000000000000000 R15: ffffffffc01ac4e0
FS: 00007f3852e4c740(0000) GS:ffff8d24c0080000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000041b3ee003 CR4: 00000000007706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
ethnl_set_coalesce+0x3ce/0x4c0
genl_family_rcv_msg_doit.isra.15+0x10f/0x150
genl_family_rcv_msg+0xb3/0x160
? coalesce_fill_reply+0x480/0x480
genl_rcv_msg+0x47/0x90
? genl_family_rcv_msg+0x160/0x160
netlink_rcv_skb+0x4c/0x120
genl_rcv+0x24/0x40
netlink_unicast+0x196/0x230
netlink_sendmsg+0x204/0x3d0
sock_sendmsg+0x4c/0x50
__sys_sendto+0xee/0x160
? syscall_trace_enter+0x1d3/0x2c0
? __audit_syscall_exit+0x249/0x2a0
__x64_sys_sendto+0x24/0x30
do_syscall_64+0x5b/0x1a0
entry_SYSCALL_64_after_hwframe+0x65/0xca
RIP: 0033:0x7f38524163bb |
["https://git.kernel.org/stable/c/38147073c96dce8c7e142ce0e5f305a420a729ba","https://git.kernel.org/stable/c/6d81ea3765dfa6c8a20822613c81edad1c4a16a0","https://git.kernel.org/stable/c/7781e32984cde65549bedc3201537e253297c98d","https://git.kernel.org/stable/c/a5a05fbef4a0dfe45fe03b2f1d02ba23aebf5384","https://git.kernel.org/stable/c/ac257c43fa615d22180916074feed803b8bb8cb0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49887
|
Medium |
fixed |
- 5.4.224
- 5.10.154
- 5.15.78
- 6.0.8
|
In the Linux kernel, the following vulnerability has been resolved:
media: meson: vdec: fix possible refcount leak in vdec_probe()
v4l2_device_unregister need to be called to put the refcount got by
v4l2_device_register when vdec_probe fails or vdec_remove is called. |
["https://git.kernel.org/stable/c/0457e7b12ece1a7e41fa0ae8b7e47c0a72a83bef","https://git.kernel.org/stable/c/70119756311a0be3b95bec2e1ba714673e90feba","https://git.kernel.org/stable/c/7718999356234d9cc6a11b4641bb773928f1390f","https://git.kernel.org/stable/c/be6e22f54623d8a856a4f167b25be73c2ff1ff80","https://git.kernel.org/stable/c/f96ad391d054bd5c36994f98afd6a12cbb5600bf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49925
|
Medium |
fixed |
- 5.4.224
- 5.10.154
- 5.15.78
- 6.0.8
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Fix null-ptr-deref in ib_core_cleanup()
KASAN reported a null-ptr-deref error:
KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]
CPU: 1 PID: 379
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:destroy_workqueue+0x2f/0x740
RSP: 0018:ffff888016137df8 EFLAGS: 00000202
...
Call Trace:
ib_core_cleanup+0xa/0xa1 [ib_core]
__do_sys_delete_module.constprop.0+0x34f/0x5b0
do_syscall_64+0x3a/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fa1a0d221b7
...
It is because the fail of roce_gid_mgmt_init() is ignored:
ib_core_init()
roce_gid_mgmt_init()
gid_cache_wq = alloc_ordered_workqueue # fail
...
ib_core_cleanup()
roce_gid_mgmt_cleanup()
destroy_workqueue(gid_cache_wq)
# destroy an unallocated wq
Fix this by catching the fail of roce_gid_mgmt_init() in ib_core_init(). |
["https://git.kernel.org/stable/c/07c0d131cc0fe1f3981a42958fc52d573d303d89","https://git.kernel.org/stable/c/6b3d5dcb12347f3518308c2c9d2cf72453a3e1e5","https://git.kernel.org/stable/c/ab817f75e5e0fa58d9be0825da6a7b7d8a1fa1d9","https://git.kernel.org/stable/c/af8fb5a0600e9ae29950e9422a032c3c22649ee5","https://git.kernel.org/stable/c/d360e875c011a005628525bf290322058927e7dc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49931
|
Medium |
fixed |
- 5.4.224
- 5.10.154
- 5.15.78
- 6.0.8
|
In the Linux kernel, the following vulnerability has been resolved:
IB/hfi1: Correctly move list in sc_disable()
Commit 13bac861952a ("IB/hfi1: Fix abba locking issue with sc_disable()")
incorrectly tries to move a list from one list head to another. The
result is a kernel crash.
The crash is triggered when a link goes down and there are waiters for a
send to complete. The following signature is seen:
BUG: kernel NULL pointer dereference, address: 0000000000000030
[...]
Call Trace:
sc_disable+0x1ba/0x240 [hfi1]
pio_freeze+0x3d/0x60 [hfi1]
handle_freeze+0x27/0x1b0 [hfi1]
process_one_work+0x1b0/0x380
? process_one_work+0x380/0x380
worker_thread+0x30/0x360
? process_one_work+0x380/0x380
kthread+0xd7/0x100
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x1f/0x30
The fix is to use the correct call to move the list. |
["https://git.kernel.org/stable/c/1afac08b39d85437187bb2a92d89a741b1078f55","https://git.kernel.org/stable/c/25760a41e3802f54aadcc31385543665ab349b8e","https://git.kernel.org/stable/c/7c4260f8f188df32414a5ecad63e8b934c2aa3f0","https://git.kernel.org/stable/c/b8bcff99b07cc175a6ee12a52db51cdd2229586c","https://git.kernel.org/stable/c/ba95409d6b580501ff6d78efd00064f7df669926"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49885
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ACPI: APEI: Fix integer overflow in ghes_estatus_pool_init()
Change num_ghes from int to unsigned int, preventing an overflow
and causing subsequent vmalloc() to fail.
The overflow happens in ghes_estatus_pool_init() when calculating
len during execution of the statement below as both multiplication
operands here are signed int:
len += (num_ghes * GHES_ESOURCE_PREALLOC_MAX_SIZE);
The following call trace is observed because of this bug:
[ 9.317108] swapper/0: vmalloc error: size 18446744071562596352, exceeds total pages, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0-1
[ 9.317131] Call Trace:
[ 9.317134] <TASK>
[ 9.317137] dump_stack_lvl+0x49/0x5f
[ 9.317145] dump_stack+0x10/0x12
[ 9.317146] warn_alloc.cold+0x7b/0xdf
[ 9.317150] ? __device_attach+0x16a/0x1b0
[ 9.317155] __vmalloc_node_range+0x702/0x740
[ 9.317160] ? device_add+0x17f/0x920
[ 9.317164] ? dev_set_name+0x53/0x70
[ 9.317166] ? platform_device_add+0xf9/0x240
[ 9.317168] __vmalloc_node+0x49/0x50
[ 9.317170] ? ghes_estatus_pool_init+0x43/0xa0
[ 9.317176] vmalloc+0x21/0x30
[ 9.317177] ghes_estatus_pool_init+0x43/0xa0
[ 9.317179] acpi_hest_init+0x129/0x19c
[ 9.317185] acpi_init+0x434/0x4a4
[ 9.317188] ? acpi_sleep_proc_init+0x2a/0x2a
[ 9.317190] do_one_initcall+0x48/0x200
[ 9.317195] kernel_init_freeable+0x221/0x284
[ 9.317200] ? rest_init+0xe0/0xe0
[ 9.317204] kernel_init+0x1a/0x130
[ 9.317205] ret_from_fork+0x22/0x30
[ 9.317208] </TASK>
[ rjw: Subject and changelog edits ] |
["https://git.kernel.org/stable/c/43d2748394c3feb86c0c771466f5847e274fc043","https://git.kernel.org/stable/c/4c10c854113720cbfe75d4f51db79b700a629e73","https://git.kernel.org/stable/c/9edf20e5a1d805855e78f241cf221d741b50d482","https://git.kernel.org/stable/c/c50ec15725e005e9fb20bce69b6c23b135a4a9b7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-22998
|
Medium |
fixed |
|
In the Linux kernel before 6.0.3, drivers/gpu/drm/virtio/virtgpu_object.c misinterprets the drm_gem_shmem_get_sg_table return value (expects it to be NULL in the error case, whereas it is actually an error pointer). |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.0.3","https://github.com/torvalds/linux/commit/c24968734abfed81c8f93dc5f44a7b7a9aecadfa","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.0.3","https://github.com/torvalds/linux/commit/c24968734abfed81c8f93dc5f44a7b7a9aecadfa","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49758
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
reset: uniphier-glue: Fix possible null-ptr-deref
It will cause null-ptr-deref when resource_size(res) invoked,
if platform_get_resource() returns NULL. |
["https://git.kernel.org/stable/c/3a2390c6777e3f6662980c6cfc25cafe9e4fef98","https://git.kernel.org/stable/c/633bad3dc81ce2aa561f704ec091e49eb647bd0b","https://git.kernel.org/stable/c/95de286200b2a046da01c4aeba02ae9220d68ca4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49837
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix memory leaks in __check_func_call
kmemleak reports this issue:
unreferenced object 0xffff88817139d000 (size 2048):
comm "test_progs", pid 33246, jiffies 4307381979 (age 45851.820s)
hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000045f075f0>] kmalloc_trace+0x27/0xa0
[<0000000098b7c90a>] __check_func_call+0x316/0x1230
[<00000000b4c3c403>] check_helper_call+0x172e/0x4700
[<00000000aa3875b7>] do_check+0x21d8/0x45e0
[<000000001147357b>] do_check_common+0x767/0xaf0
[<00000000b5a595b4>] bpf_check+0x43e3/0x5bc0
[<0000000011e391b1>] bpf_prog_load+0xf26/0x1940
[<0000000007f765c0>] __sys_bpf+0xd2c/0x3650
[<00000000839815d6>] __x64_sys_bpf+0x75/0xc0
[<00000000946ee250>] do_syscall_64+0x3b/0x90
[<0000000000506b7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
The root case here is: In function prepare_func_exit(), the callee is
not released in the abnormal scenario after "state->curframe--;". To
fix, move "state->curframe--;" to the very bottom of the function,
right when we free callee and reset frame[] pointer to NULL, as Andrii
suggested.
In addition, function __check_func_call() has a similar problem. In
the abnormal scenario before "state->curframe++;", the callee also
should be released by free_func_state(). |
["https://git.kernel.org/stable/c/83946d772e756734a900ef99dbe0aeda506adf37","https://git.kernel.org/stable/c/d4944497827a3d14bc5a26dbcfb7433eb5a956c0","https://git.kernel.org/stable/c/eb86559a691cea5fa63e57a03ec3dc9c31e97955"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49854
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mctp: Fix an error handling path in mctp_init()
If mctp_neigh_init() return error, the routes resources should
be released in the error handling path. Otherwise some resources
leak. |
["https://git.kernel.org/stable/c/216c83222d2eb24b0e63df56e8740b02c33286e8","https://git.kernel.org/stable/c/49d8a6e24a3496d86e8d8ae748375df984fb6d6f","https://git.kernel.org/stable/c/d4072058af4fd8fb4658e7452289042a406a9398"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49855
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: wwan: iosm: fix memory leak in ipc_pcie_read_bios_cfg
ipc_pcie_read_bios_cfg() is using the acpi_evaluate_dsm() to
obtain the wwan power state configuration from BIOS but is
not freeing the acpi_object. The acpi_evaluate_dsm() returned
acpi_object to be freed.
Free the acpi_object after use. |
["https://git.kernel.org/stable/c/13b1ea861e8aeb701bcfbfe436b943efa2d44029","https://git.kernel.org/stable/c/7560ceef4d2832a67e8781d924e129c7f542376f","https://git.kernel.org/stable/c/d38a648d2d6cc7bee11c6f533ff9426a00c2a74c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49860
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: ti: k3-udma-glue: fix memory leak when register device fail
If device_register() fails, it should call put_device() to give
up reference, the name allocated in dev_set_name() can be freed
in callback function kobject_cleanup(). |
["https://git.kernel.org/stable/c/025eab5189fc7ee223ae9b4bc49d7df196543e53","https://git.kernel.org/stable/c/1dd27541aa2b95bde71bddd43d73f9c16d73272c","https://git.kernel.org/stable/c/ac2b9f34f02052709aea7b34bb2a165e1853eb41"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49864
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Fix NULL pointer dereference in svm_migrate_to_ram()
./drivers/gpu/drm/amd/amdkfd/kfd_migrate.c:985:58-62: ERROR: p is NULL but dereferenced. |
["https://git.kernel.org/stable/c/3c1bb6187e566143f15dbf0367ae671584aead5b","https://git.kernel.org/stable/c/5b994354af3cab770bf13386469c5725713679af","https://git.kernel.org/stable/c/613d5a9a440828970f1543b962779401ac2c9c62"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49866
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: wwan: mhi: fix memory leak in mhi_mbim_dellink
MHI driver registers network device without setting the
needs_free_netdev flag, and does NOT call free_netdev() when
unregisters network device, which causes a memory leak.
This patch sets needs_free_netdev to true when registers
network device, which makes netdev subsystem call free_netdev()
automatically after unregister_netdevice(). |
["https://git.kernel.org/stable/c/2845bc9070cef0c651987487d84d4813d64675dd","https://git.kernel.org/stable/c/3cd3ffe952f78ec5dadf300cb58d4b38a0c0106d","https://git.kernel.org/stable/c/668205b9c9f94d5ed6ab00cce9a46a654c2b5d16"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49867
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: wwan: iosm: fix memory leak in ipc_wwan_dellink
IOSM driver registers network device without setting the
needs_free_netdev flag, and does NOT call free_netdev() when
unregisters network device, which causes a memory leak.
This patch sets needs_free_netdev to true when registers
network device, which makes netdev subsystem call free_netdev()
automatically after unregister_netdevice(). |
["https://git.kernel.org/stable/c/128514b51a5ba2c82f9e4a106f1c10423907618a","https://git.kernel.org/stable/c/2ce2348c2858d723f7fe389dead9b43b08e0944e","https://git.kernel.org/stable/c/f25caaca424703d5a0607310f0452f978f1f78d9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49878
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf, verifier: Fix memory leak in array reallocation for stack state
If an error (NULL) is returned by krealloc(), callers of realloc_array()
were setting their allocation pointers to NULL, but on error krealloc()
does not touch the original allocation. This would result in a memory
resource leak. Instead, free the old allocation on the error handling
path.
The memory leak information is as follows as also reported by Zhengchao:
unreferenced object 0xffff888019801800 (size 256):
comm "bpf_repo", pid 6490, jiffies 4294959200 (age 17.170s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000b211474b>] __kmalloc_node_track_caller+0x45/0xc0
[<0000000086712a0b>] krealloc+0x83/0xd0
[<00000000139aab02>] realloc_array+0x82/0xe2
[<00000000b1ca41d1>] grow_stack_state+0xfb/0x186
[<00000000cd6f36d2>] check_mem_access.cold+0x141/0x1341
[<0000000081780455>] do_check_common+0x5358/0xb350
[<0000000015f6b091>] bpf_check.cold+0xc3/0x29d
[<000000002973c690>] bpf_prog_load+0x13db/0x2240
[<00000000028d1644>] __sys_bpf+0x1605/0x4ce0
[<00000000053f29bd>] __x64_sys_bpf+0x75/0xb0
[<0000000056fedaf5>] do_syscall_64+0x35/0x80
[<000000002bd58261>] entry_SYSCALL_64_after_hwframe+0x63/0xcd |
["https://git.kernel.org/stable/c/06615967d4889b08b19ff3dda96e8b131282f73d","https://git.kernel.org/stable/c/3e210891c4a4c2d858cd6f9f61d5809af251d4df","https://git.kernel.org/stable/c/42378a9ca55347102bbf86708776061d8fe3ece2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49902
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
block: Fix possible memory leak for rq_wb on add_disk failure
kmemleak reported memory leaks in device_add_disk():
kmemleak: 3 new suspected memory leaks
unreferenced object 0xffff88800f420800 (size 512):
comm "modprobe", pid 4275, jiffies 4295639067 (age 223.512s)
hex dump (first 32 bytes):
04 00 00 00 08 00 00 00 01 00 00 00 00 00 00 00 ................
00 e1 f5 05 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000d3662699>] kmalloc_trace+0x26/0x60
[<00000000edc7aadc>] wbt_init+0x50/0x6f0
[<0000000069601d16>] wbt_enable_default+0x157/0x1c0
[<0000000028fc393f>] blk_register_queue+0x2a4/0x420
[<000000007345a042>] device_add_disk+0x6fd/0xe40
[<0000000060e6aab0>] nbd_dev_add+0x828/0xbf0 [nbd]
...
It is because the memory allocated in wbt_enable_default() is not
released in device_add_disk() error path.
Normally, these memory are freed in:
del_gendisk()
rq_qos_exit()
rqos->ops->exit(rqos);
wbt_exit()
So rq_qos_exit() is called to free the rq_wb memory for wbt_init().
However in the error path of device_add_disk(), only
blk_unregister_queue() is called and make rq_wb memory leaked.
Add rq_qos_exit() to the error path to fix it. |
["https://git.kernel.org/stable/c/4e68c5da60cd79950bd56287ae80b39d6261f995","https://git.kernel.org/stable/c/528677d3b4af985445bd4ac667485ded1ed11220","https://git.kernel.org/stable/c/fa81cbafbf5764ad5053512152345fab37a1fe18"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49906
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: Free rwi on reset success
Free the rwi structure in the event that the last rwi in the list
processed successfully. The logic in commit 4f408e1fa6e1 ("ibmvnic:
retry reset if there are no other resets") introduces an issue that
results in a 32 byte memory leak whenever the last rwi in the list
gets processed. |
["https://git.kernel.org/stable/c/535b78739ae75f257c894a05b1afa86ad9a3669e","https://git.kernel.org/stable/c/c3543a287cfba9105dcc4bb41eb817f51266caaf","https://git.kernel.org/stable/c/d6dd2fe71153f0ff748bf188bd4af076fe09a0a6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49908
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix memory leak in vhci_write
Syzkaller reports a memory leak as follows:
====================================
BUG: memory leak
unreferenced object 0xffff88810d81ac00 (size 240):
[...]
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff838733d9>] __alloc_skb+0x1f9/0x270 net/core/skbuff.c:418
[<ffffffff833f742f>] alloc_skb include/linux/skbuff.h:1257 [inline]
[<ffffffff833f742f>] bt_skb_alloc include/net/bluetooth/bluetooth.h:469 [inline]
[<ffffffff833f742f>] vhci_get_user drivers/bluetooth/hci_vhci.c:391 [inline]
[<ffffffff833f742f>] vhci_write+0x5f/0x230 drivers/bluetooth/hci_vhci.c:511
[<ffffffff815e398d>] call_write_iter include/linux/fs.h:2192 [inline]
[<ffffffff815e398d>] new_sync_write fs/read_write.c:491 [inline]
[<ffffffff815e398d>] vfs_write+0x42d/0x540 fs/read_write.c:578
[<ffffffff815e3cdd>] ksys_write+0x9d/0x160 fs/read_write.c:631
[<ffffffff845e0645>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<ffffffff845e0645>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
[<ffffffff84600087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
====================================
HCI core will uses hci_rx_work() to process frame, which is queued to
the hdev->rx_q tail in hci_recv_frame() by HCI driver.
Yet the problem is that, HCI core may not free the skb after handling
ACL data packets. To be more specific, when start fragment does not
contain the L2CAP length, HCI core just copies skb into conn->rx_skb and
finishes frame process in l2cap_recv_acldata(), without freeing the skb,
which triggers the above memory leak.
This patch solves it by releasing the relative skb, after processing
the above case in l2cap_recv_acldata(). |
["https://git.kernel.org/stable/c/5b4f039a2f487c5edae681d763fe1af505f84c13","https://git.kernel.org/stable/c/7c9524d929648935bac2bbb4c20437df8f9c3f42","https://git.kernel.org/stable/c/aa16cac06b752e5f609c106735bd7838f444784c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49928
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix null-ptr-deref when xps sysfs alloc failed
There is a null-ptr-deref when xps sysfs alloc failed:
BUG: KASAN: null-ptr-deref in sysfs_do_create_link_sd+0x40/0xd0
Read of size 8 at addr 0000000000000030 by task gssproxy/457
CPU: 5 PID: 457 Comm: gssproxy Not tainted 6.0.0-09040-g02357b27ee03 #9
Call Trace:
<TASK>
dump_stack_lvl+0x34/0x44
kasan_report+0xa3/0x120
sysfs_do_create_link_sd+0x40/0xd0
rpc_sysfs_client_setup+0x161/0x1b0
rpc_new_client+0x3fc/0x6e0
rpc_create_xprt+0x71/0x220
rpc_create+0x1d4/0x350
gssp_rpc_create+0xc3/0x160
set_gssp_clnt+0xbc/0x140
write_gssp+0x116/0x1a0
proc_reg_write+0xd6/0x130
vfs_write+0x177/0x690
ksys_write+0xb9/0x150
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
When the xprt_switch sysfs alloc failed, should not add xprt and
switch sysfs to it, otherwise, maybe null-ptr-deref; also initialize
the 'xps_sysfs' to NULL to avoid oops when destroy it. |
["https://git.kernel.org/stable/c/7b189b0aa8dab14b49c31c65af8a982e96e25b62","https://git.kernel.org/stable/c/cbdeaee94a415800c65a8c3fa04d9664a8b8fb3a","https://git.kernel.org/stable/c/d59722d088a9d86ce6d9d39979e5d1d669d249f7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52978
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
riscv: kprobe: Fixup kernel panic when probing an illegal position
The kernel would panic when probed for an illegal position. eg:
(CONFIG_RISCV_ISA_C=n)
echo 'p:hello kernel_clone+0x16 a0=%a0' >> kprobe_events
echo 1 > events/kprobes/hello/enable
cat trace
Kernel panic - not syncing: stack-protector: Kernel stack
is corrupted in: __do_sys_newfstatat+0xb8/0xb8
CPU: 0 PID: 111 Comm: sh Not tainted
6.2.0-rc1-00027-g2d398fe49a4d #490
Hardware name: riscv-virtio,qemu (DT)
Call Trace:
[<ffffffff80007268>] dump_backtrace+0x38/0x48
[<ffffffff80c5e83c>] show_stack+0x50/0x68
[<ffffffff80c6da28>] dump_stack_lvl+0x60/0x84
[<ffffffff80c6da6c>] dump_stack+0x20/0x30
[<ffffffff80c5ecf4>] panic+0x160/0x374
[<ffffffff80c6db94>] generic_handle_arch_irq+0x0/0xa8
[<ffffffff802deeb0>] sys_newstat+0x0/0x30
[<ffffffff800158c0>] sys_clone+0x20/0x30
[<ffffffff800039e8>] ret_from_syscall+0x0/0x4
---[ end Kernel panic - not syncing: stack-protector:
Kernel stack is corrupted in: __do_sys_newfstatat+0xb8/0xb8 ]---
That is because the kprobe's ebreak instruction broke the kernel's
original code. The user should guarantee the correction of the probe
position, but it couldn't make the kernel panic.
This patch adds arch_check_kprobe in arch_prepare_kprobe to prevent an
illegal position (Such as the middle of an instruction). |
["https://git.kernel.org/stable/c/04a73558209554da17f46490ec4faaaf1b2bab68","https://git.kernel.org/stable/c/12316538b1d193064109ce1a28fc9bacd43950de","https://git.kernel.org/stable/c/87f48c7ccc73afc78630530d9af51f458f58cab8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-53011
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: enable all safety features by default
In the original implementation of dwmac5
commit 8bf993a5877e ("net: stmmac: Add support for DWMAC5 and implement Safety Features")
all safety features were enabled by default.
Later it seems some implementations didn't have support for all the
features, so in
commit 5ac712dcdfef ("net: stmmac: enable platform specific safety features")
the safety_feat_cfg structure was added to the callback and defined for
some platforms to selectively enable these safety features.
The problem is that only certain platforms were given that software
support. If the automotive safety package bit is set in the hardware
features register the safety feature callback is called for the platform,
and for platforms that didn't get a safety_feat_cfg defined this results
in the following NULL pointer dereference:
[ 7.933303] Call trace:
[ 7.935812] dwmac5_safety_feat_config+0x20/0x170 [stmmac]
[ 7.941455] __stmmac_open+0x16c/0x474 [stmmac]
[ 7.946117] stmmac_open+0x38/0x70 [stmmac]
[ 7.950414] __dev_open+0x100/0x1dc
[ 7.954006] __dev_change_flags+0x18c/0x204
[ 7.958297] dev_change_flags+0x24/0x6c
[ 7.962237] do_setlink+0x2b8/0xfa4
[ 7.965827] __rtnl_newlink+0x4ec/0x840
[ 7.969766] rtnl_newlink+0x50/0x80
[ 7.973353] rtnetlink_rcv_msg+0x12c/0x374
[ 7.977557] netlink_rcv_skb+0x5c/0x130
[ 7.981500] rtnetlink_rcv+0x18/0x2c
[ 7.985172] netlink_unicast+0x2e8/0x340
[ 7.989197] netlink_sendmsg+0x1a8/0x420
[ 7.993222] ____sys_sendmsg+0x218/0x280
[ 7.997249] ___sys_sendmsg+0xac/0x100
[ 8.001103] __sys_sendmsg+0x84/0xe0
[ 8.004776] __arm64_sys_sendmsg+0x24/0x30
[ 8.008983] invoke_syscall+0x48/0x114
[ 8.012840] el0_svc_common.constprop.0+0xcc/0xec
[ 8.017665] do_el0_svc+0x38/0xb0
[ 8.021071] el0_svc+0x2c/0x84
[ 8.024212] el0t_64_sync_handler+0xf4/0x120
[ 8.028598] el0t_64_sync+0x190/0x194
Go back to the original behavior, if the automotive safety package
is found to be supported in hardware enable all the features unless
safety_feat_cfg is passed in saying this particular platform only
supports a subset of the features. |
["https://git.kernel.org/stable/c/120b8e527e07c65de7f2b9018dcd9d17e66f2427","https://git.kernel.org/stable/c/aebf7e62708ba706ee7bf484c9023b15c214e92a","https://git.kernel.org/stable/c/fdfc76a116b5e9d3e98e6c96fe83b42d011d21d4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49839
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: scsi_transport_sas: Fix error handling in sas_phy_add()
If transport_add_device() fails in sas_phy_add(), the kernel will crash
trying to delete the device in transport_remove_device() called from
sas_remove_host().
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108
CPU: 61 PID: 42829 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc1+ #173
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : device_del+0x54/0x3d0
lr : device_del+0x37c/0x3d0
Call trace:
device_del+0x54/0x3d0
attribute_container_class_device_del+0x28/0x38
transport_remove_classdev+0x6c/0x80
attribute_container_device_trigger+0x108/0x110
transport_remove_device+0x28/0x38
sas_phy_delete+0x30/0x60 [scsi_transport_sas]
do_sas_phy_delete+0x6c/0x80 [scsi_transport_sas]
device_for_each_child+0x68/0xb0
sas_remove_children+0x40/0x50 [scsi_transport_sas]
sas_remove_host+0x20/0x38 [scsi_transport_sas]
hisi_sas_remove+0x40/0x68 [hisi_sas_main]
hisi_sas_v2_remove+0x20/0x30 [hisi_sas_v2_hw]
platform_remove+0x2c/0x60
Fix this by checking and handling return value of transport_add_device()
in sas_phy_add(). |
["https://git.kernel.org/stable/c/03aabcb88aeeb7221ddb6196ae84ad5fb17b743f","https://git.kernel.org/stable/c/2f21d653c648735657e23948b1d7ac7273de0f87","https://git.kernel.org/stable/c/5d7bebf2dfb0dc97aac1fbace0910e557ecdb16f","https://git.kernel.org/stable/c/c736876ee294bb4f271d76a25cc7d70c8537bc5d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49857
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: marvell: prestera: fix memory leak in prestera_rxtx_switch_init()
When prestera_sdma_switch_init() failed, the memory pointed to by
sw->rxtx isn't released. Fix it. Only be compiled, not be tested. |
["https://git.kernel.org/stable/c/31e5084ac6876e52dbb0a1cc4fc18b6c79979f31","https://git.kernel.org/stable/c/409731df6310a33f4d0a3ef594d2410cdcd637f2","https://git.kernel.org/stable/c/519b58bbfa825f042fcf80261cc18e1e35f85ffd","https://git.kernel.org/stable/c/5333cf1b7f6861912aff6263978d4781f9858e47"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49873
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix wrong reg type conversion in release_reference()
Some helper functions will allocate memory. To avoid memory leaks, the
verifier requires the eBPF program to release these memories by calling
the corresponding helper functions.
When a resource is released, all pointer registers corresponding to the
resource should be invalidated. The verifier use release_references() to
do this job, by apply __mark_reg_unknown() to each relevant register.
It will give these registers the type of SCALAR_VALUE. A register that
will contain a pointer value at runtime, but of type SCALAR_VALUE, which
may allow the unprivileged user to get a kernel pointer by storing this
register into a map.
Using __mark_reg_not_init() while NOT allow_ptr_leaks can mitigate this
problem. |
["https://git.kernel.org/stable/c/466ce46f251dfb259a8cbaa895ab9edd6fb56240","https://git.kernel.org/stable/c/ae5ccad6c711db0f2ca1231be051935dd128b8f5","https://git.kernel.org/stable/c/cedd4f01f67be94735f15123158f485028571037","https://git.kernel.org/stable/c/f1db20814af532f85e091231223e5e4818e8464b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49875
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpftool: Fix NULL pointer dereference when pin {PROG, MAP, LINK} without FILE
When using bpftool to pin {PROG, MAP, LINK} without FILE,
segmentation fault will occur. The reson is that the lack
of FILE will cause strlen to trigger NULL pointer dereference.
The corresponding stacktrace is shown below:
do_pin
do_pin_any
do_pin_fd
mount_bpffs_for_pin
strlen(name) <- NULL pointer dereference
Fix it by adding validation to the common process. |
["https://git.kernel.org/stable/c/34de8e6e0e1f66e431abf4123934a2581cb5f133","https://git.kernel.org/stable/c/6dcdd1b68b7f9333d48d48fc77b75e7f235f6a4a","https://git.kernel.org/stable/c/8c80b2fca4112d724dde477aed13f7b0510a2792","https://git.kernel.org/stable/c/da5161ba94c5e9182c301dd4f09c94f715c068bd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49891
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
tracing: kprobe: Fix memory leak in test_gen_kprobe/kretprobe_cmd()
test_gen_kprobe_cmd() only free buf in fail path, hence buf will leak
when there is no failure. Move kfree(buf) from fail path to common path
to prevent the memleak. The same reason and solution in
test_gen_kretprobe_cmd().
unreferenced object 0xffff888143b14000 (size 2048):
comm "insmod", pid 52490, jiffies 4301890980 (age 40.553s)
hex dump (first 32 bytes):
70 3a 6b 70 72 6f 62 65 73 2f 67 65 6e 5f 6b 70 p:kprobes/gen_kp
72 6f 62 65 5f 74 65 73 74 20 64 6f 5f 73 79 73 robe_test do_sys
backtrace:
[<000000006d7b836b>] kmalloc_trace+0x27/0xa0
[<0000000009528b5b>] 0xffffffffa059006f
[<000000008408b580>] do_one_initcall+0x87/0x2a0
[<00000000c4980a7e>] do_init_module+0xdf/0x320
[<00000000d775aad0>] load_module+0x3006/0x3390
[<00000000e9a74b80>] __do_sys_finit_module+0x113/0x1b0
[<000000003726480d>] do_syscall_64+0x35/0x80
[<000000003441e93b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 |
["https://git.kernel.org/stable/c/66f0919c953ef7b55e5ab94389a013da2ce80a2c","https://git.kernel.org/stable/c/71aeb8d01a8c7ab5cf7da3f81b35206f56ce6bca","https://git.kernel.org/stable/c/bef08acbe560a926b4cee9cc46404cc98ae5703b","https://git.kernel.org/stable/c/d1b6a8e3414aeaa0985139180c145d2d0fbd2a49"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49923
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
nfc: nxp-nci: Fix potential memory leak in nxp_nci_send()
nxp_nci_send() will call nxp_nci_i2c_write(), and only free skb when
nxp_nci_i2c_write() failed. However, even if the nxp_nci_i2c_write()
run succeeds, the skb will not be freed in nxp_nci_i2c_write(). As the
result, the skb will memleak. nxp_nci_send() should also free the skb
when nxp_nci_i2c_write() succeeds. |
["https://git.kernel.org/stable/c/3cba1f061bfe23fece2841129ca2862cdec29d5c","https://git.kernel.org/stable/c/3ecf0f4227029b2c42e036b10ff6e5d09e20821e","https://git.kernel.org/stable/c/7bf1ed6aff0f70434bd0cdd45495e83f1dffb551","https://git.kernel.org/stable/c/9ae2c9a91ff068f4c3e392f47e8e26a1c9f85ebb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49924
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
nfc: fdp: Fix potential memory leak in fdp_nci_send()
fdp_nci_send() will call fdp_nci_i2c_write that will not free skb in
the function. As a result, when fdp_nci_i2c_write() finished, the skb
will memleak. fdp_nci_send() should free skb after fdp_nci_i2c_write()
finished. |
["https://git.kernel.org/stable/c/1a7a898f8f7b56c0eaa2baf67a0c96235a30bc29","https://git.kernel.org/stable/c/44bc1868a4f542502ea2221fe5ad88ca66d1c6b6","https://git.kernel.org/stable/c/8e4aae6b8ca76afb1fb64dcb24be44ba814e7f8a","https://git.kernel.org/stable/c/e8c11ee2d07f7c4dfa2ac0ea8efc4f627e58ea57"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52991
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: fix NULL pointer in skb_segment_list
Commit 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.")
introduced UDP listifyed GRO. The segmentation relies on frag_list being
untouched when passing through the network stack. This assumption can be
broken sometimes, where frag_list itself gets pulled into linear area,
leaving frag_list being NULL. When this happens it can trigger
following NULL pointer dereference, and panic the kernel. Reverse the
test condition should fix it.
[19185.577801][ C1] BUG: kernel NULL pointer dereference, address:
...
[19185.663775][ C1] RIP: 0010:skb_segment_list+0x1cc/0x390
...
[19185.834644][ C1] Call Trace:
[19185.841730][ C1] <TASK>
[19185.848563][ C1] __udp_gso_segment+0x33e/0x510
[19185.857370][ C1] inet_gso_segment+0x15b/0x3e0
[19185.866059][ C1] skb_mac_gso_segment+0x97/0x110
[19185.874939][ C1] __skb_gso_segment+0xb2/0x160
[19185.883646][ C1] udp_queue_rcv_skb+0xc3/0x1d0
[19185.892319][ C1] udp_unicast_rcv_skb+0x75/0x90
[19185.900979][ C1] ip_protocol_deliver_rcu+0xd2/0x200
[19185.910003][ C1] ip_local_deliver_finish+0x44/0x60
[19185.918757][ C1] __netif_receive_skb_one_core+0x8b/0xa0
[19185.927834][ C1] process_backlog+0x88/0x130
[19185.935840][ C1] __napi_poll+0x27/0x150
[19185.943447][ C1] net_rx_action+0x27e/0x5f0
[19185.951331][ C1] ? mlx5_cq_tasklet_cb+0x70/0x160 [mlx5_core]
[19185.960848][ C1] __do_softirq+0xbc/0x25d
[19185.968607][ C1] irq_exit_rcu+0x83/0xb0
[19185.976247][ C1] common_interrupt+0x43/0xa0
[19185.984235][ C1] asm_common_interrupt+0x22/0x40
...
[19186.094106][ C1] </TASK> |
["https://git.kernel.org/stable/c/046de74f9af92ae9ffce75fa22a1795223f4fb54","https://git.kernel.org/stable/c/6446369fb9f083ce032448c5047da08e298b22e6","https://git.kernel.org/stable/c/876e8ca8366735a604bac86ff7e2732fc9d85d2d","https://git.kernel.org/stable/c/888dad6f3e85e3b2f8389bd6478f181efc72534d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-22037
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix null pointer dereference in alloc_preauth_hash()
The Client send malformed smb2 negotiate request. ksmbd return error
response. Subsequently, the client can send smb2 session setup even
thought conn->preauth_info is not allocated.
This patch add KSMBD_SESS_NEED_SETUP status of connection to ignore
session setup request if smb2 negotiate phase is not complete. |
["https://git.kernel.org/stable/c/8f216b33a5e1b3489c073b1ea1b3d7cb63c8dc4d","https://git.kernel.org/stable/c/b8eb243e670ecf30e91524dd12f7260dac07d335","https://git.kernel.org/stable/c/c8b5b7c5da7d0c31c9b7190b4a7bba5281fc4780","https://git.kernel.org/stable/c/ca8bed31edf728a662ef9d6f39f50e7a7dc2b5ad"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-23455
|
Medium |
|
N/A
|
atm_tc_enqueue in net/sched/sch_atm.c in the Linux kernel through 6.1.4 allows attackers to cause a denial of service because of type confusion (non-negative numbers can sometimes indicate a TC_ACT_SHOT condition rather than valid classification results). |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a2965c7be0522eaa18808684b7b82b248515511b","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://www.debian.org/security/2023/dsa-5324","https://www.openwall.com/lists/oss-security/2023/01/10/1","https://www.openwall.com/lists/oss-security/2023/01/10/4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a2965c7be0522eaa18808684b7b82b248515511b","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://www.debian.org/security/2023/dsa-5324","https://www.openwall.com/lists/oss-security/2023/01/10/1","https://www.openwall.com/lists/oss-security/2023/01/10/4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3567
|
Medium |
|
N/A
|
A vulnerability has been found in Linux Kernel and classified as problematic. This vulnerability affects the function inet6_stream_ops/inet6_dgram_ops of the component IPv6 Handler. The manipulation leads to race condition. It is recommended to apply a patch to fix this issue. VDB-211090 is the identifier assigned to this vulnerability. |
["https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=364f997b5cfe1db0d63a390fe7c801fa2b3115f6","https://vuldb.com/?id.211090","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=364f997b5cfe1db0d63a390fe7c801fa2b3115f6","https://vuldb.com/?id.211090"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-0469
|
Medium |
fixed |
|
A use-after-free flaw was found in io_uring/filetable.c in io_install_fixed_file in the io_uring subcomponent in the Linux Kernel during call cleanup. This flaw may lead to a denial of service. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2163723","https://bugzilla.redhat.com/show_bug.cgi?id=2163723"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-34256
|
Medium |
fixed |
|
An issue was discovered in the Linux kernel before 6.3.3. There is an out-of-bounds read in crc16 in lib/crc16.c when called from fs/ext4/super.c because ext4_group_desc_csum does not properly check an offset. NOTE: this is disputed by third parties because the kernel is not intended to defend against attackers with the stated "When modifying the block device while it is mounted by the filesystem" access. |
["https://bugzilla.suse.com/show_bug.cgi?id=1211895","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.3","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f04351888a83e595571de672e0a4a8b74f4fb31","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://syzkaller.appspot.com/bug?extid=8785e41224a3afd04321","https://bugzilla.suse.com/show_bug.cgi?id=1211895","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.3","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f04351888a83e595571de672e0a4a8b74f4fb31","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://syzkaller.appspot.com/bug?extid=8785e41224a3afd04321"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-22996
|
Medium |
fixed |
|
In the Linux kernel before 5.17.2, drivers/soc/qcom/qcom_aoss.c does not release an of_find_device_by_node reference after use, e.g., with put_device. |
["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.2","https://github.com/torvalds/linux/commit/4b41a9d0fe3db5f91078a380f62f0572c3ecf2dd","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.2","https://github.com/torvalds/linux/commit/4b41a9d0fe3db5f91078a380f62f0572c3ecf2dd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-22999
|
Medium |
fixed |
|
In the Linux kernel before 5.16.3, drivers/usb/dwc3/dwc3-qcom.c misinterprets the dwc3_qcom_create_urs_usb_platdev return value (expects it to be NULL in the error case, whereas it is actually an error pointer). |
["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.3","https://github.com/torvalds/linux/commit/b52fe2dbb3e655eb1483000adfab68a219549e13","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.3","https://github.com/torvalds/linux/commit/b52fe2dbb3e655eb1483000adfab68a219549e13"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49750
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: CPPC: Add u64 casts to avoid overflowing
The fields of the _CPC object are unsigned 32-bits values.
To avoid overflows while using _CPC's values, add 'u64' casts. |
["https://git.kernel.org/stable/c/7d596bbc66a52ff2c7a83d7e0ee840cb07e2a045","https://git.kernel.org/stable/c/f5f94b9c8b805d87ff185caf9779c3a4d07819e3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-53002
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/i915: Fix a memory leak with reused mmap_offset
drm_vma_node_allow() and drm_vma_node_revoke() should be called in
balanced pairs. We call drm_vma_node_allow() once per-file everytime a
user calls mmap_offset, but only call drm_vma_node_revoke once per-file
on each mmap_offset. As the mmap_offset is reused by the client, the
per-file vm_count may remain non-zero and the rbtree leaked.
Call drm_vma_node_allow_once() instead to prevent that memory leak. |
["https://git.kernel.org/stable/c/0220e4fe178c3390eb0291cdb34912d66972db8a","https://git.kernel.org/stable/c/0bdc4b4ba7206c452ee81c82fa66e39d0e1780fb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49300
|
Medium |
fixed |
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
nbd: fix race between nbd_alloc_config() and module removal
When nbd module is being removing, nbd_alloc_config() may be
called concurrently by nbd_genl_connect(), although try_module_get()
will return false, but nbd_alloc_config() doesn't handle it.
The race may lead to the leak of nbd_config and its related
resources (e.g, recv_workq) and oops in nbd_read_stat() due
to the unload of nbd module as shown below:
BUG: kernel NULL pointer dereference, address: 0000000000000040
Oops: 0000 [#1] SMP PTI
CPU: 5 PID: 13840 Comm: kworker/u17:33 Not tainted 5.14.0+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Workqueue: knbd16-recv recv_work [nbd]
RIP: 0010:nbd_read_stat.cold+0x130/0x1a4 [nbd]
Call Trace:
recv_work+0x3b/0xb0 [nbd]
process_one_work+0x1ed/0x390
worker_thread+0x4a/0x3d0
kthread+0x12a/0x150
ret_from_fork+0x22/0x30
Fixing it by checking the return value of try_module_get()
in nbd_alloc_config(). As nbd_alloc_config() may return ERR_PTR(-ENODEV),
assign nbd->config only when nbd_alloc_config() succeeds to ensure
the value of nbd->config is binary (valid or NULL).
Also adding a debug message to check the reference counter
of nbd_config during module removal. |
["https://git.kernel.org/stable/c/122e4adaff2439f1cc18cc7e931980fa7560df5c","https://git.kernel.org/stable/c/165cf2e0019fa6cedc75b456490c41494c34abb4","https://git.kernel.org/stable/c/2573f2375b64280be977431701ed5d33b75b9ad0","https://git.kernel.org/stable/c/2888fa41985f93ed0a6837cfbb06bcbfd7fa2314","https://git.kernel.org/stable/c/71c142f910da44421213ade601bcbd23ceae19fa","https://git.kernel.org/stable/c/8a7da4ced236ce6637fe70f14ca18e718d4bf9e9","https://git.kernel.org/stable/c/c55b2b983b0fa012942c3eb16384b2b722caa810","https://git.kernel.org/stable/c/d09525720dd5201756f698bee1076de9aefd4602"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49344
|
Medium |
fixed |
- 3.3
- 3.5
- 3.11
- 3.13
- 3.15
- 3.19
- 4.2
- 4.3
- 4.19.247
- 5.4.198
- 5.10.122
- 5.15.47
- 5.17.15
- 5.18.4
|
In the Linux kernel, the following vulnerability has been resolved:
af_unix: Fix a data-race in unix_dgram_peer_wake_me().
unix_dgram_poll() calls unix_dgram_peer_wake_me() without `other`'s
lock held and check if its receive queue is full. Here we need to
use unix_recvq_full_lockless() instead of unix_recvq_full(), otherwise
KCSAN will report a data-race. |
["https://git.kernel.org/stable/c/556720013c36c193d9cbfb06e7b33e51f0c39fbf","https://git.kernel.org/stable/c/662a80946ce13633ae90a55379f1346c10f0c432","https://git.kernel.org/stable/c/71e8bfc7f838cabc60cba24e09ca84c4f8321ab2","https://git.kernel.org/stable/c/8801eb3ccd2e4e3b1a01449383e3321ae6dbd9d6","https://git.kernel.org/stable/c/95f0ba806277733bf6024e23e27e1be773701cca","https://git.kernel.org/stable/c/c61848500a3fd6867dfa4834b8c7f97133eceb9f","https://git.kernel.org/stable/c/c926ae58f24f7bd55aa2ea4add9f952032507913"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49571
|
Medium |
fixed |
- 4.19.254
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix data-races around sysctl_tcp_max_reordering.
While reading sysctl_tcp_max_reordering, it can be changed
concurrently. Thus, we need to add READ_ONCE() to its readers. |
["https://git.kernel.org/stable/c/064852663308c801861bd54789d81421fa4c2928","https://git.kernel.org/stable/c/46deb91ac8a790286ad6d24cf92e7ab0ab2582bb","https://git.kernel.org/stable/c/50a1d3d097503a90cf84ebe120afcde37e9c33b3","https://git.kernel.org/stable/c/5e38cee24f19d19280c68f1ac8bf6790d607f60a","https://git.kernel.org/stable/c/a11e5b3e7a59fde1a90b0eaeaa82320495cf8cae","https://git.kernel.org/stable/c/ce3731c61589ed73364a5b55ce34131762ef9b60"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49573
|
Medium |
fixed |
- 4.19.254
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix a data-race around sysctl_tcp_early_retrans.
While reading sysctl_tcp_early_retrans, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its reader. |
["https://git.kernel.org/stable/c/11e8b013d16e5db63f8f76acceb5b86964098aaa","https://git.kernel.org/stable/c/488d3ad98ef7cddce7054193dbae6b4349c6807d","https://git.kernel.org/stable/c/5037ca9e4b169cc9aed0174d658c3d81fdaf8ea5","https://git.kernel.org/stable/c/52e65865deb6a36718a463030500f16530eaab74","https://git.kernel.org/stable/c/83767fe800a311370330d4ec83aa76093b744a80","https://git.kernel.org/stable/c/d5975f6376ce90c2c483ae36bf88c9cface4c13b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49574
|
Medium |
fixed |
- 4.19.254
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix data-races around sysctl_tcp_recovery.
While reading sysctl_tcp_recovery, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its readers. |
["https://git.kernel.org/stable/c/52ee7f5c4811ce6be1becd14d38ba1f8a8a0df81","https://git.kernel.org/stable/c/92c35113c63306091df9211375eebd0abd8c2160","https://git.kernel.org/stable/c/a31e2d0cb5cfa2aae3144cac04f25031d5d20fb4","https://git.kernel.org/stable/c/c7a492db1f7c37c758a66915908677bd8bc5d368","https://git.kernel.org/stable/c/d8781f7cd04091744f474a2bada74772084b9dc9","https://git.kernel.org/stable/c/e7d2ef837e14a971a05f60ea08c47f3fed1a36e4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49575
|
Medium |
fixed |
- 4.19.254
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix a data-race around sysctl_tcp_thin_linear_timeouts.
While reading sysctl_tcp_thin_linear_timeouts, it can be changed
concurrently. Thus, we need to add READ_ONCE() to its reader. |
["https://git.kernel.org/stable/c/404c53ccdebd11f96954f4070cffac8e0b4d5cb6","https://git.kernel.org/stable/c/492f3713b282c0e67e951cd804edd22eccc25412","https://git.kernel.org/stable/c/7c6f2a86ca590d5187a073d987e9599985fb1c7c","https://git.kernel.org/stable/c/a0f96c4f179cb3560078cefccef105e8f1701210","https://git.kernel.org/stable/c/cc133e4f4bc225079198192623945bb872c08143","https://git.kernel.org/stable/c/f4b0295be9a3c4260de4585fac4062e602a88ac7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49586
|
Medium |
fixed |
- 4.19.254
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix data-races around sysctl_tcp_fastopen.
While reading sysctl_tcp_fastopen, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its readers. |
["https://git.kernel.org/stable/c/03da610696a32578fc4f986479341ce9d430df08","https://git.kernel.org/stable/c/22938534c611136f35e2ca545bb668073ca5ef49","https://git.kernel.org/stable/c/25d53d858a6c0b89a6e69e376c2a57c4f4c2c8cc","https://git.kernel.org/stable/c/448ab998947996a0a451f8229f19087964cf2670","https://git.kernel.org/stable/c/539d9ab79eba3974b479cad61a8688c41fe62e12","https://git.kernel.org/stable/c/5a54213318c43f4009ae158347aa6016e3b9b55a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49587
|
Medium |
fixed |
- 4.9.325
- 4.14.290
- 4.19.254
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix a data-race around sysctl_tcp_notsent_lowat.
While reading sysctl_tcp_notsent_lowat, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its reader. |
["https://git.kernel.org/stable/c/0f75343584ee474303e17efe0610bdd170af1d13","https://git.kernel.org/stable/c/55be873695ed8912eb77ff46d1d1cadf028bd0f3","https://git.kernel.org/stable/c/62e56cfeb2ae4b53ae9ca24c80f54093250ce64a","https://git.kernel.org/stable/c/80d4d0c461674eea87f0977e12a2ecd334b9b79c","https://git.kernel.org/stable/c/91e21df688f8a75255ca9c459da39ac96300113a","https://git.kernel.org/stable/c/c1b85c5a34294f7444c13bf828e0e84b0a0eed85","https://git.kernel.org/stable/c/e9362a993886613ef0284c2a4911c6017c97d803","https://git.kernel.org/stable/c/fd6f1284e380c377932186042ff0b5c987fb2b92"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49593
|
Medium |
fixed |
- 4.14.290
- 4.19.254
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix a data-race around sysctl_tcp_probe_interval.
While reading sysctl_tcp_probe_interval, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its reader. |
["https://git.kernel.org/stable/c/2a85388f1d94a9f8b5a529118a2c5eaa0520d85c","https://git.kernel.org/stable/c/73a11588751a2c13f25d9da8117efc9a79b1843f","https://git.kernel.org/stable/c/80dabd089086e6553b7acfcff2ec223bdada87a1","https://git.kernel.org/stable/c/b14cc8afbbcbc6dce4797913c0b85266b897f541","https://git.kernel.org/stable/c/b3798d3519eda9c409bb0815b0102f27ec42468d","https://git.kernel.org/stable/c/c61aede097d350d890fa1edc9521b0072e14a0b8","https://git.kernel.org/stable/c/e6b6f027e2854a51f345a5e3e808d7a88001d4f8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49598
|
Medium |
fixed |
- 4.19.254
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix data-races around sysctl_tcp_mtu_probing.
While reading sysctl_tcp_mtu_probing, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its readers. |
["https://git.kernel.org/stable/c/77a04845f0d28a3561494a5f3121488470a968a4","https://git.kernel.org/stable/c/7e8fc428a7f680f1c4994a40e52d7f95a9a93038","https://git.kernel.org/stable/c/aabe9438fdfe004e021d5a206227ec105dbe2416","https://git.kernel.org/stable/c/b0920ca09d9ce19980c8391b9002455baa9c1417","https://git.kernel.org/stable/c/f47d00e077e7d61baf69e46dde3210c886360207","https://git.kernel.org/stable/c/f966773e13cdd3f12baa90071b7b660f6c633ccb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49601
|
Medium |
fixed |
- 4.9.325
- 4.14.290
- 4.19.254
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
tcp/dccp: Fix a data-race around sysctl_tcp_fwmark_accept.
While reading sysctl_tcp_fwmark_accept, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its reader. |
["https://git.kernel.org/stable/c/13207f9485b5de68decf296ceb0046f5eabb2485","https://git.kernel.org/stable/c/1a0008f9df59451d0a17806c1ee1a19857032fa8","https://git.kernel.org/stable/c/45fc82706a97242539d6b841ddd7a077ec20757b","https://git.kernel.org/stable/c/526d8cf8824f613c72dba2155542295e70135f62","https://git.kernel.org/stable/c/a7386602a2fe2f6192477e8ede291a815da09d81","https://git.kernel.org/stable/c/abf70de2ec026ae8d7da4e79bec61888a880e00b","https://git.kernel.org/stable/c/bf3134feffe61b7a0e21f60a04743f8da0958b53","https://git.kernel.org/stable/c/d4f65615db7fca3df9f7e79eadf937e6ddb03c54"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49602
|
Medium |
fixed |
- 4.9.325
- 4.14.290
- 4.19.254
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
ip: Fix a data-race around sysctl_fwmark_reflect.
While reading sysctl_fwmark_reflect, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its reader. |
["https://git.kernel.org/stable/c/0ee76fe01ff3c0b4efaa500aecc90d7c8d3a8860","https://git.kernel.org/stable/c/25a635a67c830766110410fea88ec4e6ee29684b","https://git.kernel.org/stable/c/5e7a1be3e68deef250ad43cc91f7bb8d7d758b48","https://git.kernel.org/stable/c/85d0b4dbd74b95cc492b1f4e34497d3f894f5d9a","https://git.kernel.org/stable/c/9096edcf4854289f92252e086cf6e498c7f8c21d","https://git.kernel.org/stable/c/a475ecc9ad919aa3ebdd4e4a6ee612b793bf74b3","https://git.kernel.org/stable/c/dccf8a67f30e18980d13f07006e5a536bbd1e136","https://git.kernel.org/stable/c/fc92e3b4bebfdd986ef1d2c5019f236837b0b982"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49604
|
Medium |
fixed |
- 4.19.254
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
ip: Fix data-races around sysctl_ip_fwd_use_pmtu.
While reading sysctl_ip_fwd_use_pmtu, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its readers. |
["https://git.kernel.org/stable/c/60c158dc7b1f0558f6cadd5b50d0386da0000d50","https://git.kernel.org/stable/c/7828309df0f89419a9349761a37c7d1b0da45697","https://git.kernel.org/stable/c/93fbc06da1d819f3981a7bd7928c3641ea67b364","https://git.kernel.org/stable/c/b96ed5ccb09ae71103023ed13acefb194f609794","https://git.kernel.org/stable/c/e364b5f6ffbfc457a997ad09a7baa16c19581edc","https://git.kernel.org/stable/c/eb15262128b793e4b1d1c4514d3e6d19c3959764"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49607
|
Medium |
fixed |
- 3.3
- 3.5
- 4.9.325
- 4.14.290
- 4.19.254
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Fix data race between perf_event_set_output() and perf_mmap_close()
Yang Jihing reported a race between perf_event_set_output() and
perf_mmap_close():
CPU1 CPU2
perf_mmap_close(e2)
if (atomic_dec_and_test(&e2->rb->mmap_count)) // 1 - > 0
detach_rest = true
ioctl(e1, IOC_SET_OUTPUT, e2)
perf_event_set_output(e1, e2)
...
list_for_each_entry_rcu(e, &e2->rb->event_list, rb_entry)
ring_buffer_attach(e, NULL);
// e1 isn't yet added and
// therefore not detached
ring_buffer_attach(e1, e2->rb)
list_add_rcu(&e1->rb_entry,
&e2->rb->event_list)
After this; e1 is attached to an unmapped rb and a subsequent
perf_mmap() will loop forever more:
again:
mutex_lock(&e->mmap_mutex);
if (event->rb) {
...
if (!atomic_inc_not_zero(&e->rb->mmap_count)) {
...
mutex_unlock(&e->mmap_mutex);
goto again;
}
}
The loop in perf_mmap_close() holds e2->mmap_mutex, while the attach
in perf_event_set_output() holds e1->mmap_mutex. As such there is no
serialization to avoid this race.
Change perf_event_set_output() to take both e1->mmap_mutex and
e2->mmap_mutex to alleviate that problem. Additionally, have the loop
in perf_mmap() detach the rb directly, this avoids having to wait for
the concurrent perf_mmap_close() to get around to doing it to make
progress. |
["https://git.kernel.org/stable/c/17f5417194136517ee9bbd6511249e5310e5617c","https://git.kernel.org/stable/c/3bbd868099287ff9027db59029b502fcfa2202a0","https://git.kernel.org/stable/c/43128b3eee337824158f34da6648163d2f2fb937","https://git.kernel.org/stable/c/68e3c69803dada336893640110cb87221bb01dcf","https://git.kernel.org/stable/c/98c3c8fd0d4c560e0f8335b79c407bbf7fc9462c","https://git.kernel.org/stable/c/a9391ff7a7c5f113d6f2bf6621d49110950de49c","https://git.kernel.org/stable/c/da3c256e2d0ebc87c7db0c605c9692b6f1722074","https://git.kernel.org/stable/c/f836f9ac95df15f1e0af4beb0ec20021e8c91998"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49638
|
Medium |
fixed |
- 4.9.324
- 4.14.289
- 4.19.253
- 5.4.207
- 5.10.132
- 5.15.56
- 5.18.13
|
In the Linux kernel, the following vulnerability has been resolved:
icmp: Fix data-races around sysctl.
While reading icmp sysctl variables, they can be changed concurrently.
So, we need to add READ_ONCE() to avoid data-races. |
["https://git.kernel.org/stable/c/0cba7ca667ceb06934746ddd9833a25847bde81d","https://git.kernel.org/stable/c/1740e5922fbb705637ae9fa5203db132fc45f9f6","https://git.kernel.org/stable/c/48d7ee321ea5182c6a70782aa186422a70e67e22","https://git.kernel.org/stable/c/53ecd09ef2fb35fa69667ae8e414ef6b00fd3bf6","https://git.kernel.org/stable/c/798c2cf57c63ab39c8aac24d6a3d50f4fa5eeb06","https://git.kernel.org/stable/c/e088ceb73c24ab4774da391d54a6426f4bfaefce","https://git.kernel.org/stable/c/e2828e8c605853f71267825c9415437c0a93e4f2","https://git.kernel.org/stable/c/edeec63b13c252193d626c2a48d7a2f0e7016dc2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49639
|
Medium |
fixed |
- 4.9.324
- 4.14.289
- 4.19.253
- 5.4.207
- 5.10.132
- 5.15.56
- 5.18.13
|
In the Linux kernel, the following vulnerability has been resolved:
cipso: Fix data-races around sysctl.
While reading cipso sysctl variables, they can be changed concurrently.
So, we need to add READ_ONCE() to avoid data-races. |
["https://git.kernel.org/stable/c/07b0caf8aeb9b82e6ecc6c292a3e47c7fcdb1148","https://git.kernel.org/stable/c/0e41a0f73ccb9be112a80bde3804a771633caaef","https://git.kernel.org/stable/c/2764f82bbc158d106693ae3ced3675cf4b963b35","https://git.kernel.org/stable/c/59e26906b89cc35bb54476498772b45cbc32323f","https://git.kernel.org/stable/c/c321e99d2725d11f7e6a4ebd9ce752259f0bae81","https://git.kernel.org/stable/c/ca26ca5e2f3eeb3e6fe699cd6effa3b4b2aa8698","https://git.kernel.org/stable/c/dd44f04b9214adb68ef5684ae87a81ba03632250","https://git.kernel.org/stable/c/fe2a35fa2c4f9c8ce5ef970eb927031387f9446a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49596
|
Medium |
fixed |
- 3.17
- 4.5
- 4.10
- 4.15
- 4.20
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix data-races around sysctl_tcp_min_snd_mss.
While reading sysctl_tcp_min_snd_mss, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its readers. |
["https://git.kernel.org/stable/c/0d8a39feb58910a7f7746b1770ee5578cc551fe6","https://git.kernel.org/stable/c/0fc9357282df055e30990b29f4b7afa53ab42cdb","https://git.kernel.org/stable/c/78eb166cdefcc3221c8c7c1e2d514e91a2eb5014","https://git.kernel.org/stable/c/97992e8feff33b3ae154a113ec398546bbacda80","https://git.kernel.org/stable/c/fdb96b69f5909ffcdd6f1e0902219fc6d7689ff7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49597
|
Medium |
fixed |
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix data-races around sysctl_tcp_base_mss.
While reading sysctl_tcp_base_mss, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its readers. |
["https://git.kernel.org/stable/c/30b73edc1d2459ba2c71cb58fbf84a1a6e640fbf","https://git.kernel.org/stable/c/4d7dea651b7fe0322be95054f64e3711afccc543","https://git.kernel.org/stable/c/514d2254c7b8aa2d257f5ffc79f0d96be2d6bfda","https://git.kernel.org/stable/c/88d78bc097cd8ebc6541e93316c9d9bf651b13e8","https://git.kernel.org/stable/c/9ca18116bc16ec31b9a3ce28ea1350badfa36128"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49631
|
Medium |
fixed |
- 5.4.207
- 5.10.132
- 5.15.56
- 5.18.13
|
In the Linux kernel, the following vulnerability has been resolved:
raw: Fix a data-race around sysctl_raw_l3mdev_accept.
While reading sysctl_raw_l3mdev_accept, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its reader. |
["https://git.kernel.org/stable/c/038a87b3e460d2ee579c8b1bd3890d816d6687b1","https://git.kernel.org/stable/c/1dace014928e6e385363032d359a04dee9158af0","https://git.kernel.org/stable/c/46e9c46203fd4676720ddca0fef7eff26826648e","https://git.kernel.org/stable/c/ab5adca2e17d6595f3fc0e25ccb6bcbe2e01ca4f","https://git.kernel.org/stable/c/cc9540ba5b3652c473af7e54892a48cdced87983"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49637
|
Medium |
fixed |
- 5.4.207
- 5.10.132
- 5.15.56
- 5.18.13
|
In the Linux kernel, the following vulnerability has been resolved:
ipv4: Fix a data-race around sysctl_fib_sync_mem.
While reading sysctl_fib_sync_mem, it can be changed concurrently.
So, we need to add READ_ONCE() to avoid a data-race. |
["https://git.kernel.org/stable/c/190cd4ff128373271e065afb20f1d2247b3f10c3","https://git.kernel.org/stable/c/418b191d5f223a8cb6cab09eae1f72c04ba6adf2","https://git.kernel.org/stable/c/73318c4b7dbd0e781aaababff17376b2894745c0","https://git.kernel.org/stable/c/7c1acd98fb221dc0d847451b9ab86319f8b9916c","https://git.kernel.org/stable/c/9be8aac91960ea32fd0e874758c9afee665c57d2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49733
|
Medium |
fixed |
- 5.4.215
- 5.10.148
- 5.15.68
- 5.19.9
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: oss: Fix race at SNDCTL_DSP_SYNC
There is a small race window at snd_pcm_oss_sync() that is called from
OSS PCM SNDCTL_DSP_SYNC ioctl; namely the function calls
snd_pcm_oss_make_ready() at first, then takes the params_lock mutex
for the rest. When the stream is set up again by another thread
between them, it leads to inconsistency, and may result in unexpected
results such as NULL dereference of OSS buffer as a fuzzer spotted
recently.
The fix is simply to cover snd_pcm_oss_make_ready() call into the same
params_lock mutex with snd_pcm_oss_make_ready_locked() variant. |
["https://git.kernel.org/stable/c/4051324a6dafd7053c74c475e80b3ba10ae672b0","https://git.kernel.org/stable/c/723ac5ab2891b6c10dd6cc78ef5456af593490eb","https://git.kernel.org/stable/c/8015ef9e8a0ee5cecfd0cb6805834d007ab26f86","https://git.kernel.org/stable/c/8423f0b6d513b259fdab9c9bf4aaa6188d054c2d","https://git.kernel.org/stable/c/fce793a056c604b41a298317cf704dae255f1b36"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49579
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ipv4: Fix data-races around sysctl_fib_multipath_hash_policy.
While reading sysctl_fib_multipath_hash_policy, it can be changed
concurrently. Thus, we need to add READ_ONCE() to its readers. |
["https://git.kernel.org/stable/c/21fb844bc1dc1461f5038d655aa1a14f39e13049","https://git.kernel.org/stable/c/7998c12a08c97cc26660532c9f90a34bd7d8da5a","https://git.kernel.org/stable/c/918ee6592ab9a2ff5316d06cfd4aaef60ccabec6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49630
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix a data-race around sysctl_tcp_ecn_fallback.
While reading sysctl_tcp_ecn_fallback, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its reader. |
["https://git.kernel.org/stable/c/12b8d9ca7e678abc48195294494f1815b555d658","https://git.kernel.org/stable/c/1ec3d6c2626ee6e1b36b7bd006873a271406ba61","https://git.kernel.org/stable/c/8bcf7339f2cf70ea4461df6ea045d1aadfabfa11"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49632
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
icmp: Fix a data-race around sysctl_icmp_errors_use_inbound_ifaddr.
While reading sysctl_icmp_errors_use_inbound_ifaddr, it can be changed
concurrently. Thus, we need to add READ_ONCE() to its reader. |
["https://git.kernel.org/stable/c/d2efabce81db7eed1c98fa1a3f203f0edd738ac3","https://git.kernel.org/stable/c/de9490c32bc10020efdd1509689a28f197d6dfb8","https://git.kernel.org/stable/c/f9617844e4d5d6331dbce3fb19a24e5bda201e58"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49633
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
icmp: Fix data-races around sysctl_icmp_echo_enable_probe.
While reading sysctl_icmp_echo_enable_probe, it can be changed
concurrently. Thus, we need to add READ_ONCE() to its readers. |
["https://git.kernel.org/stable/c/05c615033174f1d19374f42285ccd8e9af13e427","https://git.kernel.org/stable/c/4a2f7083cc6cb72dade9a63699ca352fad26d1cd","https://git.kernel.org/stable/c/cce955efa0ab81f7fb72e22beed372054c86005c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49201
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: fix race between xmit and reset
There is a race between reset and the transmit paths that can lead to
ibmvnic_xmit() accessing an scrq after it has been freed in the reset
path. It can result in a crash like:
Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x00000000
Faulting instruction address: 0xc0080000016189f8
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic]
LR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280
Call Trace:
[c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (unreliable)
[c000000000c0046c] dev_hard_start_xmit+0x11c/0x280
[c000000000c9cfcc] sch_direct_xmit+0xec/0x330
[c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0
[c000000000c00ad4] __dev_queue_xmit+0x394/0x730
[c008000002db813c] __bond_start_xmit+0x254/0x450 [bonding]
[c008000002db8378] bond_start_xmit+0x40/0xc0 [bonding]
[c000000000c0046c] dev_hard_start_xmit+0x11c/0x280
[c000000000c00ca4] __dev_queue_xmit+0x564/0x730
[c000000000cf97e0] neigh_hh_output+0xd0/0x180
[c000000000cfa69c] ip_finish_output2+0x31c/0x5c0
[c000000000cfd244] __ip_queue_xmit+0x194/0x4f0
[c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0
[c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0
[c000000000d2d984] tcp_retransmit_skb+0x34/0x130
[c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0
[c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330
[c000000000d317bc] tcp_write_timer+0x5c/0x200
[c000000000243270] call_timer_fn+0x50/0x1c0
[c000000000243704] __run_timers.part.0+0x324/0x460
[c000000000243894] run_timer_softirq+0x54/0xa0
[c000000000ea713c] __do_softirq+0x15c/0x3e0
[c000000000166258] __irq_exit_rcu+0x158/0x190
[c000000000166420] irq_exit+0x20/0x40
[c00000000002853c] timer_interrupt+0x14c/0x2b0
[c000000000009a00] decrementer_common_virt+0x210/0x220
--- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c
The immediate cause of the crash is the access of tx_scrq in the following
snippet during a reset, where the tx_scrq can be either NULL or an address
that will soon be invalid:
ibmvnic_xmit()
{
...
tx_scrq = adapter->tx_scrq[queue_num];
txq = netdev_get_tx_queue(netdev, queue_num);
ind_bufp = &tx_scrq->ind_buf;
if (test_bit(0, &adapter->resetting)) {
...
}
But beyond that, the call to ibmvnic_xmit() itself is not safe during a
reset and the reset path attempts to avoid this by stopping the queue in
ibmvnic_cleanup(). However just after the queue was stopped, an in-flight
ibmvnic_complete_tx() could have restarted the queue even as the reset is
progressing.
Since the queue was restarted we could get a call to ibmvnic_xmit() which
can then access the bad tx_scrq (or other fields).
We cannot however simply have ibmvnic_complete_tx() check the ->resetting
bit and skip starting the queue. This can race at the "back-end" of a good
reset which just restarted the queue but has not cleared the ->resetting
bit yet. If we skip restarting the queue due to ->resetting being true,
the queue would remain stopped indefinitely potentially leading to transmit
timeouts.
IOW ->resetting is too broad for this purpose. Instead use a new flag
that indicates whether or not the queues are active. Only the open/
reset paths control when the queues are active. ibmvnic_complete_tx()
and others wake up the queue only if the queue is marked active.
So we will have:
A. reset/open thread in ibmvnic_cleanup() and __ibmvnic_open()
->resetting = true
->tx_queues_active = false
disable tx queues
...
->tx_queues_active = true
start tx queues
B. Tx interrupt in ibmvnic_complete_tx():
if (->tx_queues_active)
netif_wake_subqueue();
To ensure that ->tx_queues_active and state of the queues are consistent,
we need a lock which:
- must also be taken in the interrupt path (ibmvnic_complete_tx())
- shared across the multiple
---truncated--- |
["https://git.kernel.org/stable/c/1bd58abf595b6cf1ba6dd47ec887c4c009155fc9","https://git.kernel.org/stable/c/4219196d1f662cb10a462eb9e076633a3fc31a15","https://git.kernel.org/stable/c/475f9cce98b63bc145b4efa66fa51175d4cb345f","https://git.kernel.org/stable/c/8507c6ade73cdbbbda5c3d31d67f52f2e1cf03fe"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49215
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
xsk: Fix race at socket teardown
Fix a race in the xsk socket teardown code that can lead to a NULL pointer
dereference splat. The current xsk unbind code in xsk_unbind_dev() starts by
setting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for any
NAPI processing to terminate using synchronize_net(). After that, the release
code starts to tear down the socket state and free allocated memory.
BUG: kernel NULL pointer dereference, address: 00000000000000c0
PGD 8000000932469067 P4D 8000000932469067 PUD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2
Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015
RIP: 0010:__xsk_sendmsg+0x2c/0x690
[...]
RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258
RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800
RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800
R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000
FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0
Call Trace:
<TASK>
? aa_sk_perm+0x43/0x1b0
xsk_sendmsg+0xf0/0x110
sock_sendmsg+0x65/0x70
__sys_sendto+0x113/0x190
? debug_smp_processor_id+0x17/0x20
? fpregs_assert_state_consistent+0x23/0x50
? exit_to_user_mode_prepare+0xa5/0x1d0
__x64_sys_sendto+0x29/0x30
do_syscall_64+0x3b/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
There are two problems with the current code. First, setting xs->dev to NULL
before waiting for all users to stop using the socket is not correct. The
entry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg()
are all guarded by a test that xs->state is in the state XSK_BOUND and if not,
it returns right away. But one process might have passed this test but still
have not gotten to the point in which it uses xs->dev in the code. In this
interim, a second process executing xsk_unbind_dev() might have set xs->dev to
NULL which will lead to a crash for the first process. The solution here is
just to get rid of this NULL assignment since it is not used anymore. Before
commit 42fddcc7c64b ("xsk: use state member for socket synchronization"),
xs->dev was the gatekeeper to admit processes into the data plane functions,
but it was replaced with the state variable xs->state in the aforementioned
commit.
The second problem is that synchronize_net() does not wait for any process in
xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that the
state they rely on might be cleaned up prematurely. This can happen when the
notifier gets called (at driver unload for example) as it uses xsk_unbind_dev().
Solve this by extending the RCU critical region from just the ndo_xsk_wakeup
to the whole functions mentioned above, so that both the test of xs->state ==
XSK_BOUND and the last use of any member of xs is covered by the RCU critical
section. This will guarantee that when synchronize_net() completes, there will
be no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() and
state can be cleaned up safely. Note that we need to drop the RCU lock for the
skb xmit path as it uses functions that might sleep. Due to this, we have to
retest the xs->state after we grab the mutex that protects the skb xmit code
from, among a number of things, an xsk_unbind_dev() being executed from the
notifier at the same time. |
["https://git.kernel.org/stable/c/18b1ab7aa76bde181bdb1ab19a87fa9523c32f21","https://git.kernel.org/stable/c/8a2dea162b92c322f3e42eae0c4a74b8d20aa7a9","https://git.kernel.org/stable/c/ad7219cd8751bd258b9d1e69ae0654ec00f71875","https://git.kernel.org/stable/c/d1579253ffce39986e7a6ab757ac93b2680a665f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49443
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
list: fix a data-race around ep->rdllist
ep_poll() first calls ep_events_available() with no lock held and checks
if ep->rdllist is empty by list_empty_careful(), which reads
rdllist->prev. Thus all accesses to it need some protection to avoid
store/load-tearing.
Note INIT_LIST_HEAD_RCU() already has the annotation for both prev
and next.
Commit bf3b9f6372c4 ("epoll: Add busy poll support to epoll with socket
fds.") added the first lockless ep_events_available(), and commit
c5a282e9635e ("fs/epoll: reduce the scope of wq lock in epoll_wait()")
made some ep_events_available() calls lockless and added single call under
a lock, finally commit e59d3c64cba6 ("epoll: eliminate unnecessary lock
for zero timeout") made the last ep_events_available() lockless.
BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait
write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0:
INIT_LIST_HEAD include/linux/list.h:38 [inline]
list_splice_init include/linux/list.h:492 [inline]
ep_start_scan fs/eventpoll.c:622 [inline]
ep_send_events fs/eventpoll.c:1656 [inline]
ep_poll fs/eventpoll.c:1806 [inline]
do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234
do_epoll_pwait fs/eventpoll.c:2268 [inline]
__do_sys_epoll_pwait fs/eventpoll.c:2281 [inline]
__se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275
__x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1:
list_empty_careful include/linux/list.h:329 [inline]
ep_events_available fs/eventpoll.c:381 [inline]
ep_poll fs/eventpoll.c:1797 [inline]
do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234
do_epoll_pwait fs/eventpoll.c:2268 [inline]
__do_sys_epoll_pwait fs/eventpoll.c:2281 [inline]
__se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275
__x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
value changed: 0xffff88810480c7d0 -> 0xffff888103c15098
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 |
["https://git.kernel.org/stable/c/5d5d993f16be15d124be7b8ec71b28ef7b7dc3af","https://git.kernel.org/stable/c/cb3e48f7a35033deb9455abe3932e63cb500b9eb","https://git.kernel.org/stable/c/d679ae94fdd5d3ab00c35078f5af5f37e068b03d","https://git.kernel.org/stable/c/e039c0b5985999b150594126225e1ee51df7b4c9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49578
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ip: Fix data-races around sysctl_ip_prot_sock.
sysctl_ip_prot_sock is accessed concurrently, and there is always a chance
of data-race. So, all readers and writers need some basic protection to
avoid load/store-tearing. |
["https://git.kernel.org/stable/c/95724fe897a4ecf2be51452ef96e818568071664","https://git.kernel.org/stable/c/9add240f76af6d141d2eebd3a1558a0e503a993d","https://git.kernel.org/stable/c/9b55c20f83369dd54541d9ddbe3a018a8377f451","https://git.kernel.org/stable/c/ef699813d99cc29e6e25c9f6da7766526cc8bd6e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49585
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix data-races around sysctl_tcp_fastopen_blackhole_timeout.
While reading sysctl_tcp_fastopen_blackhole_timeout, it can be changed
concurrently. Thus, we need to add READ_ONCE() to its readers. |
["https://git.kernel.org/stable/c/021266ec640c7a4527e6cd4b7349a512b351de1d","https://git.kernel.org/stable/c/0dc2f19d8c2636cebda7976b5ea40c6d69f0d891","https://git.kernel.org/stable/c/8afa5604e295046c02b79ccf9e2bbbf8d969d60e","https://git.kernel.org/stable/c/a77a75a0e7f397550ab039f96115103e78dd5c69"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49629
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
nexthop: Fix data-races around nexthop_compat_mode.
While reading nexthop_compat_mode, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its readers. |
["https://git.kernel.org/stable/c/0d17723afea3ae8c9f245c9bbd2ba5945b77e812","https://git.kernel.org/stable/c/a51040d4b120f3520df64fb0b9c63b31d69bea9b","https://git.kernel.org/stable/c/ae3054f6fbccc90f14ecd6cf9b2c09a2401c64fd","https://git.kernel.org/stable/c/bdf00bf24bef9be1ca641a6390fd5487873e0d2e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49634
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
sysctl: Fix data-races in proc_dou8vec_minmax().
A sysctl variable is accessed concurrently, and there is always a chance
of data-race. So, all readers and writers need some basic protection to
avoid load/store-tearing.
This patch changes proc_dou8vec_minmax() to use READ_ONCE() and
WRITE_ONCE() internally to fix data-races on the sysctl side. For now,
proc_dou8vec_minmax() itself is tolerant to a data-race, but we still
need to add annotations on the other subsystem's side. |
["https://git.kernel.org/stable/c/5f776daef0b5354615ec4b4234cd9539ca05f273","https://git.kernel.org/stable/c/7dee5d7747a69aa2be41f04c6a7ecfe3ac8cdf18","https://git.kernel.org/stable/c/e58b02e445463065b4078bf621561da75197853f","https://git.kernel.org/stable/c/f177b382c33900d0e5a9766493c11a1074076f78"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49640
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
sysctl: Fix data races in proc_douintvec_minmax().
A sysctl variable is accessed concurrently, and there is always a chance
of data-race. So, all readers and writers need some basic protection to
avoid load/store-tearing.
This patch changes proc_douintvec_minmax() to use READ_ONCE() and
WRITE_ONCE() internally to fix data-races on the sysctl side. For now,
proc_douintvec_minmax() itself is tolerant to a data-race, but we still
need to add annotations on the other subsystem's side. |
["https://git.kernel.org/stable/c/2d3b559df3ed39258737789aae2ae7973d205bc1","https://git.kernel.org/stable/c/40e0477a7371d101c55b69d9c32a7a1ed82ab5ea","https://git.kernel.org/stable/c/b60eddf98b9716651069dfda296c91311a7a6293","https://git.kernel.org/stable/c/e3a2144b3b6bf9ecafd91087c8b8b48171ec19df"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49641
|
Medium |
fixed |
- 4.5
- 5.10.132
- 5.15.56
- 5.18.13
|
In the Linux kernel, the following vulnerability has been resolved:
sysctl: Fix data races in proc_douintvec().
A sysctl variable is accessed concurrently, and there is always a chance
of data-race. So, all readers and writers need some basic protection to
avoid load/store-tearing.
This patch changes proc_douintvec() to use READ_ONCE() and WRITE_ONCE()
internally to fix data-races on the sysctl side. For now, proc_douintvec()
itself is tolerant to a data-race, but we still need to add annotations on
the other subsystem's side. |
["https://git.kernel.org/stable/c/4762b532ec9539755aab61445d5da6e1926ccb99","https://git.kernel.org/stable/c/630c76850d554d7140232e71b5d1663e88cffb54","https://git.kernel.org/stable/c/d335db59f7fb3353f56e52371f1ee796ae9c8f09","https://git.kernel.org/stable/c/d5d54714e329f646bd7af4994fc427d88ee68936"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52926
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
IORING_OP_READ did not correctly consume the provided buffer list when
read i/o returned < 0 (except for -EAGAIN and -EIOCBQUEUED return).
This can lead to a potential use-after-free when the completion via
io_rw_done runs at separate context. |
["https://git.kernel.org/stable/c/6c27fc6a783c8a77c756dd5461b15e465020d075","https://git.kernel.org/stable/c/72060434a14caea20925e492310d6e680e3f9007","https://git.kernel.org/stable/c/a08d195b586a217d76b42062f88f375a3eedda4d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52444
|
High |
fixed |
- 4.19.306
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid dirent corruption
As Al reported in link[1]:
f2fs_rename()
...
if (old_dir != new_dir && !whiteout)
f2fs_set_link(old_inode, old_dir_entry,
old_dir_page, new_dir);
else
f2fs_put_page(old_dir_page, 0);
You want correct inumber in the ".." link. And cross-directory
rename does move the source to new parent, even if you'd been asked
to leave a whiteout in the old place.
[1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/
With below testcase, it may cause dirent corruption, due to it missed
to call f2fs_set_link() to update ".." link to new directory.
- mkdir -p dir/foo
- renameat2 -w dir/foo bar
[ASSERT] (__chk_dots_dentries:1421) --> Bad inode number[0x4] for '..', parent parent ino is [0x3]
[FSCK] other corrupted bugs [Fail] |
["https://git.kernel.org/stable/c/02160112e6d45c2610b049df6eb693d7a2e57b46","https://git.kernel.org/stable/c/2fb4867f4405aea8c0519d7d188207f232a57862","https://git.kernel.org/stable/c/53edb549565f55ccd0bdf43be3d66ce4c2d48b28","https://git.kernel.org/stable/c/5624a3c1b1ebc8991318e1cce2aa719542991024","https://git.kernel.org/stable/c/6f866885e147d33efc497f1095f35b2ee5ec7310","https://git.kernel.org/stable/c/d3c0b49aaa12a61d560528f5d605029ab57f0728","https://git.kernel.org/stable/c/f0145860c20be6bae6785c7a2249577674702ac7","https://git.kernel.org/stable/c/f100ba617d8be6c98a68f3744ef7617082975b77","https://git.kernel.org/stable/c/02160112e6d45c2610b049df6eb693d7a2e57b46","https://git.kernel.org/stable/c/2fb4867f4405aea8c0519d7d188207f232a57862","https://git.kernel.org/stable/c/53edb549565f55ccd0bdf43be3d66ce4c2d48b28","https://git.kernel.org/stable/c/5624a3c1b1ebc8991318e1cce2aa719542991024","https://git.kernel.org/stable/c/6f866885e147d33efc497f1095f35b2ee5ec7310","https://git.kernel.org/stable/c/d3c0b49aaa12a61d560528f5d605029ab57f0728","https://git.kernel.org/stable/c/f0145860c20be6bae6785c7a2249577674702ac7","https://git.kernel.org/stable/c/f100ba617d8be6c98a68f3744ef7617082975b77","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-40283
|
High |
fixed |
- 4.14.322
- 4.19.291
- 5.4.253
- 5.10.190
- 5.15.126
- 6.1.45
- 6.4.10
|
An issue was discovered in l2cap_sock_release in net/bluetooth/l2cap_sock.c in the Linux kernel before 6.4.10. There is a use-after-free because the children of an sk are mishandled. |
["http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.10","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1728137b33c00d5a2b5110ed7aafb42e7c32e4a1","https://github.com/torvalds/linux/commit/1728137b33c00d5a2b5110ed7aafb42e7c32e4a1","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20231020-0007/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492","http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.10","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1728137b33c00d5a2b5110ed7aafb42e7c32e4a1","https://github.com/torvalds/linux/commit/1728137b33c00d5a2b5110ed7aafb42e7c32e4a1","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20231020-0007/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52436
|
High |
fixed |
- 4.19.306
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.74
- 6.6.13
- 6.7.1
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: explicitly null-terminate the xattr list
When setting an xattr, explicitly null-terminate the xattr list. This
eliminates the fragile assumption that the unused xattr space is always
zeroed. |
["https://git.kernel.org/stable/c/12cf91e23b126718a96b914f949f2cdfeadc7b2a","https://git.kernel.org/stable/c/16ae3132ff7746894894927c1892493693b89135","https://git.kernel.org/stable/c/2525d1ba225b5c167162fa344013c408e8b4de36","https://git.kernel.org/stable/c/32a6cfc67675ee96fe107aeed5af9776fec63f11","https://git.kernel.org/stable/c/3e47740091b05ac8d7836a33afd8646b6863ca52","https://git.kernel.org/stable/c/5de9e9dd1828db9b8b962f7ca42548bd596deb8a","https://git.kernel.org/stable/c/e26b6d39270f5eab0087453d9b544189a38c8564","https://git.kernel.org/stable/c/f6c30bfe5a49bc38cae985083a11016800708fea","https://git.kernel.org/stable/c/12cf91e23b126718a96b914f949f2cdfeadc7b2a","https://git.kernel.org/stable/c/16ae3132ff7746894894927c1892493693b89135","https://git.kernel.org/stable/c/2525d1ba225b5c167162fa344013c408e8b4de36","https://git.kernel.org/stable/c/32a6cfc67675ee96fe107aeed5af9776fec63f11","https://git.kernel.org/stable/c/3e47740091b05ac8d7836a33afd8646b6863ca52","https://git.kernel.org/stable/c/5de9e9dd1828db9b8b962f7ca42548bd596deb8a","https://git.kernel.org/stable/c/e26b6d39270f5eab0087453d9b544189a38c8564","https://git.kernel.org/stable/c/f6c30bfe5a49bc38cae985083a11016800708fea","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52604
|
High |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree
Syzkaller reported the following issue:
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2867:6
index 196694 is out of range for type 's8[1365]' (aka 'signed char[1365]')
CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
ubsan_epilogue lib/ubsan.c:217 [inline]
__ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348
dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867
dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834
dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331
dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]
dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402
txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534
txUpdateMap+0x342/0x9e0
txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732
kthread+0x2d3/0x370 kernel/kthread.c:388
ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
</TASK>
================================================================================
Kernel panic - not syncing: UBSAN: panic_on_warn set ...
CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
panic+0x30f/0x770 kernel/panic.c:340
check_panic_on_warn+0x82/0xa0 kernel/panic.c:236
ubsan_epilogue lib/ubsan.c:223 [inline]
__ubsan_handle_out_of_bounds+0x13c/0x150 lib/ubsan.c:348
dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867
dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834
dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331
dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]
dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402
txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534
txUpdateMap+0x342/0x9e0
txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732
kthread+0x2d3/0x370 kernel/kthread.c:388
ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
</TASK>
Kernel Offset: disabled
Rebooting in 86400 seconds..
The issue is caused when the value of lp becomes greater than
CTLTREESIZE which is the max size of stree. Adding a simple check
solves this issue.
Dave:
As the function returns a void, good error handling
would require a more intrusive code reorganization, so I modified
Osama's patch at use WARN_ON_ONCE for lack of a cleaner option.
The patch is tested via syzbot. |
["https://git.kernel.org/stable/c/42f433785f108893de0dd5260bafb85d7d51db03","https://git.kernel.org/stable/c/59342822276f753e49d27ef5eebffbba990572b9","https://git.kernel.org/stable/c/6a44065dd604972ec1fbcccbdc4a70d266a89cdd","https://git.kernel.org/stable/c/6fe8b702125aeee6ce83f20092a2341446704e7b","https://git.kernel.org/stable/c/9862ec7ac1cbc6eb5ee4a045b5d5b8edbb2f7e68","https://git.kernel.org/stable/c/98f9537fe61b8382b3cc5dd97347531698517c56","https://git.kernel.org/stable/c/de34de6e57bbbc868e4fcf9e98c76b3587cabb0b","https://git.kernel.org/stable/c/e3e95c6850661c77e6dab079d9b5374a618ebb15","https://git.kernel.org/stable/c/42f433785f108893de0dd5260bafb85d7d51db03","https://git.kernel.org/stable/c/59342822276f753e49d27ef5eebffbba990572b9","https://git.kernel.org/stable/c/6a44065dd604972ec1fbcccbdc4a70d266a89cdd","https://git.kernel.org/stable/c/6fe8b702125aeee6ce83f20092a2341446704e7b","https://git.kernel.org/stable/c/9862ec7ac1cbc6eb5ee4a045b5d5b8edbb2f7e68","https://git.kernel.org/stable/c/98f9537fe61b8382b3cc5dd97347531698517c56","https://git.kernel.org/stable/c/de34de6e57bbbc868e4fcf9e98c76b3587cabb0b","https://git.kernel.org/stable/c/e3e95c6850661c77e6dab079d9b5374a618ebb15","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-22995
|
High |
fixed |
|
In the Linux kernel before 5.17, an error path in dwc3_qcom_acpi_register_core in drivers/usb/dwc3/dwc3-qcom.c lacks certain platform_device_put and kfree calls. |
["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17","https://github.com/torvalds/linux/commit/fa0ef93868a6062babe1144df2807a8b1d4924d2","https://security.netapp.com/advisory/ntap-20230331-0004/","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17","https://github.com/torvalds/linux/commit/fa0ef93868a6062babe1144df2807a8b1d4924d2","https://security.netapp.com/advisory/ntap-20230331-0004/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-34494
|
Medium |
fixed |
|
rpmsg_virtio_add_ctrl_dev in drivers/rpmsg/virtio_rpmsg_bus.c in the Linux kernel before 5.18.4 has a double free. |
["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.4","https://github.com/torvalds/linux/commit/1680939e9ecf7764fba8689cfb3429c2fe2bb23c","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.4","https://github.com/torvalds/linux/commit/1680939e9ecf7764fba8689cfb3429c2fe2bb23c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52447
|
Medium |
fixed |
- 5.10.214
- 5.15.153
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Defer the free of inner map when necessary
When updating or deleting an inner map in map array or map htab, the map
may still be accessed by non-sleepable program or sleepable program.
However bpf_map_fd_put_ptr() decreases the ref-counter of the inner map
directly through bpf_map_put(), if the ref-counter is the last one
(which is true for most cases), the inner map will be freed by
ops->map_free() in a kworker. But for now, most .map_free() callbacks
don't use synchronize_rcu() or its variants to wait for the elapse of a
RCU grace period, so after the invocation of ops->map_free completes,
the bpf program which is accessing the inner map may incur
use-after-free problem.
Fix the free of inner map by invoking bpf_map_free_deferred() after both
one RCU grace period and one tasks trace RCU grace period if the inner
map has been removed from the outer map before. The deferment is
accomplished by using call_rcu() or call_rcu_tasks_trace() when
releasing the last ref-counter of bpf map. The newly-added rcu_head
field in bpf_map shares the same storage space with work field to
reduce the size of bpf_map. |
["https://git.kernel.org/stable/c/37d98fb9c3144c0fddf7f6e99aece9927ac8dce6","https://git.kernel.org/stable/c/62fca83303d608ad4fec3f7428c8685680bb01b0","https://git.kernel.org/stable/c/876673364161da50eed6b472d746ef88242b2368","https://git.kernel.org/stable/c/90c445799fd1dc214d7c6279c144e33a35e29ef2","https://git.kernel.org/stable/c/bfd9b20c4862f41d4590fde11d70a5eeae53dcc5","https://git.kernel.org/stable/c/f91cd728b10c51f6d4a39957ccd56d1e802fc8ee","https://git.kernel.org/stable/c/37d98fb9c3144c0fddf7f6e99aece9927ac8dce6","https://git.kernel.org/stable/c/62fca83303d608ad4fec3f7428c8685680bb01b0","https://git.kernel.org/stable/c/876673364161da50eed6b472d746ef88242b2368","https://git.kernel.org/stable/c/90c445799fd1dc214d7c6279c144e33a35e29ef2","https://git.kernel.org/stable/c/bfd9b20c4862f41d4590fde11d70a5eeae53dcc5","https://git.kernel.org/stable/c/f91cd728b10c51f6d4a39957ccd56d1e802fc8ee","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48852
|
Low |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: hdmi: Unregister codec device on unbind
On bind we will register the HDMI codec device but we don't unregister
it on unbind, leading to a device leakage. Unregister our device at
unbind. |
["https://git.kernel.org/stable/c/1ed68d776246f167aee9cd79f63f089c40a5e2a3","https://git.kernel.org/stable/c/e40945ab7c7f966d0c37b7bd7b0596497dfe228d","https://git.kernel.org/stable/c/ee22082c3e2f230028afa0e22aa8773b1de3c919","https://git.kernel.org/stable/c/1ed68d776246f167aee9cd79f63f089c40a5e2a3","https://git.kernel.org/stable/c/e40945ab7c7f966d0c37b7bd7b0596497dfe228d","https://git.kernel.org/stable/c/ee22082c3e2f230028afa0e22aa8773b1de3c919"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-26966
|
Medium |
fixed |
|
An issue was discovered in the Linux kernel before 5.16.12. drivers/net/usb/sr9700.c allows attackers to obtain sensitive information from heap memory via crafted frame lengths from a device. |
["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.10","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e9da0b56fe27206b49f39805f7dcda8a89379062","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://security.netapp.com/advisory/ntap-20220419-0001/","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.10","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e9da0b56fe27206b49f39805f7dcda8a89379062","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://security.netapp.com/advisory/ntap-20220419-0001/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-0286
|
Medium |
|
N/A
|
A flaw was found in the Linux kernel. A null pointer dereference in bond_ipsec_add_sa() may lead to local denial of service. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=105cd17a866017b45f3c45901b394c711c97bf40","https://syzkaller.appspot.com/bug?id=160f641886d88bf11cbf1236cc4db994bb210626","https://www.oracle.com/security-alerts/cpujul2022.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=105cd17a866017b45f3c45901b394c711c97bf40","https://syzkaller.appspot.com/bug?id=160f641886d88bf11cbf1236cc4db994bb210626","https://www.oracle.com/security-alerts/cpujul2022.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-2308
|
Medium |
|
N/A
|
A flaw was found in vDPA with VDUSE backend. There are currently no checks in VDUSE kernel driver to ensure the size of the device config space is in line with the features advertised by the VDUSE userspace application. In case of a mismatch, Virtio drivers config read helpers do not initialize the memory indirectly passed to vduse_vdpa_get_config() returning uninitialized memory from the stack. This could cause undefined behavior or data leaks in Virtio drivers. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2103900","https://bugzilla.redhat.com/show_bug.cgi?id=2103900"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26898
|
High |
fixed |
- 4.19.311
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts
This patch is against CVE-2023-6270. The description of cve is:
A flaw was found in the ATA over Ethernet (AoE) driver in the Linux
kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on
`struct net_device`, and a use-after-free can be triggered by racing
between the free on the struct and the access through the `skbtxq`
global queue. This could lead to a denial of service condition or
potential code execution.
In aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb initial
code is finished. But the net_device ifp will still be used in
later tx()->dev_queue_xmit() in kthread. Which means that the
dev_put(ifp) should NOT be called in the success path of skb
initial code in aoecmd_cfg_pkts(). Otherwise tx() may run into
use-after-free because the net_device is freed.
This patch removed the dev_put(ifp) in the success path in
aoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx(). |
["https://git.kernel.org/stable/c/079cba4f4e307c69878226fdf5228c20aa1c969c","https://git.kernel.org/stable/c/1a54aa506b3b2f31496731039e49778f54eee881","https://git.kernel.org/stable/c/74ca3ef68d2f449bc848c0a814cefc487bf755fa","https://git.kernel.org/stable/c/7dd09fa80b0765ce68bfae92f4e2f395ccf0fba4","https://git.kernel.org/stable/c/a16fbb80064634b254520a46395e36b87ca4731e","https://git.kernel.org/stable/c/ad80c34944d7175fa1f5c7a55066020002921a99","https://git.kernel.org/stable/c/eb48680b0255a9e8a9bdc93d6a55b11c31262e62","https://git.kernel.org/stable/c/f98364e926626c678fb4b9004b75cacf92ff0662","https://git.kernel.org/stable/c/faf0b4c5e00bb680e8e43ac936df24d3f48c8e65","https://git.kernel.org/stable/c/079cba4f4e307c69878226fdf5228c20aa1c969c","https://git.kernel.org/stable/c/1a54aa506b3b2f31496731039e49778f54eee881","https://git.kernel.org/stable/c/74ca3ef68d2f449bc848c0a814cefc487bf755fa","https://git.kernel.org/stable/c/7dd09fa80b0765ce68bfae92f4e2f395ccf0fba4","https://git.kernel.org/stable/c/a16fbb80064634b254520a46395e36b87ca4731e","https://git.kernel.org/stable/c/ad80c34944d7175fa1f5c7a55066020002921a99","https://git.kernel.org/stable/c/eb48680b0255a9e8a9bdc93d6a55b11c31262e62","https://git.kernel.org/stable/c/f98364e926626c678fb4b9004b75cacf92ff0662","https://git.kernel.org/stable/c/faf0b4c5e00bb680e8e43ac936df24d3f48c8e65","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-33203
|
Medium |
fixed |
|
The Linux kernel before 6.2.9 has a race condition and resultant use-after-free in drivers/net/ethernet/qualcomm/emac/emac.c if a physically proximate attacker unplugs an emac based device. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2192667","https://bugzilla.suse.com/show_bug.cgi?id=1210685","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.9","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6b6bc5b8bd2d4ca9e1efa9ae0f98a0b0687ace75","https://bugzilla.redhat.com/show_bug.cgi?id=2192667","https://bugzilla.suse.com/show_bug.cgi?id=1210685","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.9","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6b6bc5b8bd2d4ca9e1efa9ae0f98a0b0687ace75"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-44032
|
Medium |
|
N/A
|
An issue was discovered in the Linux kernel through 6.0.6. drivers/char/pcmcia/cm4000_cs.c has a race condition and resultant use-after-free if a physically proximate attacker removes a PCMCIA device while calling open(), aka a race condition between cmm_open() and cm4000_detach(). |
["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15","https://lore.kernel.org/lkml/20220915020834.GA110086%40ubuntu/","https://lore.kernel.org/lkml/20220919040701.GA302806%40ubuntu/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15","https://lore.kernel.org/lkml/20220915020834.GA110086%40ubuntu/","https://lore.kernel.org/lkml/20220919040701.GA302806%40ubuntu/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-44033
|
Medium |
|
N/A
|
An issue was discovered in the Linux kernel through 6.0.6. drivers/char/pcmcia/cm4040_cs.c has a race condition and resultant use-after-free if a physically proximate attacker removes a PCMCIA device while calling open(), aka a race condition between cm4040_open() and reader_detach(). |
["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15","https://lore.kernel.org/lkml/20220915020834.GA110086%40ubuntu/","https://lore.kernel.org/lkml/20220919040457.GA302681%40ubuntu/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15","https://lore.kernel.org/lkml/20220915020834.GA110086%40ubuntu/","https://lore.kernel.org/lkml/20220919040457.GA302681%40ubuntu/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-44034
|
Medium |
|
N/A
|
An issue was discovered in the Linux kernel through 6.0.6. drivers/char/pcmcia/scr24x_cs.c has a race condition and resultant use-after-free if a physically proximate attacker removes a PCMCIA device while calling open(), aka a race condition between scr24x_open() and scr24x_remove(). |
["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15","https://lore.kernel.org/lkml/20220916050333.GA188358%40ubuntu/","https://lore.kernel.org/lkml/20220919101825.GA313940%40ubuntu/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15","https://lore.kernel.org/lkml/20220916050333.GA188358%40ubuntu/","https://lore.kernel.org/lkml/20220919101825.GA313940%40ubuntu/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-22018
|
Medium |
fixed |
- 5.4.292
- 5.10.236
- 5.15.180
- 6.1.133
- 6.6.86
- 6.12.22
- 6.13.10
- 6.14.1
|
In the Linux kernel, the following vulnerability has been resolved:
atm: Fix NULL pointer dereference
When MPOA_cache_impos_rcvd() receives the msg, it can trigger
Null Pointer Dereference Vulnerability if both entry and
holding_time are NULL. Because there is only for the situation
where entry is NULL and holding_time exists, it can be passed
when both entry and holding_time are NULL. If these are NULL,
the entry will be passd to eg_cache_put() as parameter and
it is referenced by entry->use code in it.
kasan log:
[ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I
[ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
[ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102
[ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[ 3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470
[ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80
[ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006
[ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e
[ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030
[ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88
[ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15
[ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068
[ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000
[ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0
[ 3.326430] Call Trace:
[ 3.326725] <TASK>
[ 3.326927] ? die_addr+0x3c/0xa0
[ 3.327330] ? exc_general_protection+0x161/0x2a0
[ 3.327662] ? asm_exc_general_protection+0x26/0x30
[ 3.328214] ? vprintk_emit+0x15e/0x420
[ 3.328543] ? eg_cache_remove_entry+0xa5/0x470
[ 3.328910] ? eg_cache_remove_entry+0x9a/0x470
[ 3.329294] ? __pfx_eg_cache_remove_entry+0x10/0x10
[ 3.329664] ? console_unlock+0x107/0x1d0
[ 3.329946] ? __pfx_console_unlock+0x10/0x10
[ 3.330283] ? do_syscall_64+0xa6/0x1a0
[ 3.330584] ? entry_SYSCALL_64_after_hwframe+0x47/0x7f
[ 3.331090] ? __pfx_prb_read_valid+0x10/0x10
[ 3.331395] ? down_trylock+0x52/0x80
[ 3.331703] ? vprintk_emit+0x15e/0x420
[ 3.331986] ? __pfx_vprintk_emit+0x10/0x10
[ 3.332279] ? down_trylock+0x52/0x80
[ 3.332527] ? _printk+0xbf/0x100
[ 3.332762] ? __pfx__printk+0x10/0x10
[ 3.333007] ? _raw_write_lock_irq+0x81/0xe0
[ 3.333284] ? __pfx__raw_write_lock_irq+0x10/0x10
[ 3.333614] msg_from_mpoad+0x1185/0x2750
[ 3.333893] ? __build_skb_around+0x27b/0x3a0
[ 3.334183] ? __pfx_msg_from_mpoad+0x10/0x10
[ 3.334501] ? __alloc_skb+0x1c0/0x310
[ 3.334809] ? __pfx___alloc_skb+0x10/0x10
[ 3.335283] ? _raw_spin_lock+0xe0/0xe0
[ 3.335632] ? finish_wait+0x8d/0x1e0
[ 3.335975] vcc_sendmsg+0x684/0xba0
[ 3.336250] ? __pfx_vcc_sendmsg+0x10/0x10
[ 3.336587] ? __pfx_autoremove_wake_function+0x10/0x10
[ 3.337056] ? fdget+0x176/0x3e0
[ 3.337348] __sys_sendto+0x4a2/0x510
[ 3.337663] ? __pfx___sys_sendto+0x10/0x10
[ 3.337969] ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400
[ 3.338364] ? sock_ioctl+0x1bb/0x5a0
[ 3.338653] ? __rseq_handle_notify_resume+0x825/0xd20
[ 3.339017] ? __pfx_sock_ioctl+0x10/0x10
[ 3.339316] ? __pfx___rseq_handle_notify_resume+0x10/0x10
[ 3.339727] ? selinux_file_ioctl+0xa4/0x260
[ 3.340166] __x64_sys_sendto+0xe0/0x1c0
[ 3.340526] ? syscall_exit_to_user_mode+0x123/0x140
[ 3.340898] do_syscall_64+0xa6/0x1a0
[ 3.341170] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 3.341533] RIP: 0033:0x44a380
[ 3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00
[
---truncated--- |
["https://git.kernel.org/stable/c/09691f367df44fe93255274d80a439f9bb3263fc","https://git.kernel.org/stable/c/0ef6e49881b6b50ac454cb9d6501d009fdceb6fc","https://git.kernel.org/stable/c/14c7aca5ba2740973de27c1bb8df77b4dcb6f775","https://git.kernel.org/stable/c/1505f9b720656b17865e4166ab002960162bf679","https://git.kernel.org/stable/c/3c23bb2c894e9ef2727682f98c341b20f78c9013","https://git.kernel.org/stable/c/9da6b6340dbcf0f60ae3ec6a7d6438337c32518a","https://git.kernel.org/stable/c/ab92f51c7f53a08f1a686bfb80690ebb3672357d","https://git.kernel.org/stable/c/bf2986fcf82a449441f9ee4335df19be19e83970","https://git.kernel.org/stable/c/d7f1e4a53a51cc6ba833afcb40439f18dab61c1f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3104
|
Medium |
fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. lkdtm_ARRAY_BOUNDS in drivers/misc/lkdtm/bugs.c lacks check of the return value of kmalloc() and will cause the null pointer dereference. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2153062","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=4a9800c81d2f34afb66b4b42e0330ae8298019a2","https://bugzilla.redhat.com/show_bug.cgi?id=2153062","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=4a9800c81d2f34afb66b4b42e0330ae8298019a2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3105
|
Medium |
fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. uapi_finalize in drivers/infiniband/core/uverbs_uapi.c lacks check of kmalloc_array(). |
["https://bugzilla.redhat.com/show_bug.cgi?id=2153067","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=7694a7de22c53a312ea98960fcafc6ec62046531","https://bugzilla.redhat.com/show_bug.cgi?id=2153067","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=7694a7de22c53a312ea98960fcafc6ec62046531"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3106
|
Medium |
fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. ef100_update_stats in drivers/net/ethernet/sfc/ef100_nic.c lacks check of the return value of kmalloc(). |
["https://bugzilla.redhat.com/show_bug.cgi?id=2153066","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=407ecd1bd726f240123f704620d46e285ff30dd9","https://bugzilla.redhat.com/show_bug.cgi?id=2153066","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=407ecd1bd726f240123f704620d46e285ff30dd9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3112
|
Medium |
fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. amvdec_set_canvases in drivers/staging/media/meson/vdec/vdec_helpers.c lacks check of the return value of kzalloc() and will cause the null pointer dereference. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2153068","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=c8c80c996182239ff9b05eda4db50184cf3b2e99","https://bugzilla.redhat.com/show_bug.cgi?id=2153068","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=c8c80c996182239ff9b05eda4db50184cf3b2e99"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3115
|
Medium |
fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. malidp_crtc_reset in drivers/gpu/drm/arm/malidp_crtc.c lacks check of the return value of kzalloc() and will cause the null pointer dereference. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2153058","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=73c3ed7495c67b8fbdc31cf58e6ca8757df31a33","https://bugzilla.redhat.com/show_bug.cgi?id=2153058","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=73c3ed7495c67b8fbdc31cf58e6ca8757df31a33"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52470
|
Medium |
fixed |
- 4.19.306
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: check the alloc_workqueue return value in radeon_crtc_init()
check the alloc_workqueue return value in radeon_crtc_init()
to avoid null-ptr-deref. |
["https://git.kernel.org/stable/c/0b813a6a0087451cb702b6eb841f10856f49d088","https://git.kernel.org/stable/c/14bbfaa5df273b26cde6707f6e655585700e6fe1","https://git.kernel.org/stable/c/21b1645660717d6126dd4866c850fcc5c4703a41","https://git.kernel.org/stable/c/57ca7984806d79b38af528de88fd803babf27feb","https://git.kernel.org/stable/c/5d12c5d75f7c78b83a738025947651ec5c95b4d4","https://git.kernel.org/stable/c/7a2464fac80d42f6f8819fed97a553e9c2f43310","https://git.kernel.org/stable/c/c4ff55408187f2595066967047363ca84e76db85","https://git.kernel.org/stable/c/fb2d8bc9b5e55848b8a7c3c028e2ee8d49f28f97","https://git.kernel.org/stable/c/0b813a6a0087451cb702b6eb841f10856f49d088","https://git.kernel.org/stable/c/14bbfaa5df273b26cde6707f6e655585700e6fe1","https://git.kernel.org/stable/c/21b1645660717d6126dd4866c850fcc5c4703a41","https://git.kernel.org/stable/c/57ca7984806d79b38af528de88fd803babf27feb","https://git.kernel.org/stable/c/5d12c5d75f7c78b83a738025947651ec5c95b4d4","https://git.kernel.org/stable/c/7a2464fac80d42f6f8819fed97a553e9c2f43310","https://git.kernel.org/stable/c/c4ff55408187f2595066967047363ca84e76db85","https://git.kernel.org/stable/c/fb2d8bc9b5e55848b8a7c3c028e2ee8d49f28f97","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52606
|
Medium |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
powerpc/lib: Validate size for vector operations
Some of the fp/vmx code in sstep.c assume a certain maximum size for the
instructions being emulated. The size of those operations however is
determined separately in analyse_instr().
Add a check to validate the assumption on the maximum size of the
operations, so as to prevent any unintended kernel stack corruption. |
["https://git.kernel.org/stable/c/0580f4403ad33f379eef865c2a6fe94de37febdf","https://git.kernel.org/stable/c/28b8ba8eebf26f66d9f2df4ba550b6b3b136082c","https://git.kernel.org/stable/c/42084a428a139f1a429f597d44621e3a18f3e414","https://git.kernel.org/stable/c/848e1d7fd710900397e1d0e7584680c1c04e3afd","https://git.kernel.org/stable/c/8f9abaa6d7de0a70fc68acaedce290c1f96e2e59","https://git.kernel.org/stable/c/abd26515d4b767ba48241eea77b28ce0872aef3e","https://git.kernel.org/stable/c/beee482cc4c9a6b1dcffb2e190b4fd8782258678","https://git.kernel.org/stable/c/de4f5ed63b8a199704d8cdcbf810309d7eb4b36b","https://git.kernel.org/stable/c/0580f4403ad33f379eef865c2a6fe94de37febdf","https://git.kernel.org/stable/c/28b8ba8eebf26f66d9f2df4ba550b6b3b136082c","https://git.kernel.org/stable/c/42084a428a139f1a429f597d44621e3a18f3e414","https://git.kernel.org/stable/c/848e1d7fd710900397e1d0e7584680c1c04e3afd","https://git.kernel.org/stable/c/8f9abaa6d7de0a70fc68acaedce290c1f96e2e59","https://git.kernel.org/stable/c/abd26515d4b767ba48241eea77b28ce0872aef3e","https://git.kernel.org/stable/c/beee482cc4c9a6b1dcffb2e190b4fd8782258678","https://git.kernel.org/stable/c/de4f5ed63b8a199704d8cdcbf810309d7eb4b36b","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26663
|
Medium |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.78
- 6.6.17
- 6.7.5
|
In the Linux kernel, the following vulnerability has been resolved:
tipc: Check the bearer type before calling tipc_udp_nl_bearer_add()
syzbot reported the following general protection fault [1]:
general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087]
...
RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291
...
Call Trace:
<TASK>
tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646
tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089
genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972
genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline]
genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067
netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544
genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367
netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0xd5/0x180 net/socket.c:745
____sys_sendmsg+0x6ac/0x940 net/socket.c:2584
___sys_sendmsg+0x135/0x1d0 net/socket.c:2638
__sys_sendmsg+0x117/0x1e0 net/socket.c:2667
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
The cause of this issue is that when tipc_nl_bearer_add() is called with
the TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is called
even if the bearer is not UDP.
tipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes that
the media_ptr field of the tipc_bearer has an udp_bearer type object, so
the function goes crazy for non-UDP bearers.
This patch fixes the issue by checking the bearer type before calling
tipc_udp_nl_bearer_add() in tipc_nl_bearer_add(). |
["https://git.kernel.org/stable/c/0cd331dfd6023640c9669d0592bc0fd491205f87","https://git.kernel.org/stable/c/19d7314f2fb9515bdaac9829d4d8eb34edd1fe95","https://git.kernel.org/stable/c/24ec8f0da93b8a9fba11600be8a90f0d73fb46f1","https://git.kernel.org/stable/c/3871aa01e1a779d866fa9dfdd5a836f342f4eb87","https://git.kernel.org/stable/c/3d3a5b31b43515b5752ff282702ca546ec3e48b6","https://git.kernel.org/stable/c/6f70f0b412458c622a12d4292782c8e92e210c2f","https://git.kernel.org/stable/c/888e3524be87f3df9fa3c083484e4b62b3e3bb59","https://git.kernel.org/stable/c/c1701ea85ef0ec7be6a1b36c7da69f572ed2fd12","https://git.kernel.org/stable/c/0cd331dfd6023640c9669d0592bc0fd491205f87","https://git.kernel.org/stable/c/19d7314f2fb9515bdaac9829d4d8eb34edd1fe95","https://git.kernel.org/stable/c/24ec8f0da93b8a9fba11600be8a90f0d73fb46f1","https://git.kernel.org/stable/c/3871aa01e1a779d866fa9dfdd5a836f342f4eb87","https://git.kernel.org/stable/c/3d3a5b31b43515b5752ff282702ca546ec3e48b6","https://git.kernel.org/stable/c/6f70f0b412458c622a12d4292782c8e92e210c2f","https://git.kernel.org/stable/c/888e3524be87f3df9fa3c083484e4b62b3e3bb59","https://git.kernel.org/stable/c/c1701ea85ef0ec7be6a1b36c7da69f572ed2fd12","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26812
|
Medium |
fixed |
- 6.1.84
- 6.6.24
- 6.7.12
- 6.8.3
|
In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: Create persistent INTx handler
A vulnerability exists where the eventfd for INTx signaling can be
deconfigured, which unregisters the IRQ handler but still allows
eventfds to be signaled with a NULL context through the SET_IRQS ioctl
or through unmask irqfd if the device interrupt is pending.
Ideally this could be solved with some additional locking; the igate
mutex serializes the ioctl and config space accesses, and the interrupt
handler is unregistered relative to the trigger, but the irqfd path
runs asynchronous to those. The igate mutex cannot be acquired from the
atomic context of the eventfd wake function. Disabling the irqfd
relative to the eventfd registration is potentially incompatible with
existing userspace.
As a result, the solution implemented here moves configuration of the
INTx interrupt handler to track the lifetime of the INTx context object
and irq_type configuration, rather than registration of a particular
trigger eventfd. Synchronization is added between the ioctl path and
eventfd_signal() wrapper such that the eventfd trigger can be
dynamically updated relative to in-flight interrupts or irqfd callbacks. |
["https://git.kernel.org/stable/c/0e09cf81959d9f12b75ad5c6dd53d237432ed034","https://git.kernel.org/stable/c/18c198c96a815c962adc2b9b77909eec0be7df4d","https://git.kernel.org/stable/c/27d40bf72dd9a6600b76ad05859176ea9a1b4897","https://git.kernel.org/stable/c/4c089cefe30924fbe20dd1ee92774ea1f5eca834","https://git.kernel.org/stable/c/4cb0d7532126d23145329826c38054b4e9a05e7c","https://git.kernel.org/stable/c/69276a555c740acfbff13fb5769ee9c92e1c828e","https://git.kernel.org/stable/c/7d29d4c72c1e196cce6969c98072a272d1a703b3","https://git.kernel.org/stable/c/b18fa894d615c8527e15d96b76c7448800e13899","https://git.kernel.org/stable/c/0e09cf81959d9f12b75ad5c6dd53d237432ed034","https://git.kernel.org/stable/c/18c198c96a815c962adc2b9b77909eec0be7df4d","https://git.kernel.org/stable/c/27d40bf72dd9a6600b76ad05859176ea9a1b4897","https://git.kernel.org/stable/c/4c089cefe30924fbe20dd1ee92774ea1f5eca834","https://git.kernel.org/stable/c/4cb0d7532126d23145329826c38054b4e9a05e7c","https://git.kernel.org/stable/c/69276a555c740acfbff13fb5769ee9c92e1c828e","https://git.kernel.org/stable/c/7d29d4c72c1e196cce6969c98072a272d1a703b3","https://git.kernel.org/stable/c/b18fa894d615c8527e15d96b76c7448800e13899","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26813
|
Medium |
fixed |
- 5.4.274
- 5.10.215
- 5.15.154
- 6.1.84
- 6.6.24
- 6.7.12
- 6.8.3
|
In the Linux kernel, the following vulnerability has been resolved:
vfio/platform: Create persistent IRQ handlers
The vfio-platform SET_IRQS ioctl currently allows loopback triggering of
an interrupt before a signaling eventfd has been configured by the user,
which thereby allows a NULL pointer dereference.
Rather than register the IRQ relative to a valid trigger, register all
IRQs in a disabled state in the device open path. This allows mask
operations on the IRQ to nest within the overall enable state governed
by a valid eventfd signal. This decouples @masked, protected by the
@locked spinlock from @trigger, protected via the @igate mutex.
In doing so, it's guaranteed that changes to @trigger cannot race the
IRQ handlers because the IRQ handler is synchronously disabled before
modifying the trigger, and loopback triggering of the IRQ via ioctl is
safe due to serialization with trigger changes via igate.
For compatibility, request_irq() failures are maintained to be local to
the SET_IRQS ioctl rather than a fatal error in the open device path.
This allows, for example, a userspace driver with polling mode support
to continue to work regardless of moving the request_irq() call site.
This necessarily blocks all SET_IRQS access to the failed index. |
["https://git.kernel.org/stable/c/07afdfd8a68f9eea8db0ddc4626c874f29d2ac5e","https://git.kernel.org/stable/c/09452c8fcbd7817c06e8e3212d99b45917e603a5","https://git.kernel.org/stable/c/0f8d8f9c2173a541812dd750529f4a415117eb29","https://git.kernel.org/stable/c/62d4e43a569b67929eb3319780be5359694c8086","https://git.kernel.org/stable/c/675daf435e9f8e5a5eab140a9864dfad6668b375","https://git.kernel.org/stable/c/7932db06c82c5b2f42a4d1a849d97dba9ce4a362","https://git.kernel.org/stable/c/cc5838f19d39a5fef04c468199699d2a4578be3a","https://git.kernel.org/stable/c/d6bedd6acc0bcb1e7e010bc046032e47f08d379f","https://git.kernel.org/stable/c/07afdfd8a68f9eea8db0ddc4626c874f29d2ac5e","https://git.kernel.org/stable/c/09452c8fcbd7817c06e8e3212d99b45917e603a5","https://git.kernel.org/stable/c/0f8d8f9c2173a541812dd750529f4a415117eb29","https://git.kernel.org/stable/c/62d4e43a569b67929eb3319780be5359694c8086","https://git.kernel.org/stable/c/675daf435e9f8e5a5eab140a9864dfad6668b375","https://git.kernel.org/stable/c/7932db06c82c5b2f42a4d1a849d97dba9ce4a362","https://git.kernel.org/stable/c/cc5838f19d39a5fef04c468199699d2a4578be3a","https://git.kernel.org/stable/c/d6bedd6acc0bcb1e7e010bc046032e47f08d379f","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-27437
|
Medium |
fixed |
- 6.1.84
- 6.6.24
- 6.7.12
- 6.8.3
|
In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: Disable auto-enable of exclusive INTx IRQ
Currently for devices requiring masking at the irqchip for INTx, ie.
devices without DisINTx support, the IRQ is enabled in request_irq()
and subsequently disabled as necessary to align with the masked status
flag. This presents a window where the interrupt could fire between
these events, resulting in the IRQ incrementing the disable depth twice.
This would be unrecoverable for a user since the masked flag prevents
nested enables through vfio.
Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx
is never auto-enabled, then unmask as required. |
["https://git.kernel.org/stable/c/139dfcc4d723ab13469881200c7d80f49d776060","https://git.kernel.org/stable/c/26389925d6c2126fb777821a0a983adca7ee6351","https://git.kernel.org/stable/c/2a4a666c45107206605b7b5bc20545f8aabc4fa2","https://git.kernel.org/stable/c/3b3491ad0f80d913e7d255941d4470f4a4d9bfda","https://git.kernel.org/stable/c/561d5e1998d58b54ce2bbbb3e843b669aa0b3db5","https://git.kernel.org/stable/c/b7a2f0955ffceffadfe098b40b50307431f45438","https://git.kernel.org/stable/c/bf0bc84a20e6109ab07d5dc072067bd01eb931ec","https://git.kernel.org/stable/c/fe9a7082684eb059b925c535682e68c34d487d43","https://git.kernel.org/stable/c/139dfcc4d723ab13469881200c7d80f49d776060","https://git.kernel.org/stable/c/26389925d6c2126fb777821a0a983adca7ee6351","https://git.kernel.org/stable/c/2a4a666c45107206605b7b5bc20545f8aabc4fa2","https://git.kernel.org/stable/c/3b3491ad0f80d913e7d255941d4470f4a4d9bfda","https://git.kernel.org/stable/c/561d5e1998d58b54ce2bbbb3e843b669aa0b3db5","https://git.kernel.org/stable/c/b7a2f0955ffceffadfe098b40b50307431f45438","https://git.kernel.org/stable/c/bf0bc84a20e6109ab07d5dc072067bd01eb931ec","https://git.kernel.org/stable/c/fe9a7082684eb059b925c535682e68c34d487d43","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-23002
|
Medium |
fixed |
|
In the Linux kernel before 5.16.3, drivers/bluetooth/hci_qca.c misinterprets the devm_gpiod_get_index_optional return value (expects it to be NULL in the error case, whereas it is actually an error pointer). |
["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.3","https://github.com/torvalds/linux/commit/6845667146a28c09b5dfc401c1ad112374087944","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.3","https://github.com/torvalds/linux/commit/6845667146a28c09b5dfc401c1ad112374087944"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48864
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
vdpa/mlx5: add validation for VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command
When control vq receives a VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command
request from the driver, presently there is no validation against the
number of queue pairs to configure, or even if multiqueue had been
negotiated or not is unverified. This may lead to kernel panic due to
uninitialized resource for the queues were there any bogus request
sent down by untrusted driver. Tie up the loose ends there. |
["https://git.kernel.org/stable/c/9f6effca75626c7a7c7620dabcb1a254ca530230","https://git.kernel.org/stable/c/e7e118416465f2ba8b55007e5b789823e101421e","https://git.kernel.org/stable/c/ed0f849fc3a63ed2ddf5e72cdb1de3bdbbb0f8eb","https://git.kernel.org/stable/c/9f6effca75626c7a7c7620dabcb1a254ca530230","https://git.kernel.org/stable/c/e7e118416465f2ba8b55007e5b789823e101421e","https://git.kernel.org/stable/c/ed0f849fc3a63ed2ddf5e72cdb1de3bdbbb0f8eb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-38600
|
Medium |
fixed |
- 5.15.161
- 6.1.93
- 6.6.33
- 6.8.12
- 6.9.3
|
In the Linux kernel, the following vulnerability has been resolved:
ALSA: Fix deadlocks with kctl removals at disconnection
In snd_card_disconnect(), we set card->shutdown flag at the beginning,
call callbacks and do sync for card->power_ref_sleep waiters at the
end. The callback may delete a kctl element, and this can lead to a
deadlock when the device was in the suspended state. Namely:
* A process waits for the power up at snd_power_ref_and_wait() in
snd_ctl_info() or read/write() inside card->controls_rwsem.
* The system gets disconnected meanwhile, and the driver tries to
delete a kctl via snd_ctl_remove*(); it tries to take
card->controls_rwsem again, but this is already locked by the
above. Since the sleeper isn't woken up, this deadlocks.
An easy fix is to wake up sleepers before processing the driver
disconnect callbacks but right after setting the card->shutdown flag.
Then all sleepers will abort immediately, and the code flows again.
So, basically this patch moves the wait_event() call at the right
timing. While we're at it, just to be sure, call wait_event_all()
instead of wait_event(), although we don't use exclusive events on
this queue for now. |
["https://git.kernel.org/stable/c/2f103287ef7960854808930499d1181bd0145d68","https://git.kernel.org/stable/c/6b55e879e7bd023a03888fc6c8339edf82f576f4","https://git.kernel.org/stable/c/87988a534d8e12f2e6fc01fe63e6c1925dc5307c","https://git.kernel.org/stable/c/88ce3fe255d58a93624b467af036dc3519f309c7","https://git.kernel.org/stable/c/c2fb439f4f1425a961d20bec818fed2c2d9ef70a","https://git.kernel.org/stable/c/ff80185e7b7b547a0911fcfc8aefc61c3e8304d7","https://git.kernel.org/stable/c/2f103287ef7960854808930499d1181bd0145d68","https://git.kernel.org/stable/c/6b55e879e7bd023a03888fc6c8339edf82f576f4","https://git.kernel.org/stable/c/87988a534d8e12f2e6fc01fe63e6c1925dc5307c","https://git.kernel.org/stable/c/88ce3fe255d58a93624b467af036dc3519f309c7","https://git.kernel.org/stable/c/c2fb439f4f1425a961d20bec818fed2c2d9ef70a","https://git.kernel.org/stable/c/ff80185e7b7b547a0911fcfc8aefc61c3e8304d7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-42329
|
Medium |
fixed |
|
Guests can trigger deadlock in Linux netback driver T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] The patch for XSA-392 introduced another issue which might result in a deadlock when trying to free the SKB of a packet dropped due to the XSA-392 handling (CVE-2022-42328). Additionally when dropping packages for other reasons the same deadlock could occur in case of netpoll being active for the interface the xen-netback driver is connected to (CVE-2022-42329). |
["http://www.openwall.com/lists/oss-security/2022/12/08/2","http://www.openwall.com/lists/oss-security/2022/12/08/3","http://www.openwall.com/lists/oss-security/2022/12/09/2","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://xenbits.xenproject.org/xsa/advisory-424.txt","http://www.openwall.com/lists/oss-security/2022/12/08/2","http://www.openwall.com/lists/oss-security/2022/12/08/3","http://www.openwall.com/lists/oss-security/2022/12/09/2","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://xenbits.xenproject.org/xsa/advisory-424.txt"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-23005
|
Medium |
fixed |
|
In the Linux kernel before 6.2, mm/memory-tiers.c misinterprets the alloc_memory_type return value (expects it to be NULL in the error case, whereas it is actually an error pointer). NOTE: this is disputed by third parties because there are no realistic cases in which a user can cause the alloc_memory_type error case to be reached. |
["https://bugzilla.suse.com/show_bug.cgi?id=1208844#c2","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2","https://github.com/torvalds/linux/commit/4a625ceee8a0ab0273534cb6b432ce6b331db5ee","https://bugzilla.suse.com/show_bug.cgi?id=1208844#c2","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2","https://github.com/torvalds/linux/commit/4a625ceee8a0ab0273534cb6b432ce6b331db5ee"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52585
|
Medium |
fixed |
- 5.4.277
- 5.10.218
- 5.15.160
- 6.1.92
- 6.6.32
- 6.7.4
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix possible NULL dereference in amdgpu_ras_query_error_status_helper()
Return invalid error code -EINVAL for invalid block id.
Fixes the below:
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1183 amdgpu_ras_query_error_status_helper() error: we previously assumed 'info' could be null (see line 1176) |
["https://git.kernel.org/stable/c/0eb296233f86750102aa43b97879b8d8311f249a","https://git.kernel.org/stable/c/195a6289282e039024ad30ba66e6f94a4d0fbe49","https://git.kernel.org/stable/c/467139546f3fb93913de064461b1a43a212d7626","https://git.kernel.org/stable/c/7e6d6f27522bcd037856234b720ff607b9c4a09b","https://git.kernel.org/stable/c/92cb363d16ac1e41c9764cdb513d0e89a6ff4915","https://git.kernel.org/stable/c/b8d55a90fd55b767c25687747e2b24abd1ef8680","https://git.kernel.org/stable/c/c364e7a34c85c2154fb2e47561965d5b5a0b69b1","https://git.kernel.org/stable/c/0eb296233f86750102aa43b97879b8d8311f249a","https://git.kernel.org/stable/c/195a6289282e039024ad30ba66e6f94a4d0fbe49","https://git.kernel.org/stable/c/467139546f3fb93913de064461b1a43a212d7626","https://git.kernel.org/stable/c/7e6d6f27522bcd037856234b720ff607b9c4a09b","https://git.kernel.org/stable/c/92cb363d16ac1e41c9764cdb513d0e89a6ff4915","https://git.kernel.org/stable/c/b8d55a90fd55b767c25687747e2b24abd1ef8680","https://git.kernel.org/stable/c/c364e7a34c85c2154fb2e47561965d5b5a0b69b1","https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html","https://security.netapp.com/advisory/ntap-20240912-0009/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26816
|
Medium |
fixed |
- 4.19.311
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
x86, relocs: Ignore relocations in .notes section
When building with CONFIG_XEN_PV=y, .text symbols are emitted into
the .notes section so that Xen can find the "startup_xen" entry point.
This information is used prior to booting the kernel, so relocations
are not useful. In fact, performing relocations against the .notes
section means that the KASLR base is exposed since /sys/kernel/notes
is world-readable.
To avoid leaking the KASLR base without breaking unprivileged tools that
are expecting to read /sys/kernel/notes, skip performing relocations in
the .notes section. The values readable in .notes are then identical to
those found in System.map. |
["https://git.kernel.org/stable/c/13edb509abc91c72152a11baaf0e7c060a312e03","https://git.kernel.org/stable/c/47635b112a64b7b208224962471e7e42f110e723","https://git.kernel.org/stable/c/52018aa146e3cf76569a9b1e6e49a2b7c8d4a088","https://git.kernel.org/stable/c/5cb59db49c9c0fccfd33b2209af4f7ae3c6ddf40","https://git.kernel.org/stable/c/a4e7ff1a74274e59a2de9bb57236542aa990d20a","https://git.kernel.org/stable/c/aaa8736370db1a78f0e8434344a484f9fd20be3b","https://git.kernel.org/stable/c/ae7079238f6faf1b94accfccf334e98b46a0c0aa","https://git.kernel.org/stable/c/af2a9f98d884205145fd155304a6955822ccca1c","https://git.kernel.org/stable/c/c7cff9780297d55d97ad068b68b703cfe53ef9af","https://git.kernel.org/stable/c/13edb509abc91c72152a11baaf0e7c060a312e03","https://git.kernel.org/stable/c/47635b112a64b7b208224962471e7e42f110e723","https://git.kernel.org/stable/c/52018aa146e3cf76569a9b1e6e49a2b7c8d4a088","https://git.kernel.org/stable/c/5cb59db49c9c0fccfd33b2209af4f7ae3c6ddf40","https://git.kernel.org/stable/c/a4e7ff1a74274e59a2de9bb57236542aa990d20a","https://git.kernel.org/stable/c/aaa8736370db1a78f0e8434344a484f9fd20be3b","https://git.kernel.org/stable/c/ae7079238f6faf1b94accfccf334e98b46a0c0aa","https://git.kernel.org/stable/c/af2a9f98d884205145fd155304a6955822ccca1c","https://git.kernel.org/stable/c/c7cff9780297d55d97ad068b68b703cfe53ef9af","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52488
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFO
The SC16IS7XX IC supports a burst mode to access the FIFOs where the
initial register address is sent ($00), followed by all the FIFO data
without having to resend the register address each time. In this mode, the
IC doesn't increment the register address for each R/W byte.
The regmap_raw_read() and regmap_raw_write() are functions which can
perform IO over multiple registers. They are currently used to read/write
from/to the FIFO, and although they operate correctly in this burst mode on
the SPI bus, they would corrupt the regmap cache if it was not disabled
manually. The reason is that when the R/W size is more than 1 byte, these
functions assume that the register address is incremented and handle the
cache accordingly.
Convert FIFO R/W functions to use the regmap _noinc_ versions in order to
remove the manual cache control which was a workaround when using the
_raw_ versions. FIFO registers are properly declared as volatile so
cache will not be used/updated for FIFO accesses. |
["https://git.kernel.org/stable/c/084c24e788d9cf29c55564de368bf5284f2bb5db","https://git.kernel.org/stable/c/416b10d2817c94db86829fb92ad43ce7d002c573","https://git.kernel.org/stable/c/4e37416e4ee1b1bc17364a68973e0c63be89e611","https://git.kernel.org/stable/c/aa7cb4787698add9367b19f7afc667662c9bdb23","https://git.kernel.org/stable/c/dbf4ab821804df071c8b566d9813083125e6d97b","https://git.kernel.org/stable/c/e635f652696ef6f1230621cfd89c350cb5ec6169","https://git.kernel.org/stable/c/084c24e788d9cf29c55564de368bf5284f2bb5db","https://git.kernel.org/stable/c/416b10d2817c94db86829fb92ad43ce7d002c573","https://git.kernel.org/stable/c/4e37416e4ee1b1bc17364a68973e0c63be89e611","https://git.kernel.org/stable/c/aa7cb4787698add9367b19f7afc667662c9bdb23","https://git.kernel.org/stable/c/dbf4ab821804df071c8b566d9813083125e6d97b","https://git.kernel.org/stable/c/e635f652696ef6f1230621cfd89c350cb5ec6169","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3107
|
Medium |
fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. netvsc_get_ethtool_stats in drivers/net/hyperv/netvsc_drv.c lacks check of the return value of kvmalloc_array() and will cause the null pointer dereference. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2153060","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=886e44c9298a6b428ae046e2fa092ca52e822e6a","https://bugzilla.redhat.com/show_bug.cgi?id=2153060","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=886e44c9298a6b428ae046e2fa092ca52e822e6a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3108
|
Medium |
fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. kfd_parse_subtype_iolink in drivers/gpu/drm/amd/amdkfd/kfd_crat.c lacks check of the return value of kmemdup(). |
["https://bugzilla.redhat.com/show_bug.cgi?id=2153052","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=abfaf0eee97925905e742aa3b0b72e04a918fa9e","https://bugzilla.redhat.com/show_bug.cgi?id=2153052","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=abfaf0eee97925905e742aa3b0b72e04a918fa9e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3111
|
Medium |
fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. free_charger_irq() in drivers/power/supply/wm8350_power.c lacks free of WM8350_IRQ_CHG_FAST_RDY, which is registered in wm8350_init_charger(). |
["https://bugzilla.redhat.com/show_bug.cgi?id=2153059","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=6dee930f6f6776d1e5a7edf542c6863b47d9f078","https://bugzilla.redhat.com/show_bug.cgi?id=2153059","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=6dee930f6f6776d1e5a7edf542c6863b47d9f078"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49850
|
Medium |
fixed |
- 4.9.334
- 4.14.300
- 4.19.267
- 5.4.225
- 5.10.155
- 5.15.79
- 6.0.9
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix deadlock in nilfs_count_free_blocks()
A semaphore deadlock can occur if nilfs_get_block() detects metadata
corruption while locating data blocks and a superblock writeback occurs at
the same time:
task 1 task 2
------ ------
* A file operation *
nilfs_truncate()
nilfs_get_block()
down_read(rwsem A) <--
nilfs_bmap_lookup_contig()
... generic_shutdown_super()
nilfs_put_super()
* Prepare to write superblock *
down_write(rwsem B) <--
nilfs_cleanup_super()
* Detect b-tree corruption * nilfs_set_log_cursor()
nilfs_bmap_convert_error() nilfs_count_free_blocks()
__nilfs_error() down_read(rwsem A) <--
nilfs_set_error()
down_write(rwsem B) <--
*** DEADLOCK ***
Here, nilfs_get_block() readlocks rwsem A (= NILFS_MDT(dat_inode)->mi_sem)
and then calls nilfs_bmap_lookup_contig(), but if it fails due to metadata
corruption, __nilfs_error() is called from nilfs_bmap_convert_error()
inside the lock section.
Since __nilfs_error() calls nilfs_set_error() unless the filesystem is
read-only and nilfs_set_error() attempts to writelock rwsem B (=
nilfs->ns_sem) to write back superblock exclusively, hierarchical lock
acquisition occurs in the order rwsem A -> rwsem B.
Now, if another task starts updating the superblock, it may writelock
rwsem B during the lock sequence above, and can deadlock trying to
readlock rwsem A in nilfs_count_free_blocks().
However, there is actually no need to take rwsem A in
nilfs_count_free_blocks() because it, within the lock section, only reads
a single integer data on a shared struct with
nilfs_sufile_get_ncleansegs(). This has been the case after commit
aa474a220180 ("nilfs2: add local variable to cache the number of clean
segments"), that is, even before this bug was introduced.
So, this resolves the deadlock problem by just not taking the semaphore in
nilfs_count_free_blocks(). |
["https://git.kernel.org/stable/c/1d4ff73062096c21b47954d2996b4df259777bda","https://git.kernel.org/stable/c/36ff974b0310771417c0be64b64aa221bd70d63d","https://git.kernel.org/stable/c/3c89ca6d3dfa6c09c515807a7a97a521f5d5147e","https://git.kernel.org/stable/c/8ac932a4921a96ca52f61935dbba64ea87bbd5dc","https://git.kernel.org/stable/c/8b4506cff6630bb474bb46a2a75c31e533a756ba","https://git.kernel.org/stable/c/abc082aac0d9b6b926038fc3adb7008306581be2","https://git.kernel.org/stable/c/cb029b54953420f7a2d65100f1c5107f14411bdc","https://git.kernel.org/stable/c/f0cc93080d4c09510b74ecba87fd778cca390bb1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-22010
|
Medium |
fixed |
- 6.1.132
- 6.6.85
- 6.12.21
- 6.13.9
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix soft lockup during bt pages loop
Driver runs a for-loop when allocating bt pages and mapping them with
buffer pages. When a large buffer (e.g. MR over 100GB) is being allocated,
it may require a considerable loop count. This will lead to soft lockup:
watchdog: BUG: soft lockup - CPU#27 stuck for 22s!
...
Call trace:
hem_list_alloc_mid_bt+0x124/0x394 [hns_roce_hw_v2]
hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2]
hns_roce_mtr_create+0x2e4/0x360 [hns_roce_hw_v2]
alloc_mr_pbl+0xd4/0x17c [hns_roce_hw_v2]
hns_roce_reg_user_mr+0xf8/0x190 [hns_roce_hw_v2]
ib_uverbs_reg_mr+0x118/0x290
watchdog: BUG: soft lockup - CPU#35 stuck for 23s!
...
Call trace:
hns_roce_hem_list_find_mtt+0x7c/0xb0 [hns_roce_hw_v2]
mtr_map_bufs+0xc4/0x204 [hns_roce_hw_v2]
hns_roce_mtr_create+0x31c/0x3c4 [hns_roce_hw_v2]
alloc_mr_pbl+0xb0/0x160 [hns_roce_hw_v2]
hns_roce_reg_user_mr+0x108/0x1c0 [hns_roce_hw_v2]
ib_uverbs_reg_mr+0x120/0x2bc
Add a cond_resched() to fix soft lockup during these loops. In order not
to affect the allocation performance of normal-size buffer, set the loop
count of a 100GB MR as the threshold to call cond_resched(). |
["https://git.kernel.org/stable/c/13a52f6c9ff99f7d88f81da535cb4e85eade662b","https://git.kernel.org/stable/c/25655580136de59ec89f09089dd28008ea440fc9","https://git.kernel.org/stable/c/4104b0023ff66b5df900d23dbf38310893deca79","https://git.kernel.org/stable/c/461eb4ddede266df8f181f578732bb01742c3fd6","https://git.kernel.org/stable/c/975355faba56c0751292ed15a90c3e2c7dc0aad6","https://git.kernel.org/stable/c/9ab20fec7a1ce3057ad86afd27bfd08420b7cd11","https://git.kernel.org/stable/c/efe544462fc0b499725364f90bd0f8bbf16f861a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-22014
|
Medium |
fixed |
- 6.1.132
- 6.6.85
- 6.12.21
- 6.13.9
|
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: pdr: Fix the potential deadlock
When some client process A call pdr_add_lookup() to add the look up for
the service and does schedule locator work, later a process B got a new
server packet indicating locator is up and call pdr_locator_new_server()
which eventually sets pdr->locator_init_complete to true which process A
sees and takes list lock and queries domain list but it will timeout due
to deadlock as the response will queued to the same qmi->wq and it is
ordered workqueue and process B is not able to complete new server
request work due to deadlock on list lock.
Fix it by removing the unnecessary list iteration as the list iteration
is already being done inside locator work, so avoid it here and just
call schedule_work() here.
Process A Process B
process_scheduled_works()
pdr_add_lookup() qmi_data_ready_work()
process_scheduled_works() pdr_locator_new_server()
pdr->locator_init_complete=true;
pdr_locator_work()
mutex_lock(&pdr->list_lock);
pdr_locate_service() mutex_lock(&pdr->list_lock);
pdr_get_domain_list()
pr_err("PDR: %s get domain list
txn wait failed: %d\n",
req->service_name,
ret);
Timeout error log due to deadlock:
"
PDR: tms/servreg get domain list txn wait failed: -110
PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110
"
Thanks to Bjorn and Johan for letting me know that this commit also fixes
an audio regression when using the in-kernel pd-mapper as that makes it
easier to hit this race. [1] |
["https://git.kernel.org/stable/c/02612f1e4c34d94d6c8ee75bf7d254ed697e22d4","https://git.kernel.org/stable/c/0a566a79aca9851fae140536e0fc5b0853c90a90","https://git.kernel.org/stable/c/2eeb03ad9f42dfece63051be2400af487ddb96d2","https://git.kernel.org/stable/c/72a222b6af10c2a05a5fad0029246229ed8912c2","https://git.kernel.org/stable/c/daba84612236de3ab39083e62c9e326a654ebd20","https://git.kernel.org/stable/c/f2bbfd50e95bc117360f0f59e629aa03d821ebd6","https://git.kernel.org/stable/c/f4489260f5713c94e1966e5f20445bff262876f4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52593
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap()
Since 'ieee80211_beacon_get()' can return NULL, 'wfx_set_mfp_ap()'
should check the return value before examining skb data. So convert
the latter to return an appropriate error code and propagate it to
return from 'wfx_start_ap()' as well. Compile tested only. |
["https://git.kernel.org/stable/c/3739121443f5114c6bcf6d841a5124deb006b878","https://git.kernel.org/stable/c/574dcd3126aa2eed75437137843f254b1190dd03","https://git.kernel.org/stable/c/9ab224744a47363f74ea29c6894c405e3bcf5132","https://git.kernel.org/stable/c/fe0a7776d4d19e613bb8dd80fe2d78ae49e8b49d","https://git.kernel.org/stable/c/3739121443f5114c6bcf6d841a5124deb006b878","https://git.kernel.org/stable/c/574dcd3126aa2eed75437137843f254b1190dd03","https://git.kernel.org/stable/c/9ab224744a47363f74ea29c6894c405e3bcf5132","https://git.kernel.org/stable/c/fe0a7776d4d19e613bb8dd80fe2d78ae49e8b49d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52632
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Fix lock dependency warning with srcu
======================================================
WARNING: possible circular locking dependency detected
6.5.0-kfd-yangp #2289 Not tainted
------------------------------------------------------
kworker/0:2/996 is trying to acquire lock:
(srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0
but task is already holding lock:
((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}, at:
process_one_work+0x211/0x560
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}:
__flush_work+0x88/0x4f0
svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu]
svm_range_set_attr+0xd6/0x14c0 [amdgpu]
kfd_ioctl+0x1d1/0x630 [amdgpu]
__x64_sys_ioctl+0x88/0xc0
-> #2 (&info->lock#2){+.+.}-{3:3}:
__mutex_lock+0x99/0xc70
amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu]
restore_process_helper+0x22/0x80 [amdgpu]
restore_process_worker+0x2d/0xa0 [amdgpu]
process_one_work+0x29b/0x560
worker_thread+0x3d/0x3d0
-> #1 ((work_completion)(&(&process->restore_work)->work)){+.+.}-{0:0}:
__flush_work+0x88/0x4f0
__cancel_work_timer+0x12c/0x1c0
kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu]
__mmu_notifier_release+0xad/0x240
exit_mmap+0x6a/0x3a0
mmput+0x6a/0x120
do_exit+0x322/0xb90
do_group_exit+0x37/0xa0
__x64_sys_exit_group+0x18/0x20
do_syscall_64+0x38/0x80
-> #0 (srcu){.+.+}-{0:0}:
__lock_acquire+0x1521/0x2510
lock_sync+0x5f/0x90
__synchronize_srcu+0x4f/0x1a0
__mmu_notifier_release+0x128/0x240
exit_mmap+0x6a/0x3a0
mmput+0x6a/0x120
svm_range_deferred_list_work+0x19f/0x350 [amdgpu]
process_one_work+0x29b/0x560
worker_thread+0x3d/0x3d0
other info that might help us debug this:
Chain exists of:
srcu --> &info->lock#2 --> (work_completion)(&svms->deferred_list_work)
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock((work_completion)(&svms->deferred_list_work));
lock(&info->lock#2);
lock((work_completion)(&svms->deferred_list_work));
sync(srcu); |
["https://git.kernel.org/stable/c/1556c242e64cdffe58736aa650b0b395854fe4d4","https://git.kernel.org/stable/c/2a9de42e8d3c82c6990d226198602be44f43f340","https://git.kernel.org/stable/c/752312f6a79440086ac0f9b08d7776870037323c","https://git.kernel.org/stable/c/b602f098f716723fa5c6c96a486e0afba83b7b94","https://git.kernel.org/stable/c/1556c242e64cdffe58736aa650b0b395854fe4d4","https://git.kernel.org/stable/c/2a9de42e8d3c82c6990d226198602be44f43f340","https://git.kernel.org/stable/c/752312f6a79440086ac0f9b08d7776870037323c","https://git.kernel.org/stable/c/b602f098f716723fa5c6c96a486e0afba83b7b94"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-53013
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ptdma: pt_core_execute_cmd() should use spinlock
The interrupt handler (pt_core_irq_handler()) of the ptdma
driver can be called from interrupt context. The code flow
in this function can lead down to pt_core_execute_cmd() which
will attempt to grab a mutex, which is not appropriate in
interrupt context and ultimately leads to a kernel panic.
The fix here changes this mutex to a spinlock, which has
been verified to resolve the issue. |
["https://git.kernel.org/stable/c/13ba563c2c8055ba8a637c9f70bb833b43cb4207","https://git.kernel.org/stable/c/95e5fda3b5f9ed8239b145da3fa01e641cf5d53c","https://git.kernel.org/stable/c/ed0d8f731e0bf1bb12a7a37698ac613db20e2794"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4385
|
Medium |
|
N/A
|
A NULL pointer dereference flaw was found in dbFree in fs/jfs/jfs_dmap.c in the journaling file system (JFS) in the Linux Kernel. This issue may allow a local attacker to crash the system due to a missing sanity check. |
["https://access.redhat.com/security/cve/CVE-2023-4385","https://bugzilla.redhat.com/show_bug.cgi?id=2219272","https://github.com/torvalds/linux/commit/0d4837fdb796f99369cf7691d33de1b856bcaf1f","https://access.redhat.com/security/cve/CVE-2023-4385","https://bugzilla.redhat.com/show_bug.cgi?id=2219272","https://github.com/torvalds/linux/commit/0d4837fdb796f99369cf7691d33de1b856bcaf1f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-6610
|
High |
|
N/A
|
An out-of-bounds read vulnerability was found in smb2_dump_detail in fs/smb/client/smb2ops.c in the Linux Kernel. This issue could allow a local attacker to crash the system or leak internal kernel information. |
["https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:0881","https://access.redhat.com/errata/RHSA-2024:0897","https://access.redhat.com/errata/RHSA-2024:1248","https://access.redhat.com/errata/RHSA-2024:1404","https://access.redhat.com/errata/RHSA-2024:2094","https://access.redhat.com/security/cve/CVE-2023-6610","https://bugzilla.kernel.org/show_bug.cgi?id=218219","https://bugzilla.redhat.com/show_bug.cgi?id=2253614","https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:0881","https://access.redhat.com/errata/RHSA-2024:0897","https://access.redhat.com/errata/RHSA-2024:1248","https://access.redhat.com/errata/RHSA-2024:1404","https://access.redhat.com/errata/RHSA-2024:2094","https://access.redhat.com/security/cve/CVE-2023-6610","https://bugzilla.kernel.org/show_bug.cgi?id=218219","https://bugzilla.redhat.com/show_bug.cgi?id=2253614"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-41858
|
High |
fixed |
- 4.9.311
- 4.14.276
- 4.19.239
- 5.4.190
- 5.10.112
- 5.15.35
- 5.17.4
|
A flaw was found in the Linux kernel. A NULL pointer dereference may occur while a slip driver is in progress to detach in sl_tx_timeout in drivers/net/slip/slip.c. This issue could allow an attacker to crash the system or leak internal kernel information. |
["https://github.com/torvalds/linux/commit/ec4eb8a86ade4d22633e1da2a7d85a846b7d1798","https://security.netapp.com/advisory/ntap-20230223-0006/","https://github.com/torvalds/linux/commit/ec4eb8a86ade4d22633e1da2a7d85a846b7d1798","https://security.netapp.com/advisory/ntap-20230223-0006/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26593
|
High |
fixed |
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
i2c: i801: Fix block process call transactions
According to the Intel datasheets, software must reset the block
buffer index twice for block process call transactions: once before
writing the outgoing data to the buffer, and once again before
reading the incoming data from the buffer.
The driver is currently missing the second reset, causing the wrong
portion of the block buffer to be read. |
["https://git.kernel.org/stable/c/1f8d0691c50581ba6043f009ec9e8b9f78f09d5a","https://git.kernel.org/stable/c/491528935c9c48bf341d8b40eabc6c4fc5df6f2c","https://git.kernel.org/stable/c/609c7c1cc976e740d0fed4dbeec688b3ecb5dce2","https://git.kernel.org/stable/c/6be99c51829b24c914cef5bff6164877178e84d9","https://git.kernel.org/stable/c/7a14b8a477b88607d157c24aeb23e7389ec3319f","https://git.kernel.org/stable/c/c1c9d0f6f7f1dbf29db996bd8e166242843a5f21","https://git.kernel.org/stable/c/d074d5ff5ae77b18300e5079c6bda6342a4d44b7","https://git.kernel.org/stable/c/1f8d0691c50581ba6043f009ec9e8b9f78f09d5a","https://git.kernel.org/stable/c/491528935c9c48bf341d8b40eabc6c4fc5df6f2c","https://git.kernel.org/stable/c/609c7c1cc976e740d0fed4dbeec688b3ecb5dce2","https://git.kernel.org/stable/c/6be99c51829b24c914cef5bff6164877178e84d9","https://git.kernel.org/stable/c/7a14b8a477b88607d157c24aeb23e7389ec3319f","https://git.kernel.org/stable/c/c1c9d0f6f7f1dbf29db996bd8e166242843a5f21","https://git.kernel.org/stable/c/d074d5ff5ae77b18300e5079c6bda6342a4d44b7","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1990
|
Medium |
fixed |
|
A use-after-free flaw was found in ndlc_remove in drivers/nfc/st-nci/ndlc.c in the Linux Kernel. This flaw could allow an attacker to crash the system due to a race problem. |
["https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20230312160837.2040857-1-zyytlz.wz%40163.com/","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20230312160837.2040857-1-zyytlz.wz%40163.com/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1734
|
High |
fixed |
|
A flaw in Linux Kernel found in nfcmrvl_nci_unregister_dev() in drivers/nfc/nfcmrvl/main.c can lead to use after free both read or write when non synchronized between cleanup routine and firmware download routine. |
["http://www.openwall.com/lists/oss-security/2022/06/05/4","http://www.openwall.com/lists/oss-security/2022/06/09/1","https://github.com/torvalds/linux/commit/d270453a0d9ec10bb8a802a142fb1b3601a83098","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://security.netapp.com/advisory/ntap-20220707-0007/","https://www.debian.org/security/2022/dsa-5173","http://www.openwall.com/lists/oss-security/2022/06/05/4","http://www.openwall.com/lists/oss-security/2022/06/09/1","https://github.com/torvalds/linux/commit/d270453a0d9ec10bb8a802a142fb1b3601a83098","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://security.netapp.com/advisory/ntap-20220707-0007/","https://www.debian.org/security/2022/dsa-5173"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-35824
|
High |
fixed |
|
An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in dm1105_remove in drivers/media/pci/dm1105/dm1105.c. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5abda7a16698d4d1f47af1168d8fa2c640116b4a","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/all/49bb0b6a-e669-d4e7-d742-a19d2763e947%40xs4all.nl/","https://lore.kernel.org/lkml/20230318081506.795147-1-zyytlz.wz%40163.com/","https://security.netapp.com/advisory/ntap-20230803-0002/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5abda7a16698d4d1f47af1168d8fa2c640116b4a","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/all/49bb0b6a-e669-d4e7-d742-a19d2763e947%40xs4all.nl/","https://lore.kernel.org/lkml/20230318081506.795147-1-zyytlz.wz%40163.com/","https://security.netapp.com/advisory/ntap-20230803-0002/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-51043
|
High |
fixed |
|
In the Linux kernel before 6.4.5, drivers/gpu/drm/drm_atomic.c has a use-after-free during a race condition between a nonblocking atomic commit and a driver unload. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.5","https://github.com/torvalds/linux/commit/4e076c73e4f6e90816b30fcd4a0d7ab365087255","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.5","https://github.com/torvalds/linux/commit/4e076c73e4f6e90816b30fcd4a0d7ab365087255"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52480
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix race condition between session lookup and expire
Thread A + Thread B
ksmbd_session_lookup | smb2_sess_setup
sess = xa_load |
|
| xa_erase(&conn->sessions, sess->id);
|
| ksmbd_session_destroy(sess) --> kfree(sess)
|
// UAF! |
sess->last_active = jiffies |
+
This patch add rwsem to fix race condition between ksmbd_session_lookup
and ksmbd_expire_session. |
["https://git.kernel.org/stable/c/18ced78b0ebccc2d16f426143dc56ab3aad666be","https://git.kernel.org/stable/c/53ff5cf89142b978b1a5ca8dc4d4425e6a09745f","https://git.kernel.org/stable/c/a2ca5fd3dbcc665e1169044fa0c9e3eba779202b","https://git.kernel.org/stable/c/c77fd3e25a51ac92b0f1b347a96eff6a0b4f066f","https://git.kernel.org/stable/c/18ced78b0ebccc2d16f426143dc56ab3aad666be","https://git.kernel.org/stable/c/53ff5cf89142b978b1a5ca8dc4d4425e6a09745f","https://git.kernel.org/stable/c/a2ca5fd3dbcc665e1169044fa0c9e3eba779202b","https://git.kernel.org/stable/c/c77fd3e25a51ac92b0f1b347a96eff6a0b4f066f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52517
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
spi: sun6i: fix race between DMA RX transfer completion and RX FIFO drain
Previously the transfer complete IRQ immediately drained to RX FIFO to
read any data remaining in FIFO to the RX buffer. This behaviour is
correct when dealing with SPI in interrupt mode. However in DMA mode the
transfer complete interrupt still fires as soon as all bytes to be
transferred have been stored in the FIFO. At that point data in the FIFO
still needs to be picked up by the DMA engine. Thus the drain procedure
and DMA engine end up racing to read from RX FIFO, corrupting any data
read. Additionally the RX buffer pointer is never adjusted according to
DMA progress in DMA mode, thus calling the RX FIFO drain procedure in DMA
mode is a bug.
Fix corruptions in DMA RX mode by draining RX FIFO only in interrupt mode.
Also wait for completion of RX DMA when in DMA mode before returning to
ensure all data has been copied to the supplied memory buffer. |
["https://git.kernel.org/stable/c/1f11f4202caf5710204d334fe63392052783876d","https://git.kernel.org/stable/c/36b29974a7ad2ff604c24ad348f940506c7b1209","https://git.kernel.org/stable/c/4e149d524678431638ff378ef6025e4e89b71097","https://git.kernel.org/stable/c/bd1ec7f9983b5cd3c77e0f7cda3fa8aed041af2f","https://git.kernel.org/stable/c/1f11f4202caf5710204d334fe63392052783876d","https://git.kernel.org/stable/c/36b29974a7ad2ff604c24ad348f940506c7b1209","https://git.kernel.org/stable/c/4e149d524678431638ff378ef6025e4e89b71097","https://git.kernel.org/stable/c/bd1ec7f9983b5cd3c77e0f7cda3fa8aed041af2f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-34495
|
Medium |
fixed |
|
rpmsg_probe in drivers/rpmsg/virtio_rpmsg_bus.c in the Linux kernel before 5.18.4 has a double free. |
["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.4","https://github.com/torvalds/linux/commit/c2eecefec5df1306eafce28ccdf1ca159a552ecc","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.4","https://github.com/torvalds/linux/commit/c2eecefec5df1306eafce28ccdf1ca159a552ecc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-32296
|
Low |
fixed |
|
The Linux kernel before 5.17.9 allows TCP servers to identify clients by observing what source ports are used. This occurs because of use of Algorithm 4 ("Double-Hash Port Selection Algorithm") of RFC 6056. |
["https://arxiv.org/abs/2209.12993","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.9","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4c2c8f03a5ab7cb04ec64724d7d176d00bcc91e5","https://github.com/0xkol/rfc6056-device-tracker","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://www.debian.org/security/2022/dsa-5173","https://arxiv.org/abs/2209.12993","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.9","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4c2c8f03a5ab7cb04ec64724d7d176d00bcc91e5","https://github.com/0xkol/rfc6056-device-tracker","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://www.debian.org/security/2022/dsa-5173"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1353
|
High |
fixed |
|
A vulnerability was found in the pfkey_register function in net/key/af_key.c in the Linux kernel. This flaw allows a local, unprivileged user to gain access to kernel memory, leading to a system crash or a leak of internal kernel information. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2066819","https://github.com/torvalds/linux/commit/9a564bccb78a76740ea9d75a259942df8143d02c","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://security.netapp.com/advisory/ntap-20220629-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173","https://bugzilla.redhat.com/show_bug.cgi?id=2066819","https://github.com/torvalds/linux/commit/9a564bccb78a76740ea9d75a259942df8143d02c","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://security.netapp.com/advisory/ntap-20220629-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-21505
|
Medium |
fixed |
- 5.4.208
- 5.10.134
- 5.15.58
- 5.18.15
|
In the linux kernel, if IMA appraisal is used with the "ima_appraise=log" boot param, lockdown can be defeated with kexec on any machine when Secure Boot is disabled or unavailable. IMA prevents setting "ima_appraise=log" from the boot param when Secure Boot is enabled, but this does not cover cases where lockdown is used without Secure Boot. CVSS 3.1 Base Score 6.7 (Confidentiality, Integrity, Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H). |
["https://git.kernel.org/linus/543ce63b664e2c2f9533d089a4664b559c3e6b5b","https://linux.oracle.com/cve/CVE-2022-21505.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-35788
|
High |
fixed |
- 4.19.285
- 5.4.246
- 5.10.183
- 5.15.116
- 6.1.33
- 6.3.7
|
An issue was discovered in fl_set_geneve_opt in net/sched/cls_flower.c in the Linux kernel before 6.3.7. It allows an out-of-bounds write in the flower classifier code via TCA_FLOWER_KEY_ENC_OPTS_GENEVE packets. This may result in denial of service or privilege escalation. |
["http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","http://www.openwall.com/lists/oss-security/2023/06/17/1","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.7","https://git.kernel.org/linus/4d56304e5827c8cc8cc18c75343d283af7c4825c","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20230714-0002/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5480","https://www.openwall.com/lists/oss-security/2023/06/07/1","http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","http://www.openwall.com/lists/oss-security/2023/06/17/1","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.7","https://git.kernel.org/linus/4d56304e5827c8cc8cc18c75343d283af7c4825c","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20230714-0002/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5480","https://www.openwall.com/lists/oss-security/2023/06/07/1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26656
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix use-after-free bug
The bug can be triggered by sending a single amdgpu_gem_userptr_ioctl
to the AMDGPU DRM driver on any ASICs with an invalid address and size.
The bug was reported by Joonkyo Jung <joonkyoj@yonsei.ac.kr>.
For example the following code:
static void Syzkaller1(int fd)
{
struct drm_amdgpu_gem_userptr arg;
int ret;
arg.addr = 0xffffffffffff0000;
arg.size = 0x80000000; /*2 Gb*/
arg.flags = 0x7;
ret = drmIoctl(fd, 0xc1186451/*amdgpu_gem_userptr_ioctl*/, &arg);
}
Due to the address and size are not valid there is a failure in
amdgpu_hmm_register->mmu_interval_notifier_insert->__mmu_interval_notifier_insert->
check_shl_overflow, but we even the amdgpu_hmm_register failure we still call
amdgpu_hmm_unregister into amdgpu_gem_object_free which causes access to a bad address.
The following stack is below when the issue is reproduced when Kazan is enabled:
[ +0.000014] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020
[ +0.000009] RIP: 0010:mmu_interval_notifier_remove+0x327/0x340
[ +0.000017] Code: ff ff 49 89 44 24 08 48 b8 00 01 00 00 00 00 ad de 4c 89 f7 49 89 47 40 48 83 c0 22 49 89 47 48 e8 ce d1 2d 01 e9 32 ff ff ff <0f> 0b e9 16 ff ff ff 4c 89 ef e8 fa 14 b3 ff e9 36 ff ff ff e8 80
[ +0.000014] RSP: 0018:ffffc90002657988 EFLAGS: 00010246
[ +0.000013] RAX: 0000000000000000 RBX: 1ffff920004caf35 RCX: ffffffff8160565b
[ +0.000011] RDX: dffffc0000000000 RSI: 0000000000000004 RDI: ffff8881a9f78260
[ +0.000010] RBP: ffffc90002657a70 R08: 0000000000000001 R09: fffff520004caf25
[ +0.000010] R10: 0000000000000003 R11: ffffffff8161d1d6 R12: ffff88810e988c00
[ +0.000010] R13: ffff888126fb5a00 R14: ffff88810e988c0c R15: ffff8881a9f78260
[ +0.000011] FS: 00007ff9ec848540(0000) GS:ffff8883cc880000(0000) knlGS:0000000000000000
[ +0.000012] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ +0.000010] CR2: 000055b3f7e14328 CR3: 00000001b5770000 CR4: 0000000000350ef0
[ +0.000010] Call Trace:
[ +0.000006] <TASK>
[ +0.000007] ? show_regs+0x6a/0x80
[ +0.000018] ? __warn+0xa5/0x1b0
[ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340
[ +0.000018] ? report_bug+0x24a/0x290
[ +0.000022] ? handle_bug+0x46/0x90
[ +0.000015] ? exc_invalid_op+0x19/0x50
[ +0.000016] ? asm_exc_invalid_op+0x1b/0x20
[ +0.000017] ? kasan_save_stack+0x26/0x50
[ +0.000017] ? mmu_interval_notifier_remove+0x23b/0x340
[ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340
[ +0.000019] ? mmu_interval_notifier_remove+0x23b/0x340
[ +0.000020] ? __pfx_mmu_interval_notifier_remove+0x10/0x10
[ +0.000017] ? kasan_save_alloc_info+0x1e/0x30
[ +0.000018] ? srso_return_thunk+0x5/0x5f
[ +0.000014] ? __kasan_kmalloc+0xb1/0xc0
[ +0.000018] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? __kasan_check_read+0x11/0x20
[ +0.000020] amdgpu_hmm_unregister+0x34/0x50 [amdgpu]
[ +0.004695] amdgpu_gem_object_free+0x66/0xa0 [amdgpu]
[ +0.004534] ? __pfx_amdgpu_gem_object_free+0x10/0x10 [amdgpu]
[ +0.004291] ? do_syscall_64+0x5f/0xe0
[ +0.000023] ? srso_return_thunk+0x5/0x5f
[ +0.000017] drm_gem_object_free+0x3b/0x50 [drm]
[ +0.000489] amdgpu_gem_userptr_ioctl+0x306/0x500 [amdgpu]
[ +0.004295] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]
[ +0.004270] ? srso_return_thunk+0x5/0x5f
[ +0.000014] ? __this_cpu_preempt_check+0x13/0x20
[ +0.000015] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? sysvec_apic_timer_interrupt+0x57/0xc0
[ +0.000020] ? srso_return_thunk+0x5/0x5f
[ +0.000014] ? asm_sysvec_apic_timer_interrupt+0x1b/0x20
[ +0.000022] ? drm_ioctl_kernel+0x17b/0x1f0 [drm]
[ +0.000496] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]
[ +0.004272] ? drm_ioctl_kernel+0x190/0x1f0 [drm]
[ +0.000492] drm_ioctl_kernel+0x140/0x1f0 [drm]
[ +0.000497] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]
[ +0.004297] ? __pfx_drm_ioctl_kernel+0x10/0x10 [d
---truncated--- |
["https://git.kernel.org/stable/c/22207fd5c80177b860279653d017474b2812af5e","https://git.kernel.org/stable/c/22f665ecfd1225afa1309ace623157d12bb9bb0c","https://git.kernel.org/stable/c/2e13f88e01ae7e28a7e831bf5c2409c4748e0a60","https://git.kernel.org/stable/c/af054a5fb24a144f99895afce9519d709891894c","https://git.kernel.org/stable/c/e87e08c94c9541b4e18c4c13f2f605935f512605","https://git.kernel.org/stable/c/22207fd5c80177b860279653d017474b2812af5e","https://git.kernel.org/stable/c/22f665ecfd1225afa1309ace623157d12bb9bb0c","https://git.kernel.org/stable/c/af054a5fb24a144f99895afce9519d709891894c","https://git.kernel.org/stable/c/e87e08c94c9541b4e18c4c13f2f605935f512605"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-3759
|
Medium |
|
N/A
|
A memory overflow vulnerability was found in the Linux kernel’s ipc functionality of the memcg subsystem, in the way a user calls the semget function multiple times, creating semaphores. This flaw allows a local user to starve the resources, causing a denial of service. The highest threat from this vulnerability is to system availability. |
["https://access.redhat.com/security/cve/CVE-2021-3759","https://bugzilla.redhat.com/show_bug.cgi?id=1999675","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lore.kernel.org/linux-mm/1626333284-1404-1-git-send-email-nglaive%40gmail.com/","https://access.redhat.com/security/cve/CVE-2021-3759","https://bugzilla.redhat.com/show_bug.cgi?id=1999675","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lore.kernel.org/linux-mm/1626333284-1404-1-git-send-email-nglaive%40gmail.com/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52622
|
Medium |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid online resizing failures due to oversized flex bg
When we online resize an ext4 filesystem with a oversized flexbg_size,
mkfs.ext4 -F -G 67108864 $dev -b 4096 100M
mount $dev $dir
resize2fs $dev 16G
the following WARN_ON is triggered:
==================================================================
WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550
Modules linked in: sg(E)
CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314
RIP: 0010:__alloc_pages+0x411/0x550
Call Trace:
<TASK>
__kmalloc_large_node+0xa2/0x200
__kmalloc+0x16e/0x290
ext4_resize_fs+0x481/0xd80
__ext4_ioctl+0x1616/0x1d90
ext4_ioctl+0x12/0x20
__x64_sys_ioctl+0xf0/0x150
do_syscall_64+0x3b/0x90
==================================================================
This is because flexbg_size is too large and the size of the new_group_data
array to be allocated exceeds MAX_ORDER. Currently, the minimum value of
MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding
maximum number of groups that can be allocated is:
(PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) ≈ 21845
And the value that is down-aligned to the power of 2 is 16384. Therefore,
this value is defined as MAX_RESIZE_BG, and the number of groups added
each time does not exceed this value during resizing, and is added multiple
times to complete the online resizing. The difference is that the metadata
in a flex_bg may be more dispersed. |
["https://git.kernel.org/stable/c/5d1935ac02ca5aee364a449a35e2977ea84509b0","https://git.kernel.org/stable/c/6d2cbf517dcabc093159cf138ad5712c9c7fa954","https://git.kernel.org/stable/c/8b1413dbfe49646eda2c00c0f1144ee9d3368e0c","https://git.kernel.org/stable/c/b183fe8702e78bba3dcef8e7193cab6898abee07","https://git.kernel.org/stable/c/cd1f93ca97a9136989f3bd2bf90696732a2ed644","https://git.kernel.org/stable/c/cfbbb3199e71b63fc26cee0ebff327c47128a1e8","https://git.kernel.org/stable/c/d76c8d7ffe163c6bf2f1ef680b0539c2b3902b90","https://git.kernel.org/stable/c/dc3e0f55bec4410f3d74352c4a7c79f518088ee2","https://git.kernel.org/stable/c/5d1935ac02ca5aee364a449a35e2977ea84509b0","https://git.kernel.org/stable/c/6d2cbf517dcabc093159cf138ad5712c9c7fa954","https://git.kernel.org/stable/c/8b1413dbfe49646eda2c00c0f1144ee9d3368e0c","https://git.kernel.org/stable/c/b183fe8702e78bba3dcef8e7193cab6898abee07","https://git.kernel.org/stable/c/cd1f93ca97a9136989f3bd2bf90696732a2ed644","https://git.kernel.org/stable/c/cfbbb3199e71b63fc26cee0ebff327c47128a1e8","https://git.kernel.org/stable/c/d76c8d7ffe163c6bf2f1ef680b0539c2b3902b90","https://git.kernel.org/stable/c/dc3e0f55bec4410f3d74352c4a7c79f518088ee2","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50001
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix error path in multi-packet WQE transmit
Remove the erroneous unmap in case no DMA mapping was established
The multi-packet WQE transmit code attempts to obtain a DMA mapping for
the skb. This could fail, e.g. under memory pressure, when the IOMMU
driver just can't allocate more memory for page tables. While the code
tries to handle this in the path below the err_unmap label it erroneously
unmaps one entry from the sq's FIFO list of active mappings. Since the
current map attempt failed this unmap is removing some random DMA mapping
that might still be required. If the PCI function now presents that IOVA,
the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI
function in error state.
The erroneous behavior was seen in a stress-test environment that created
memory pressure. |
["https://git.kernel.org/stable/c/26fad69b34fcba80d5c7d9e651f628e6ac927754","https://git.kernel.org/stable/c/2bcae12c795f32ddfbf8c80d1b5f1d3286341c32","https://git.kernel.org/stable/c/8bb8c12fb5e2b1f03d603d493c92941676f109b5","https://git.kernel.org/stable/c/ca36d6c1a49b6965c86dd528a73f38bc62d9c625","https://git.kernel.org/stable/c/ce828b347cf1b3c1b12b091d02463c35ce5097f5","https://git.kernel.org/stable/c/ecf310aaf256acbc8182189fe0aa1021c3ddef72","https://git.kernel.org/stable/c/fc357e78176945ca7bcacf92ab794b9ccd41b4f4"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52993
|
Medium |
fixed |
- 4.14.305
- 4.19.272
- 5.4.231
- 5.10.166
- 5.15.91
- 6.1.9
|
In the Linux kernel, the following vulnerability has been resolved:
x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL
Baoquan reported that after triggering a crash the subsequent crash-kernel
fails to boot about half of the time. It triggers a NULL pointer
dereference in the periodic tick code.
This happens because the legacy timer interrupt (IRQ0) is resent in
software which happens in soft interrupt (tasklet) context. In this context
get_irq_regs() returns NULL which leads to the NULL pointer dereference.
The reason for the resend is a spurious APIC interrupt on the IRQ0 vector
which is captured and leads to a resend when the legacy timer interrupt is
enabled. This is wrong because the legacy PIC interrupts are level
triggered and therefore should never be resent in software, but nothing
ever sets the IRQ_LEVEL flag on those interrupts, so the core code does not
know about their trigger type.
Ensure that IRQ_LEVEL is set when the legacy PCI interrupts are set up. |
["https://git.kernel.org/stable/c/0b08201158f177aab469e356b4d6af24fdd118df","https://git.kernel.org/stable/c/137f1b47da5f58805da42c1b7811e28c1e353f39","https://git.kernel.org/stable/c/496975d1a2937f4baadf3d985991b13fc4fc4f27","https://git.kernel.org/stable/c/5fa55950729d0762a787451dc52862c3f850f859","https://git.kernel.org/stable/c/744fe9be9665227335539b7a77ece8d9ff62b6c0","https://git.kernel.org/stable/c/8770cd9d7c14aa99c255a0d08186f0be953e1638","https://git.kernel.org/stable/c/e284c273dbb4c1ed68d4204bff94d0b10e4a90f5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-53005
|
Medium |
fixed |
- 4.19.272
- 5.4.231
- 5.10.166
- 5.15.91
- 6.1.9
|
In the Linux kernel, the following vulnerability has been resolved:
trace_events_hist: add check for return value of 'create_hist_field'
Function 'create_hist_field' is called recursively at
trace_events_hist.c:1954 and can return NULL-value that's why we have
to check it to avoid null pointer dereference.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/31b2414abeaa6de0490e85164badc6dcb1bb8ec9","https://git.kernel.org/stable/c/592ba7116fa620425725ff0972691f352ba3caf6","https://git.kernel.org/stable/c/886aa449235f478e262bbd5dcdee6ed6bc202949","https://git.kernel.org/stable/c/8b152e9150d07a885f95e1fd401fc81af202d9a4","https://git.kernel.org/stable/c/b4e7e81b4fdfcf457daee6b7a61769f62198d840","https://git.kernel.org/stable/c/d2d1ada58e7cc100b8d7d6b082d19321ba4a700a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-42752
|
Medium |
|
N/A
|
An integer overflow flaw was found in the Linux kernel. This issue leads to the kernel allocating `skb_shared_info` in the userspace, which is exploitable in systems without SMAP protection since `skb_shared_info` contains references to function pointers. |
["http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://access.redhat.com/security/cve/CVE-2023-42752","https://bugzilla.redhat.com/show_bug.cgi?id=2239828","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=915d975b2ffa","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=c3b704d4a4a2","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://access.redhat.com/security/cve/CVE-2023-42752","https://bugzilla.redhat.com/show_bug.cgi?id=2239828","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=915d975b2ffa","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=c3b704d4a4a2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49741
|
Medium |
fixed |
- 5.4.232
- 5.10.168
- 5.15.93
- 6.1.11
|
In the Linux kernel, the following vulnerability has been resolved:
fbdev: smscufx: fix error handling code in ufx_usb_probe
The current error handling code in ufx_usb_probe have many unmatching
issues, e.g., missing ufx_free_usb_list, destroy_modedb label should
only include framebuffer_release, fb_dealloc_cmap only matches
fb_alloc_cmap.
My local syzkaller reports a memory leak bug:
memory leak in ufx_usb_probe
BUG: memory leak
unreferenced object 0xffff88802f879580 (size 128):
comm "kworker/0:7", pid 17416, jiffies 4295067474 (age 46.710s)
hex dump (first 32 bytes):
80 21 7c 2e 80 88 ff ff 18 d0 d0 0c 80 88 ff ff .!|.............
00 d0 d0 0c 80 88 ff ff e0 ff ff ff 0f 00 00 00 ................
backtrace:
[<ffffffff814c99a0>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1045
[<ffffffff824d219c>] kmalloc include/linux/slab.h:553 [inline]
[<ffffffff824d219c>] kzalloc include/linux/slab.h:689 [inline]
[<ffffffff824d219c>] ufx_alloc_urb_list drivers/video/fbdev/smscufx.c:1873 [inline]
[<ffffffff824d219c>] ufx_usb_probe+0x11c/0x15a0 drivers/video/fbdev/smscufx.c:1655
[<ffffffff82d17927>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
[<ffffffff82712f0d>] call_driver_probe drivers/base/dd.c:560 [inline]
[<ffffffff82712f0d>] really_probe+0x12d/0x390 drivers/base/dd.c:639
[<ffffffff8271322f>] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778
[<ffffffff827132da>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:808
[<ffffffff82713c27>] __device_attach_driver+0xf7/0x150 drivers/base/dd.c:936
[<ffffffff82710137>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
[<ffffffff827136b5>] __device_attach+0x105/0x2d0 drivers/base/dd.c:1008
[<ffffffff82711d36>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487
[<ffffffff8270e242>] device_add+0x642/0xdc0 drivers/base/core.c:3517
[<ffffffff82d14d5f>] usb_set_configuration+0x8ef/0xb80 drivers/usb/core/message.c:2170
[<ffffffff82d2576c>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238
[<ffffffff82d16ffc>] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293
[<ffffffff82712f0d>] call_driver_probe drivers/base/dd.c:560 [inline]
[<ffffffff82712f0d>] really_probe+0x12d/0x390 drivers/base/dd.c:639
[<ffffffff8271322f>] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778
Fix this bug by rewriting the error handling code in ufx_usb_probe. |
["https://git.kernel.org/stable/c/1b4c08844628dfc8d72d3f51b657f2a5e63b7b4b","https://git.kernel.org/stable/c/3931014367ef31d26af65386a4ca496f50f0cfdf","https://git.kernel.org/stable/c/3b3d3127f5b4291ae4caaf50f7b66089ad600480","https://git.kernel.org/stable/c/64fa364ad3245508d393e16ed4886f92d7eb423c","https://git.kernel.org/stable/c/b76449ee75e21acfe9fa4c653d8598f191ed7d68"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49748
|
Medium |
fixed |
- 5.4.231
- 5.10.166
- 5.15.91
- 6.1.9
|
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/amd: fix potential integer overflow on shift of a int
The left shift of int 32 bit integer constant 1 is evaluated using 32 bit
arithmetic and then passed as a 64 bit function argument. In the case where
i is 32 or more this can lead to an overflow. Avoid this by shifting
using the BIT_ULL macro instead. |
["https://git.kernel.org/stable/c/08245672cdc6505550d1a5020603b0a8d4a6dcc7","https://git.kernel.org/stable/c/14cc13e433e1067557435b1adbf05608d7d47a93","https://git.kernel.org/stable/c/a4d01fb87ece45d4164fd725890211ccf9a307a9","https://git.kernel.org/stable/c/f84c9b72fb200633774704d8020f769c88a4b249","https://git.kernel.org/stable/c/fbf7b0e4cef3b5470b610f14fb9faa5ee7f63954"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52976
|
Medium |
fixed |
- 5.4.232
- 5.10.168
- 5.15.93
- 6.1.11
|
In the Linux kernel, the following vulnerability has been resolved:
efi: fix potential NULL deref in efi_mem_reserve_persistent
When iterating on a linked list, a result of memremap is dereferenced
without checking it for NULL.
This patch adds a check that falls back on allocating a new page in
case memremap doesn't succeed.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
[ardb: return -ENOMEM instead of breaking out of the loop] |
["https://git.kernel.org/stable/c/87d4ff18738fd71e7e3c10827c80257da6283697","https://git.kernel.org/stable/c/966d47e1f27c45507c5df82b2a2157e5a4fd3909","https://git.kernel.org/stable/c/a2e6a9ff89f13666a1c3ff7195612ab949ea9afc","https://git.kernel.org/stable/c/d8fc0b5fb3e816a4a8684bcd3ed02cbef0fce23c","https://git.kernel.org/stable/c/d92a25627bcdf264183670da73c9a60c0bac327e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-53026
|
Medium |
fixed |
- 5.4.231
- 5.10.166
- 5.15.91
- 6.1.9
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Fix ib block iterator counter overflow
When registering a new DMA MR after selecting the best aligned page size
for it, we iterate over the given sglist to split each entry to smaller,
aligned to the selected page size, DMA blocks.
In given circumstances where the sg entry and page size fit certain
sizes and the sg entry is not aligned to the selected page size, the
total size of the aligned pages we need to cover the sg entry is >= 4GB.
Under this circumstances, while iterating page aligned blocks, the
counter responsible for counting how much we advanced from the start of
the sg entry is overflowed because its type is u32 and we pass 4GB in
size. This can lead to an infinite loop inside the iterator function
because the overflow prevents the counter to be larger
than the size of the sg entry.
Fix the presented problem by changing the advancement condition to
eliminate overflow.
Backtrace:
[ 192.374329] efa_reg_user_mr_dmabuf
[ 192.376783] efa_register_mr
[ 192.382579] pgsz_bitmap 0xfffff000 rounddown 0x80000000
[ 192.386423] pg_sz [0x80000000] umem_length[0xc0000000]
[ 192.392657] start 0x0 length 0xc0000000 params.page_shift 31 params.page_num 3
[ 192.399559] hp_cnt[3], pages_in_hp[524288]
[ 192.403690] umem->sgt_append.sgt.nents[1]
[ 192.407905] number entries: [1], pg_bit: [31]
[ 192.411397] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8]
[ 192.415601] biter->__sg_advance [665837568] sg_dma_len[3221225472]
[ 192.419823] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8]
[ 192.423976] biter->__sg_advance [2813321216] sg_dma_len[3221225472]
[ 192.428243] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8]
[ 192.432397] biter->__sg_advance [665837568] sg_dma_len[3221225472] |
["https://git.kernel.org/stable/c/0afec5e9cea732cb47014655685a2a47fb180c31","https://git.kernel.org/stable/c/362c9489720b31b6aa7491423ba65a4e98aa9838","https://git.kernel.org/stable/c/43811d07ea64366af8ec9e168c558ec51440c39e","https://git.kernel.org/stable/c/902063a9fea5f8252df392ade746bc9cfd07a5ae","https://git.kernel.org/stable/c/d66c1d4178c219b6e7d7a6f714e3e3656faccc36"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26687
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
xen/events: close evtchn after mapping cleanup
shutdown_pirq and startup_pirq are not taking the
irq_mapping_update_lock because they can't due to lock inversion. Both
are called with the irq_desc->lock being taking. The lock order,
however, is first irq_mapping_update_lock and then irq_desc->lock.
This opens multiple races:
- shutdown_pirq can be interrupted by a function that allocates an event
channel:
CPU0 CPU1
shutdown_pirq {
xen_evtchn_close(e)
__startup_pirq {
EVTCHNOP_bind_pirq
-> returns just freed evtchn e
set_evtchn_to_irq(e, irq)
}
xen_irq_info_cleanup() {
set_evtchn_to_irq(e, -1)
}
}
Assume here event channel e refers here to the same event channel
number.
After this race the evtchn_to_irq mapping for e is invalid (-1).
- __startup_pirq races with __unbind_from_irq in a similar way. Because
__startup_pirq doesn't take irq_mapping_update_lock it can grab the
evtchn that __unbind_from_irq is currently freeing and cleaning up. In
this case even though the event channel is allocated, its mapping can
be unset in evtchn_to_irq.
The fix is to first cleanup the mappings and then close the event
channel. In this way, when an event channel gets allocated it's
potential previous evtchn_to_irq mappings are guaranteed to be unset already.
This is also the reverse order of the allocation where first the event
channel is allocated and then the mappings are setup.
On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal
[un]bind interfaces"), we hit a BUG like the following during probing of NVMe
devices. The issue is that during nvme_setup_io_queues, pci_free_irq
is called for every device which results in a call to shutdown_pirq.
With many nvme devices it's therefore likely to hit this race during
boot because there will be multiple calls to shutdown_pirq and
startup_pirq are running potentially in parallel.
------------[ cut here ]------------
blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled
kernel BUG at drivers/xen/events/events_base.c:499!
invalid opcode: 0000 [#1] SMP PTI
CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1
Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006
Workqueue: nvme-reset-wq nvme_reset_work
RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0
Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00
RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006
RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff
RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00
R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed
R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002
FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
? show_trace_log_lvl+0x1c1/0x2d9
? show_trace_log_lvl+0x1c1/0x2d9
? set_affinity_irq+0xdc/0x1c0
? __die_body.cold+0x8/0xd
? die+0x2b/0x50
? do_trap+0x90/0x110
? bind_evtchn_to_cpu+0xdf/0xf0
? do_error_trap+0x65/0x80
? bind_evtchn_to_cpu+0xdf/0xf0
? exc_invalid_op+0x4e/0x70
? bind_evtchn_to_cpu+0xdf/0xf0
? asm_exc_invalid_op+0x12/0x20
? bind_evtchn_to_cpu+0xdf/0x
---truncated--- |
["https://git.kernel.org/stable/c/0fc88aeb2e32b76db3fe6a624b8333dbe621b8fd","https://git.kernel.org/stable/c/20980195ec8d2e41653800c45c8c367fa1b1f2b4","https://git.kernel.org/stable/c/585a344af6bcac222608a158fc2830ff02712af5","https://git.kernel.org/stable/c/9470f5b2503cae994098dea9682aee15b313fa44","https://git.kernel.org/stable/c/9be71aa12afa91dfe457b3fb4a444c42b1ee036b","https://git.kernel.org/stable/c/ea592baf9e41779fe9a0424c03dd2f324feca3b3","https://git.kernel.org/stable/c/fa765c4b4aed2d64266b694520ecb025c862c5a9","https://git.kernel.org/stable/c/0fc88aeb2e32b76db3fe6a624b8333dbe621b8fd","https://git.kernel.org/stable/c/20980195ec8d2e41653800c45c8c367fa1b1f2b4","https://git.kernel.org/stable/c/585a344af6bcac222608a158fc2830ff02712af5","https://git.kernel.org/stable/c/9470f5b2503cae994098dea9682aee15b313fa44","https://git.kernel.org/stable/c/9be71aa12afa91dfe457b3fb4a444c42b1ee036b","https://git.kernel.org/stable/c/ea592baf9e41779fe9a0424c03dd2f324feca3b3","https://git.kernel.org/stable/c/fa765c4b4aed2d64266b694520ecb025c862c5a9","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26688
|
Medium |
fixed |
- 5.4.271
- 5.10.212
- 5.15.151
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
fs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super
When configuring a hugetlb filesystem via the fsconfig() syscall, there is
a possible NULL dereference in hugetlbfs_fill_super() caused by assigning
NULL to ctx->hstate in hugetlbfs_parse_param() when the requested pagesize
is non valid.
E.g: Taking the following steps:
fd = fsopen("hugetlbfs", FSOPEN_CLOEXEC);
fsconfig(fd, FSCONFIG_SET_STRING, "pagesize", "1024", 0);
fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);
Given that the requested "pagesize" is invalid, ctxt->hstate will be replaced
with NULL, losing its previous value, and we will print an error:
...
...
case Opt_pagesize:
ps = memparse(param->string, &rest);
ctx->hstate = h;
if (!ctx->hstate) {
pr_err("Unsupported page size %lu MB\n", ps / SZ_1M);
return -EINVAL;
}
return 0;
...
...
This is a problem because later on, we will dereference ctxt->hstate in
hugetlbfs_fill_super()
...
...
sb->s_blocksize = huge_page_size(ctx->hstate);
...
...
Causing below Oops.
Fix this by replacing cxt->hstate value only when then pagesize is known
to be valid.
kernel: hugetlbfs: Unsupported page size 0 MB
kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028
kernel: #PF: supervisor read access in kernel mode
kernel: #PF: error_code(0x0000) - not-present page
kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0
kernel: Oops: 0000 [#1] PREEMPT SMP PTI
kernel: CPU: 4 PID: 5659 Comm: syscall Tainted: G E 6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344aabc35190ae8f
kernel: Hardware name: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 05/03/2017
kernel: RIP: 0010:hugetlbfs_fill_super+0xb4/0x1a0
kernel: Code: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 <8b> 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28
kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246
kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004
kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff RDI: ffff9af555e9b000
kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004
kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000
kernel: R13: ffffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400
kernel: FS: 00007ffbc0ba4740(0000) GS:ffff9b0bd7000000(0000) knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0
kernel: Call Trace:
kernel: <TASK>
kernel: ? __die_body+0x1a/0x60
kernel: ? page_fault_oops+0x16f/0x4a0
kernel: ? search_bpf_extables+0x65/0x70
kernel: ? fixup_exception+0x22/0x310
kernel: ? exc_page_fault+0x69/0x150
kernel: ? asm_exc_page_fault+0x22/0x30
kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10
kernel: ? hugetlbfs_fill_super+0xb4/0x1a0
kernel: ? hugetlbfs_fill_super+0x28/0x1a0
kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10
kernel: vfs_get_super+0x40/0xa0
kernel: ? __pfx_bpf_lsm_capable+0x10/0x10
kernel: vfs_get_tree+0x25/0xd0
kernel: vfs_cmd_create+0x64/0xe0
kernel: __x64_sys_fsconfig+0x395/0x410
kernel: do_syscall_64+0x80/0x160
kernel: ? syscall_exit_to_user_mode+0x82/0x240
kernel: ? do_syscall_64+0x8d/0x160
kernel: ? syscall_exit_to_user_mode+0x82/0x240
kernel: ? do_syscall_64+0x8d/0x160
kernel: ? exc_page_fault+0x69/0x150
kernel: entry_SYSCALL_64_after_hwframe+0x6e/0x76
kernel: RIP: 0033:0x7ffbc0cb87c9
kernel: Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 97 96 0d 00 f7 d8 64 89 01 48
kernel: RSP: 002b:00007ffc29d2f388 EFLAGS: 00000206 ORIG_RAX: 00000000000001af
kernel: RAX: fffffffffff
---truncated--- |
["https://git.kernel.org/stable/c/13c5a9fb07105557a1fa9efdb4f23d7ef30b7274","https://git.kernel.org/stable/c/1dde8ef4b7a749ae1bc73617c91775631d167557","https://git.kernel.org/stable/c/22850c9950a4e43a67299755d11498f3292d02ff","https://git.kernel.org/stable/c/2e2c07104b4904aed1389a59b25799b95a85b5b9","https://git.kernel.org/stable/c/79d72c68c58784a3e1cd2378669d51bfd0cb7498","https://git.kernel.org/stable/c/80d852299987a8037be145a94f41874228f1a773","https://git.kernel.org/stable/c/ec78418801ef7b0c22cd6a30145ec480dd48db39","https://git.kernel.org/stable/c/13c5a9fb07105557a1fa9efdb4f23d7ef30b7274","https://git.kernel.org/stable/c/1dde8ef4b7a749ae1bc73617c91775631d167557","https://git.kernel.org/stable/c/22850c9950a4e43a67299755d11498f3292d02ff","https://git.kernel.org/stable/c/2e2c07104b4904aed1389a59b25799b95a85b5b9","https://git.kernel.org/stable/c/79d72c68c58784a3e1cd2378669d51bfd0cb7498","https://git.kernel.org/stable/c/80d852299987a8037be145a94f41874228f1a773","https://git.kernel.org/stable/c/ec78418801ef7b0c22cd6a30145ec480dd48db39","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26814
|
Medium |
fixed |
- 6.1.84
- 6.6.24
- 6.7.12
- 6.8.3
|
In the Linux kernel, the following vulnerability has been resolved:
vfio/fsl-mc: Block calling interrupt handler without trigger
The eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is
initially NULL and may become NULL if the user sets the trigger
eventfd to -1. The interrupt handler itself is guaranteed that
trigger is always valid between request_irq() and free_irq(), but
the loopback testing mechanisms to invoke the handler function
need to test the trigger. The triggering and setting ioctl paths
both make use of igate and are therefore mutually exclusive.
The vfio-fsl-mc driver does not make use of irqfds, nor does it
support any sort of masking operations, therefore unlike vfio-pci
and vfio-platform, the flow can remain essentially unchanged. |
["https://git.kernel.org/stable/c/083e750c9f5f4c3bf61161330fb84d7c8e8bb417","https://git.kernel.org/stable/c/250219c6a556f8c69c5910fca05a59037e24147d","https://git.kernel.org/stable/c/6ec0d88166dac43f29e96801c0927d514f17add9","https://git.kernel.org/stable/c/7447d911af699a15f8d050dfcb7c680a86f87012","https://git.kernel.org/stable/c/a563fc18583ca4f42e2fdd0c70c7c618288e7ede","https://git.kernel.org/stable/c/de87511fb0404d23b6da5f4660383b6ed095e28d","https://git.kernel.org/stable/c/ee0bd4ad780dfbb60355b99f25063357ab488267","https://git.kernel.org/stable/c/083e750c9f5f4c3bf61161330fb84d7c8e8bb417","https://git.kernel.org/stable/c/250219c6a556f8c69c5910fca05a59037e24147d","https://git.kernel.org/stable/c/6ec0d88166dac43f29e96801c0927d514f17add9","https://git.kernel.org/stable/c/7447d911af699a15f8d050dfcb7c680a86f87012","https://git.kernel.org/stable/c/a563fc18583ca4f42e2fdd0c70c7c618288e7ede","https://git.kernel.org/stable/c/de87511fb0404d23b6da5f4660383b6ed095e28d","https://git.kernel.org/stable/c/ee0bd4ad780dfbb60355b99f25063357ab488267","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49752
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
device property: fix of node refcount leak in fwnode_graph_get_next_endpoint()
The 'parent' returned by fwnode_graph_get_port_parent()
with refcount incremented when 'prev' is not NULL, it
needs be put when finish using it.
Because the parent is const, introduce a new variable to
store the returned fwnode, then put it before returning
from fwnode_graph_get_next_endpoint(). |
["https://git.kernel.org/stable/c/39af728649b05e88a2b40e714feeee6451c3f18e","https://git.kernel.org/stable/c/7701a4bd45c11f9a289d8f262fad05705a012339","https://git.kernel.org/stable/c/e75485fc589ec729cc182aa9b41dfb6c15ae6f6e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52936
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
kernel/irq/irqdomain.c: fix memory leak with using debugfs_lookup()
When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once. |
["https://git.kernel.org/stable/c/066ecbf1a53eb0b92b10c8df7808666be6ea5681","https://git.kernel.org/stable/c/cf1c917bf1c761a557b26410024e90057646c049","https://git.kernel.org/stable/c/d83d7ed260283560700d4034a80baad46620481b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49742
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: initialize locks earlier in f2fs_fill_super()
syzbot is reporting lockdep warning at f2fs_handle_error() [1], for
spin_lock(&sbi->error_lock) is called before spin_lock_init() is called.
For safe locking in error handling, move initialization of locks (and
obvious structures) in f2fs_fill_super() to immediately after memory
allocation. |
["https://git.kernel.org/stable/c/92b4cf5b48955a4bdd15fe4e2067db8ebd87f04c","https://git.kernel.org/stable/c/ddeff03bb33810fcf2f0c18e03d099cf0aacda62"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52429
|
Medium |
fixed |
- 5.10.210
- 5.15.149
- 6.1.79
- 6.6.18
- 6.7.6
|
dm_table_create in drivers/md/dm-table.c in the Linux kernel through 6.7.4 can attempt to (in alloc_targets) allocate more than INT_MAX bytes, and crash, because of a missing check for struct dm_ioctl.target_count. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd504bcfec41a503b32054da5472904b404341a4","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3LZROQAX7Q7LEP4F7WQ3KUZKWCZGFFP2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GS7S3XLTLOUKBXV67LLFZWB3YVFJZHRK/","https://www.spinics.net/lists/dm-devel/msg56625.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd504bcfec41a503b32054da5472904b404341a4","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3LZROQAX7Q7LEP4F7WQ3KUZKWCZGFFP2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GS7S3XLTLOUKBXV67LLFZWB3YVFJZHRK/","https://www.spinics.net/lists/dm-devel/msg56625.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-53090
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
afs: Fix lock recursion
afs_wake_up_async_call() can incur lock recursion. The problem is that it
is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to
take a ref on the afs_call struct in order to pass it to a work queue - but
if the afs_call is already queued, we then have an extraneous ref that must
be put... calling afs_put_call() may call back down into AF_RXRPC through
rxrpc_kernel_shutdown_call(), however, which might try taking the
->notify_lock again.
This case isn't very common, however, so defer it to a workqueue. The oops
looks something like:
BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646
lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0
CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351
Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
Call Trace:
<TASK>
dump_stack_lvl+0x47/0x70
do_raw_spin_lock+0x3c/0x90
rxrpc_kernel_shutdown_call+0x83/0xb0
afs_put_call+0xd7/0x180
rxrpc_notify_socket+0xa0/0x190
rxrpc_input_split_jumbo+0x198/0x1d0
rxrpc_input_data+0x14b/0x1e0
? rxrpc_input_call_packet+0xc2/0x1f0
rxrpc_input_call_event+0xad/0x6b0
rxrpc_input_packet_on_conn+0x1e1/0x210
rxrpc_input_packet+0x3f2/0x4d0
rxrpc_io_thread+0x243/0x410
? __pfx_rxrpc_io_thread+0x10/0x10
kthread+0xcf/0xe0
? __pfx_kthread+0x10/0x10
ret_from_fork+0x24/0x40
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK> |
["https://git.kernel.org/stable/c/610a79ffea02102899a1373fe226d949944a7ed6","https://git.kernel.org/stable/c/d7cbf81df996b1eae2dee8deb6df08e2eba78661"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26600
|
Medium |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.78
- 6.6.17
- 6.7.5
|
In the Linux kernel, the following vulnerability has been resolved:
phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP
If the external phy working together with phy-omap-usb2 does not implement
send_srp(), we may still attempt to call it. This can happen on an idle
Ethernet gadget triggering a wakeup for example:
configfs-gadget.g1 gadget.0: ECM Suspend
configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup
...
Unable to handle kernel NULL pointer dereference at virtual address
00000000 when execute
...
PC is at 0x0
LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc]
...
musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core]
usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether]
eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c
dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4
sch_direct_xmit from __dev_queue_xmit+0x334/0xd88
__dev_queue_xmit from arp_solicit+0xf0/0x268
arp_solicit from neigh_probe+0x54/0x7c
neigh_probe from __neigh_event_send+0x22c/0x47c
__neigh_event_send from neigh_resolve_output+0x14c/0x1c0
neigh_resolve_output from ip_finish_output2+0x1c8/0x628
ip_finish_output2 from ip_send_skb+0x40/0xd8
ip_send_skb from udp_send_skb+0x124/0x340
udp_send_skb from udp_sendmsg+0x780/0x984
udp_sendmsg from __sys_sendto+0xd8/0x158
__sys_sendto from ret_fast_syscall+0x0/0x58
Let's fix the issue by checking for send_srp() and set_vbus() before
calling them. For USB peripheral only cases these both could be NULL. |
["https://git.kernel.org/stable/c/0430bfcd46657d9116a26cd377f112cbc40826a4","https://git.kernel.org/stable/c/14ef61594a5a286ae0d493b8acbf9eac46fd04c4","https://git.kernel.org/stable/c/396e17af6761b3cc9e6e4ca94b4de7f642bfece1","https://git.kernel.org/stable/c/486218c11e8d1c8f515a3bdd70d62203609d4b6b","https://git.kernel.org/stable/c/7104ba0f1958adb250319e68a15eff89ec4fd36d","https://git.kernel.org/stable/c/8398d8d735ee93a04fb9e9f490e8cacd737e3bf5","https://git.kernel.org/stable/c/8cc889b9dea0579726be9520fcc766077890b462","https://git.kernel.org/stable/c/be3b82e4871ba00e9b5d0ede92d396d579d7b3b3","https://git.kernel.org/stable/c/0430bfcd46657d9116a26cd377f112cbc40826a4","https://git.kernel.org/stable/c/14ef61594a5a286ae0d493b8acbf9eac46fd04c4","https://git.kernel.org/stable/c/396e17af6761b3cc9e6e4ca94b4de7f642bfece1","https://git.kernel.org/stable/c/486218c11e8d1c8f515a3bdd70d62203609d4b6b","https://git.kernel.org/stable/c/7104ba0f1958adb250319e68a15eff89ec4fd36d","https://git.kernel.org/stable/c/8398d8d735ee93a04fb9e9f490e8cacd737e3bf5","https://git.kernel.org/stable/c/8cc889b9dea0579726be9520fcc766077890b462","https://git.kernel.org/stable/c/be3b82e4871ba00e9b5d0ede92d396d579d7b3b3","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52449
|
Medium |
fixed |
- 4.19.306
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
mtd: Fix gluebi NULL pointer dereference caused by ftl notifier
If both ftl.ko and gluebi.ko are loaded, the notifier of ftl
triggers NULL pointer dereference when trying to access
‘gluebi->desc’ in gluebi_read().
ubi_gluebi_init
ubi_register_volume_notifier
ubi_enumerate_volumes
ubi_notify_all
gluebi_notify nb->notifier_call()
gluebi_create
mtd_device_register
mtd_device_parse_register
add_mtd_device
blktrans_notify_add not->add()
ftl_add_mtd tr->add_mtd()
scan_header
mtd_read
mtd_read_oob
mtd_read_oob_std
gluebi_read mtd->read()
gluebi->desc - NULL
Detailed reproduction information available at the Link [1],
In the normal case, obtain gluebi->desc in the gluebi_get_device(),
and access gluebi->desc in the gluebi_read(). However,
gluebi_get_device() is not executed in advance in the
ftl_add_mtd() process, which leads to NULL pointer dereference.
The solution for the gluebi module is to run jffs2 on the UBI
volume without considering working with ftl or mtdblock [2].
Therefore, this problem can be avoided by preventing gluebi from
creating the mtdblock device after creating mtd partition of the
type MTD_UBIVOLUME. |
["https://git.kernel.org/stable/c/001a3f59d8c914ef8273461d4bf495df384cc5f8","https://git.kernel.org/stable/c/1bf4fe14e97cda621522eb2f28b0a4e87c5b0745","https://git.kernel.org/stable/c/5389407bba1eab1266c6d83e226fb0840cb98dd5","https://git.kernel.org/stable/c/a43bdc376deab5fff1ceb93dca55bcab8dbdc1d6","https://git.kernel.org/stable/c/aeba358bcc8ffddf9b4a9bd0e5ec9eb338d46022","https://git.kernel.org/stable/c/b36aaa64d58aaa2f2cbc8275e89bae76a2b6c3dc","https://git.kernel.org/stable/c/cfd7c9d260dc0a3baaea05a122a19ab91e193c65","https://git.kernel.org/stable/c/d8ac2537763b54d278b80b2b080e1652523c7d4c","https://git.kernel.org/stable/c/001a3f59d8c914ef8273461d4bf495df384cc5f8","https://git.kernel.org/stable/c/1bf4fe14e97cda621522eb2f28b0a4e87c5b0745","https://git.kernel.org/stable/c/5389407bba1eab1266c6d83e226fb0840cb98dd5","https://git.kernel.org/stable/c/a43bdc376deab5fff1ceb93dca55bcab8dbdc1d6","https://git.kernel.org/stable/c/aeba358bcc8ffddf9b4a9bd0e5ec9eb338d46022","https://git.kernel.org/stable/c/b36aaa64d58aaa2f2cbc8275e89bae76a2b6c3dc","https://git.kernel.org/stable/c/cfd7c9d260dc0a3baaea05a122a19ab91e193c65","https://git.kernel.org/stable/c/d8ac2537763b54d278b80b2b080e1652523c7d4c","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52619
|
Medium |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
pstore/ram: Fix crash when setting number of cpus to an odd number
When the number of cpu cores is adjusted to 7 or other odd numbers,
the zone size will become an odd number.
The address of the zone will become:
addr of zone0 = BASE
addr of zone1 = BASE + zone_size
addr of zone2 = BASE + zone_size*2
...
The address of zone1/3/5/7 will be mapped to non-alignment va.
Eventually crashes will occur when accessing these va.
So, use ALIGN_DOWN() to make sure the zone size is even
to avoid this bug. |
["https://git.kernel.org/stable/c/0593cfd321df9001142a9d2c58d4144917dff7ee","https://git.kernel.org/stable/c/2a37905d47bffec61e95d99f0c1cc5dc6377956c","https://git.kernel.org/stable/c/75b0f71b26b3ad833c5c0670109c0af6e021e86a","https://git.kernel.org/stable/c/8b69c30f4e8b69131d92096cb296dc1f217101e4","https://git.kernel.org/stable/c/a63e48cd835c34c38ef671d344cc029b1ea5bf10","https://git.kernel.org/stable/c/cd40e43f870cf21726b22487a95ed223790b3542","https://git.kernel.org/stable/c/d49270a04623ce3c0afddbf3e984cb245aa48e9c","https://git.kernel.org/stable/c/e9f6ac50890104fdf8194f2865680689239d30fb","https://git.kernel.org/stable/c/0593cfd321df9001142a9d2c58d4144917dff7ee","https://git.kernel.org/stable/c/2a37905d47bffec61e95d99f0c1cc5dc6377956c","https://git.kernel.org/stable/c/75b0f71b26b3ad833c5c0670109c0af6e021e86a","https://git.kernel.org/stable/c/8b69c30f4e8b69131d92096cb296dc1f217101e4","https://git.kernel.org/stable/c/a63e48cd835c34c38ef671d344cc029b1ea5bf10","https://git.kernel.org/stable/c/cd40e43f870cf21726b22487a95ed223790b3542","https://git.kernel.org/stable/c/d49270a04623ce3c0afddbf3e984cb245aa48e9c","https://git.kernel.org/stable/c/e9f6ac50890104fdf8194f2865680689239d30fb","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26606
|
Medium |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
binder: signal epoll threads of self-work
In (e)poll mode, threads often depend on I/O events to determine when
data is ready for consumption. Within binder, a thread may initiate a
command via BINDER_WRITE_READ without a read buffer and then make use
of epoll_wait() or similar to consume any responses afterwards.
It is then crucial that epoll threads are signaled via wakeup when they
queue their own work. Otherwise, they risk waiting indefinitely for an
event leaving their work unhandled. What is worse, subsequent commands
won't trigger a wakeup either as the thread has pending work. |
["https://git.kernel.org/stable/c/42beab162dcee1e691ee4934292d51581c29df61","https://git.kernel.org/stable/c/82722b453dc2f967b172603e389ee7dc1b3137cc","https://git.kernel.org/stable/c/90e09c016d72b91e76de25f71c7b93d94cc3c769","https://git.kernel.org/stable/c/93b372c39c40cbf179e56621e6bc48240943af69","https://git.kernel.org/stable/c/97830f3c3088638ff90b20dfba2eb4d487bf14d7","https://git.kernel.org/stable/c/a423042052ec2bdbf1e552e621e6a768922363cc","https://git.kernel.org/stable/c/a7ae586f6f6024f490b8546c8c84670f96bb9b68","https://git.kernel.org/stable/c/dd64bb8329ce0ea27bc557e4160c2688835402ac","https://git.kernel.org/stable/c/42beab162dcee1e691ee4934292d51581c29df61","https://git.kernel.org/stable/c/82722b453dc2f967b172603e389ee7dc1b3137cc","https://git.kernel.org/stable/c/90e09c016d72b91e76de25f71c7b93d94cc3c769","https://git.kernel.org/stable/c/93b372c39c40cbf179e56621e6bc48240943af69","https://git.kernel.org/stable/c/97830f3c3088638ff90b20dfba2eb4d487bf14d7","https://git.kernel.org/stable/c/a423042052ec2bdbf1e552e621e6a768922363cc","https://git.kernel.org/stable/c/a7ae586f6f6024f490b8546c8c84670f96bb9b68","https://git.kernel.org/stable/c/dd64bb8329ce0ea27bc557e4160c2688835402ac","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49749
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
i2c: designware: use casting of u64 in clock multiplication to avoid overflow
In functions i2c_dw_scl_lcnt() and i2c_dw_scl_hcnt() may have overflow
by depending on the values of the given parameters including the ic_clk.
For example in our use case where ic_clk is larger than one million,
multiplication of ic_clk * 4700 will result in 32 bit overflow.
Add cast of u64 to the calculation to avoid multiplication overflow, and
use the corresponding define for divide. |
["https://git.kernel.org/stable/c/2f29d780bd691d20e89e5b35d5e6568607115e94","https://git.kernel.org/stable/c/9f36aae9e80e79b7a6d62227eaa96935166be9fe","https://git.kernel.org/stable/c/c8c37bc514514999e62a17e95160ed9ebf75ca8d","https://git.kernel.org/stable/c/ed173f77fd28a3e4fffc13b3f28687b9eba61157"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52984
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: phy: dp83822: Fix null pointer access on DP83825/DP83826 devices
The probe() function is only used for the DP83822 PHY, leaving the
private data pointer uninitialized for the smaller DP83825/26 models.
While all uses of the private data structure are hidden in 82822 specific
callbacks, configuring the interrupt is shared across all models.
This causes a NULL pointer dereference on the smaller PHYs as it accesses
the private data unchecked. Verifying the pointer avoids that. |
["https://git.kernel.org/stable/c/2cd1e9c013ec56421c58921b1ddf1d2d53bd47fa","https://git.kernel.org/stable/c/362a2f5531dc0e5b0b5b3e3a541000dbffa75461","https://git.kernel.org/stable/c/422ae7d9c7221e8d4c8526d0f54106307d69d2dc","https://git.kernel.org/stable/c/78901b10522cdf6badf24acf65a892637596bccc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26640
|
Medium |
fixed |
- 5.10.210
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: add sanity checks to rx zerocopy
TCP rx zerocopy intent is to map pages initially allocated
from NIC drivers, not pages owned by a fs.
This patch adds to can_map_frag() these additional checks:
- Page must not be a compound one.
- page->mapping must be NULL.
This fixes the panic reported by ZhangPeng.
syzbot was able to loopback packets built with sendfile(),
mapping pages owned by an ext4 file to TCP rx zerocopy.
r3 = socket$inet_tcp(0x2, 0x1, 0x0)
mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0)
r4 = socket$inet_tcp(0x2, 0x1, 0x0)
bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10)
connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10)
r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00',
0x181e42, 0x0)
fallocate(r5, 0x0, 0x0, 0x85b8)
sendfile(r4, r5, 0x0, 0x8ba0)
getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23,
&(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40)
r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00',
0x181e42, 0x0) |
["https://git.kernel.org/stable/c/1b8adcc0e2c584fec778add7777fe28e20781e60","https://git.kernel.org/stable/c/577e4432f3ac810049cb7e6b71f4d96ec7c6e894","https://git.kernel.org/stable/c/718f446e60316bf606946f7f42367d691d21541e","https://git.kernel.org/stable/c/b383d4ea272fe5795877506dcce5aad1f6330e5e","https://git.kernel.org/stable/c/d15cc0f66884ef2bed28c7ccbb11c102aa3a0760","https://git.kernel.org/stable/c/f48bf9a83b1666d934247cb58a9887d7b3127b6f","https://git.kernel.org/stable/c/1b8adcc0e2c584fec778add7777fe28e20781e60","https://git.kernel.org/stable/c/577e4432f3ac810049cb7e6b71f4d96ec7c6e894","https://git.kernel.org/stable/c/718f446e60316bf606946f7f42367d691d21541e","https://git.kernel.org/stable/c/b383d4ea272fe5795877506dcce5aad1f6330e5e","https://git.kernel.org/stable/c/d15cc0f66884ef2bed28c7ccbb11c102aa3a0760","https://git.kernel.org/stable/c/f48bf9a83b1666d934247cb58a9887d7b3127b6f","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26773
|
Medium |
fixed |
- 4.19.308
- 5.4.270
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found()
Determine if the group block bitmap is corrupted before using ac_b_ex in
ext4_mb_try_best_found() to avoid allocating blocks from a group with a
corrupted block bitmap in the following concurrency and making the
situation worse.
ext4_mb_regular_allocator
ext4_lock_group(sb, group)
ext4_mb_good_group
// check if the group bbitmap is corrupted
ext4_mb_complex_scan_group
// Scan group gets ac_b_ex but doesn't use it
ext4_unlock_group(sb, group)
ext4_mark_group_bitmap_corrupted(group)
// The block bitmap was corrupted during
// the group unlock gap.
ext4_mb_try_best_found
ext4_lock_group(ac->ac_sb, group)
ext4_mb_use_best_found
mb_mark_used
// Allocating blocks in block bitmap corrupted group |
["https://git.kernel.org/stable/c/0184747b552d6b5a14db3b7fcc3b792ce64dedd1","https://git.kernel.org/stable/c/21f8cfe79f776287459343e9cfa6055af61328ea","https://git.kernel.org/stable/c/260fc96283c0f594de18a1b045faf6d8fb42874d","https://git.kernel.org/stable/c/4530b3660d396a646aad91a787b6ab37cf604b53","https://git.kernel.org/stable/c/4c21fa60a6f4606f6214a38f50612b17b2f738f5","https://git.kernel.org/stable/c/927794a02169778c9c2e7b25c768ab3ea8c1dc03","https://git.kernel.org/stable/c/a2576ae9a35c078e488f2c573e9e6821d651fbbe","https://git.kernel.org/stable/c/f97e75fa4e12b0aa0224e83fcbda8853ac2adf36","https://git.kernel.org/stable/c/0184747b552d6b5a14db3b7fcc3b792ce64dedd1","https://git.kernel.org/stable/c/21f8cfe79f776287459343e9cfa6055af61328ea","https://git.kernel.org/stable/c/260fc96283c0f594de18a1b045faf6d8fb42874d","https://git.kernel.org/stable/c/4530b3660d396a646aad91a787b6ab37cf604b53","https://git.kernel.org/stable/c/4c21fa60a6f4606f6214a38f50612b17b2f738f5","https://git.kernel.org/stable/c/927794a02169778c9c2e7b25c768ab3ea8c1dc03","https://git.kernel.org/stable/c/a2576ae9a35c078e488f2c573e9e6821d651fbbe","https://git.kernel.org/stable/c/f97e75fa4e12b0aa0224e83fcbda8853ac2adf36","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49932
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't readahead the relocation inode on RST
On relocation we're doing readahead on the relocation inode, but if the
filesystem is backed by a RAID stripe tree we can get ENOENT (e.g. due to
preallocated extents not being mapped in the RST) from the lookup.
But readahead doesn't handle the error and submits invalid reads to the
device, causing an assertion in the scatter-gather list code:
BTRFS info (device nvme1n1): balance: start -d -m -s
BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0
BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0
------------[ cut here ]------------
kernel BUG at include/linux/scatterlist.h:115!
Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI
CPU: 0 PID: 1012 Comm: btrfs Not tainted 6.10.0-rc7+ #567
RIP: 0010:__blk_rq_map_sg+0x339/0x4a0
RSP: 0018:ffffc90001a43820 EFLAGS: 00010202
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802
RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000
RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8
R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000
FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0
Call Trace:
<TASK>
? __die_body.cold+0x14/0x25
? die+0x2e/0x50
? do_trap+0xca/0x110
? do_error_trap+0x65/0x80
? __blk_rq_map_sg+0x339/0x4a0
? exc_invalid_op+0x50/0x70
? __blk_rq_map_sg+0x339/0x4a0
? asm_exc_invalid_op+0x1a/0x20
? __blk_rq_map_sg+0x339/0x4a0
nvme_prep_rq.part.0+0x9d/0x770
nvme_queue_rq+0x7d/0x1e0
__blk_mq_issue_directly+0x2a/0x90
? blk_mq_get_budget_and_tag+0x61/0x90
blk_mq_try_issue_list_directly+0x56/0xf0
blk_mq_flush_plug_list.part.0+0x52b/0x5d0
__blk_flush_plug+0xc6/0x110
blk_finish_plug+0x28/0x40
read_pages+0x160/0x1c0
page_cache_ra_unbounded+0x109/0x180
relocate_file_extent_cluster+0x611/0x6a0
? btrfs_search_slot+0xba4/0xd20
? balance_dirty_pages_ratelimited_flags+0x26/0xb00
relocate_data_extent.constprop.0+0x134/0x160
relocate_block_group+0x3f2/0x500
btrfs_relocate_block_group+0x250/0x430
btrfs_relocate_chunk+0x3f/0x130
btrfs_balance+0x71b/0xef0
? kmalloc_trace_noprof+0x13b/0x280
btrfs_ioctl+0x2c2e/0x3030
? kvfree_call_rcu+0x1e6/0x340
? list_lru_add_obj+0x66/0x80
? mntput_no_expire+0x3a/0x220
__x64_sys_ioctl+0x96/0xc0
do_syscall_64+0x54/0x110
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7fcc04514f9b
Code: Unable to access opcode bytes at 0x7fcc04514f71.
RSP: 002b:00007ffeba923370 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fcc04514f9b
RDX: 00007ffeba923460 RSI: 00000000c4009420 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000013 R09: 0000000000000001
R10: 00007fcc043fbba8 R11: 0000000000000246 R12: 00007ffeba924fc5
R13: 00007ffeba923460 R14: 0000000000000002 R15: 00000000004d4bb0
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:__blk_rq_map_sg+0x339/0x4a0
RSP: 0018:ffffc90001a43820 EFLAGS: 00010202
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802
RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000
RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8
R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000
FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fcc04514f71 CR3: 00000001109ea001 CR4: 0000000000370eb0
Kernel p
---truncated--- |
["https://git.kernel.org/stable/c/04915240e2c3a018e4c7f23418478d27226c8957","https://git.kernel.org/stable/c/f7a1218a983ab98aba140dc20b25f60b39ee4033"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26651
|
Medium |
fixed |
- 4.19.311
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
sr9800: Add check for usbnet_get_endpoints
Add check for usbnet_get_endpoints() and return the error if it fails
in order to transfer the error. |
["https://git.kernel.org/stable/c/07161b2416f740a2cb87faa5566873f401440a61","https://git.kernel.org/stable/c/276873ae26c8d75b00747c1dadb9561d6ef20581","https://git.kernel.org/stable/c/424eba06ed405d557077339edb19ce0ebe39e7c7","https://git.kernel.org/stable/c/6b4a39acafaf0186ed8e97c16e0aa6fca0e52009","https://git.kernel.org/stable/c/8a8b6a24684bc278036c3f159f7b3a31ad89546a","https://git.kernel.org/stable/c/9c402819620a842cbfe39359a3ddfaac9adc8384","https://git.kernel.org/stable/c/e39a3a14eafcf17f03c037290b78c8f483529028","https://git.kernel.org/stable/c/efba65777f98457773c5b65e3135c6132d3b015f","https://git.kernel.org/stable/c/f546cc19f9b82975238d0ba413adc27714750774","https://git.kernel.org/stable/c/07161b2416f740a2cb87faa5566873f401440a61","https://git.kernel.org/stable/c/276873ae26c8d75b00747c1dadb9561d6ef20581","https://git.kernel.org/stable/c/424eba06ed405d557077339edb19ce0ebe39e7c7","https://git.kernel.org/stable/c/6b4a39acafaf0186ed8e97c16e0aa6fca0e52009","https://git.kernel.org/stable/c/8a8b6a24684bc278036c3f159f7b3a31ad89546a","https://git.kernel.org/stable/c/9c402819620a842cbfe39359a3ddfaac9adc8384","https://git.kernel.org/stable/c/e39a3a14eafcf17f03c037290b78c8f483529028","https://git.kernel.org/stable/c/efba65777f98457773c5b65e3135c6132d3b015f","https://git.kernel.org/stable/c/f546cc19f9b82975238d0ba413adc27714750774","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3344
|
Medium |
|
N/A
|
A flaw was found in the KVM's AMD nested virtualization (SVM). A malicious L1 guest could purposely fail to intercept the shutdown of a cooperative nested guest (L2), possibly leading to a page fault and kernel panic in the host (L0). |
["https://bugzilla.redhat.com/show_bug.cgi?id=2130278","https://lore.kernel.org/lkml/20221020093055.224317-5-mlevitsk%40redhat.com/T/","https://bugzilla.redhat.com/show_bug.cgi?id=2130278","https://lore.kernel.org/lkml/20221020093055.224317-5-mlevitsk%40redhat.com/T/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52616
|
Medium |
fixed |
- 5.10.210
- 5.15.149
- 6.1.79
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init
When the mpi_ec_ctx structure is initialized, some fields are not
cleared, causing a crash when referencing the field when the
structure was released. Initially, this issue was ignored because
memory for mpi_ec_ctx is allocated with the __GFP_ZERO flag.
For example, this error will be triggered when calculating the
Za value for SM2 separately. |
["https://git.kernel.org/stable/c/0c3687822259a7628c85cd21a3445cbe3c367165","https://git.kernel.org/stable/c/2bb86817b33c9d704e127f92b838035a72c315b6","https://git.kernel.org/stable/c/7abdfd45a650c714d5ebab564bb1b988f14d9b49","https://git.kernel.org/stable/c/7ebf812b7019fd2d4d5a7ca45ef4bf3a6f4bda0a","https://git.kernel.org/stable/c/ba3c5574203034781ac4231acf117da917efcd2a","https://git.kernel.org/stable/c/bb44477d4506e52785693a39f03cdc6a2c5e8598","https://git.kernel.org/stable/c/0c3687822259a7628c85cd21a3445cbe3c367165","https://git.kernel.org/stable/c/2bb86817b33c9d704e127f92b838035a72c315b6","https://git.kernel.org/stable/c/7abdfd45a650c714d5ebab564bb1b988f14d9b49","https://git.kernel.org/stable/c/7ebf812b7019fd2d4d5a7ca45ef4bf3a6f4bda0a","https://git.kernel.org/stable/c/ba3c5574203034781ac4231acf117da917efcd2a","https://git.kernel.org/stable/c/bb44477d4506e52785693a39f03cdc6a2c5e8598","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26627
|
Medium |
fixed |
- 5.10.210
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler
Inside scsi_eh_wakeup(), scsi_host_busy() is called & checked with host
lock every time for deciding if error handler kthread needs to be waken up.
This can be too heavy in case of recovery, such as:
- N hardware queues
- queue depth is M for each hardware queue
- each scsi_host_busy() iterates over (N * M) tag/requests
If recovery is triggered in case that all requests are in-flight, each
scsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is called
for the last in-flight request, scsi_host_busy() has been run for (N * M -
1) times, and request has been iterated for (N*M - 1) * (N * M) times.
If both N and M are big enough, hard lockup can be triggered on acquiring
host lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169).
Fix the issue by calling scsi_host_busy() outside the host lock. We don't
need the host lock for getting busy count because host the lock never
covers that.
[mkp: Drop unnecessary 'busy' variables pointed out by Bart] |
["https://git.kernel.org/stable/c/07e3ca0f17f579491b5f54e9ed05173d6c1d6fcb","https://git.kernel.org/stable/c/4373534a9850627a2695317944898eb1283a2db0","https://git.kernel.org/stable/c/65ead8468c21c2676d4d06f50b46beffdea69df1","https://git.kernel.org/stable/c/d37c1c81419fdef66ebd0747cf76fb8b7d979059","https://git.kernel.org/stable/c/db6338f45971b4285ea368432a84033690eaf53c","https://git.kernel.org/stable/c/f5944853f7a961fedc1227dc8f60393f8936d37c","https://git.kernel.org/stable/c/07e3ca0f17f579491b5f54e9ed05173d6c1d6fcb","https://git.kernel.org/stable/c/4373534a9850627a2695317944898eb1283a2db0","https://git.kernel.org/stable/c/65ead8468c21c2676d4d06f50b46beffdea69df1","https://git.kernel.org/stable/c/d37c1c81419fdef66ebd0747cf76fb8b7d979059","https://git.kernel.org/stable/c/db6338f45971b4285ea368432a84033690eaf53c","https://git.kernel.org/stable/c/f5944853f7a961fedc1227dc8f60393f8936d37c","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-2177
|
Medium |
fixed |
|
A null pointer dereference issue was found in the sctp network protocol in net/sctp/stream_sched.c in Linux Kernel. If stream_in allocation is failed, stream_out is freed which would further be accessed. A local user could use this flaw to crash the system or potentially cause a denial of service. |
["https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=181d8d2066c0","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=181d8d2066c0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52458
|
Medium |
fixed |
- 5.10.215
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
block: add check that partition length needs to be aligned with block size
Before calling add partition or resize partition, there is no check
on whether the length is aligned with the logical block size.
If the logical block size of the disk is larger than 512 bytes,
then the partition size maybe not the multiple of the logical block size,
and when the last sector is read, bio_truncate() will adjust the bio size,
resulting in an IO error if the size of the read command is smaller than
the logical block size.If integrity data is supported, this will also
result in a null pointer dereference when calling bio_integrity_free. |
["https://git.kernel.org/stable/c/5010c27120962c85d2f421d2cf211791c9603503","https://git.kernel.org/stable/c/6f64f866aa1ae6975c95d805ed51d7e9433a0016","https://git.kernel.org/stable/c/8f6dfa1f1efe6dcca2d43e575491d8fcbe922f62","https://git.kernel.org/stable/c/bcdc288e7bc008daf38ef0401b53e4a8bb61bbe5","https://git.kernel.org/stable/c/cb16cc1abda18a9514106d2ac8c8d7abc0be5ed8","https://git.kernel.org/stable/c/ef31cc87794731ffcb578a195a2c47d744e25fb8","https://git.kernel.org/stable/c/5010c27120962c85d2f421d2cf211791c9603503","https://git.kernel.org/stable/c/6f64f866aa1ae6975c95d805ed51d7e9433a0016","https://git.kernel.org/stable/c/8f6dfa1f1efe6dcca2d43e575491d8fcbe922f62","https://git.kernel.org/stable/c/bcdc288e7bc008daf38ef0401b53e4a8bb61bbe5","https://git.kernel.org/stable/c/cb16cc1abda18a9514106d2ac8c8d7abc0be5ed8","https://git.kernel.org/stable/c/ef31cc87794731ffcb578a195a2c47d744e25fb8","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26601
|
Medium |
fixed |
- 5.10.211
- 5.15.150
- 6.1.78
- 6.6.17
- 6.7.5
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: regenerate buddy after block freeing failed if under fc replay
This mostly reverts commit 6bd97bf273bd ("ext4: remove redundant
mb_regenerate_buddy()") and reintroduces mb_regenerate_buddy(). Based on
code in mb_free_blocks(), fast commit replay can end up marking as free
blocks that are already marked as such. This causes corruption of the
buddy bitmap so we need to regenerate it in that case. |
["https://git.kernel.org/stable/c/6b0d48647935e4b8c7b75d1eccb9043fcd4ee581","https://git.kernel.org/stable/c/78327acd4cdc4a1601af718b781eece577b6b7d4","https://git.kernel.org/stable/c/94ebf71bddbcd4ab1ce43ae32c6cb66396d2d51a","https://git.kernel.org/stable/c/c1317822e2de80e78f137d3a2d99febab1b80326","https://git.kernel.org/stable/c/c9b528c35795b711331ed36dc3dbee90d5812d4e","https://git.kernel.org/stable/c/ea42d6cffb0dd27a417f410b9d0011e9859328cb","https://git.kernel.org/stable/c/6b0d48647935e4b8c7b75d1eccb9043fcd4ee581","https://git.kernel.org/stable/c/78327acd4cdc4a1601af718b781eece577b6b7d4","https://git.kernel.org/stable/c/94ebf71bddbcd4ab1ce43ae32c6cb66396d2d51a","https://git.kernel.org/stable/c/c1317822e2de80e78f137d3a2d99febab1b80326","https://git.kernel.org/stable/c/c9b528c35795b711331ed36dc3dbee90d5812d4e","https://git.kernel.org/stable/c/ea42d6cffb0dd27a417f410b9d0011e9859328cb","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49920
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: netlink notifier might race to release objects
commit release path is invoked via call_rcu and it runs lockless to
release the objects after rcu grace period. The netlink notifier handler
might win race to remove objects that the transaction context is still
referencing from the commit release path.
Call rcu_barrier() to ensure pending rcu callbacks run to completion
if the list of transactions to be destroyed is not empty. |
["https://git.kernel.org/stable/c/1ffe7100411a8b9015115ce124cd6c9c9da6f8e3","https://git.kernel.org/stable/c/d4bc8271db21ea9f1c86a1ca4d64999f184d4aae","https://git.kernel.org/stable/c/e40b7c44d19e327ad8b49a491ef1fa8dcc4566e0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26830
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
i40e: Do not allow untrusted VF to remove administratively set MAC
Currently when PF administratively sets VF's MAC address and the VF
is put down (VF tries to delete all MACs) then the MAC is removed
from MAC filters and primary VF MAC is zeroed.
Do not allow untrusted VF to remove primary MAC when it was set
administratively by PF.
Reproducer:
1) Create VF
2) Set VF interface up
3) Administratively set the VF's MAC
4) Put VF interface down
[root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs
[root@host ~]# ip link set enp2s0f0v0 up
[root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d
[root@host ~]# ip link show enp2s0f0
23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff
vf 0 link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
[root@host ~]# ip link set enp2s0f0v0 down
[root@host ~]# ip link show enp2s0f0
23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff
vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off |
["https://git.kernel.org/stable/c/1c981792e4ccbc134b468797acdd7781959e6893","https://git.kernel.org/stable/c/73d9629e1c8c1982f13688c4d1019c3994647ccc","https://git.kernel.org/stable/c/be147926140ac48022c9605d7ab0a67387e4b404","https://git.kernel.org/stable/c/d250a81ba813a93563be68072c563aa1e346346d","https://git.kernel.org/stable/c/1c981792e4ccbc134b468797acdd7781959e6893","https://git.kernel.org/stable/c/73d9629e1c8c1982f13688c4d1019c3994647ccc","https://git.kernel.org/stable/c/be147926140ac48022c9605d7ab0a67387e4b404","https://git.kernel.org/stable/c/d250a81ba813a93563be68072c563aa1e346346d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-0841
|
High |
fixed |
- 5.4.271
- 5.10.212
- 5.15.151
- 6.1.79
- 6.6.18
- 6.7.6
|
A null pointer dereference flaw was found in the hugetlbfs_fill_super function in the Linux kernel hugetlbfs (HugeTLB pages) functionality. This issue may allow a local user to crash the system or potentially escalate their privileges on the system. |
["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2024-0841","https://bugzilla.redhat.com/show_bug.cgi?id=2256490","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2024-0841","https://bugzilla.redhat.com/show_bug.cgi?id=2256490","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-56662
|
Medium |
fixed |
- 4.15
- 4.20
- 5.10.232
- 5.15.175
- 6.1.121
- 6.6.67
- 6.12.6
|
In the Linux kernel, the following vulnerability has been resolved:
acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl
Fix an issue detected by syzbot with KASAN:
BUG: KASAN: vmalloc-out-of-bounds in cmd_to_func drivers/acpi/nfit/
core.c:416 [inline]
BUG: KASAN: vmalloc-out-of-bounds in acpi_nfit_ctl+0x20e8/0x24a0
drivers/acpi/nfit/core.c:459
The issue occurs in cmd_to_func when the call_pkg->nd_reserved2
array is accessed without verifying that call_pkg points to a buffer
that is appropriately sized as a struct nd_cmd_pkg. This can lead
to out-of-bounds access and undefined behavior if the buffer does not
have sufficient space.
To address this, a check was added in acpi_nfit_ctl() to ensure that
buf is not NULL and that buf_len is less than sizeof(*call_pkg)
before accessing it. This ensures safe access to the members of
call_pkg, including the nd_reserved2 array. |
["https://git.kernel.org/stable/c/143f723e9eb4f0302ffb7adfdc7ef77eab3f68e0","https://git.kernel.org/stable/c/212846fafb753a48e869e2a342fc1e24048da771","https://git.kernel.org/stable/c/265e98f72bac6c41a4492d3e30a8e5fd22fe0779","https://git.kernel.org/stable/c/616aa5f3c86e0479bcbb81e41c08c43ff32af637","https://git.kernel.org/stable/c/bbdb3307f609ec4dc9558770f464ede01fe52aed","https://git.kernel.org/stable/c/e08dc2dc3c3f7938df0e4476fe3e6fdec5583c1d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-2019
|
Medium |
fixed |
|
A flaw was found in the Linux kernel's netdevsim device driver, within the scheduling of events. This issue results from the improper management of a reference count. This may allow an attacker to create a denial of service condition on the system. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2189137","https://github.com/torvalds/linux/commit/180a6a3ee60a","https://www.zerodayinitiative.com/advisories/ZDI-CAN-17811/","https://bugzilla.redhat.com/show_bug.cgi?id=2189137","https://github.com/torvalds/linux/commit/180a6a3ee60a","https://www.zerodayinitiative.com/advisories/ZDI-CAN-17811/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4387
|
High |
fixed |
- 3.17
- 4.9.316
- 4.14.281
- 4.19.245
- 5.4.196
- 5.10.118
- 5.15.42
- 5.17.10
|
A use-after-free flaw was found in vmxnet3_rq_alloc_rx_buf in drivers/net/vmxnet3/vmxnet3_drv.c in VMware's vmxnet3 ethernet NIC driver in the Linux Kernel. This issue could allow a local attacker to crash the system due to a double-free while cleaning up vmxnet3_rq_cleanup_all, which could also lead to a kernel information leak problem. |
["https://access.redhat.com/errata/RHSA-2022:8267","https://access.redhat.com/security/cve/CVE-2023-4387","https://bugzilla.redhat.com/show_bug.cgi?id=2219270","https://github.com/torvalds/linux/commit/9e7fef9521e73ca8afd7da9e58c14654b02dfad8","https://access.redhat.com/security/cve/CVE-2023-4387","https://bugzilla.redhat.com/show_bug.cgi?id=2219270","https://github.com/torvalds/linux/commit/9e7fef9521e73ca8afd7da9e58c14654b02dfad8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52519
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
HID: intel-ish-hid: ipc: Disable and reenable ACPI GPE bit
The EHL (Elkhart Lake) based platforms provide a OOB (Out of band)
service, which allows to wakup device when the system is in S5 (Soft-Off
state). This OOB service can be enabled/disabled from BIOS settings. When
enabled, the ISH device gets PME wake capability. To enable PME wakeup,
driver also needs to enable ACPI GPE bit.
On resume, BIOS will clear the wakeup bit. So driver need to re-enable it
in resume function to keep the next wakeup capability. But this BIOS
clearing of wakeup bit doesn't decrement internal OS GPE reference count,
so this reenabling on every resume will cause reference count to overflow.
So first disable and reenable ACPI GPE bit using acpi_disable_gpe(). |
["https://git.kernel.org/stable/c/60fb3f054c99608ddb1f2466c07108da6292951e","https://git.kernel.org/stable/c/8781fe259dd5a178fdd1069401bbd1437f9491c5","https://git.kernel.org/stable/c/8f02139ad9a7e6e5c05712f8c1501eebed8eacfd","https://git.kernel.org/stable/c/cdcc04e844a2d22d9d25cef1e8e504a174ea9f8f","https://git.kernel.org/stable/c/60fb3f054c99608ddb1f2466c07108da6292951e","https://git.kernel.org/stable/c/8781fe259dd5a178fdd1069401bbd1437f9491c5","https://git.kernel.org/stable/c/8f02139ad9a7e6e5c05712f8c1501eebed8eacfd","https://git.kernel.org/stable/c/cdcc04e844a2d22d9d25cef1e8e504a174ea9f8f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52578
|
High |
fixed |
- 4.19.296
- 5.4.258
- 5.10.198
- 5.15.134
- 6.1.56
- 6.5.6
|
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: use DEV_STATS_INC()
syzbot/KCSAN reported data-races in br_handle_frame_finish() [1]
This function can run from multiple cpus without mutual exclusion.
Adopt SMP safe DEV_STATS_INC() to update dev->stats fields.
Handles updates to dev->stats.tx_dropped while we are at it.
[1]
BUG: KCSAN: data-race in br_handle_frame_finish / br_handle_frame_finish
read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 1:
br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189
br_nf_hook_thresh+0x1ed/0x220
br_nf_pre_routing_finish_ipv6+0x50f/0x540
NF_HOOK include/linux/netfilter.h:304 [inline]
br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178
br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508
nf_hook_entry_hookfn include/linux/netfilter.h:144 [inline]
nf_hook_bridge_pre net/bridge/br_input.c:272 [inline]
br_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417
__netif_receive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417
__netif_receive_skb_one_core net/core/dev.c:5521 [inline]
__netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637
process_backlog+0x21f/0x380 net/core/dev.c:5965
__napi_poll+0x60/0x3b0 net/core/dev.c:6527
napi_poll net/core/dev.c:6594 [inline]
net_rx_action+0x32b/0x750 net/core/dev.c:6727
__do_softirq+0xc1/0x265 kernel/softirq.c:553
run_ksoftirqd+0x17/0x20 kernel/softirq.c:921
smpboot_thread_fn+0x30a/0x4a0 kernel/smpboot.c:164
kthread+0x1d7/0x210 kernel/kthread.c:388
ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 0:
br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189
br_nf_hook_thresh+0x1ed/0x220
br_nf_pre_routing_finish_ipv6+0x50f/0x540
NF_HOOK include/linux/netfilter.h:304 [inline]
br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178
br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508
nf_hook_entry_hookfn include/linux/netfilter.h:144 [inline]
nf_hook_bridge_pre net/bridge/br_input.c:272 [inline]
br_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417
__netif_receive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417
__netif_receive_skb_one_core net/core/dev.c:5521 [inline]
__netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637
process_backlog+0x21f/0x380 net/core/dev.c:5965
__napi_poll+0x60/0x3b0 net/core/dev.c:6527
napi_poll net/core/dev.c:6594 [inline]
net_rx_action+0x32b/0x750 net/core/dev.c:6727
__do_softirq+0xc1/0x265 kernel/softirq.c:553
do_softirq+0x5e/0x90 kernel/softirq.c:454
__local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381
__raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]
_raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210
spin_unlock_bh include/linux/spinlock.h:396 [inline]
batadv_tt_local_purge+0x1a8/0x1f0 net/batman-adv/translation-table.c:1356
batadv_tt_purge+0x2b/0x630 net/batman-adv/translation-table.c:3560
process_one_work kernel/workqueue.c:2630 [inline]
process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2703
worker_thread+0x525/0x730 kernel/workqueue.c:2784
kthread+0x1d7/0x210 kernel/kthread.c:388
ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
value changed: 0x00000000000d7190 -> 0x00000000000d7191
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 14848 Comm: kworker/u4:11 Not tainted 6.6.0-rc1-syzkaller-00236-gad8a69f361b9 #0 |
["https://git.kernel.org/stable/c/04cc361f029c14dd067ad180525c7392334c9bfd","https://git.kernel.org/stable/c/44bdb313da57322c9b3c108eb66981c6ec6509f4","https://git.kernel.org/stable/c/89f9f20b1cbd36d99d5a248a4bf8d11d4fd049a2","https://git.kernel.org/stable/c/8bc97117b51d68d5cea8f5351cca2d8c4153f394","https://git.kernel.org/stable/c/ad8d39c7b437fcdab7208a6a56c093d222c008d5","https://git.kernel.org/stable/c/d2346e6beb699909ca455d9d20c4e577ce900839","https://git.kernel.org/stable/c/f2ef4cb4d418fa64fe73eb84d10cc5c0e52e00fa","https://git.kernel.org/stable/c/04cc361f029c14dd067ad180525c7392334c9bfd","https://git.kernel.org/stable/c/44bdb313da57322c9b3c108eb66981c6ec6509f4","https://git.kernel.org/stable/c/89f9f20b1cbd36d99d5a248a4bf8d11d4fd049a2","https://git.kernel.org/stable/c/8bc97117b51d68d5cea8f5351cca2d8c4153f394","https://git.kernel.org/stable/c/ad8d39c7b437fcdab7208a6a56c093d222c008d5","https://git.kernel.org/stable/c/d2346e6beb699909ca455d9d20c4e577ce900839","https://git.kernel.org/stable/c/f2ef4cb4d418fa64fe73eb84d10cc5c0e52e00fa"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-42328
|
Medium |
fixed |
|
Guests can trigger deadlock in Linux netback driver T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] The patch for XSA-392 introduced another issue which might result in a deadlock when trying to free the SKB of a packet dropped due to the XSA-392 handling (CVE-2022-42328). Additionally when dropping packages for other reasons the same deadlock could occur in case of netpoll being active for the interface the xen-netback driver is connected to (CVE-2022-42329). |
["http://www.openwall.com/lists/oss-security/2022/12/08/2","http://www.openwall.com/lists/oss-security/2022/12/08/3","http://www.openwall.com/lists/oss-security/2022/12/09/2","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://xenbits.xenproject.org/xsa/advisory-424.txt","http://www.openwall.com/lists/oss-security/2022/12/08/2","http://www.openwall.com/lists/oss-security/2022/12/08/3","http://www.openwall.com/lists/oss-security/2022/12/09/2","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://xenbits.xenproject.org/xsa/advisory-424.txt"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1048
|
High |
fixed |
- 4.14.279
- 4.19.243
- 5.4.193
- 5.10.109
- 5.15.32
- 5.16.18
|
A use-after-free flaw was found in the Linux kernel’s sound subsystem in the way a user triggers concurrent calls of PCM hw_params. The hw_free ioctls or similar race condition happens inside ALSA PCM for other ioctls. This flaw allows a local user to crash or potentially escalate their privileges on the system. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2066706","https://lore.kernel.org/lkml/20220322170720.3529-5-tiwai%40suse.de/T/#m1d3b791b815556012c6be92f1c4a7086b854f7f3","https://security.netapp.com/advisory/ntap-20220629-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173","https://bugzilla.redhat.com/show_bug.cgi?id=2066706","https://lore.kernel.org/lkml/20220322170720.3529-5-tiwai%40suse.de/T/#m1d3b791b815556012c6be92f1c4a7086b854f7f3","https://security.netapp.com/advisory/ntap-20220629-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52633
|
Medium |
fixed |
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
um: time-travel: fix time corruption
In 'basic' time-travel mode (without =inf-cpu or =ext), we
still get timer interrupts. These can happen at arbitrary
points in time, i.e. while in timer_read(), which pushes
time forward just a little bit. Then, if we happen to get
the interrupt after calculating the new time to push to,
but before actually finishing that, the interrupt will set
the time to a value that's incompatible with the forward,
and we'll crash because time goes backwards when we do the
forwarding.
Fix this by reading the time_travel_time, calculating the
adjustment, and doing the adjustment all with interrupts
disabled. |
["https://git.kernel.org/stable/c/0c7478a2da3f5fe106b4658338873d50c86ac7ab","https://git.kernel.org/stable/c/4f7dad73df4cdb2b7042103d3922745d040ad025","https://git.kernel.org/stable/c/abe4eaa8618bb36c2b33e9cdde0499296a23448c","https://git.kernel.org/stable/c/b427f55e9d4185f6f17cc1e3296eb8d0c4425283","https://git.kernel.org/stable/c/de3e9d8e8d1ae0a4d301109d1ec140796901306c","https://git.kernel.org/stable/c/0c7478a2da3f5fe106b4658338873d50c86ac7ab","https://git.kernel.org/stable/c/4f7dad73df4cdb2b7042103d3922745d040ad025","https://git.kernel.org/stable/c/abe4eaa8618bb36c2b33e9cdde0499296a23448c","https://git.kernel.org/stable/c/b427f55e9d4185f6f17cc1e3296eb8d0c4425283","https://git.kernel.org/stable/c/de3e9d8e8d1ae0a4d301109d1ec140796901306c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-32269
|
Medium |
fixed |
|
An issue was discovered in the Linux kernel before 6.1.11. In net/netrom/af_netrom.c, there is a use-after-free because accept is also allowed for a successfully connected AF_NETROM socket. However, in order for an attacker to exploit this, the system must have netrom routing configured or the attacker must have the CAP_NET_ADMIN capability. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.11","https://github.com/torvalds/linux/commit/611792920925fb088ddccbe2783c7f92fdfb6b64","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.11","https://github.com/torvalds/linux/commit/611792920925fb088ddccbe2783c7f92fdfb6b64"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-42155
|
Low |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
s390/pkey: Wipe copies of protected- and secure-keys
Although the clear-key of neither protected- nor secure-keys is
accessible, this key material should only be visible to the calling
process. So wipe all copies of protected- or secure-keys from stack,
even in case of an error. |
["https://git.kernel.org/stable/c/c746f7ced4ad88ee48d0b6c92710e4674403185b","https://git.kernel.org/stable/c/f2ebdadd85af4f4d0cae1e5d009c70eccc78c207","https://git.kernel.org/stable/c/c746f7ced4ad88ee48d0b6c92710e4674403185b","https://git.kernel.org/stable/c/f2ebdadd85af4f4d0cae1e5d009c70eccc78c207"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-22997
|
Medium |
fixed |
|
In the Linux kernel before 6.1.2, kernel/module/decompress.c misinterprets the module_get_next_page return value (expects it to be NULL in the error case, whereas it is actually an error pointer). |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.2","https://github.com/torvalds/linux/commit/45af1d7aae7d5520d2858f8517a1342646f015db","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.2","https://github.com/torvalds/linux/commit/45af1d7aae7d5520d2858f8517a1342646f015db"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26801
|
Medium |
fixed |
- 4.19.309
- 5.4.271
- 5.10.212
- 5.15.151
- 6.1.81
- 6.6.21
- 6.7.9
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Avoid potential use-after-free in hci_error_reset
While handling the HCI_EV_HARDWARE_ERROR event, if the underlying
BT controller is not responding, the GPIO reset mechanism would
free the hci_dev and lead to a use-after-free in hci_error_reset.
Here's the call trace observed on a ChromeOS device with Intel AX201:
queue_work_on+0x3e/0x6c
__hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth <HASH:3b4a6>]
? init_wait_entry+0x31/0x31
__hci_cmd_sync+0x16/0x20 [bluetooth <HASH:3b4a 6>]
hci_error_reset+0x4f/0xa4 [bluetooth <HASH:3b4a 6>]
process_one_work+0x1d8/0x33f
worker_thread+0x21b/0x373
kthread+0x13a/0x152
? pr_cont_work+0x54/0x54
? kthread_blkcg+0x31/0x31
ret_from_fork+0x1f/0x30
This patch holds the reference count on the hci_dev while processing
a HCI_EV_HARDWARE_ERROR event to avoid potential crash. |
["https://git.kernel.org/stable/c/2449007d3f73b2842c9734f45f0aadb522daf592","https://git.kernel.org/stable/c/2ab9a19d896f5a0dd386e1f001c5309bc35f433b","https://git.kernel.org/stable/c/45085686b9559bfbe3a4f41d3d695a520668f5e1","https://git.kernel.org/stable/c/6dd0a9dfa99f8990a08eb8fdd8e79bee31c7d8e2","https://git.kernel.org/stable/c/98fb98fd37e42fd4ce13ff657ea64503e24b6090","https://git.kernel.org/stable/c/da4569d450b193e39e87119fd316c0291b585d14","https://git.kernel.org/stable/c/dd594cdc24f2e48dab441732e6dfcafd6b0711d1","https://git.kernel.org/stable/c/e0b278650f07acf2e0932149183458468a731c03","https://git.kernel.org/stable/c/2449007d3f73b2842c9734f45f0aadb522daf592","https://git.kernel.org/stable/c/2ab9a19d896f5a0dd386e1f001c5309bc35f433b","https://git.kernel.org/stable/c/45085686b9559bfbe3a4f41d3d695a520668f5e1","https://git.kernel.org/stable/c/6dd0a9dfa99f8990a08eb8fdd8e79bee31c7d8e2","https://git.kernel.org/stable/c/98fb98fd37e42fd4ce13ff657ea64503e24b6090","https://git.kernel.org/stable/c/da4569d450b193e39e87119fd316c0291b585d14","https://git.kernel.org/stable/c/dd594cdc24f2e48dab441732e6dfcafd6b0711d1","https://git.kernel.org/stable/c/e0b278650f07acf2e0932149183458468a731c03","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49899
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
fscrypt: stop using keyrings subsystem for fscrypt_master_key
The approach of fs/crypto/ internally managing the fscrypt_master_key
structs as the payloads of "struct key" objects contained in a
"struct key" keyring has outlived its usefulness. The original idea was
to simplify the code by reusing code from the keyrings subsystem.
However, several issues have arisen that can't easily be resolved:
- When a master key struct is destroyed, blk_crypto_evict_key() must be
called on any per-mode keys embedded in it. (This started being the
case when inline encryption support was added.) Yet, the keyrings
subsystem can arbitrarily delay the destruction of keys, even past the
time the filesystem was unmounted. Therefore, currently there is no
easy way to call blk_crypto_evict_key() when a master key is
destroyed. Currently, this is worked around by holding an extra
reference to the filesystem's request_queue(s). But it was overlooked
that the request_queue reference is *not* guaranteed to pin the
corresponding blk_crypto_profile too; for device-mapper devices that
support inline crypto, it doesn't. This can cause a use-after-free.
- When the last inode that was using an incompletely-removed master key
is evicted, the master key removal is completed by removing the key
struct from the keyring. Currently this is done via key_invalidate().
Yet, key_invalidate() takes the key semaphore. This can deadlock when
called from the shrinker, since in fscrypt_ioctl_add_key(), memory is
allocated with GFP_KERNEL under the same semaphore.
- More generally, the fact that the keyrings subsystem can arbitrarily
delay the destruction of keys (via garbage collection delay, or via
random processes getting temporary key references) is undesirable, as
it means we can't strictly guarantee that all secrets are ever wiped.
- Doing the master key lookups via the keyrings subsystem results in the
key_permission LSM hook being called. fscrypt doesn't want this, as
all access control for encrypted files is designed to happen via the
files themselves, like any other files. The workaround which SELinux
users are using is to change their SELinux policy to grant key search
access to all domains. This works, but it is an odd extra step that
shouldn't really have to be done.
The fix for all these issues is to change the implementation to what I
should have done originally: don't use the keyrings subsystem to keep
track of the filesystem's fscrypt_master_key structs. Instead, just
store them in a regular kernel data structure, and rework the reference
counting, locking, and lifetime accordingly. Retain support for
RCU-mode key lookups by using a hash table. Replace fscrypt_sb_free()
with fscrypt_sb_delete(), which releases the keys synchronously and runs
a bit earlier during unmount, so that block devices are still available.
A side effect of this patch is that neither the master keys themselves
nor the filesystem keyrings will be listed in /proc/keys anymore.
("Master key users" and the master key users keyrings will still be
listed.) However, this was mostly an implementation detail, and it was
intended just for debugging purposes. I don't know of anyone using it.
This patch does *not* change how "master key users" (->mk_users) works;
that still uses the keyrings subsystem. That is still needed for key
quotas, and changing that isn't necessary to solve the issues listed
above. If we decide to change that too, it would be a separate patch.
I've marked this as fixing the original commit that added the fscrypt
keyring, but as noted above the most important issue that this patch
fixes wasn't introduced until the addition of inline encryption support. |
["https://git.kernel.org/stable/c/391cceee6d435e616f68631e68f5b32d480b1e67","https://git.kernel.org/stable/c/68d15d6558a386f46d815a6ac39edecad713a1bf","https://git.kernel.org/stable/c/d7e7b9af104c7b389a0c21eb26532511bce4b510","https://git.kernel.org/stable/c/e6f4fd85ef1ee6ab356bfbd64df28c1cb73aee7e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26870
|
Medium |
fixed |
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102
A call to listxattr() with a buffer size = 0 returns the actual
size of the buffer needed for a subsequent call. When size > 0,
nfs4_listxattr() does not return an error because either
generic_listxattr() or nfs4_listxattr_nfs4_label() consumes
exactly all the bytes then size is 0 when calling
nfs4_listxattr_nfs4_user() which then triggers the following
kernel BUG:
[ 99.403778] kernel BUG at mm/usercopy.c:102!
[ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
[ 99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1
[ 99.415827] Call trace:
[ 99.415985] usercopy_abort+0x70/0xa0
[ 99.416227] __check_heap_object+0x134/0x158
[ 99.416505] check_heap_object+0x150/0x188
[ 99.416696] __check_object_size.part.0+0x78/0x168
[ 99.416886] __check_object_size+0x28/0x40
[ 99.417078] listxattr+0x8c/0x120
[ 99.417252] path_listxattr+0x78/0xe0
[ 99.417476] __arm64_sys_listxattr+0x28/0x40
[ 99.417723] invoke_syscall+0x78/0x100
[ 99.417929] el0_svc_common.constprop.0+0x48/0xf0
[ 99.418186] do_el0_svc+0x24/0x38
[ 99.418376] el0_svc+0x3c/0x110
[ 99.418554] el0t_64_sync_handler+0x120/0x130
[ 99.418788] el0t_64_sync+0x194/0x198
[ 99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000)
Issue is reproduced when generic_listxattr() returns 'system.nfs4_acl',
thus calling lisxattr() with size = 16 will trigger the bug.
Add check on nfs4_listxattr() to return ERANGE error when it is
called with size > 0 and the return value is greater than size. |
["https://git.kernel.org/stable/c/06e828b3f1b206de08ef520fc46a40b22e1869cb","https://git.kernel.org/stable/c/23bfecb4d852751d5e403557dd500bb563313baf","https://git.kernel.org/stable/c/251a658bbfceafb4d58c76b77682c8bf7bcfad65","https://git.kernel.org/stable/c/4403438eaca6e91f02d272211c4d6b045092396b","https://git.kernel.org/stable/c/79cdcc765969d23f4e3d6ea115660c3333498768","https://git.kernel.org/stable/c/80365c9f96015bbf048fdd6c8705d3f8770132bf","https://git.kernel.org/stable/c/9d52865ff28245fc2134da9f99baff603a24407a","https://git.kernel.org/stable/c/06e828b3f1b206de08ef520fc46a40b22e1869cb","https://git.kernel.org/stable/c/23bfecb4d852751d5e403557dd500bb563313baf","https://git.kernel.org/stable/c/251a658bbfceafb4d58c76b77682c8bf7bcfad65","https://git.kernel.org/stable/c/4403438eaca6e91f02d272211c4d6b045092396b","https://git.kernel.org/stable/c/79cdcc765969d23f4e3d6ea115660c3333498768","https://git.kernel.org/stable/c/80365c9f96015bbf048fdd6c8705d3f8770132bf","https://git.kernel.org/stable/c/9d52865ff28245fc2134da9f99baff603a24407a","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52454
|
Medium |
fixed |
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length
If the host sends an H2CData command with an invalid DATAL,
the kernel may crash in nvmet_tcp_build_pdu_iovec().
Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000000
lr : nvmet_tcp_io_work+0x6ac/0x718 [nvmet_tcp]
Call trace:
process_one_work+0x174/0x3c8
worker_thread+0x2d0/0x3e8
kthread+0x104/0x110
Fix the bug by raising a fatal error if DATAL isn't coherent
with the packet size.
Also, the PDU length should never exceed the MAXH2CDATA parameter which
has been communicated to the host in nvmet_tcp_handle_icreq(). |
["https://git.kernel.org/stable/c/24e05760186dc070d3db190ca61efdbce23afc88","https://git.kernel.org/stable/c/2871aa407007f6f531fae181ad252486e022df42","https://git.kernel.org/stable/c/4cb3cf7177ae3666be7fb27d4ad4d72a295fb02d","https://git.kernel.org/stable/c/70154e8d015c9b4fb56c1a2ef1fc8b83d45c7f68","https://git.kernel.org/stable/c/ee5e7632e981673f42a50ade25e71e612e543d9d","https://git.kernel.org/stable/c/efa56305908ba20de2104f1b8508c6a7401833be","https://git.kernel.org/stable/c/f775f2621c2ac5cc3a0b3a64665dad4fb146e510","https://git.kernel.org/stable/c/24e05760186dc070d3db190ca61efdbce23afc88","https://git.kernel.org/stable/c/2871aa407007f6f531fae181ad252486e022df42","https://git.kernel.org/stable/c/4cb3cf7177ae3666be7fb27d4ad4d72a295fb02d","https://git.kernel.org/stable/c/70154e8d015c9b4fb56c1a2ef1fc8b83d45c7f68","https://git.kernel.org/stable/c/ee5e7632e981673f42a50ade25e71e612e543d9d","https://git.kernel.org/stable/c/efa56305908ba20de2104f1b8508c6a7401833be","https://git.kernel.org/stable/c/f775f2621c2ac5cc3a0b3a64665dad4fb146e510","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26684
|
Medium |
fixed |
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.78
- 6.6.17
- 6.7.5
|
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: xgmac: fix handling of DPP safety error for DMA channels
Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in
XGMAC core") checks and reports safety errors, but leaves the
Data Path Parity Errors for each channel in DMA unhandled at all, lead to
a storm of interrupt.
Fix it by checking and clearing the DMA_DPP_Interrupt_Status register. |
["https://git.kernel.org/stable/c/2fc45a4631ac7837a5c497cb4f7e2115d950fc37","https://git.kernel.org/stable/c/3b48c9e258c8691c2f093ee07b1ea3764caaa1b2","https://git.kernel.org/stable/c/46eba193d04f8bd717e525eb4110f3c46c12aec3","https://git.kernel.org/stable/c/6609e98ed82966a1b3168c142aca30f8284a7b89","https://git.kernel.org/stable/c/7e0ff50131e9d1aa507be8e670d38e9300a5f5bf","https://git.kernel.org/stable/c/e42ff0844fe418c7d03a14f9f90e1b91ba119591","https://git.kernel.org/stable/c/e9837c83befb5b852fa76425dde98a87b737df00","https://git.kernel.org/stable/c/2fc45a4631ac7837a5c497cb4f7e2115d950fc37","https://git.kernel.org/stable/c/3b48c9e258c8691c2f093ee07b1ea3764caaa1b2","https://git.kernel.org/stable/c/46eba193d04f8bd717e525eb4110f3c46c12aec3","https://git.kernel.org/stable/c/6609e98ed82966a1b3168c142aca30f8284a7b89","https://git.kernel.org/stable/c/7e0ff50131e9d1aa507be8e670d38e9300a5f5bf","https://git.kernel.org/stable/c/e42ff0844fe418c7d03a14f9f90e1b91ba119591","https://git.kernel.org/stable/c/e9837c83befb5b852fa76425dde98a87b737df00","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-45862
|
Medium |
fixed |
|
An issue was discovered in drivers/usb/storage/ene_ub6250.c for the ENE UB6250 reader driver in the Linux kernel before 6.2.5. An object could potentially extend beyond the end of an allocation. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.5","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ce33e64c1788912976b61314b56935abd4bc97ef","https://security.netapp.com/advisory/ntap-20231116-0004/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.5","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ce33e64c1788912976b61314b56935abd4bc97ef","https://security.netapp.com/advisory/ntap-20231116-0004/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52932
|
Medium |
fixed |
- 4.14.306
- 4.19.273
- 5.4.232
- 5.10.168
- 5.15.93
- 6.1.11
|
In the Linux kernel, the following vulnerability has been resolved:
mm/swapfile: add cond_resched() in get_swap_pages()
The softlockup still occurs in get_swap_pages() under memory pressure. 64
CPU cores, 64GB memory, and 28 zram devices, the disksize of each zram
device is 50MB with same priority as si. Use the stress-ng tool to
increase memory pressure, causing the system to oom frequently.
The plist_for_each_entry_safe() loops in get_swap_pages() could reach tens
of thousands of times to find available space (extreme case:
cond_resched() is not called in scan_swap_map_slots()). Let's add
cond_resched() into get_swap_pages() when failed to find available space
to avoid softlockup. |
["https://git.kernel.org/stable/c/29f0349c5c76b627fe06b87d4b13fa03a6ce8e64","https://git.kernel.org/stable/c/30187be29052bba9203b0ae2bdd815e0bc2faaab","https://git.kernel.org/stable/c/387217b97e99699c34e6d95ce2b91b327fcd853e","https://git.kernel.org/stable/c/49178d4d61e78aed8c837dfeea8a450700f196e2","https://git.kernel.org/stable/c/5dbe1ebd56470d03b78fc31491a9e4d433106ef2","https://git.kernel.org/stable/c/7717fc1a12f88701573f9ed897cc4f6699c661e3","https://git.kernel.org/stable/c/d49c85a1913385eed46dd16a25ad0928253767f0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-23001
|
Medium |
fixed |
|
In the Linux kernel before 5.16.3, drivers/scsi/ufs/ufs-mediatek.c misinterprets the regulator_get return value (expects it to be NULL in the error case, whereas it is actually an error pointer). |
["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.3","https://github.com/torvalds/linux/commit/3ba880a12df5aa4488c18281701b5b1bc3d4531a","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.3","https://github.com/torvalds/linux/commit/3ba880a12df5aa4488c18281701b5b1bc3d4531a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-53016
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix possible deadlock in rfcomm_sk_state_change
syzbot reports a possible deadlock in rfcomm_sk_state_change [1].
While rfcomm_sock_connect acquires the sk lock and waits for
the rfcomm lock, rfcomm_sock_release could have the rfcomm
lock and hit a deadlock for acquiring the sk lock.
Here's a simplified flow:
rfcomm_sock_connect:
lock_sock(sk)
rfcomm_dlc_open:
rfcomm_lock()
rfcomm_sock_release:
rfcomm_sock_shutdown:
rfcomm_lock()
__rfcomm_dlc_close:
rfcomm_k_state_change:
lock_sock(sk)
This patch drops the sk lock before calling rfcomm_dlc_open to
avoid the possible deadlock and holds sk's reference count to
prevent use-after-free after rfcomm_dlc_open completes. |
["https://git.kernel.org/stable/c/17511bd84871f4a6106cb335616e086880313f3f","https://git.kernel.org/stable/c/1d80d57ffcb55488f0ec0b77928d4f82d16b6a90","https://git.kernel.org/stable/c/98aec50ff7f60cc6f2d6a4396b475c547e58b04d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-53022
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: enetc: avoid deadlock in enetc_tx_onestep_tstamp()
This lockdep splat says it better than I could:
================================
WARNING: inconsistent lock state
6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 Not tainted
--------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
kworker/1:3/179 [HC0[0]:SC0[0]:HE1:SE1] takes:
ffff3ec4036ce098 (_xmit_ETHER#2){+.?.}-{3:3}, at: netif_freeze_queues+0x5c/0xc0
{IN-SOFTIRQ-W} state was registered at:
_raw_spin_lock+0x5c/0xc0
sch_direct_xmit+0x148/0x37c
__dev_queue_xmit+0x528/0x111c
ip6_finish_output2+0x5ec/0xb7c
ip6_finish_output+0x240/0x3f0
ip6_output+0x78/0x360
ndisc_send_skb+0x33c/0x85c
ndisc_send_rs+0x54/0x12c
addrconf_rs_timer+0x154/0x260
call_timer_fn+0xb8/0x3a0
__run_timers.part.0+0x214/0x26c
run_timer_softirq+0x3c/0x74
__do_softirq+0x14c/0x5d8
____do_softirq+0x10/0x20
call_on_irq_stack+0x2c/0x5c
do_softirq_own_stack+0x1c/0x30
__irq_exit_rcu+0x168/0x1a0
irq_exit_rcu+0x10/0x40
el1_interrupt+0x38/0x64
irq event stamp: 7825
hardirqs last enabled at (7825): [<ffffdf1f7200cae4>] exit_to_kernel_mode+0x34/0x130
hardirqs last disabled at (7823): [<ffffdf1f708105f0>] __do_softirq+0x550/0x5d8
softirqs last enabled at (7824): [<ffffdf1f7081050c>] __do_softirq+0x46c/0x5d8
softirqs last disabled at (7811): [<ffffdf1f708166e0>] ____do_softirq+0x10/0x20
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(_xmit_ETHER#2);
<Interrupt>
lock(_xmit_ETHER#2);
*** DEADLOCK ***
3 locks held by kworker/1:3/179:
#0: ffff3ec400004748 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0
#1: ffff80000a0bbdc8 ((work_completion)(&priv->tx_onestep_tstamp)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0
#2: ffff3ec4036cd438 (&dev->tx_global_lock){+.+.}-{3:3}, at: netif_tx_lock+0x1c/0x34
Workqueue: events enetc_tx_onestep_tstamp
Call trace:
print_usage_bug.part.0+0x208/0x22c
mark_lock+0x7f0/0x8b0
__lock_acquire+0x7c4/0x1ce0
lock_acquire.part.0+0xe0/0x220
lock_acquire+0x68/0x84
_raw_spin_lock+0x5c/0xc0
netif_freeze_queues+0x5c/0xc0
netif_tx_lock+0x24/0x34
enetc_tx_onestep_tstamp+0x20/0x100
process_one_work+0x28c/0x6c0
worker_thread+0x74/0x450
kthread+0x118/0x11c
but I'll say it anyway: the enetc_tx_onestep_tstamp() work item runs in
process context, therefore with softirqs enabled (i.o.w., it can be
interrupted by a softirq). If we hold the netif_tx_lock() when there is
an interrupt, and the NET_TX softirq then gets scheduled, this will take
the netif_tx_lock() a second time and deadlock the kernel.
To solve this, use netif_tx_lock_bh(), which blocks softirqs from
running. |
["https://git.kernel.org/stable/c/3c463721a73bdb57a913e0d3124677a3758886fc","https://git.kernel.org/stable/c/8232e5a84d25a84a5cbda0f241a00793fb6eb608","https://git.kernel.org/stable/c/e893dced1a18e77b1262f5c10169413f0ece0da7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49155
|
Medium |
fixed |
- 4.14.276
- 4.19.238
- 5.4.189
- 5.10.110
- 5.15.33
- 5.16.19
- 5.17.2
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Suppress a kernel complaint in qla_create_qpair()
[ 12.323788] BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/1020
[ 12.332297] caller is qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx]
[ 12.338417] CPU: 7 PID: 1020 Comm: systemd-udevd Tainted: G I --------- --- 5.14.0-29.el9.x86_64 #1
[ 12.348827] Hardware name: Dell Inc. PowerEdge R610/0F0XJ6, BIOS 6.6.0 05/22/2018
[ 12.356356] Call Trace:
[ 12.358821] dump_stack_lvl+0x34/0x44
[ 12.362514] check_preemption_disabled+0xd9/0xe0
[ 12.367164] qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx]
[ 12.372481] qla2x00_probe_one+0xa3a/0x1b80 [qla2xxx]
[ 12.377617] ? _raw_spin_lock_irqsave+0x19/0x40
[ 12.384284] local_pci_probe+0x42/0x80
[ 12.390162] ? pci_match_device+0xd7/0x110
[ 12.396366] pci_device_probe+0xfd/0x1b0
[ 12.402372] really_probe+0x1e7/0x3e0
[ 12.408114] __driver_probe_device+0xfe/0x180
[ 12.414544] driver_probe_device+0x1e/0x90
[ 12.420685] __driver_attach+0xc0/0x1c0
[ 12.426536] ? __device_attach_driver+0xe0/0xe0
[ 12.433061] ? __device_attach_driver+0xe0/0xe0
[ 12.439538] bus_for_each_dev+0x78/0xc0
[ 12.445294] bus_add_driver+0x12b/0x1e0
[ 12.451021] driver_register+0x8f/0xe0
[ 12.456631] ? 0xffffffffc07bc000
[ 12.461773] qla2x00_module_init+0x1be/0x229 [qla2xxx]
[ 12.468776] do_one_initcall+0x44/0x200
[ 12.474401] ? load_module+0xad3/0xba0
[ 12.479908] ? kmem_cache_alloc_trace+0x45/0x410
[ 12.486268] do_init_module+0x5c/0x280
[ 12.491730] __do_sys_init_module+0x12e/0x1b0
[ 12.497785] do_syscall_64+0x3b/0x90
[ 12.503029] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 12.509764] RIP: 0033:0x7f554f73ab2e |
["https://git.kernel.org/stable/c/1ab81d82fb1db7ec4be4b0d04563513e6d4bcdd5","https://git.kernel.org/stable/c/43195a0c620761fbb88db04e2475313855b948a4","https://git.kernel.org/stable/c/8077a7162bc3cf658dd9ff112bc77716c08458c5","https://git.kernel.org/stable/c/9c33d49ab9f3d8bd7512b3070cd2f07c4a8849d5","https://git.kernel.org/stable/c/a60447e7d451df42c7bde43af53b34f10f34f469","https://git.kernel.org/stable/c/a669a22aef0ceff706b885370af74b5a60a8ac85","https://git.kernel.org/stable/c/f68776f28d9134fa65056e7e63bfc734049730b7","https://git.kernel.org/stable/c/f97316dd393bc8df1cc2af6295a97b876eecf252"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26915
|
Medium |
fixed |
- 5.15.152
- 6.1.82
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Reset IH OVERFLOW_CLEAR bit
Allows us to detect subsequent IH ring buffer overflows as well. |
["https://git.kernel.org/stable/c/2827633c9dab6304ec4cdbf369363219832e605d","https://git.kernel.org/stable/c/7330256268664ea0a7dd5b07a3fed363093477dd","https://git.kernel.org/stable/c/8983397951b4b0bd51bb4b4ba9749424e1ccbb70","https://git.kernel.org/stable/c/9a9d00c23d170d4ef5a1b28e6b69f5c85dd12bc1","https://git.kernel.org/stable/c/a28f4d1e0bed85943d309ac243fd1c200f8af9a2","https://git.kernel.org/stable/c/2827633c9dab6304ec4cdbf369363219832e605d","https://git.kernel.org/stable/c/7330256268664ea0a7dd5b07a3fed363093477dd","https://git.kernel.org/stable/c/8983397951b4b0bd51bb4b4ba9749424e1ccbb70","https://git.kernel.org/stable/c/9a9d00c23d170d4ef5a1b28e6b69f5c85dd12bc1","https://git.kernel.org/stable/c/a28f4d1e0bed85943d309ac243fd1c200f8af9a2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52634
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix disable_otg_wa logic
[Why]
When switching to another HDMI mode, we are unnecesarilly
disabling/enabling FIFO causing both HPO and DIG registers to be set at
the same time when only HPO is supposed to be set.
This can lead to a system hang the next time we change refresh rates as
there are cases when we don't disable OTG/FIFO but FIFO is enabled when
it isn't supposed to be.
[How]
Removing the enable/disable FIFO entirely. |
["https://git.kernel.org/stable/c/2ce156482a6fef349d2eba98e5070c412d3af662","https://git.kernel.org/stable/c/ce29728ef6485a367934cc100249c66dd3cde5b6","https://git.kernel.org/stable/c/2ce156482a6fef349d2eba98e5070c412d3af662","https://git.kernel.org/stable/c/ce29728ef6485a367934cc100249c66dd3cde5b6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26757
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
md: Don't ignore read-only array in md_check_recovery()
Usually if the array is not read-write, md_check_recovery() won't
register new sync_thread in the first place. And if the array is
read-write and sync_thread is registered, md_set_readonly() will
unregister sync_thread before setting the array read-only. md/raid
follow this behavior hence there is no problem.
After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following
hang can be triggered by test shell/integrity-caching.sh:
1) array is read-only. dm-raid update super block:
rs_update_sbs
ro = mddev->ro
mddev->ro = 0
-> set array read-write
md_update_sb
2) register new sync thread concurrently.
3) dm-raid set array back to read-only:
rs_update_sbs
mddev->ro = ro
4) stop the array:
raid_dtr
md_stop
stop_sync_thread
set_bit(MD_RECOVERY_INTR, &mddev->recovery);
md_wakeup_thread_directly(mddev->sync_thread);
wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))
5) sync thread done:
md_do_sync
set_bit(MD_RECOVERY_DONE, &mddev->recovery);
md_wakeup_thread(mddev->thread);
6) daemon thread can't unregister sync thread:
md_check_recovery
if (!md_is_rdwr(mddev) &&
!test_bit(MD_RECOVERY_NEEDED, &mddev->recovery))
return;
-> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang;
The root cause is that dm-raid manipulate 'mddev->ro' by itself,
however, dm-raid really should stop sync thread before setting the
array read-only. Unfortunately, I need to read more code before I
can refacter the handler of 'mddev->ro' in dm-raid, hence let's fix
the problem the easy way for now to prevent dm-raid regression. |
["https://git.kernel.org/stable/c/2ea169c5a0b1134d573d07fc27a16f327ad0e7d3","https://git.kernel.org/stable/c/55a48ad2db64737f7ffc0407634218cc6e4c513b","https://git.kernel.org/stable/c/2ea169c5a0b1134d573d07fc27a16f327ad0e7d3","https://git.kernel.org/stable/c/55a48ad2db64737f7ffc0407634218cc6e4c513b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-23849
|
Medium |
|
N/A
|
In rds_recv_track_latency in net/rds/af_rds.c in the Linux kernel through 6.7.1, there is an off-by-one error for an RDS_MSG_RX_DGRAM_TRACE_MAX comparison, resulting in out-of-bounds access. |
["https://bugzilla.suse.com/show_bug.cgi?id=1219127","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=13e788deb7348cc88df34bed736c3b3b9927ea52","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/7LSPIOMIJYTLZB6QKPQVVAYSUETUWKPF/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LBVHM4LGMFIHBN4UBESYRFMYX3WUICV5/","https://lore.kernel.org/netdev/1705715319-19199-1-git-send-email-sharath.srinivasan%40oracle.com/","https://lore.kernel.org/netdev/CALGdzuoVdq-wtQ4Az9iottBqC5cv9ZhcE5q8N7LfYFvkRsOVcw%40mail.gmail.com","https://bugzilla.suse.com/show_bug.cgi?id=1219127","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=13e788deb7348cc88df34bed736c3b3b9927ea52","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/7LSPIOMIJYTLZB6QKPQVVAYSUETUWKPF/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LBVHM4LGMFIHBN4UBESYRFMYX3WUICV5/","https://lore.kernel.org/netdev/1705715319-19199-1-git-send-email-sharath.srinivasan%40oracle.com/","https://lore.kernel.org/netdev/CALGdzuoVdq-wtQ4Az9iottBqC5cv9ZhcE5q8N7LfYFvkRsOVcw%40mail.gmail.com"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26896
|
Medium |
fixed |
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: wfx: fix memory leak when starting AP
Kmemleak reported this error:
unreferenced object 0xd73d1180 (size 184):
comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.245s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 1e 00 01 00 00 00 00 00 ................
backtrace:
[<5ca11420>] kmem_cache_alloc+0x20c/0x5ac
[<127bdd74>] __alloc_skb+0x144/0x170
[<fb8a5e38>] __netdev_alloc_skb+0x50/0x180
[<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]
[<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]
[<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx]
[<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211]
[<a4a661cd>] nl80211_start_ap+0x76c/0x9e0 [cfg80211]
[<47bd8b68>] genl_rcv_msg+0x198/0x378
[<453ef796>] netlink_rcv_skb+0xd0/0x130
[<6b7c977a>] genl_rcv+0x34/0x44
[<66b2d04d>] netlink_unicast+0x1b4/0x258
[<f965b9b6>] netlink_sendmsg+0x1e8/0x428
[<aadb8231>] ____sys_sendmsg+0x1e0/0x274
[<d2b5212d>] ___sys_sendmsg+0x80/0xb4
[<69954f45>] __sys_sendmsg+0x64/0xa8
unreferenced object 0xce087000 (size 1024):
comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.246s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
10 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............
backtrace:
[<9a993714>] __kmalloc_track_caller+0x230/0x600
[<f83ea192>] kmalloc_reserve.constprop.0+0x30/0x74
[<a2c61343>] __alloc_skb+0xa0/0x170
[<fb8a5e38>] __netdev_alloc_skb+0x50/0x180
[<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]
[<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]
[<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx]
[<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211]
[<a4a661cd>] nl80211_start_ap+0x76c/0x9e0 [cfg80211]
[<47bd8b68>] genl_rcv_msg+0x198/0x378
[<453ef796>] netlink_rcv_skb+0xd0/0x130
[<6b7c977a>] genl_rcv+0x34/0x44
[<66b2d04d>] netlink_unicast+0x1b4/0x258
[<f965b9b6>] netlink_sendmsg+0x1e8/0x428
[<aadb8231>] ____sys_sendmsg+0x1e0/0x274
[<d2b5212d>] ___sys_sendmsg+0x80/0xb4
However, since the kernel is build optimized, it seems the stack is not
accurate. It appears the issue is related to wfx_set_mfp_ap(). The issue
is obvious in this function: memory allocated by ieee80211_beacon_get()
is never released. Fixing this leak makes kmemleak happy. |
["https://git.kernel.org/stable/c/12f00a367b2b62756e0396f14b54c2c15524e1c3","https://git.kernel.org/stable/c/3a71ec74e5e3478d202a1874f085ca3ef40be49b","https://git.kernel.org/stable/c/a1f57a0127b89a6b6620514564aa7eaec16d9af3","https://git.kernel.org/stable/c/b8cfb7c819dd39965136a66fe3a7fde688d976fc","https://git.kernel.org/stable/c/dadbb5d29d6c5f571a50272fce8c1505a9559487","https://git.kernel.org/stable/c/12f00a367b2b62756e0396f14b54c2c15524e1c3","https://git.kernel.org/stable/c/3a71ec74e5e3478d202a1874f085ca3ef40be49b","https://git.kernel.org/stable/c/a1f57a0127b89a6b6620514564aa7eaec16d9af3","https://git.kernel.org/stable/c/b8cfb7c819dd39965136a66fe3a7fde688d976fc","https://git.kernel.org/stable/c/dadbb5d29d6c5f571a50272fce8c1505a9559487"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26718
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
dm-crypt, dm-verity: disable tasklets
Tasklets have an inherent problem with memory corruption. The function
tasklet_action_common calls tasklet_trylock, then it calls the tasklet
callback and then it calls tasklet_unlock. If the tasklet callback frees
the structure that contains the tasklet or if it calls some code that may
free it, tasklet_unlock will write into free memory.
The commits 8e14f610159d and d9a02e016aaf try to fix it for dm-crypt, but
it is not a sufficient fix and the data corruption can still happen [1].
There is no fix for dm-verity and dm-verity will write into free memory
with every tasklet-processed bio.
There will be atomic workqueues implemented in the kernel 6.9 [2]. They
will have better interface and they will not suffer from the memory
corruption problem.
But we need something that stops the memory corruption now and that can be
backported to the stable kernels. So, I'm proposing this commit that
disables tasklets in both dm-crypt and dm-verity. This commit doesn't
remove the tasklet support, because the tasklet code will be reused when
atomic workqueues will be implemented.
[1] https://lore.kernel.org/all/d390d7ee-f142-44d3-822a-87949e14608b@suse.de/T/
[2] https://lore.kernel.org/lkml/20240130091300.2968534-1-tj@kernel.org/ |
["https://git.kernel.org/stable/c/0a9bab391e336489169b95cb0d4553d921302189","https://git.kernel.org/stable/c/0c45a20cbe68bc4d681734f5c03891124a274257","https://git.kernel.org/stable/c/30884a44e0cedc3dfda8c22432f3ba4078ec2d94","https://git.kernel.org/stable/c/5735a2671ffb70ea29ca83969fe01316ee2ed6fc","https://git.kernel.org/stable/c/b825e0f9d68c178072bffd32dd34c39e3d2d597a","https://git.kernel.org/stable/c/0a9bab391e336489169b95cb0d4553d921302189","https://git.kernel.org/stable/c/0c45a20cbe68bc4d681734f5c03891124a274257","https://git.kernel.org/stable/c/30884a44e0cedc3dfda8c22432f3ba4078ec2d94","https://git.kernel.org/stable/c/5735a2671ffb70ea29ca83969fe01316ee2ed6fc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26591
|
Medium |
fixed |
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix re-attachment branch in bpf_tracing_prog_attach
The following case can cause a crash due to missing attach_btf:
1) load rawtp program
2) load fentry program with rawtp as target_fd
3) create tracing link for fentry program with target_fd = 0
4) repeat 3
In the end we have:
- prog->aux->dst_trampoline == NULL
- tgt_prog == NULL (because we did not provide target_fd to link_create)
- prog->aux->attach_btf == NULL (the program was loaded with attach_prog_fd=X)
- the program was loaded for tgt_prog but we have no way to find out which one
BUG: kernel NULL pointer dereference, address: 0000000000000058
Call Trace:
<TASK>
? __die+0x20/0x70
? page_fault_oops+0x15b/0x430
? fixup_exception+0x22/0x330
? exc_page_fault+0x6f/0x170
? asm_exc_page_fault+0x22/0x30
? bpf_tracing_prog_attach+0x279/0x560
? btf_obj_id+0x5/0x10
bpf_tracing_prog_attach+0x439/0x560
__sys_bpf+0x1cf4/0x2de0
__x64_sys_bpf+0x1c/0x30
do_syscall_64+0x41/0xf0
entry_SYSCALL_64_after_hwframe+0x6e/0x76
Return -EINVAL in this situation. |
["https://git.kernel.org/stable/c/50ae82f080cf87e84828f066c31723b781d68f5b","https://git.kernel.org/stable/c/6cc9c0af0aa06f781fa515a1734b1a4239dfd2c0","https://git.kernel.org/stable/c/715d82ba636cb3629a6e18a33bb9dbe53f9936ee","https://git.kernel.org/stable/c/8c8bcd45e9b10eef12321f08d2e5be33d615509c","https://git.kernel.org/stable/c/a7b98aa10f895e2569403896f2d19b73b6c95653","https://git.kernel.org/stable/c/50ae82f080cf87e84828f066c31723b781d68f5b","https://git.kernel.org/stable/c/6cc9c0af0aa06f781fa515a1734b1a4239dfd2c0","https://git.kernel.org/stable/c/715d82ba636cb3629a6e18a33bb9dbe53f9936ee","https://git.kernel.org/stable/c/8c8bcd45e9b10eef12321f08d2e5be33d615509c","https://git.kernel.org/stable/c/a7b98aa10f895e2569403896f2d19b73b6c95653"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-50211
|
Low |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
udf: refactor inode_bmap() to handle error
Refactor inode_bmap() to handle error since udf_next_aext() can return
error now. On situations like ftruncate, udf_extend_file() can now
detect errors and bail out early without resorting to checking for
particular offsets and assuming internal behavior of these functions. |
["https://git.kernel.org/stable/c/493447dd8336607fce426f7879e581095f6c606e","https://git.kernel.org/stable/c/b22d9a5698abf04341f8fbc30141e0673863c3a6","https://git.kernel.org/stable/c/c226964ec786f3797ed389a16392ce4357697d24"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26875
|
Medium |
fixed |
- 4.19.311
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
media: pvrusb2: fix uaf in pvr2_context_set_notify
[Syzbot reported]
BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26
CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Workqueue: usb_hub_wq hub_event
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:377 [inline]
print_report+0xc4/0x620 mm/kasan/report.c:488
kasan_report+0xda/0x110 mm/kasan/report.c:601
pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline]
pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272
Freed by task 906:
kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640
poison_slab_object mm/kasan/common.c:241 [inline]
__kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257
kasan_slab_free include/linux/kasan.h:184 [inline]
slab_free_hook mm/slub.c:2121 [inline]
slab_free mm/slub.c:4299 [inline]
kfree+0x105/0x340 mm/slub.c:4409
pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline]
pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158
[Analyze]
Task A set disconnect_flag = !0, which resulted in Task B's condition being met
and releasing mp, leading to this issue.
[Fix]
Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect()
to avoid this issue. |
["https://git.kernel.org/stable/c/0a0b79ea55de8514e1750884e5fec77f9fdd01ee","https://git.kernel.org/stable/c/3a1ec89708d2e57e2712f46241282961b1a7a475","https://git.kernel.org/stable/c/40cd818fae875c424a8335009db33c7b5a07de3a","https://git.kernel.org/stable/c/8e60b99f6b7ccb3badeb512f5eb613ad45904592","https://git.kernel.org/stable/c/ab896d93fd6a2cd1afeb034c3cc9226cb499209f","https://git.kernel.org/stable/c/d29ed08964cec8b9729bc55c7bb23f679d7a18fb","https://git.kernel.org/stable/c/eaa410e05bdf562c90b23cdf2d9327f9c4625e16","https://git.kernel.org/stable/c/eb6e9dce979c08210ff7249e5e0eceb8991bfcd7","https://git.kernel.org/stable/c/ed8000e1e8e9684ab6c30cf2b526c0cea039929c","https://git.kernel.org/stable/c/0a0b79ea55de8514e1750884e5fec77f9fdd01ee","https://git.kernel.org/stable/c/3a1ec89708d2e57e2712f46241282961b1a7a475","https://git.kernel.org/stable/c/40cd818fae875c424a8335009db33c7b5a07de3a","https://git.kernel.org/stable/c/8e60b99f6b7ccb3badeb512f5eb613ad45904592","https://git.kernel.org/stable/c/ab896d93fd6a2cd1afeb034c3cc9226cb499209f","https://git.kernel.org/stable/c/d29ed08964cec8b9729bc55c7bb23f679d7a18fb","https://git.kernel.org/stable/c/eaa410e05bdf562c90b23cdf2d9327f9c4625e16","https://git.kernel.org/stable/c/eb6e9dce979c08210ff7249e5e0eceb8991bfcd7","https://git.kernel.org/stable/c/ed8000e1e8e9684ab6c30cf2b526c0cea039929c","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3635
|
High |
fixed |
- 4.9.326
- 4.14.291
- 4.19.256
- 5.4.211
- 5.10.138
- 5.15.63
- 5.19.4
|
A vulnerability, which was classified as critical, has been found in Linux Kernel. Affected by this issue is the function tst_timer of the file drivers/atm/idt77252.c of the component IPsec. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. VDB-211934 is the identifier assigned to this vulnerability. |
["https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=3f4093e2bf4673f218c0bf17d8362337c400e77b","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://vuldb.com/?id.211934","https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=3f4093e2bf4673f218c0bf17d8362337c400e77b","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://vuldb.com/?id.211934"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3633
|
Low |
|
N/A
|
A vulnerability classified as problematic has been found in Linux Kernel. Affected is the function j1939_session_destroy of the file net/can/j1939/transport.c. The manipulation leads to memory leak. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211932. |
["https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=8c21c54a53ab21842f5050fa090f26b03c0313d6","https://vuldb.com/?ctiid.211932","https://vuldb.com/?id.211932","https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=8c21c54a53ab21842f5050fa090f26b03c0313d6","https://vuldb.com/?ctiid.211932","https://vuldb.com/?id.211932"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-0264
|
Medium |
fixed |
|
A vulnerability was found in the Linux kernel's eBPF verifier when handling internal data structures. Internal memory locations could be returned to userspace. A local attacker with the permissions to insert eBPF code to the kernel can use this to leak internal kernel memory details defeating some of the exploit mitigations in place for the kernel. This flaws affects kernel versions < v5.16-rc6 |
["https://bugzilla.redhat.com/show_bug.cgi?id=2041547","https://bugzilla.redhat.com/show_bug.cgi?id=2041547"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-47745
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mm: call the security_mmap_file() LSM hook in remap_file_pages()
The remap_file_pages syscall handler calls do_mmap() directly, which
doesn't contain the LSM security check. And if the process has called
personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for
RW pages, this will actually result in remapping the pages to RWX,
bypassing a W^X policy enforced by SELinux.
So we should check prot by security_mmap_file LSM hook in the
remap_file_pages syscall handler before do_mmap() is called. Otherwise, it
potentially permits an attacker to bypass a W^X policy enforced by
SELinux.
The bypass is similar to CVE-2016-10044, which bypass the same thing via
AIO and can be found in [1].
The PoC:
$ cat > test.c
int main(void) {
size_t pagesz = sysconf(_SC_PAGE_SIZE);
int mfd = syscall(SYS_memfd_create, "test", 0);
const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE,
MAP_SHARED, mfd, 0);
unsigned int old = syscall(SYS_personality, 0xffffffff);
syscall(SYS_personality, READ_IMPLIES_EXEC | old);
syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0);
syscall(SYS_personality, old);
// show the RWX page exists even if W^X policy is enforced
int fd = open("/proc/self/maps", O_RDONLY);
unsigned char buf2[1024];
while (1) {
int ret = read(fd, buf2, 1024);
if (ret <= 0) break;
write(1, buf2, ret);
}
close(fd);
}
$ gcc test.c -o test
$ ./test | grep rwx
7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted)
[PM: subject line tweaks] |
["https://git.kernel.org/stable/c/0f910dbf2f2a4a7820ba4bac7b280f7108aa05b1","https://git.kernel.org/stable/c/3393fddbfa947c8e1fdcc4509226905ffffd8b89","https://git.kernel.org/stable/c/49d3a4ad57c57227c3b0fd6cd4188b2a5ebd6178","https://git.kernel.org/stable/c/ce14f38d6ee9e88e37ec28427b4b93a7c33c70d3","https://git.kernel.org/stable/c/ea7e2d5e49c05e5db1922387b09ca74aa40f46e2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3812
|
High |
fixed |
- 4.19.265
- 5.4.224
- 5.10.154
- 5.15.78
- 6.0.8
|
An out-of-bounds memory access flaw was found in the Linux kernel’s TUN/TAP device driver functionality in how a user generates a malicious (too big) networking packet when napi frags is enabled. This flaw allows a local user to crash or potentially escalate their privileges on the system. |
["https://access.redhat.com/errata/RHSA-2023:6799","https://access.redhat.com/errata/RHSA-2023:6813","https://access.redhat.com/errata/RHSA-2023:7370","https://access.redhat.com/errata/RHSA-2023:7379","https://access.redhat.com/errata/RHSA-2023:7382","https://access.redhat.com/errata/RHSA-2023:7389","https://access.redhat.com/errata/RHSA-2023:7411","https://access.redhat.com/errata/RHSA-2023:7418","https://access.redhat.com/errata/RHSA-2023:7548","https://access.redhat.com/errata/RHSA-2023:7549","https://access.redhat.com/errata/RHSA-2023:7554","https://access.redhat.com/errata/RHSA-2024:0340","https://access.redhat.com/errata/RHSA-2024:0378","https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:0461","https://access.redhat.com/errata/RHSA-2024:0554","https://access.redhat.com/errata/RHSA-2024:0562","https://access.redhat.com/errata/RHSA-2024:0563","https://access.redhat.com/errata/RHSA-2024:0575","https://access.redhat.com/errata/RHSA-2024:0593","https://access.redhat.com/errata/RHSA-2024:1961","https://access.redhat.com/errata/RHSA-2024:2006","https://access.redhat.com/errata/RHSA-2024:2008","https://access.redhat.com/security/cve/CVE-2023-3812","https://bugzilla.redhat.com/show_bug.cgi?id=2224048","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=363a5328f4b0","https://access.redhat.com/errata/RHSA-2023:6799","https://access.redhat.com/errata/RHSA-2023:6813","https://access.redhat.com/errata/RHSA-2023:7370","https://access.redhat.com/errata/RHSA-2023:7379","https://access.redhat.com/errata/RHSA-2023:7382","https://access.redhat.com/errata/RHSA-2023:7389","https://access.redhat.com/errata/RHSA-2023:7411","https://access.redhat.com/errata/RHSA-2023:7418","https://access.redhat.com/errata/RHSA-2023:7548","https://access.redhat.com/errata/RHSA-2023:7549","https://access.redhat.com/errata/RHSA-2023:7554","https://access.redhat.com/errata/RHSA-2024:0340","https://access.redhat.com/errata/RHSA-2024:0378","https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:0461","https://access.redhat.com/errata/RHSA-2024:0554","https://access.redhat.com/errata/RHSA-2024:0562","https://access.redhat.com/errata/RHSA-2024:0563","https://access.redhat.com/errata/RHSA-2024:0575","https://access.redhat.com/errata/RHSA-2024:0593","https://access.redhat.com/errata/RHSA-2024:1961","https://access.redhat.com/errata/RHSA-2024:2006","https://access.redhat.com/errata/RHSA-2024:2008","https://access.redhat.com/security/cve/CVE-2023-3812","https://bugzilla.redhat.com/show_bug.cgi?id=2224048","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=363a5328f4b0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46794
|
Low |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
x86/tdx: Fix data leak in mmio_read()
The mmio_read() function makes a TDVMCALL to retrieve MMIO data for an
address from the VMM.
Sean noticed that mmio_read() unintentionally exposes the value of an
initialized variable (val) on the stack to the VMM.
This variable is only needed as an output value. It did not need to be
passed to the VMM in the first place.
Do not send the original value of *val to the VMM.
[ dhansen: clarify what 'val' is used for. ] |
["https://git.kernel.org/stable/c/26c6af49d26ffc377e392e30d4086db19eed0ef7","https://git.kernel.org/stable/c/b55ce742afcb8e8189d82f2f1e635ba1b5a461fa","https://git.kernel.org/stable/c/b6fb565a2d15277896583d471b21bc14a0c99661","https://git.kernel.org/stable/c/ef00818c50cf55a3a56bd9a9fae867c92dfb84e7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-7042
|
Medium |
fixed |
- 4.19.311
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
A null pointer dereference vulnerability was found in ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() in drivers/net/wireless/ath/ath10k/wmi-tlv.c in the Linux kernel. This issue could be exploited to trigger a denial of service. |
["https://access.redhat.com/security/cve/CVE-2023-7042","https://bugzilla.redhat.com/show_bug.cgi?id=2255497","https://patchwork.kernel.org/project/linux-wireless/patch/20231208043433.271449-1-hdthky0@gmail.com/","https://access.redhat.com/security/cve/CVE-2023-7042","https://bugzilla.redhat.com/show_bug.cgi?id=2255497","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/54PLF5J33IRSLSR4UU6LQSMXX6FI5AOQ/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/C25BK2YH5MZ6VNQXKF2NAJBTGXVEPKGC/","https://patchwork.kernel.org/project/linux-wireless/patch/20231208043433.271449-1-hdthky0@gmail.com/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3773
|
Medium |
|
N/A
|
A flaw was found in the Linux kernel’s IP framework for transforming packets (XFRM subsystem). This issue may allow a malicious user with CAP_NET_ADMIN privileges to cause a 4 byte out-of-bounds read of XFRMA_MTIMER_THRESH when parsing netlink attributes, leading to potential leakage of sensitive heap data to userspace. |
["https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/security/cve/CVE-2023-3773","https://bugzilla.redhat.com/show_bug.cgi?id=2218944","https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/security/cve/CVE-2023-3773","https://bugzilla.redhat.com/show_bug.cgi?id=2218944","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://www.debian.org/security/2023/dsa-5492"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-6915
|
Medium |
fixed |
|
A Null pointer dereference problem was found in ida_free in lib/idr.c in the Linux Kernel. This issue may allow an attacker using this library to cause a denial of service problem due to a missing check at a function return. |
["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-6915","https://bugzilla.redhat.com/show_bug.cgi?id=2254982","https://github.com/torvalds/linux/commit/af73483f4e8b6f5c68c9aa63257bdd929a9c194a","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-6915","https://bugzilla.redhat.com/show_bug.cgi?id=2254982","https://github.com/torvalds/linux/commit/af73483f4e8b6f5c68c9aa63257bdd929a9c194a","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2019-3887
|
Medium |
|
N/A
|
A flaw was found in the way KVM hypervisor handled x2APIC Machine Specific Rregister (MSR) access with nested(=1) virtualization enabled. In that, L1 guest could access L0's APIC register values via L2 guest, when 'virtualize x2APIC mode' is enabled. A guest could use this flaw to potentially crash the host kernel resulting in DoS issue. Kernel versions from 4.16 and newer are vulnerable to this issue. |
["http://www.securityfocus.com/bid/107850","https://access.redhat.com/errata/RHSA-2019:2703","https://access.redhat.com/errata/RHSA-2019:2741","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-3887","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IWPOIII2L73HV5PGXSGMRMKQIK47UIYE/","https://usn.ubuntu.com/3979-1/","https://usn.ubuntu.com/3980-1/","https://usn.ubuntu.com/3980-2/","http://www.securityfocus.com/bid/107850","https://access.redhat.com/errata/RHSA-2019:2703","https://access.redhat.com/errata/RHSA-2019:2741","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-3887","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IWPOIII2L73HV5PGXSGMRMKQIK47UIYE/","https://usn.ubuntu.com/3979-1/","https://usn.ubuntu.com/3980-1/","https://usn.ubuntu.com/3980-2/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-4002
|
Medium |
fixed |
|
A memory leak flaw in the Linux kernel's hugetlbfs memory usage was found in the way the user maps some regions of memory twice using shmget() which are aligned to PUD alignment with the fault of some of the memory pages. A local user could use this flaw to get unauthorized access to some data. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2025726","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=13e4ad2ce8df6e058ef482a31fdd81c725b0f7ea","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a4a118f2eead1d6c49e00765de89878288d4b890","https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://www.debian.org/security/2022/dsa-5096","https://www.openwall.com/lists/oss-security/2021/11/25/1","https://www.oracle.com/security-alerts/cpujul2022.html","https://bugzilla.redhat.com/show_bug.cgi?id=2025726","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=13e4ad2ce8df6e058ef482a31fdd81c725b0f7ea","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a4a118f2eead1d6c49e00765de89878288d4b890","https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://www.debian.org/security/2022/dsa-5096","https://www.openwall.com/lists/oss-security/2021/11/25/1","https://www.oracle.com/security-alerts/cpujul2022.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-2513
|
Medium |
|
N/A
|
A use-after-free vulnerability was found in the Linux kernel's ext4 filesystem in the way it handled the extra inode size for extended attributes. This flaw could allow a privileged local user to cause a system crash or other undefined behaviors. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2193097","https://github.com/torvalds/linux/commit/67d7d8ad99be","https://lore.kernel.org/all/20220616021358.2504451-1-libaokun1%40huawei.com/","https://bugzilla.redhat.com/show_bug.cgi?id=2193097","https://github.com/torvalds/linux/commit/67d7d8ad99be","https://lore.kernel.org/all/20220616021358.2504451-1-libaokun1%40huawei.com/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26586
|
Medium |
fixed |
- 5.10.209
- 5.15.148
- 6.1.79
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix stack corruption
When tc filters are first added to a net device, the corresponding local
port gets bound to an ACL group in the device. The group contains a list
of ACLs. In turn, each ACL points to a different TCAM region where the
filters are stored. During forwarding, the ACLs are sequentially
evaluated until a match is found.
One reason to place filters in different regions is when they are added
with decreasing priorities and in an alternating order so that two
consecutive filters can never fit in the same region because of their
key usage.
In Spectrum-2 and newer ASICs the firmware started to report that the
maximum number of ACLs in a group is more than 16, but the layout of the
register that configures ACL groups (PAGT) was not updated to account
for that. It is therefore possible to hit stack corruption [1] in the
rare case where more than 16 ACLs in a group are required.
Fix by limiting the maximum ACL group size to the minimum between what
the firmware reports and the maximum ACLs that fit in the PAGT register.
Add a test case to make sure the machine does not crash when this
condition is hit.
[1]
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120
[...]
dump_stack_lvl+0x36/0x50
panic+0x305/0x330
__stack_chk_fail+0x15/0x20
mlxsw_sp_acl_tcam_group_update+0x116/0x120
mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110
mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20
mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0
mlxsw_sp_acl_rule_add+0x47/0x240
mlxsw_sp_flower_replace+0x1a9/0x1d0
tc_setup_cb_add+0xdc/0x1c0
fl_hw_replace_filter+0x146/0x1f0
fl_change+0xc17/0x1360
tc_new_tfilter+0x472/0xb90
rtnetlink_rcv_msg+0x313/0x3b0
netlink_rcv_skb+0x58/0x100
netlink_unicast+0x244/0x390
netlink_sendmsg+0x1e4/0x440
____sys_sendmsg+0x164/0x260
___sys_sendmsg+0x9a/0xe0
__sys_sendmsg+0x7a/0xc0
do_syscall_64+0x40/0xe0
entry_SYSCALL_64_after_hwframe+0x63/0x6b |
["https://git.kernel.org/stable/c/2f5e1565740490706332c06f36211d4ce0f88e62","https://git.kernel.org/stable/c/348112522a35527c5bcba933b9fefb40a4f44f15","https://git.kernel.org/stable/c/483ae90d8f976f8339cf81066312e1329f2d3706","https://git.kernel.org/stable/c/56750ea5d15426b5f307554e7699e8b5f76c3182","https://git.kernel.org/stable/c/6fd24675188d354b1cad47462969afa2ab09d819","https://git.kernel.org/stable/c/a361c2c1da5dbb13ca67601cf961ab3ad68af383","https://git.kernel.org/stable/c/2f5e1565740490706332c06f36211d4ce0f88e62","https://git.kernel.org/stable/c/348112522a35527c5bcba933b9fefb40a4f44f15","https://git.kernel.org/stable/c/483ae90d8f976f8339cf81066312e1329f2d3706","https://git.kernel.org/stable/c/56750ea5d15426b5f307554e7699e8b5f76c3182","https://git.kernel.org/stable/c/6fd24675188d354b1cad47462969afa2ab09d819","https://git.kernel.org/stable/c/a361c2c1da5dbb13ca67601cf961ab3ad68af383","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52504
|
High |
fixed |
- 4.19.297
- 5.4.270
- 5.10.199
- 5.15.136
- 6.1.59
- 6.5.8
|
In the Linux kernel, the following vulnerability has been resolved:
x86/alternatives: Disable KASAN in apply_alternatives()
Fei has reported that KASAN triggers during apply_alternatives() on
a 5-level paging machine:
BUG: KASAN: out-of-bounds in rcu_is_watching()
Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0
...
__asan_load4()
rcu_is_watching()
trace_hardirqs_on()
text_poke_early()
apply_alternatives()
...
On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57)
gets patched. It includes KASAN code, where KASAN_SHADOW_START depends on
__VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled().
KASAN gets confused when apply_alternatives() patches the
KASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START
static, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue.
Fix it for real by disabling KASAN while the kernel is patching alternatives.
[ mingo: updated the changelog ] |
["https://git.kernel.org/stable/c/3719d3c36aa853d5a2401af9f8d6b116c91ad5ae","https://git.kernel.org/stable/c/3770c38cd6a60494da29ac2da73ff8156440a2d1","https://git.kernel.org/stable/c/5b784489c8158518bf7a466bb3cc045b0fb66b4b","https://git.kernel.org/stable/c/6788b10620ca6e98575d1e06e72a8974aad7657e","https://git.kernel.org/stable/c/cd287cc208dfe6bd6da98e7f88e723209242c9b4","https://git.kernel.org/stable/c/d35652a5fc9944784f6f50a5c979518ff8dacf61","https://git.kernel.org/stable/c/ecba5afe86f30605eb9dfb7f265a8de0218d4cfc","https://git.kernel.org/stable/c/3719d3c36aa853d5a2401af9f8d6b116c91ad5ae","https://git.kernel.org/stable/c/3770c38cd6a60494da29ac2da73ff8156440a2d1","https://git.kernel.org/stable/c/5b784489c8158518bf7a466bb3cc045b0fb66b4b","https://git.kernel.org/stable/c/6788b10620ca6e98575d1e06e72a8974aad7657e","https://git.kernel.org/stable/c/cd287cc208dfe6bd6da98e7f88e723209242c9b4","https://git.kernel.org/stable/c/d35652a5fc9944784f6f50a5c979518ff8dacf61","https://git.kernel.org/stable/c/ecba5afe86f30605eb9dfb7f265a8de0218d4cfc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3567
|
High |
fixed |
|
A use-after-free flaw was found in vcs_read in drivers/tty/vt/vc_screen.c in vc_screen in the Linux Kernel. This issue may allow an attacker with local user access to cause a system crash or leak internal kernel information. |
["https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:0431","https://access.redhat.com/errata/RHSA-2024:0432","https://access.redhat.com/errata/RHSA-2024:0439","https://access.redhat.com/errata/RHSA-2024:0448","https://access.redhat.com/errata/RHSA-2024:0575","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-3567","https://bugzilla.redhat.com/show_bug.cgi?id=2221463","https://www.spinics.net/lists/stable-commits/msg285184.html","http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:0431","https://access.redhat.com/errata/RHSA-2024:0432","https://access.redhat.com/errata/RHSA-2024:0439","https://access.redhat.com/errata/RHSA-2024:0448","https://access.redhat.com/errata/RHSA-2024:0575","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-3567","https://bugzilla.redhat.com/show_bug.cgi?id=2221463","https://www.spinics.net/lists/stable-commits/msg285184.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26597
|
High |
fixed |
- 4.19.306
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
net: qualcomm: rmnet: fix global oob in rmnet_policy
The variable rmnet_link_ops assign a *bigger* maxtype which leads to a
global out-of-bounds read when parsing the netlink attributes. See bug
trace below:
==================================================================
BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]
BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
Read of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207
CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G N 6.1.0 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:284 [inline]
print_report+0x172/0x475 mm/kasan/report.c:395
kasan_report+0xbb/0x1c0 mm/kasan/report.c:495
validate_nla lib/nlattr.c:386 [inline]
__nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
__nla_parse+0x3e/0x50 lib/nlattr.c:697
nla_parse_nested_deprecated include/net/netlink.h:1248 [inline]
__rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485
rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594
rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091
netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg+0x154/0x190 net/socket.c:734
____sys_sendmsg+0x6df/0x840 net/socket.c:2482
___sys_sendmsg+0x110/0x1b0 net/socket.c:2536
__sys_sendmsg+0xf3/0x1c0 net/socket.c:2565
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fdcf2072359
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359
RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003
RBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000
</TASK>
The buggy address belongs to the variable:
rmnet_policy+0x30/0xe0
The buggy address belongs to the physical page:
page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243
flags: 0x200000000001000(reserved|node=0|zone=2)
raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000
raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07
ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9
>ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9
^
ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9
ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9
According to the comment of `nla_parse_nested_deprecated`, the maxtype
should be len(destination array) - 1. Hence use `IFLA_RMNET_MAX` here. |
["https://git.kernel.org/stable/c/02467ab8b404d80429107588e0f3425cf5fcd2e5","https://git.kernel.org/stable/c/093dab655808207f7a9f54cf156240aeafc70590","https://git.kernel.org/stable/c/17d06a5c44d8fd2e8e61bac295b09153496f87e1","https://git.kernel.org/stable/c/2295c22348faf795e1ccdf618f6eb7afdb2f7447","https://git.kernel.org/stable/c/3b5254862258b595662a0ccca6e9eeb88d6e7468","https://git.kernel.org/stable/c/b33fb5b801c6db408b774a68e7c8722796b59ecc","https://git.kernel.org/stable/c/c4734535034672f59f2652e1e0058c490da62a5c","https://git.kernel.org/stable/c/ee1dc3bf86f2df777038506b139371a9add02534","https://git.kernel.org/stable/c/02467ab8b404d80429107588e0f3425cf5fcd2e5","https://git.kernel.org/stable/c/093dab655808207f7a9f54cf156240aeafc70590","https://git.kernel.org/stable/c/17d06a5c44d8fd2e8e61bac295b09153496f87e1","https://git.kernel.org/stable/c/2295c22348faf795e1ccdf618f6eb7afdb2f7447","https://git.kernel.org/stable/c/3b5254862258b595662a0ccca6e9eeb88d6e7468","https://git.kernel.org/stable/c/b33fb5b801c6db408b774a68e7c8722796b59ecc","https://git.kernel.org/stable/c/c4734535034672f59f2652e1e0058c490da62a5c","https://git.kernel.org/stable/c/ee1dc3bf86f2df777038506b139371a9add02534","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-33288
|
Medium |
fixed |
|
An issue was discovered in the Linux kernel before 6.2.9. A use-after-free was found in bq24190_remove in drivers/power/supply/bq24190_charger.c. It could allow a local attacker to crash the system due to a race condition. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.9","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=47c29d69212911f50bdcdd0564b5999a559010d4","https://github.com/torvalds/linux/commit/47c29d69212911f50bdcdd0564b5999a559010d4","https://lore.kernel.org/all/CAHk-=whcaHLNpb7Mu_QX7ABwPgyRyfW-V8=v4Mv0S22fpjY4JQ%40mail.gmail.com/","https://lore.kernel.org/lkml/20230309174728.233732-1-zyytlz.wz%40163.com/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.9","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=47c29d69212911f50bdcdd0564b5999a559010d4","https://github.com/torvalds/linux/commit/47c29d69212911f50bdcdd0564b5999a559010d4","https://lore.kernel.org/all/CAHk-=whcaHLNpb7Mu_QX7ABwPgyRyfW-V8=v4Mv0S22fpjY4JQ%40mail.gmail.com/","https://lore.kernel.org/lkml/20230309174728.233732-1-zyytlz.wz%40163.com/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-53020
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
l2tp: close all race conditions in l2tp_tunnel_register()
The code in l2tp_tunnel_register() is racy in several ways:
1. It modifies the tunnel socket _after_ publishing it.
2. It calls setup_udp_tunnel_sock() on an existing socket without
locking.
3. It changes sock lock class on fly, which triggers many syzbot
reports.
This patch amends all of them by moving socket initialization code
before publishing and under sock lock. As suggested by Jakub, the
l2tp lockdep class is not necessary as we can just switch to
bh_lock_sock_nested(). |
["https://git.kernel.org/stable/c/0b2c59720e65885a394a017d0cf9cab118914682","https://git.kernel.org/stable/c/2d77e5c0ad79004b5ef901895437e9cce6dfcc7e","https://git.kernel.org/stable/c/77e8ed776cdb1a24b2aab8fe7c6f1f154235e1ce","https://git.kernel.org/stable/c/cef0845b6dcfa2f6c2c832e7f9622551456c741d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52589
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
media: rkisp1: Fix IRQ disable race issue
In rkisp1_isp_stop() and rkisp1_csi_disable() the driver masks the
interrupts and then apparently assumes that the interrupt handler won't
be running, and proceeds in the stop procedure. This is not the case, as
the interrupt handler can already be running, which would lead to the
ISP being disabled while the interrupt handler handling a captured
frame.
This brings up two issues: 1) the ISP could be powered off while the
interrupt handler is still running and accessing registers, leading to
board lockup, and 2) the interrupt handler code and the code that
disables the streaming might do things that conflict.
It is not clear to me if 2) causes a real issue, but 1) can be seen with
a suitable delay (or printk in my case) in the interrupt handler,
leading to board lockup. |
["https://git.kernel.org/stable/c/7bb1a2822aa2c2de4e09bf7c56dd93bd532f1fa7","https://git.kernel.org/stable/c/870565f063a58576e8a4529f122cac4325c6b395","https://git.kernel.org/stable/c/bf808f58681cab64c81cd814551814fd34e540fe","https://git.kernel.org/stable/c/fab483438342984f2a315fe13c882a80f0f7e545","https://git.kernel.org/stable/c/7bb1a2822aa2c2de4e09bf7c56dd93bd532f1fa7","https://git.kernel.org/stable/c/870565f063a58576e8a4529f122cac4325c6b395","https://git.kernel.org/stable/c/bf808f58681cab64c81cd814551814fd34e540fe","https://git.kernel.org/stable/c/fab483438342984f2a315fe13c882a80f0f7e545"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52639
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: vsie: fix race during shadow creation
Right now it is possible to see gmap->private being zero in
kvm_s390_vsie_gmap_notifier resulting in a crash. This is due to the
fact that we add gmap->private == kvm after creation:
static int acquire_gmap_shadow(struct kvm_vcpu *vcpu,
struct vsie_page *vsie_page)
{
[...]
gmap = gmap_shadow(vcpu->arch.gmap, asce, edat);
if (IS_ERR(gmap))
return PTR_ERR(gmap);
gmap->private = vcpu->kvm;
Let children inherit the private field of the parent. |
["https://git.kernel.org/stable/c/28bb27824f25f36e5f80229a358d66ee09244082","https://git.kernel.org/stable/c/5df3b81a567eb565029563f26f374ae3803a1dfc","https://git.kernel.org/stable/c/f5572c0323cf8b4f1f0618178648a25b8fb8a380","https://git.kernel.org/stable/c/fe752331d4b361d43cfd0b89534b4b2176057c32","https://git.kernel.org/stable/c/28bb27824f25f36e5f80229a358d66ee09244082","https://git.kernel.org/stable/c/5df3b81a567eb565029563f26f374ae3803a1dfc","https://git.kernel.org/stable/c/f5572c0323cf8b4f1f0618178648a25b8fb8a380","https://git.kernel.org/stable/c/fe752331d4b361d43cfd0b89534b4b2176057c32"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-0590
|
Medium |
fixed |
|
A use-after-free flaw was found in qdisc_graft in net/sched/sch_api.c in the Linux Kernel due to a race problem. This flaw leads to a denial of service issue. If patch ebda44da44f6 ("net: sched: fix race condition in qdisc_graft()") not applied yet, then kernel could be affected. |
["https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lore.kernel.org/all/20221018203258.2793282-1-edumazet%40google.com/","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lore.kernel.org/all/20221018203258.2793282-1-edumazet%40google.com/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52443
|
Medium |
fixed |
- 4.19.306
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
apparmor: avoid crash when parsed profile name is empty
When processing a packed profile in unpack_profile() described like
"profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}"
a string ":samba-dcerpcd" is unpacked as a fully-qualified name and then
passed to aa_splitn_fqname().
aa_splitn_fqname() treats ":samba-dcerpcd" as only containing a namespace.
Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later
aa_alloc_profile() crashes as the new profile name is NULL now.
general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
RIP: 0010:strlen+0x1e/0xa0
Call Trace:
<TASK>
? strlen+0x1e/0xa0
aa_policy_init+0x1bb/0x230
aa_alloc_profile+0xb1/0x480
unpack_profile+0x3bc/0x4960
aa_unpack+0x309/0x15e0
aa_replace_profiles+0x213/0x33c0
policy_update+0x261/0x370
profile_replace+0x20e/0x2a0
vfs_write+0x2af/0xe00
ksys_write+0x126/0x250
do_syscall_64+0x46/0xf0
entry_SYSCALL_64_after_hwframe+0x6e/0x76
</TASK>
---[ end trace 0000000000000000 ]---
RIP: 0010:strlen+0x1e/0xa0
It seems such behaviour of aa_splitn_fqname() is expected and checked in
other places where it is called (e.g. aa_remove_profiles). Well, there
is an explicit comment "a ns name without a following profile is allowed"
inside.
AFAICS, nothing can prevent unpacked "name" to be in form like
":samba-dcerpcd" - it is passed from userspace.
Deny the whole profile set replacement in such case and inform user with
EPROTO and an explaining message.
Found by Linux Verification Center (linuxtesting.org). |
["https://git.kernel.org/stable/c/0a12db736edbb4933e4274932aeea594b5876fa4","https://git.kernel.org/stable/c/1d8e62b5569cc1466ceb8a7e4872cf10160a9dcf","https://git.kernel.org/stable/c/55a8210c9e7d21ff2644809699765796d4bfb200","https://git.kernel.org/stable/c/5c0392fdafb0a2321311900be83ffa572bef8203","https://git.kernel.org/stable/c/5ff00408e5029d3550ee77f62dc15f1e15c47f87","https://git.kernel.org/stable/c/77ab09b92f16c8439a948d1af489196953dc4a0e","https://git.kernel.org/stable/c/9286ee97aa4803d99185768735011d0d65827c9e","https://git.kernel.org/stable/c/9d4fa5fe2b1d56662afd14915a73b4d0783ffa45","https://git.kernel.org/stable/c/0a12db736edbb4933e4274932aeea594b5876fa4","https://git.kernel.org/stable/c/1d8e62b5569cc1466ceb8a7e4872cf10160a9dcf","https://git.kernel.org/stable/c/55a8210c9e7d21ff2644809699765796d4bfb200","https://git.kernel.org/stable/c/5c0392fdafb0a2321311900be83ffa572bef8203","https://git.kernel.org/stable/c/5ff00408e5029d3550ee77f62dc15f1e15c47f87","https://git.kernel.org/stable/c/77ab09b92f16c8439a948d1af489196953dc4a0e","https://git.kernel.org/stable/c/9286ee97aa4803d99185768735011d0d65827c9e","https://git.kernel.org/stable/c/9d4fa5fe2b1d56662afd14915a73b4d0783ffa45","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-46805
|
Medium |
fixed |
- 5.15.167
- 6.1.109
- 6.6.50
- 6.10.9
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix the waring dereferencing hive
Check the amdgpu_hive_info *hive that maybe is NULL. |
["https://git.kernel.org/stable/c/01cd55b971131b07b7ff8d622fa93bb4f8be07df","https://git.kernel.org/stable/c/1940708ccf5aff76de4e0b399f99267c93a89193","https://git.kernel.org/stable/c/4ab720b6aa1ef5e71db1e534b5b45c80ac4ec58a","https://git.kernel.org/stable/c/d3f927ef0607b3c8c3f79ab6d9a4ebead3e35f4c","https://git.kernel.org/stable/c/f20d1d5cbb39802f68be24458861094f3e66f356"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-2430
|
Medium |
fixed |
|
A vulnerability was found due to missing lock for IOPOLL flaw in io_cqring_event_overflow() in io_uring.c in Linux Kernel. This flaw allows a local attacker with user privilege to trigger a Denial of Service threat. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e12d7a46f65ae4b7d58a5e0c1cbfa825cf8","https://www.debian.org/security/2023/dsa-5492","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e12d7a46f65ae4b7d58a5e0c1cbfa825cf8","https://www.debian.org/security/2023/dsa-5492"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-28328
|
Medium |
fixed |
|
A NULL pointer dereference flaw was found in the az6027 driver in drivers/media/usb/dev-usb/az6027.c in the Linux Kernel. The message from user space is not checked properly before transferring into the device. This flaw allows a local user to crash the system or potentially cause a denial of service. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2177389","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://bugzilla.redhat.com/show_bug.cgi?id=2177389","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26643
|
Medium |
fixed |
- 5.4.274
- 5.10.215
- 5.15.154
- 6.1.84
- 6.6.24
- 6.7.12
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout
While the rhashtable set gc runs asynchronously, a race allows it to
collect elements from anonymous sets with timeouts while it is being
released from the commit path.
Mingi Cho originally reported this issue in a different path in 6.1.x
with a pipapo set with low timeouts which is not possible upstream since
7395dfacfff6 ("netfilter: nf_tables: use timestamp to check for set
element timeout").
Fix this by setting on the dead flag for anonymous sets to skip async gc
in this case.
According to 08e4c8c5919f ("netfilter: nf_tables: mark newset as dead on
transaction abort"), Florian plans to accelerate abort path by releasing
objects via workqueue, therefore, this sets on the dead flag for abort
path too. |
["https://git.kernel.org/stable/c/291cca35818bd52a407bc37ab45a15816039e363","https://git.kernel.org/stable/c/406b0241d0eb598a0b330ab20ae325537d8d8163","https://git.kernel.org/stable/c/5224afbc30c3ca9ba23e752f0f138729b2c48dd8","https://git.kernel.org/stable/c/552705a3650bbf46a22b1adedc1b04181490fc36","https://git.kernel.org/stable/c/b2d6f9a5b1cf968f1eaa71085ceeb09c2cb276b1","https://git.kernel.org/stable/c/d75a589bb92af1abf3b779cfcd1977ca11b27033","https://git.kernel.org/stable/c/e2d45f467096e931044f0ab7634499879d851a5c","https://git.kernel.org/stable/c/edcf1a3f182ecf8b6b805f0ce90570ea98c5f6bf","https://git.kernel.org/stable/c/291cca35818bd52a407bc37ab45a15816039e363","https://git.kernel.org/stable/c/406b0241d0eb598a0b330ab20ae325537d8d8163","https://git.kernel.org/stable/c/5224afbc30c3ca9ba23e752f0f138729b2c48dd8","https://git.kernel.org/stable/c/552705a3650bbf46a22b1adedc1b04181490fc36","https://git.kernel.org/stable/c/b2d6f9a5b1cf968f1eaa71085ceeb09c2cb276b1","https://git.kernel.org/stable/c/d75a589bb92af1abf3b779cfcd1977ca11b27033","https://git.kernel.org/stable/c/e2d45f467096e931044f0ab7634499879d851a5c","https://git.kernel.org/stable/c/edcf1a3f182ecf8b6b805f0ce90570ea98c5f6bf","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4132
|
Medium |
|
N/A
|
A use-after-free vulnerability was found in the siano smsusb module in the Linux kernel. The bug occurs during device initialization when the siano device is plugged in. This flaw allows a local user to crash the system, causing a denial of service condition. |
["https://access.redhat.com/errata/RHSA-2023:6901","https://access.redhat.com/errata/RHSA-2023:7077","https://access.redhat.com/errata/RHSA-2024:0575","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/security/cve/CVE-2023-4132","https://bugzilla.redhat.com/show_bug.cgi?id=2221707","https://access.redhat.com/errata/RHSA-2023:6901","https://access.redhat.com/errata/RHSA-2023:7077","https://access.redhat.com/errata/RHSA-2024:0575","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/security/cve/CVE-2023-4132","https://bugzilla.redhat.com/show_bug.cgi?id=2221707","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20231020-0005/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26642
|
Medium |
fixed |
- 4.19.312
- 5.4.274
- 5.10.215
- 5.15.154
- 6.1.84
- 6.6.24
- 6.7.12
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: disallow anonymous set with timeout flag
Anonymous sets are never used with timeout from userspace, reject this.
Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work. |
["https://git.kernel.org/stable/c/16603605b667b70da974bea8216c93e7db043bf1","https://git.kernel.org/stable/c/72c1efe3f247a581667b7d368fff3bd9a03cd57a","https://git.kernel.org/stable/c/7cdc1be24cc1bcd56a3e89ac4aef20e31ad09199","https://git.kernel.org/stable/c/8e07c16695583a66e81f67ce4c46e94dece47ba7","https://git.kernel.org/stable/c/c0c2176d1814b92ea4c8e7eb7c9cd94cd99c1b12","https://git.kernel.org/stable/c/e4988d8415bd0294d6f9f4a1e7095f8b50a97ca9","https://git.kernel.org/stable/c/e9a0d3f376eb356d54ffce36e7cc37514cbfbd6f","https://git.kernel.org/stable/c/fe40ffbca19dc70d7c6b1e3c77b9ccb404c57351","https://git.kernel.org/stable/c/16603605b667b70da974bea8216c93e7db043bf1","https://git.kernel.org/stable/c/72c1efe3f247a581667b7d368fff3bd9a03cd57a","https://git.kernel.org/stable/c/7cdc1be24cc1bcd56a3e89ac4aef20e31ad09199","https://git.kernel.org/stable/c/8e07c16695583a66e81f67ce4c46e94dece47ba7","https://git.kernel.org/stable/c/c0c2176d1814b92ea4c8e7eb7c9cd94cd99c1b12","https://git.kernel.org/stable/c/e4988d8415bd0294d6f9f4a1e7095f8b50a97ca9","https://git.kernel.org/stable/c/e9a0d3f376eb356d54ffce36e7cc37514cbfbd6f","https://git.kernel.org/stable/c/fe40ffbca19dc70d7c6b1e3c77b9ccb404c57351","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26853
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
igc: avoid returning frame twice in XDP_REDIRECT
When a frame can not be transmitted in XDP_REDIRECT
(e.g. due to a full queue), it is necessary to free
it by calling xdp_return_frame_rx_napi.
However, this is the responsibility of the caller of
the ndo_xdp_xmit (see for example bq_xmit_all in
kernel/bpf/devmap.c) and thus calling it inside
igc_xdp_xmit (which is the ndo_xdp_xmit of the igc
driver) as well will lead to memory corruption.
In fact, bq_xmit_all expects that it can return all
frames after the last successfully transmitted one.
Therefore, break for the first not transmitted frame,
but do not call xdp_return_frame_rx_napi in igc_xdp_xmit.
This is equally implemented in other Intel drivers
such as the igb.
There are two alternatives to this that were rejected:
1. Return num_frames as all the frames would have been
transmitted and release them inside igc_xdp_xmit.
While it might work technically, it is not what
the return value is meant to represent (i.e. the
number of SUCCESSFULLY transmitted packets).
2. Rework kernel/bpf/devmap.c and all drivers to
support non-consecutively dropped packets.
Besides being complex, it likely has a negative
performance impact without a significant gain
since it is anyway unlikely that the next frame
can be transmitted if the previous one was dropped.
The memory corruption can be reproduced with
the following script which leads to a kernel panic
after a few seconds. It basically generates more
traffic than a i225 NIC can transmit and pushes it
via XDP_REDIRECT from a virtual interface to the
physical interface where frames get dropped.
#!/bin/bash
INTERFACE=enp4s0
INTERFACE_IDX=`cat /sys/class/net/$INTERFACE/ifindex`
sudo ip link add dev veth1 type veth peer name veth2
sudo ip link set up $INTERFACE
sudo ip link set up veth1
sudo ip link set up veth2
cat << EOF > redirect.bpf.c
SEC("prog")
int redirect(struct xdp_md *ctx)
{
return bpf_redirect($INTERFACE_IDX, 0);
}
char _license[] SEC("license") = "GPL";
EOF
clang -O2 -g -Wall -target bpf -c redirect.bpf.c -o redirect.bpf.o
sudo ip link set veth2 xdp obj redirect.bpf.o
cat << EOF > pass.bpf.c
SEC("prog")
int pass(struct xdp_md *ctx)
{
return XDP_PASS;
}
char _license[] SEC("license") = "GPL";
EOF
clang -O2 -g -Wall -target bpf -c pass.bpf.c -o pass.bpf.o
sudo ip link set $INTERFACE xdp obj pass.bpf.o
cat << EOF > trafgen.cfg
{
/* Ethernet Header */
0xe8, 0x6a, 0x64, 0x41, 0xbf, 0x46,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
const16(ETH_P_IP),
/* IPv4 Header */
0b01000101, 0, # IPv4 version, IHL, TOS
const16(1028), # IPv4 total length (UDP length + 20 bytes (IP header))
const16(2), # IPv4 ident
0b01000000, 0, # IPv4 flags, fragmentation off
64, # IPv4 TTL
17, # Protocol UDP
csumip(14, 33), # IPv4 checksum
/* UDP Header */
10, 0, 1, 1, # IP Src - adapt as needed
10, 0, 1, 2, # IP Dest - adapt as needed
const16(6666), # UDP Src Port
const16(6666), # UDP Dest Port
const16(1008), # UDP length (UDP header 8 bytes + payload length)
csumudp(14, 34), # UDP checksum
/* Payload */
fill('W', 1000),
}
EOF
sudo trafgen -i trafgen.cfg -b3000MB -o veth1 --cpp |
["https://git.kernel.org/stable/c/1b3b8231386a572bac8cd5b6fd7e944b84f9bb1f","https://git.kernel.org/stable/c/63a3c1f3c9ecc654d851e7906d05334cd0c236e2","https://git.kernel.org/stable/c/8df393af9e7e8dfd62e9c41dbaa4d2ff53bf794a","https://git.kernel.org/stable/c/ef27f655b438bed4c83680e4f01e1cde2739854b","https://git.kernel.org/stable/c/1b3b8231386a572bac8cd5b6fd7e944b84f9bb1f","https://git.kernel.org/stable/c/63a3c1f3c9ecc654d851e7906d05334cd0c236e2","https://git.kernel.org/stable/c/8df393af9e7e8dfd62e9c41dbaa4d2ff53bf794a","https://git.kernel.org/stable/c/ef27f655b438bed4c83680e4f01e1cde2739854b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1074
|
Medium |
|
N/A
|
A memory leak flaw was found in the Linux kernel's Stream Control Transmission Protocol. This issue may occur when a user starts a malicious networking service and someone connects to this service. This could allow a local user to starve resources, causing a denial of service. |
["http://www.openwall.com/lists/oss-security/2023/11/05/4","https://bugzilla.redhat.com/show_bug.cgi?id=2173430","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=458e279f861d3f61796894cd158b780765a1569f","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://www.openwall.com/lists/oss-security/2023/01/23/1","http://www.openwall.com/lists/oss-security/2023/11/05/4","https://bugzilla.redhat.com/show_bug.cgi?id=2173430","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=458e279f861d3f61796894cd158b780765a1569f","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://www.openwall.com/lists/oss-security/2023/01/23/1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26680
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: atlantic: Fix DMA mapping for PTP hwts ring
Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes
for PTP HWTS ring but then generic aq_ring_free() does not take this
into account.
Create and use a specific function to free HWTS ring to fix this
issue.
Trace:
[ 215.351607] ------------[ cut here ]------------
[ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes]
[ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360
...
[ 215.581176] Call Trace:
[ 215.583632] <TASK>
[ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df
[ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df
[ 215.594497] ? debug_dma_free_coherent+0x196/0x210
[ 215.599305] ? check_unmap+0xa6f/0x2360
[ 215.603147] ? __warn+0xca/0x1d0
[ 215.606391] ? check_unmap+0xa6f/0x2360
[ 215.610237] ? report_bug+0x1ef/0x370
[ 215.613921] ? handle_bug+0x3c/0x70
[ 215.617423] ? exc_invalid_op+0x14/0x50
[ 215.621269] ? asm_exc_invalid_op+0x16/0x20
[ 215.625480] ? check_unmap+0xa6f/0x2360
[ 215.629331] ? mark_lock.part.0+0xca/0xa40
[ 215.633445] debug_dma_free_coherent+0x196/0x210
[ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10
[ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0
[ 215.648060] dma_free_attrs+0x6d/0x130
[ 215.651834] aq_ring_free+0x193/0x290 [atlantic]
[ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic]
...
[ 216.127540] ---[ end trace 6467e5964dd2640b ]---
[ 216.132160] DMA-API: Mapped at:
[ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0
[ 216.132165] dma_alloc_attrs+0xf5/0x1b0
[ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic]
[ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic]
[ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic] |
["https://git.kernel.org/stable/c/004fe5b7f59286a926a45e0cafc7870e9cdddd56","https://git.kernel.org/stable/c/2e7d3b67630dfd8f178c41fa2217aa00e79a5887","https://git.kernel.org/stable/c/466ceebe48cbba3f4506f165fca7111f9eb8bb12","https://git.kernel.org/stable/c/e42e334c645575be5432adee224975d4f536fdb1","https://git.kernel.org/stable/c/004fe5b7f59286a926a45e0cafc7870e9cdddd56","https://git.kernel.org/stable/c/2e7d3b67630dfd8f178c41fa2217aa00e79a5887","https://git.kernel.org/stable/c/466ceebe48cbba3f4506f165fca7111f9eb8bb12","https://git.kernel.org/stable/c/e42e334c645575be5432adee224975d4f536fdb1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26893
|
Medium |
fixed |
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Fix double free in SMC transport cleanup path
When the generic SCMI code tears down a channel, it calls the chan_free
callback function, defined by each transport. Since multiple protocols
might share the same transport_info member, chan_free() might want to
clean up the same member multiple times within the given SCMI transport
implementation. In this case, it is SMC transport. This will lead to a NULL
pointer dereference at the second time:
| scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16
| arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.
| arm-scmi firmware:scmi: unable to communicate with SCMI
| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
| Mem abort info:
| ESR = 0x0000000096000004
| EC = 0x25: DABT (current EL), IL = 32 bits
| SET = 0, FnV = 0
| EA = 0, S1PTW = 0
| FSC = 0x04: level 0 translation fault
| Data abort info:
| ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
| CM = 0, WnR = 0, TnD = 0, TagAccess = 0
| GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000
| [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
| Modules linked in:
| CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793
| Hardware name: FVP Base RevC (DT)
| pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
| pc : smc_chan_free+0x3c/0x6c
| lr : smc_chan_free+0x3c/0x6c
| Call trace:
| smc_chan_free+0x3c/0x6c
| idr_for_each+0x68/0xf8
| scmi_cleanup_channels.isra.0+0x2c/0x58
| scmi_probe+0x434/0x734
| platform_probe+0x68/0xd8
| really_probe+0x110/0x27c
| __driver_probe_device+0x78/0x12c
| driver_probe_device+0x3c/0x118
| __driver_attach+0x74/0x128
| bus_for_each_dev+0x78/0xe0
| driver_attach+0x24/0x30
| bus_add_driver+0xe4/0x1e8
| driver_register+0x60/0x128
| __platform_driver_register+0x28/0x34
| scmi_driver_init+0x84/0xc0
| do_one_initcall+0x78/0x33c
| kernel_init_freeable+0x2b8/0x51c
| kernel_init+0x24/0x130
| ret_from_fork+0x10/0x20
| Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280)
| ---[ end trace 0000000000000000 ]---
Simply check for the struct pointer being NULL before trying to access
its members, to avoid this situation.
This was found when a transport doesn't really work (for instance no SMC
service), the probe routines then tries to clean up, and triggers a crash. |
["https://git.kernel.org/stable/c/0d276d9f335f41d6524258d58c0c0241ef9a83a4","https://git.kernel.org/stable/c/857f56db8c3a71f9871922b6984ff74ad588cb2c","https://git.kernel.org/stable/c/8ffaa17ccb1eb1b65cf85db63225a3581c303773","https://git.kernel.org/stable/c/ead445dd3d681020af333649a27306160eee761d","https://git.kernel.org/stable/c/f1d71576d2c9ec8fdb822173fa7f3de79475e9bd","https://git.kernel.org/stable/c/0d276d9f335f41d6524258d58c0c0241ef9a83a4","https://git.kernel.org/stable/c/857f56db8c3a71f9871922b6984ff74ad588cb2c","https://git.kernel.org/stable/c/8ffaa17ccb1eb1b65cf85db63225a3581c303773","https://git.kernel.org/stable/c/ead445dd3d681020af333649a27306160eee761d","https://git.kernel.org/stable/c/f1d71576d2c9ec8fdb822173fa7f3de79475e9bd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26696
|
Medium |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix hang in nilfs_lookup_dirty_data_buffers()
Syzbot reported a hang issue in migrate_pages_batch() called by mbind()
and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.
While migrate_pages_batch() locks a folio and waits for the writeback to
complete, the log writer thread that should bring the writeback to
completion picks up the folio being written back in
nilfs_lookup_dirty_data_buffers() that it calls for subsequent log
creation and was trying to lock the folio. Thus causing a deadlock.
In the first place, it is unexpected that folios/pages in the middle of
writeback will be updated and become dirty. Nilfs2 adds a checksum to
verify the validity of the log being written and uses it for recovery at
mount, so data changes during writeback are suppressed. Since this is
broken, an unclean shutdown could potentially cause recovery to fail.
Investigation revealed that the root cause is that the wait for writeback
completion in nilfs_page_mkwrite() is conditional, and if the backing
device does not require stable writes, data may be modified without
waiting.
Fix these issues by making nilfs_page_mkwrite() wait for writeback to
finish regardless of the stable write requirement of the backing device. |
["https://git.kernel.org/stable/c/228742b2ddfb99dfd71e5a307e6088ab6836272e","https://git.kernel.org/stable/c/38296afe3c6ee07319e01bb249aa4bb47c07b534","https://git.kernel.org/stable/c/7e9b622bd0748cc104d66535b76d9b3535f9dc0f","https://git.kernel.org/stable/c/8494ba2c9ea00a54d5b50e69b22c55a8958bce32","https://git.kernel.org/stable/c/862ee4422c38be5c249844a684b00d0dbe9d1e46","https://git.kernel.org/stable/c/98a4026b22ff440c7f47056481bcbbe442f607d6","https://git.kernel.org/stable/c/e38585401d464578d30f5868ff4ca54475c34f7d","https://git.kernel.org/stable/c/ea5ddbc11613b55e5128c85f57b08f907abd9b28","https://git.kernel.org/stable/c/228742b2ddfb99dfd71e5a307e6088ab6836272e","https://git.kernel.org/stable/c/38296afe3c6ee07319e01bb249aa4bb47c07b534","https://git.kernel.org/stable/c/7e9b622bd0748cc104d66535b76d9b3535f9dc0f","https://git.kernel.org/stable/c/8494ba2c9ea00a54d5b50e69b22c55a8958bce32","https://git.kernel.org/stable/c/862ee4422c38be5c249844a684b00d0dbe9d1e46","https://git.kernel.org/stable/c/98a4026b22ff440c7f47056481bcbbe442f607d6","https://git.kernel.org/stable/c/e38585401d464578d30f5868ff4ca54475c34f7d","https://git.kernel.org/stable/c/ea5ddbc11613b55e5128c85f57b08f907abd9b28","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26737
|
Medium |
fixed |
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix racing between bpf_timer_cancel_and_free and bpf_timer_cancel
The following race is possible between bpf_timer_cancel_and_free
and bpf_timer_cancel. It will lead a UAF on the timer->timer.
bpf_timer_cancel();
spin_lock();
t = timer->time;
spin_unlock();
bpf_timer_cancel_and_free();
spin_lock();
t = timer->timer;
timer->timer = NULL;
spin_unlock();
hrtimer_cancel(&t->timer);
kfree(t);
/* UAF on t */
hrtimer_cancel(&t->timer);
In bpf_timer_cancel_and_free, this patch frees the timer->timer
after a rcu grace period. This requires a rcu_head addition
to the "struct bpf_hrtimer". Another kfree(t) happens in bpf_timer_init,
this does not need a kfree_rcu because it is still under the
spin_lock and timer->timer has not been visible by others yet.
In bpf_timer_cancel, rcu_read_lock() is added because this helper
can be used in a non rcu critical section context (e.g. from
a sleepable bpf prog). Other timer->timer usages in helpers.c
have been audited, bpf_timer_cancel() is the only place where
timer->timer is used outside of the spin_lock.
Another solution considered is to mark a t->flag in bpf_timer_cancel
and clear it after hrtimer_cancel() is done. In bpf_timer_cancel_and_free,
it busy waits for the flag to be cleared before kfree(t). This patch
goes with a straight forward solution and frees timer->timer after
a rcu grace period. |
["https://git.kernel.org/stable/c/0281b919e175bb9c3128bd3872ac2903e9436e3f","https://git.kernel.org/stable/c/5268bb02107b9eedfdcd51db75b407d10043368c","https://git.kernel.org/stable/c/7d80a9e745fa5b47da3bca001f186c02485c7c33","https://git.kernel.org/stable/c/8327ed12e8ebc5436bfaa1786c49988894f9c8a6","https://git.kernel.org/stable/c/addf5e297e6cbf5341f9c07720693ca9ba0057b5","https://git.kernel.org/stable/c/0281b919e175bb9c3128bd3872ac2903e9436e3f","https://git.kernel.org/stable/c/5268bb02107b9eedfdcd51db75b407d10043368c","https://git.kernel.org/stable/c/7d80a9e745fa5b47da3bca001f186c02485c7c33","https://git.kernel.org/stable/c/8327ed12e8ebc5436bfaa1786c49988894f9c8a6","https://git.kernel.org/stable/c/addf5e297e6cbf5341f9c07720693ca9ba0057b5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-6039
|
Medium |
fixed |
|
A use-after-free flaw was found in lan78xx_disconnect in drivers/net/usb/lan78xx.c in the network sub-component, net/usb/lan78xx in the Linux Kernel. This flaw allows a local attacker to crash the system when the LAN78XX USB device detaches. |
["https://access.redhat.com/security/cve/CVE-2023-6039","https://bugzilla.redhat.com/show_bug.cgi?id=2248755","https://github.com/torvalds/linux/commit/1e7417c188d0a83fb385ba2dbe35fd2563f2b6f3","https://access.redhat.com/security/cve/CVE-2023-6039","https://bugzilla.redhat.com/show_bug.cgi?id=2248755","https://github.com/torvalds/linux/commit/1e7417c188d0a83fb385ba2dbe35fd2563f2b6f3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26866
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
spi: lpspi: Avoid potential use-after-free in probe()
fsl_lpspi_probe() is allocating/disposing memory manually with
spi_alloc_host()/spi_alloc_target(), but uses
devm_spi_register_controller(). In case of error after the latter call the
memory will be explicitly freed in the probe function by
spi_controller_put() call, but used afterwards by "devm" management outside
probe() (spi_unregister_controller() <- devm_spi_unregister() below).
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070
...
Call trace:
kernfs_find_ns
kernfs_find_and_get_ns
sysfs_remove_group
sysfs_remove_groups
device_remove_attrs
device_del
spi_unregister_controller
devm_spi_unregister
release_nodes
devres_release_all
really_probe
driver_probe_device
__device_attach_driver
bus_for_each_drv
__device_attach
device_initial_probe
bus_probe_device
deferred_probe_work_func
process_one_work
worker_thread
kthread
ret_from_fork |
["https://git.kernel.org/stable/c/1543418e82789cc383cd36d41469983c64e3fc7f","https://git.kernel.org/stable/c/2ae0ab0143fcc06190713ed81a6486ed0ad3c861","https://git.kernel.org/stable/c/996ce839606afd0fef91355627868022aa73eb68","https://git.kernel.org/stable/c/da83ed350e4604b976e94239b08d8e2e7eaee7ea","https://git.kernel.org/stable/c/1543418e82789cc383cd36d41469983c64e3fc7f","https://git.kernel.org/stable/c/2ae0ab0143fcc06190713ed81a6486ed0ad3c861","https://git.kernel.org/stable/c/996ce839606afd0fef91355627868022aa73eb68","https://git.kernel.org/stable/c/da83ed350e4604b976e94239b08d8e2e7eaee7ea"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26686
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
fs/proc: do_task_stat: use sig->stats_lock to gather the threads/children stats
lock_task_sighand() can trigger a hard lockup. If NR_CPUS threads call
do_task_stat() at the same time and the process has NR_THREADS, it will
spin with irqs disabled O(NR_CPUS * NR_THREADS) time.
Change do_task_stat() to use sig->stats_lock to gather the statistics
outside of ->siglock protected section, in the likely case this code will
run lockless. |
["https://git.kernel.org/stable/c/0c35d1914353799c54fa1843fe7dea6fcbcdbac5","https://git.kernel.org/stable/c/27978243f165b44e342f28f449b91327944ea071","https://git.kernel.org/stable/c/3820b0fac7732a653bcc6f6ac20c1d72e697f8f6","https://git.kernel.org/stable/c/4fe85bdaabd63f8f8579b24a10ed597c9c482164","https://git.kernel.org/stable/c/7601df8031fd67310af891897ef6cc0df4209305","https://git.kernel.org/stable/c/cf4b8c39b9a0bd81c47afc7ef62914a62dd5ec4d","https://git.kernel.org/stable/c/27978243f165b44e342f28f449b91327944ea071","https://git.kernel.org/stable/c/7601df8031fd67310af891897ef6cc0df4209305","https://git.kernel.org/stable/c/cf4b8c39b9a0bd81c47afc7ef62914a62dd5ec4d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26835
|
Medium |
fixed |
- 5.4.270
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: set dormant flag on hook register failure
We need to set the dormant flag again if we fail to register
the hooks.
During memory pressure hook registration can fail and we end up
with a table marked as active but no registered hooks.
On table/base chain deletion, nf_tables will attempt to unregister
the hook again which yields a warn splat from the nftables core. |
["https://git.kernel.org/stable/c/0c9302a6da262e6ab6a6c1d30f04a6130ed97376","https://git.kernel.org/stable/c/31ea574aeca1aa488e18716459bde057217637af","https://git.kernel.org/stable/c/664264a5c55bf97a9c571c557d477b75416199be","https://git.kernel.org/stable/c/6f2496366426cec18ba53f1c7f6c3ac307ca6a95","https://git.kernel.org/stable/c/a6411f3c48f991c19aaf9a24fce36865fbba28d7","https://git.kernel.org/stable/c/ae4360cbd385f0d7a8a86d5723e50448cc6318f3","https://git.kernel.org/stable/c/bccebf64701735533c8db37773eeacc6566cc8ec","https://git.kernel.org/stable/c/f2135bbf14949687e96cabb13d8a91ae3deb9069","https://git.kernel.org/stable/c/0c9302a6da262e6ab6a6c1d30f04a6130ed97376","https://git.kernel.org/stable/c/31ea574aeca1aa488e18716459bde057217637af","https://git.kernel.org/stable/c/664264a5c55bf97a9c571c557d477b75416199be","https://git.kernel.org/stable/c/6f2496366426cec18ba53f1c7f6c3ac307ca6a95","https://git.kernel.org/stable/c/a6411f3c48f991c19aaf9a24fce36865fbba28d7","https://git.kernel.org/stable/c/ae4360cbd385f0d7a8a86d5723e50448cc6318f3","https://git.kernel.org/stable/c/bccebf64701735533c8db37773eeacc6566cc8ec","https://git.kernel.org/stable/c/f2135bbf14949687e96cabb13d8a91ae3deb9069","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52456
|
Medium |
fixed |
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
serial: imx: fix tx statemachine deadlock
When using the serial port as RS485 port, the tx statemachine is used to
control the RTS pin to drive the RS485 transceiver TX_EN pin. When the
TTY port is closed in the middle of a transmission (for instance during
userland application crash), imx_uart_shutdown disables the interface
and disables the Transmission Complete interrupt. afer that,
imx_uart_stop_tx bails on an incomplete transmission, to be retriggered
by the TC interrupt. This interrupt is disabled and therefore the tx
statemachine never transitions out of SEND. The statemachine is in
deadlock now, and the TX_EN remains low, making the interface useless.
imx_uart_stop_tx now checks for incomplete transmission AND whether TC
interrupts are enabled before bailing to be retriggered. This makes sure
the state machine handling is reached, and is properly set to
WAIT_AFTER_SEND. |
["https://git.kernel.org/stable/c/63ee7be01a3f7d28b1ea8b8d7944f12bb7b0ed06","https://git.kernel.org/stable/c/6e04a9d30509fb53ba6df5d655ed61d607a7cfda","https://git.kernel.org/stable/c/763cd68746317b5d746dc2649a3295c1efb41181","https://git.kernel.org/stable/c/78d60dae9a0c9f09aa3d6477c94047df2fe6f7b0","https://git.kernel.org/stable/c/9a662d06c22ddfa371958c2071dc350436be802b","https://git.kernel.org/stable/c/ff168d4fdb0e1ba35fb413a749b3d6cce918ec19","https://git.kernel.org/stable/c/63ee7be01a3f7d28b1ea8b8d7944f12bb7b0ed06","https://git.kernel.org/stable/c/6e04a9d30509fb53ba6df5d655ed61d607a7cfda","https://git.kernel.org/stable/c/763cd68746317b5d746dc2649a3295c1efb41181","https://git.kernel.org/stable/c/78d60dae9a0c9f09aa3d6477c94047df2fe6f7b0","https://git.kernel.org/stable/c/9a662d06c22ddfa371958c2071dc350436be802b","https://git.kernel.org/stable/c/ff168d4fdb0e1ba35fb413a749b3d6cce918ec19","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52625
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Refactor DMCUB enter/exit idle interface
[Why]
We can hang in place trying to send commands when the DMCUB isn't
powered on.
[How]
We need to exit out of the idle state prior to sending a command,
but the process that performs the exit also invokes a command itself.
Fixing this issue involves the following:
1. Using a software state to track whether or not we need to start
the process to exit idle or notify idle.
It's possible for the hardware to have exited an idle state without
driver knowledge, but entering one is always restricted to a driver
allow - which makes the SW state vs HW state mismatch issue purely one
of optimization, which should seldomly be hit, if at all.
2. Refactor any instances of exit/notify idle to use a single wrapper
that maintains this SW state.
This works simialr to dc_allow_idle_optimizations, but works at the
DMCUB level and makes sure the state is marked prior to any notify/exit
idle so we don't enter an infinite loop.
3. Make sure we exit out of idle prior to sending any commands or
waiting for DMCUB idle.
This patch takes care of 1/2. A future patch will take care of wrapping
DMCUB command submission with calls to this new interface. |
["https://git.kernel.org/stable/c/820c3870c491946a78950cdf961bf40e28c1025f","https://git.kernel.org/stable/c/8e57c06bf4b0f51a4d6958e15e1a99c9520d00fa","https://git.kernel.org/stable/c/820c3870c491946a78950cdf961bf40e28c1025f","https://git.kernel.org/stable/c/8e57c06bf4b0f51a4d6958e15e1a99c9520d00fa"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-49875
|
Medium |
fixed |
- 5.10.227
- 5.15.168
- 6.1.113
- 6.6.55
- 6.10.14
- 6.11.3
|
In the Linux kernel, the following vulnerability has been resolved:
nfsd: map the EBADMSG to nfserr_io to avoid warning
Ext4 will throw -EBADMSG through ext4_readdir when a checksum error
occurs, resulting in the following WARNING.
Fix it by mapping EBADMSG to nfserr_io.
nfsd_buffered_readdir
iterate_dir // -EBADMSG -74
ext4_readdir // .iterate_shared
ext4_dx_readdir
ext4_htree_fill_tree
htree_dirblock_to_tree
ext4_read_dirblock
__ext4_read_dirblock
ext4_dirblock_csum_verify
warn_no_space_for_csum
__warn_no_space_for_csum
return ERR_PTR(-EFSBADCRC) // -EBADMSG -74
nfserrno // WARNING
[ 161.115610] ------------[ cut here ]------------
[ 161.116465] nfsd: non-standard errno: -74
[ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0
[ 161.118596] Modules linked in:
[ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138
[ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe
mu.org 04/01/2014
[ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0
[ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6
05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33
[ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286
[ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a
[ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827
[ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021
[ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8
[ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000
[ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0
[ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 161.141519] PKRU: 55555554
[ 161.142076] Call Trace:
[ 161.142575] ? __warn+0x9b/0x140
[ 161.143229] ? nfserrno+0x9d/0xd0
[ 161.143872] ? report_bug+0x125/0x150
[ 161.144595] ? handle_bug+0x41/0x90
[ 161.145284] ? exc_invalid_op+0x14/0x70
[ 161.146009] ? asm_exc_invalid_op+0x12/0x20
[ 161.146816] ? nfserrno+0x9d/0xd0
[ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0
[ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380
[ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0
[ 161.150093] ? wait_for_concurrent_writes+0x170/0x170
[ 161.151004] ? generic_file_llseek_size+0x48/0x160
[ 161.151895] nfsd_readdir+0x132/0x190
[ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380
[ 161.153516] ? nfsd_unlink+0x380/0x380
[ 161.154256] ? override_creds+0x45/0x60
[ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0
[ 161.155850] ? nfsd4_encode_readlink+0x210/0x210
[ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0
[ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0
[ 161.158494] ? lock_downgrade+0x90/0x90
[ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10
[ 161.160092] nfsd4_encode_operation+0x15a/0x440
[ 161.160959] nfsd4_proc_compound+0x718/0xe90
[ 161.161818] nfsd_dispatch+0x18e/0x2c0
[ 161.162586] svc_process_common+0x786/0xc50
[ 161.163403] ? nfsd_svc+0x380/0x380
[ 161.164137] ? svc_printk+0x160/0x160
[ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380
[ 161.165808] ? nfsd_svc+0x380/0x380
[ 161.166523] ? rcu_is_watching+0x23/0x40
[ 161.167309] svc_process+0x1a5/0x200
[ 161.168019] nfsd+0x1f5/0x380
[ 161.168663] ? nfsd_shutdown_threads+0x260/0x260
[ 161.169554] kthread+0x1c4/0x210
[ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80
[ 161.171246] ret_from_fork+0x1f/0x30 |
["https://git.kernel.org/stable/c/0ea4333c679f333e23956de743ad17387819d3f2","https://git.kernel.org/stable/c/340e61e44c1d2a15c42ec72ade9195ad525fd048","https://git.kernel.org/stable/c/6fe058502f8864649c3d614b06b2235223798f48","https://git.kernel.org/stable/c/825789ca94602543101045ad3aad19b2b60c6b2a","https://git.kernel.org/stable/c/c76005adfa93d1a027433331252422078750321f","https://git.kernel.org/stable/c/e9cfecca22a36b927a440abc6307efb9e138fed5","https://git.kernel.org/stable/c/f7d8ee9db94372b8235f5f22bb24381891594c42"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26759
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mm/swap: fix race when skipping swapcache
When skipping swapcache for SWP_SYNCHRONOUS_IO, if two or more threads
swapin the same entry at the same time, they get different pages (A, B).
Before one thread (T0) finishes the swapin and installs page (A) to the
PTE, another thread (T1) could finish swapin of page (B), swap_free the
entry, then swap out the possibly modified page reusing the same entry.
It breaks the pte_same check in (T0) because PTE value is unchanged,
causing ABA problem. Thread (T0) will install a stalled page (A) into the
PTE and cause data corruption.
One possible callstack is like this:
CPU0 CPU1
---- ----
do_swap_page() do_swap_page() with same entry
<direct swapin path> <direct swapin path>
<alloc page A> <alloc page B>
swap_read_folio() <- read to page A swap_read_folio() <- read to page B
<slow on later locks or interrupt> <finished swapin first>
... set_pte_at()
swap_free() <- entry is free
<write to page B, now page A stalled>
<swap out page B to same swap entry>
pte_same() <- Check pass, PTE seems
unchanged, but page A
is stalled!
swap_free() <- page B content lost!
set_pte_at() <- staled page A installed!
And besides, for ZRAM, swap_free() allows the swap device to discard the
entry content, so even if page (B) is not modified, if swap_read_folio()
on CPU0 happens later than swap_free() on CPU1, it may also cause data
loss.
To fix this, reuse swapcache_prepare which will pin the swap entry using
the cache flag, and allow only one thread to swap it in, also prevent any
parallel code from putting the entry in the cache. Release the pin after
PT unlocked.
Racers just loop and wait since it's a rare and very short event. A
schedule_timeout_uninterruptible(1) call is added to avoid repeated page
faults wasting too much CPU, causing livelock or adding too much noise to
perf statistics. A similar livelock issue was described in commit
029c4628b2eb ("mm: swap: get rid of livelock in swapin readahead")
Reproducer:
This race issue can be triggered easily using a well constructed
reproducer and patched brd (with a delay in read path) [1]:
With latest 6.8 mainline, race caused data loss can be observed easily:
$ gcc -g -lpthread test-thread-swap-race.c && ./a.out
Polulating 32MB of memory region...
Keep swapping out...
Starting round 0...
Spawning 65536 workers...
32746 workers spawned, wait for done...
Round 0: Error on 0x5aa00, expected 32746, got 32743, 3 data loss!
Round 0: Error on 0x395200, expected 32746, got 32743, 3 data loss!
Round 0: Error on 0x3fd000, expected 32746, got 32737, 9 data loss!
Round 0 Failed, 15 data loss!
This reproducer spawns multiple threads sharing the same memory region
using a small swap device. Every two threads updates mapped pages one by
one in opposite direction trying to create a race, with one dedicated
thread keep swapping out the data out using madvise.
The reproducer created a reproduce rate of about once every 5 minutes, so
the race should be totally possible in production.
After this patch, I ran the reproducer for over a few hundred rounds and
no data loss observed.
Performance overhead is minimal, microbenchmark swapin 10G from 32G
zram:
Before: 10934698 us
After: 11157121 us
Cached: 13155355 us (Dropping SWP_SYNCHRONOUS_IO flag)
[kasong@tencent.com: v4] |
["https://git.kernel.org/stable/c/13ddaf26be324a7f951891ecd9ccd04466d27458","https://git.kernel.org/stable/c/2dedda77d4493f3e92e414b272bfa60f1f51ed95","https://git.kernel.org/stable/c/305152314df82b22cf9b181f3dc5fc411002079a","https://git.kernel.org/stable/c/d183a4631acfc7af955c02a02e739cec15f5234d","https://git.kernel.org/stable/c/13ddaf26be324a7f951891ecd9ccd04466d27458","https://git.kernel.org/stable/c/2dedda77d4493f3e92e414b272bfa60f1f51ed95","https://git.kernel.org/stable/c/305152314df82b22cf9b181f3dc5fc411002079a","https://git.kernel.org/stable/c/d183a4631acfc7af955c02a02e739cec15f5234d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52516
|
Medium |
fixed |
- 5.10.198
- 5.15.134
- 6.1.56
- 6.5.6
|
In the Linux kernel, the following vulnerability has been resolved:
dma-debug: don't call __dma_entry_alloc_check_leak() under free_entries_lock
__dma_entry_alloc_check_leak() calls into printk -> serial console
output (qcom geni) and grabs port->lock under free_entries_lock
spin lock, which is a reverse locking dependency chain as qcom_geni
IRQ handler can call into dma-debug code and grab free_entries_lock
under port->lock.
Move __dma_entry_alloc_check_leak() call out of free_entries_lock
scope so that we don't acquire serial console's port->lock under it.
Trimmed-down lockdep splat:
The existing dependency chain (in reverse order) is:
-> #2 (free_entries_lock){-.-.}-{2:2}:
_raw_spin_lock_irqsave+0x60/0x80
dma_entry_alloc+0x38/0x110
debug_dma_map_page+0x60/0xf8
dma_map_page_attrs+0x1e0/0x230
dma_map_single_attrs.constprop.0+0x6c/0xc8
geni_se_rx_dma_prep+0x40/0xcc
qcom_geni_serial_isr+0x310/0x510
__handle_irq_event_percpu+0x110/0x244
handle_irq_event_percpu+0x20/0x54
handle_irq_event+0x50/0x88
handle_fasteoi_irq+0xa4/0xcc
handle_irq_desc+0x28/0x40
generic_handle_domain_irq+0x24/0x30
gic_handle_irq+0xc4/0x148
do_interrupt_handler+0xa4/0xb0
el1_interrupt+0x34/0x64
el1h_64_irq_handler+0x18/0x24
el1h_64_irq+0x64/0x68
arch_local_irq_enable+0x4/0x8
____do_softirq+0x18/0x24
...
-> #1 (&port_lock_key){-.-.}-{2:2}:
_raw_spin_lock_irqsave+0x60/0x80
qcom_geni_serial_console_write+0x184/0x1dc
console_flush_all+0x344/0x454
console_unlock+0x94/0xf0
vprintk_emit+0x238/0x24c
vprintk_default+0x3c/0x48
vprintk+0xb4/0xbc
_printk+0x68/0x90
register_console+0x230/0x38c
uart_add_one_port+0x338/0x494
qcom_geni_serial_probe+0x390/0x424
platform_probe+0x70/0xc0
really_probe+0x148/0x280
__driver_probe_device+0xfc/0x114
driver_probe_device+0x44/0x100
__device_attach_driver+0x64/0xdc
bus_for_each_drv+0xb0/0xd8
__device_attach+0xe4/0x140
device_initial_probe+0x1c/0x28
bus_probe_device+0x44/0xb0
device_add+0x538/0x668
of_device_add+0x44/0x50
of_platform_device_create_pdata+0x94/0xc8
of_platform_bus_create+0x270/0x304
of_platform_populate+0xac/0xc4
devm_of_platform_populate+0x60/0xac
geni_se_probe+0x154/0x160
platform_probe+0x70/0xc0
...
-> #0 (console_owner){-...}-{0:0}:
__lock_acquire+0xdf8/0x109c
lock_acquire+0x234/0x284
console_flush_all+0x330/0x454
console_unlock+0x94/0xf0
vprintk_emit+0x238/0x24c
vprintk_default+0x3c/0x48
vprintk+0xb4/0xbc
_printk+0x68/0x90
dma_entry_alloc+0xb4/0x110
debug_dma_map_sg+0xdc/0x2f8
__dma_map_sg_attrs+0xac/0xe4
dma_map_sgtable+0x30/0x4c
get_pages+0x1d4/0x1e4 [msm]
msm_gem_pin_pages_locked+0x38/0xac [msm]
msm_gem_pin_vma_locked+0x58/0x88 [msm]
msm_ioctl_gem_submit+0xde4/0x13ac [msm]
drm_ioctl_kernel+0xe0/0x15c
drm_ioctl+0x2e8/0x3f4
vfs_ioctl+0x30/0x50
...
Chain exists of:
console_owner --> &port_lock_key --> free_entries_lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(free_entries_lock);
lock(&port_lock_key);
lock(free_entries_lock);
lock(console_owner);
*** DEADLOCK ***
Call trace:
dump_backtrace+0xb4/0xf0
show_stack+0x20/0x30
dump_stack_lvl+0x60/0x84
dump_stack+0x18/0x24
print_circular_bug+0x1cc/0x234
check_noncircular+0x78/0xac
__lock_acquire+0xdf8/0x109c
lock_acquire+0x234/0x284
console_flush_all+0x330/0x454
consol
---truncated--- |
["https://git.kernel.org/stable/c/ac0d068099349cbca3d93f2e3b15bb329364b08c","https://git.kernel.org/stable/c/be8f49029eca3efbad0d74dbff3cb9129994ffab","https://git.kernel.org/stable/c/c79300599923daaa30f417c75555d5566b3d31ae","https://git.kernel.org/stable/c/fb5a4315591dae307a65fc246ca80b5159d296e1","https://git.kernel.org/stable/c/fe2b811a02c3244ebf6059039e4a9e715e26a9e3","https://git.kernel.org/stable/c/ac0d068099349cbca3d93f2e3b15bb329364b08c","https://git.kernel.org/stable/c/be8f49029eca3efbad0d74dbff3cb9129994ffab","https://git.kernel.org/stable/c/c79300599923daaa30f417c75555d5566b3d31ae","https://git.kernel.org/stable/c/fb5a4315591dae307a65fc246ca80b5159d296e1","https://git.kernel.org/stable/c/fe2b811a02c3244ebf6059039e4a9e715e26a9e3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-6622
|
Medium |
|
N/A
|
A null pointer dereference vulnerability was found in nft_dynset_init() in net/netfilter/nft_dynset.c in nf_tables in the Linux kernel. This issue may allow a local attacker with CAP_NET_ADMIN user privilege to trigger a denial of service. |
["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-6622","https://bugzilla.redhat.com/show_bug.cgi?id=2253632","https://github.com/torvalds/linux/commit/3701cd390fd731ee7ae8b8006246c8db82c72bea","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-6622","https://bugzilla.redhat.com/show_bug.cgi?id=2253632","https://github.com/torvalds/linux/commit/3701cd390fd731ee7ae8b8006246c8db82c72bea","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/AAOVK2F3ALGKYIQ5IOMAYEC2DGI7BWAW/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/G3AGDVE3KBLOOYBPISFDS74R4YAZEDAY/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26647
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix late derefrence 'dsc' check in 'link_set_dsc_pps_packet()'
In link_set_dsc_pps_packet(), 'struct display_stream_compressor *dsc'
was dereferenced in a DC_LOGGER_INIT(dsc->ctx->logger); before the 'dsc'
NULL pointer check.
Fixes the below:
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dpms.c:905 link_set_dsc_pps_packet() warn: variable dereferenced before check 'dsc' (see line 903) |
["https://git.kernel.org/stable/c/3bb9b1f958c3d986ed90a3ff009f1e77e9553207","https://git.kernel.org/stable/c/6aa5ede6665122f4c8abce3c6eba06b49e54d25c","https://git.kernel.org/stable/c/cf656fc7276e5b3709a81bc9d9639459be2b2647","https://git.kernel.org/stable/c/3bb9b1f958c3d986ed90a3ff009f1e77e9553207","https://git.kernel.org/stable/c/6aa5ede6665122f4c8abce3c6eba06b49e54d25c","https://git.kernel.org/stable/c/cf656fc7276e5b3709a81bc9d9639459be2b2647"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26714
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
interconnect: qcom: sc8180x: Mark CO0 BCM keepalive
The CO0 BCM needs to be up at all times, otherwise some hardware (like
the UFS controller) loses its connection to the rest of the SoC,
resulting in a hang of the platform, accompanied by a spectacular
logspam.
Mark it as keepalive to prevent such cases. |
["https://git.kernel.org/stable/c/6616d3c4f8284a7b3ef978c916566bd240cea1c7","https://git.kernel.org/stable/c/7a3a70dd08e4b7dffc2f86f2c68fc3812804b9d0","https://git.kernel.org/stable/c/85e985a4f46e462a37f1875cb74ed380e7c0c2e0","https://git.kernel.org/stable/c/d8e36ff40cf9dadb135f3a97341c02c9a7afcc43","https://git.kernel.org/stable/c/6616d3c4f8284a7b3ef978c916566bd240cea1c7","https://git.kernel.org/stable/c/7a3a70dd08e4b7dffc2f86f2c68fc3812804b9d0","https://git.kernel.org/stable/c/85e985a4f46e462a37f1875cb74ed380e7c0c2e0","https://git.kernel.org/stable/c/d8e36ff40cf9dadb135f3a97341c02c9a7afcc43"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49326
|
Medium |
fixed |
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
rtl818x: Prevent using not initialized queues
Using not existing queues can panic the kernel with rtl8180/rtl8185 cards.
Ignore the skb priority for those cards, they only have one tx queue. Pierre
Asselin (pa@panix.com) reported the kernel crash in the Gentoo forum:
https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html
He also confirmed that this patch fixes the issue. In summary this happened:
After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a
"divide error: 0000" when connecting to an AP. Control port tx now tries to
use IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in
2.10.
Since only the rtl8187se part of the driver supports QoS, the priority
of the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185
cards.
rtl8180 is then unconditionally reading out the priority and finally crashes on
drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this
patch:
idx = (ring->idx + skb_queue_len(&ring->queue)) % ring->entries
"ring->entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never got
initialized. |
["https://git.kernel.org/stable/c/6ad81ad0cf5744738ce94c8e64051ddd80a1734c","https://git.kernel.org/stable/c/746285cf81dc19502ab238249d75f5990bd2d231","https://git.kernel.org/stable/c/769ec2a824deae2f1268dfda14999a4d14d0d0c5","https://git.kernel.org/stable/c/98e55b0b876bde3353f4e074883d66ecb55c65a3","https://git.kernel.org/stable/c/9ad1981fc4de3afb7db3e8eb5a6a52d4c7d0d577","https://git.kernel.org/stable/c/9d5e96cc1f1720019ce27b127a31695148d38bb0","https://git.kernel.org/stable/c/b5dca2cd3f0239512da808598b4e70557eb4c2a1","https://git.kernel.org/stable/c/b8ce58ab80faaea015c206382041ff3bcf5495ff","https://git.kernel.org/stable/c/d7e30dfc166d33470bba31a42f9bbc346e5409d5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26685
|
Medium |
fixed |
- 3.3
- 3.5
- 3.11
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential bug in end_buffer_async_write
According to a syzbot report, end_buffer_async_write(), which handles the
completion of block device writes, may detect abnormal condition of the
buffer async_write flag and cause a BUG_ON failure when using nilfs2.
Nilfs2 itself does not use end_buffer_async_write(). But, the async_write
flag is now used as a marker by commit 7f42ec394156 ("nilfs2: fix issue
with race condition of competition between segments for dirty blocks") as
a means of resolving double list insertion of dirty blocks in
nilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the
resulting crash.
This modification is safe as long as it is used for file data and b-tree
node blocks where the page caches are independent. However, it was
irrelevant and redundant to also introduce async_write for segment summary
and super root blocks that share buffers with the backing device. This
led to the possibility that the BUG_ON check in end_buffer_async_write
would fail as described above, if independent writebacks of the backing
device occurred in parallel.
The use of async_write for segment summary buffers has already been
removed in a previous change.
Fix this issue by removing the manipulation of the async_write flag for
the remaining super root block buffer. |
["https://git.kernel.org/stable/c/2c3bdba00283a6c7a5b19481a59a730f46063803","https://git.kernel.org/stable/c/5bc09b397cbf1221f8a8aacb1152650c9195b02b","https://git.kernel.org/stable/c/626daab3811b772086aef1bf8eed3ffe6f523eff","https://git.kernel.org/stable/c/6589f0f72f8edd1fa11adce4eedbd3615f2e78ab","https://git.kernel.org/stable/c/8fa90634ec3e9cc50f42dd605eec60f2d146ced8","https://git.kernel.org/stable/c/c4a09fdac625e64abe478dcf88bfa20406616928","https://git.kernel.org/stable/c/d31c8721e816eff5ca6573cc487754f357c093cd","https://git.kernel.org/stable/c/f3e4963566f58726d3265a727116a42b591f6596","https://git.kernel.org/stable/c/2c3bdba00283a6c7a5b19481a59a730f46063803","https://git.kernel.org/stable/c/5bc09b397cbf1221f8a8aacb1152650c9195b02b","https://git.kernel.org/stable/c/626daab3811b772086aef1bf8eed3ffe6f523eff","https://git.kernel.org/stable/c/6589f0f72f8edd1fa11adce4eedbd3615f2e78ab","https://git.kernel.org/stable/c/8fa90634ec3e9cc50f42dd605eec60f2d146ced8","https://git.kernel.org/stable/c/c4a09fdac625e64abe478dcf88bfa20406616928","https://git.kernel.org/stable/c/d31c8721e816eff5ca6573cc487754f357c093cd","https://git.kernel.org/stable/c/f3e4963566f58726d3265a727116a42b591f6596","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26677
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix delayed ACKs to not set the reference serial number
Fix the construction of delayed ACKs to not set the reference serial number
as they can't be used as an RTT reference. |
["https://git.kernel.org/stable/c/200cb50b9e154434470c8969d32474d38475acc2","https://git.kernel.org/stable/c/63719f490e6a89896e9a463d2b45e8203eab23ae","https://git.kernel.org/stable/c/e7870cf13d20f56bfc19f9c3e89707c69cf104ef","https://git.kernel.org/stable/c/200cb50b9e154434470c8969d32474d38475acc2","https://git.kernel.org/stable/c/63719f490e6a89896e9a463d2b45e8203eab23ae","https://git.kernel.org/stable/c/e7870cf13d20f56bfc19f9c3e89707c69cf104ef"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26646
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
thermal: intel: hfi: Add syscore callbacks for system-wide PM
The kernel allocates a memory buffer and provides its location to the
hardware, which uses it to update the HFI table. This allocation occurs
during boot and remains constant throughout runtime.
When resuming from hibernation, the restore kernel allocates a second
memory buffer and reprograms the HFI hardware with the new location as
part of a normal boot. The location of the second memory buffer may
differ from the one allocated by the image kernel.
When the restore kernel transfers control to the image kernel, its HFI
buffer becomes invalid, potentially leading to memory corruption if the
hardware writes to it (the hardware continues to use the buffer from the
restore kernel).
It is also possible that the hardware "forgets" the address of the memory
buffer when resuming from "deep" suspend. Memory corruption may also occur
in such a scenario.
To prevent the described memory corruption, disable HFI when preparing to
suspend or hibernate. Enable it when resuming.
Add syscore callbacks to handle the package of the boot CPU (packages of
non-boot CPUs are handled via CPU offline). Syscore ops always run on the
boot CPU. Additionally, HFI only needs to be disabled during "deep" suspend
and hibernation. Syscore ops only run in these cases.
[ rjw: Comment adjustment, subject and changelog edits ] |
["https://git.kernel.org/stable/c/019ccc66d56a696a4dfee3bfa2f04d0a7c3d89ee","https://git.kernel.org/stable/c/28f010dc50df0f7987c04112114fcfa7e0803566","https://git.kernel.org/stable/c/97566d09fd02d2ab329774bb89a2cdf2267e86d9","https://git.kernel.org/stable/c/c9d6d63b6c03afaa6f185df249af693a7939577c","https://git.kernel.org/stable/c/019ccc66d56a696a4dfee3bfa2f04d0a7c3d89ee","https://git.kernel.org/stable/c/28f010dc50df0f7987c04112114fcfa7e0803566","https://git.kernel.org/stable/c/97566d09fd02d2ab329774bb89a2cdf2267e86d9","https://git.kernel.org/stable/c/c9d6d63b6c03afaa6f185df249af693a7939577c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52561
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
arm64: dts: qcom: sdm845-db845c: Mark cont splash memory region as reserved
Adding a reserved memory region for the framebuffer memory
(the splash memory region set up by the bootloader).
It fixes a kernel panic (arm-smmu: Unhandled context fault
at this particular memory region) reported on DB845c running
v5.10.y. |
["https://git.kernel.org/stable/c/110e70fccce4f22b53986ae797d665ffb1950aa6","https://git.kernel.org/stable/c/82dacd0ca0d9640723824026d6fdf773c02de1d2","https://git.kernel.org/stable/c/dc1ab6577475b0460ba4261cd9caec37bd62ca0b","https://git.kernel.org/stable/c/110e70fccce4f22b53986ae797d665ffb1950aa6","https://git.kernel.org/stable/c/82dacd0ca0d9640723824026d6fdf773c02de1d2","https://git.kernel.org/stable/c/dc1ab6577475b0460ba4261cd9caec37bd62ca0b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-37453
|
Medium |
|
N/A
|
An issue was discovered in the USB subsystem in the Linux kernel through 6.4.2. There is an out-of-bounds and crash in read_descriptors in drivers/usb/core/sysfs.c. |
["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1e4c574225cc5a0553115e5eb5787d1474db5b0f","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=85d07c55621676d47d873d2749b88f783cd4d5a1","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=de28e469da75359a2bb8cd8778b78aa64b1be1f4","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ff33299ec8bb80cdcc073ad9c506bd79bb2ed20b","https://lore.kernel.org/all/000000000000c0ffe505fe86c9ca%40google.com/T/","https://lore.kernel.org/all/000000000000e56434059580f86e%40google.com/T/","https://syzkaller.appspot.com/bug?extid=18996170f8096c6174d0","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1e4c574225cc5a0553115e5eb5787d1474db5b0f","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=85d07c55621676d47d873d2749b88f783cd4d5a1","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=de28e469da75359a2bb8cd8778b78aa64b1be1f4","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ff33299ec8bb80cdcc073ad9c506bd79bb2ed20b","https://lore.kernel.org/all/000000000000c0ffe505fe86c9ca%40google.com/T/","https://lore.kernel.org/all/000000000000e56434059580f86e%40google.com/T/","https://syzkaller.appspot.com/bug?extid=18996170f8096c6174d0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-45888
|
Medium |
|
N/A
|
An issue was discovered in the Linux kernel through 6.0.9. drivers/char/xillybus/xillyusb.c has a race condition and use-after-free during physical removal of a USB device. |
["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=282a4b71816b6076029017a7bab3a9dcee12a920","https://lore.kernel.org/all/20221022175404.GA375335%40ubuntu/","https://security.netapp.com/advisory/ntap-20230113-0006/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=282a4b71816b6076029017a7bab3a9dcee12a920","https://lore.kernel.org/all/20221022175404.GA375335%40ubuntu/","https://security.netapp.com/advisory/ntap-20230113-0006/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-26545
|
Medium |
fixed |
|
In the Linux kernel before 6.1.13, there is a double free in net/mpls/af_mpls.c upon an allocation failure (for registering the sysctl table under a new location) during the renaming of a device. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.13","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fda6c89fe3d9aca073495a664e1d5aea28cd4377","https://github.com/torvalds/linux/commit/fda6c89fe3d9aca073495a664e1d5aea28cd4377","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230316-0009/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.13","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fda6c89fe3d9aca073495a664e1d5aea28cd4377","https://github.com/torvalds/linux/commit/fda6c89fe3d9aca073495a664e1d5aea28cd4377","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230316-0009/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26671
|
Medium |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.77
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
blk-mq: fix IO hang from sbitmap wakeup race
In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered
with the following blk_mq_get_driver_tag() in case of getting driver
tag failure.
Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe
the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime
blk_mq_mark_tag_wait() can't get driver tag successfully.
This issue can be reproduced by running the following test in loop, and
fio hang can be observed in < 30min when running it on my test VM
in laptop.
modprobe -r scsi_debug
modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4
dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename`
fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \
--runtime=100 --numjobs=40 --time_based --name=test \
--ioengine=libaio
Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which
is just fine in case of running out of tag. |
["https://git.kernel.org/stable/c/1d9c777d3e70bdc57dddf7a14a80059d65919e56","https://git.kernel.org/stable/c/5266caaf5660529e3da53004b8b7174cab6374ed","https://git.kernel.org/stable/c/6d8b01624a2540336a32be91f25187a433af53a0","https://git.kernel.org/stable/c/7610ba1319253225a9ba8a9d28d472fc883b4e2f","https://git.kernel.org/stable/c/89e0e66682e1538aeeaa3109503473663cd24c8b","https://git.kernel.org/stable/c/9525b38180e2753f0daa1a522b7767a2aa969676","https://git.kernel.org/stable/c/ecd7744a1446eb02ccc63e493e2eb6ede4ef1e10","https://git.kernel.org/stable/c/f1bc0d8163f8ee84a8d5affdf624cfad657df1d2","https://git.kernel.org/stable/c/1d9c777d3e70bdc57dddf7a14a80059d65919e56","https://git.kernel.org/stable/c/5266caaf5660529e3da53004b8b7174cab6374ed","https://git.kernel.org/stable/c/6d8b01624a2540336a32be91f25187a433af53a0","https://git.kernel.org/stable/c/7610ba1319253225a9ba8a9d28d472fc883b4e2f","https://git.kernel.org/stable/c/89e0e66682e1538aeeaa3109503473663cd24c8b","https://git.kernel.org/stable/c/9525b38180e2753f0daa1a522b7767a2aa969676","https://git.kernel.org/stable/c/ecd7744a1446eb02ccc63e493e2eb6ede4ef1e10","https://git.kernel.org/stable/c/f1bc0d8163f8ee84a8d5affdf624cfad657df1d2","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52609
|
Medium |
fixed |
- 4.19.306
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
binder: fix race between mmput() and do_exit()
Task A calls binder_update_page_range() to allocate and insert pages on
a remote address space from Task B. For this, Task A pins the remote mm
via mmget_not_zero() first. This can race with Task B do_exit() and the
final mmput() refcount decrement will come from Task A.
Task A | Task B
------------------+------------------
mmget_not_zero() |
| do_exit()
| exit_mm()
| mmput()
mmput() |
exit_mmap() |
remove_vma() |
fput() |
In this case, the work of ____fput() from Task B is queued up in Task A
as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup
work gets executed. However, Task A instead sleep, waiting for a reply
from Task B that never comes (it's dead).
This means the binder_deferred_release() is blocked until an unrelated
binder event forces Task A to go back to userspace. All the associated
death notifications will also be delayed until then.
In order to fix this use mmput_async() that will schedule the work in
the corresponding mm->async_put_work WQ instead of Task A. |
["https://git.kernel.org/stable/c/252a2a5569eb9f8d16428872cc24dea1ac0bb097","https://git.kernel.org/stable/c/6696f76c32ff67fec26823fc2df46498e70d9bf3","https://git.kernel.org/stable/c/67f16bf2cc1698fd50e01ee8a2becc5a8e6d3a3e","https://git.kernel.org/stable/c/77d210e8db4d61d43b2d16df66b1ec46fad2ee01","https://git.kernel.org/stable/c/7e7a0d86542b0ea903006d3f42f33c4f7ead6918","https://git.kernel.org/stable/c/95b1d336b0642198b56836b89908d07b9a0c9608","https://git.kernel.org/stable/c/98fee5bee97ad47b527a997d5786410430d1f0e9","https://git.kernel.org/stable/c/9a9ab0d963621d9d12199df9817e66982582d5a5","https://git.kernel.org/stable/c/252a2a5569eb9f8d16428872cc24dea1ac0bb097","https://git.kernel.org/stable/c/6696f76c32ff67fec26823fc2df46498e70d9bf3","https://git.kernel.org/stable/c/67f16bf2cc1698fd50e01ee8a2becc5a8e6d3a3e","https://git.kernel.org/stable/c/77d210e8db4d61d43b2d16df66b1ec46fad2ee01","https://git.kernel.org/stable/c/7e7a0d86542b0ea903006d3f42f33c4f7ead6918","https://git.kernel.org/stable/c/95b1d336b0642198b56836b89908d07b9a0c9608","https://git.kernel.org/stable/c/98fee5bee97ad47b527a997d5786410430d1f0e9","https://git.kernel.org/stable/c/9a9ab0d963621d9d12199df9817e66982582d5a5","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1852
|
Medium |
fixed |
|
A NULL pointer dereference flaw was found in the Linux kernel’s KVM module, which can lead to a denial of service in the x86_emulate_insn in arch/x86/kvm/emulate.c. This flaw occurs while executing an illegal instruction in guest in the Intel CPU. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2089815","https://github.com/torvalds/linux/commit/fee060cd52d69c114b62d1a2948ea9648b5131f9","https://bugzilla.redhat.com/show_bug.cgi?id=2089815","https://github.com/torvalds/linux/commit/fee060cd52d69c114b62d1a2948ea9648b5131f9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1195
|
Medium |
fixed |
|
A use-after-free vulnerability was found in the Linux kernel in drivers/net/hamradio. This flaw allows a local attacker with a user privilege to cause a denial of service (DOS) when the mkiss or sixpack device is detached and reclaim resources early. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2056381","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0b9111922b1f399aba6ed1e1b8f2079c3da1aed8","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e0588c291d6ce225f2b891753ca41d45ba42469","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=81b1d548d00bcd028303c4f3150fa753b9b8aa71","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b2f37aead1b82a770c48b5d583f35ec22aabb61e","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173","https://bugzilla.redhat.com/show_bug.cgi?id=2056381","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0b9111922b1f399aba6ed1e1b8f2079c3da1aed8","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e0588c291d6ce225f2b891753ca41d45ba42469","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=81b1d548d00bcd028303c4f3150fa753b9b8aa71","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b2f37aead1b82a770c48b5d583f35ec22aabb61e","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-23848
|
Medium |
|
N/A
|
In the Linux kernel through 6.7.1, there is a use-after-free in cec_queue_msg_fh, related to drivers/media/cec/core/cec-adap.c and drivers/media/cec/core/cec-api.c. |
["https://lore.kernel.org/lkml/e9f42704-2f99-4f2c-ade5-f952e5fd53e5%40xs4all.nl/","https://lore.kernel.org/lkml/e9f42704-2f99-4f2c-ade5-f952e5fd53e5%40xs4all.nl/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26659
|
Medium |
fixed |
- 5.10.213
- 5.15.152
- 6.1.82
- 6.6.17
- 6.7.5
|
In the Linux kernel, the following vulnerability has been resolved:
xhci: handle isoc Babble and Buffer Overrun events properly
xHCI 4.9 explicitly forbids assuming that the xHC has released its
ownership of a multi-TRB TD when it reports an error on one of the
early TRBs. Yet the driver makes such assumption and releases the TD,
allowing the remaining TRBs to be freed or overwritten by new TDs.
The xHC should also report completion of the final TRB due to its IOC
flag being set by us, regardless of prior errors. This event cannot
be recognized if the TD has already been freed earlier, resulting in
"Transfer event TRB DMA ptr not part of current TD" error message.
Fix this by reusing the logic for processing isoc Transaction Errors.
This also handles hosts which fail to report the final completion.
Fix transfer length reporting on Babble errors. They may be caused by
device malfunction, no guarantee that the buffer has been filled. |
["https://git.kernel.org/stable/c/2aa7bcfdbb46241c701811bbc0d64d7884e3346c","https://git.kernel.org/stable/c/2e3ec80ea7ba58bbb210e83b5a0afefee7c171d3","https://git.kernel.org/stable/c/418456c0ce56209610523f21734c5612ee634134","https://git.kernel.org/stable/c/696e4112e5c1ee61996198f0ebb6ca3fab55166e","https://git.kernel.org/stable/c/7c4650ded49e5b88929ecbbb631efb8b0838e811","https://git.kernel.org/stable/c/f5e7ffa9269a448a720e21f1ed1384d118298c97","https://git.kernel.org/stable/c/2aa7bcfdbb46241c701811bbc0d64d7884e3346c","https://git.kernel.org/stable/c/2e3ec80ea7ba58bbb210e83b5a0afefee7c171d3","https://git.kernel.org/stable/c/418456c0ce56209610523f21734c5612ee634134","https://git.kernel.org/stable/c/696e4112e5c1ee61996198f0ebb6ca3fab55166e","https://git.kernel.org/stable/c/7c4650ded49e5b88929ecbbb631efb8b0838e811","https://git.kernel.org/stable/c/f5e7ffa9269a448a720e21f1ed1384d118298c97","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52583
|
Medium |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix deadlock or deadcode of misusing dget()
The lock order is incorrect between denty and its parent, we should
always make sure that the parent get the lock first.
But since this deadcode is never used and the parent dir will always
be set from the callers, let's just remove it. |
["https://git.kernel.org/stable/c/196b87e5c00ce021e164a5de0f0d04f4116a9160","https://git.kernel.org/stable/c/6ab4fd508fad942f1f1ba940492f2735e078e980","https://git.kernel.org/stable/c/76cb2aa3421fee4fde706dec41b1344bc0a9ad67","https://git.kernel.org/stable/c/7f2649c94264d00df6b6ac27161e9f4372a3450e","https://git.kernel.org/stable/c/a9c15d6e8aee074fae66c04d114f20b84274fcca","https://git.kernel.org/stable/c/b493ad718b1f0357394d2cdecbf00a44a36fa085","https://git.kernel.org/stable/c/e016e358461b89b231626fcf78c5c38e35c44fd3","https://git.kernel.org/stable/c/eb55ba8aa7fb7aad54f40fbf4d8dcdfdba0bebf6","https://git.kernel.org/stable/c/196b87e5c00ce021e164a5de0f0d04f4116a9160","https://git.kernel.org/stable/c/6ab4fd508fad942f1f1ba940492f2735e078e980","https://git.kernel.org/stable/c/76cb2aa3421fee4fde706dec41b1344bc0a9ad67","https://git.kernel.org/stable/c/7f2649c94264d00df6b6ac27161e9f4372a3450e","https://git.kernel.org/stable/c/a9c15d6e8aee074fae66c04d114f20b84274fcca","https://git.kernel.org/stable/c/b493ad718b1f0357394d2cdecbf00a44a36fa085","https://git.kernel.org/stable/c/e016e358461b89b231626fcf78c5c38e35c44fd3","https://git.kernel.org/stable/c/eb55ba8aa7fb7aad54f40fbf4d8dcdfdba0bebf6","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26679
|
Medium |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.78
- 6.6.17
- 6.7.5
|
In the Linux kernel, the following vulnerability has been resolved:
inet: read sk->sk_family once in inet_recv_error()
inet_recv_error() is called without holding the socket lock.
IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM
socket option and trigger a KCSAN warning. |
["https://git.kernel.org/stable/c/307fa8a75ab7423fa5c73573ec3d192de5027830","https://git.kernel.org/stable/c/3266e638ba5cc1165f5e6989eb8c0720f1cc4b41","https://git.kernel.org/stable/c/4a5e31bdd3c1702b520506d9cf8c41085f75c7f2","https://git.kernel.org/stable/c/54538752216bf89ee88d47ad07802063a498c299","https://git.kernel.org/stable/c/5993f121fbc01dc2d734f0ff2628009b258fb1dd","https://git.kernel.org/stable/c/88081ba415224cf413101def4343d660f56d082b","https://git.kernel.org/stable/c/caa064c3c2394d03e289ebd6b0be5102eb8a5b40","https://git.kernel.org/stable/c/eef00a82c568944f113f2de738156ac591bbd5cd","https://git.kernel.org/stable/c/307fa8a75ab7423fa5c73573ec3d192de5027830","https://git.kernel.org/stable/c/3266e638ba5cc1165f5e6989eb8c0720f1cc4b41","https://git.kernel.org/stable/c/4a5e31bdd3c1702b520506d9cf8c41085f75c7f2","https://git.kernel.org/stable/c/54538752216bf89ee88d47ad07802063a498c299","https://git.kernel.org/stable/c/5993f121fbc01dc2d734f0ff2628009b258fb1dd","https://git.kernel.org/stable/c/88081ba415224cf413101def4343d660f56d082b","https://git.kernel.org/stable/c/caa064c3c2394d03e289ebd6b0be5102eb8a5b40","https://git.kernel.org/stable/c/eef00a82c568944f113f2de738156ac591bbd5cd","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26902
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
perf: RISCV: Fix panic on pmu overflow handler
(1 << idx) of int is not desired when setting bits in unsigned long
overflowed_ctrs, use BIT() instead. This panic happens when running
'perf record -e branches' on sophgo sg2042.
[ 273.311852] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098
[ 273.320851] Oops [#1]
[ 273.323179] Modules linked in:
[ 273.326303] CPU: 0 PID: 1475 Comm: perf Not tainted 6.6.0-rc3+ #9
[ 273.332521] Hardware name: Sophgo Mango (DT)
[ 273.336878] epc : riscv_pmu_ctr_get_width_mask+0x8/0x62
[ 273.342291] ra : pmu_sbi_ovf_handler+0x2e0/0x34e
[ 273.347091] epc : ffffffff80aecd98 ra : ffffffff80aee056 sp : fffffff6e36928b0
[ 273.354454] gp : ffffffff821f82d0 tp : ffffffd90c353200 t0 : 0000002ade4f9978
[ 273.361815] t1 : 0000000000504d55 t2 : ffffffff8016cd8c s0 : fffffff6e3692a70
[ 273.369180] s1 : 0000000000000020 a0 : 0000000000000000 a1 : 00001a8e81800000
[ 273.376540] a2 : 0000003c00070198 a3 : 0000003c00db75a4 a4 : 0000000000000015
[ 273.383901] a5 : ffffffd7ff8804b0 a6 : 0000000000000015 a7 : 000000000000002a
[ 273.391327] s2 : 000000000000ffff s3 : 0000000000000000 s4 : ffffffd7ff8803b0
[ 273.398773] s5 : 0000000000504d55 s6 : ffffffd905069800 s7 : ffffffff821fe210
[ 273.406139] s8 : 000000007fffffff s9 : ffffffd7ff8803b0 s10: ffffffd903f29098
[ 273.413660] s11: 0000000080000000 t3 : 0000000000000003 t4 : ffffffff8017a0ca
[ 273.421022] t5 : ffffffff8023cfc2 t6 : ffffffd9040780e8
[ 273.426437] status: 0000000200000100 badaddr: 0000000000000098 cause: 000000000000000d
[ 273.434512] [<ffffffff80aecd98>] riscv_pmu_ctr_get_width_mask+0x8/0x62
[ 273.441169] [<ffffffff80076bd8>] handle_percpu_devid_irq+0x98/0x1ee
[ 273.447562] [<ffffffff80071158>] generic_handle_domain_irq+0x28/0x36
[ 273.454151] [<ffffffff8047a99a>] riscv_intc_irq+0x36/0x4e
[ 273.459659] [<ffffffff80c944de>] handle_riscv_irq+0x4a/0x74
[ 273.465442] [<ffffffff80c94c48>] do_irq+0x62/0x92
[ 273.470360] Code: 0420 60a2 6402 5529 0141 8082 0013 0000 0013 0000 (6d5c) b783
[ 273.477921] ---[ end trace 0000000000000000 ]---
[ 273.482630] Kernel panic - not syncing: Fatal exception in interrupt |
["https://git.kernel.org/stable/c/34b567868777e9fd39ec5333969728a7f0cf179c","https://git.kernel.org/stable/c/3ede8e94de6b834b48b0643385e66363e7a04be9","https://git.kernel.org/stable/c/9f599ba3b9cc4bdb8ec1e3f0feddd41bf9d296d6","https://git.kernel.org/stable/c/34b567868777e9fd39ec5333969728a7f0cf179c","https://git.kernel.org/stable/c/3ede8e94de6b834b48b0643385e66363e7a04be9","https://git.kernel.org/stable/c/9f599ba3b9cc4bdb8ec1e3f0feddd41bf9d296d6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26751
|
Medium |
fixed |
- 4.19.308
- 5.4.270
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
ARM: ep93xx: Add terminator to gpiod_lookup_table
Without the terminator, if a con_id is passed to gpio_find() that
does not exist in the lookup table the function will not stop looping
correctly, and eventually cause an oops. |
["https://git.kernel.org/stable/c/6abe0895b63c20de06685c8544b908c7e413efa8","https://git.kernel.org/stable/c/70d92abbe29692a3de8697ae082c60f2d21ab482","https://git.kernel.org/stable/c/786f089086b505372fb3f4f008d57e7845fff0d8","https://git.kernel.org/stable/c/97ba7c1f9c0a2401e644760d857b2386aa895997","https://git.kernel.org/stable/c/999a8bb70da2946336327b4480824d1691cae1fa","https://git.kernel.org/stable/c/9e200a06ae2abb321939693008290af32b33dd6e","https://git.kernel.org/stable/c/eec6cbbfa1e8d685cc245cfd5626d0715a127a48","https://git.kernel.org/stable/c/fdf87a0dc26d0550c60edc911cda42f9afec3557","https://git.kernel.org/stable/c/6abe0895b63c20de06685c8544b908c7e413efa8","https://git.kernel.org/stable/c/70d92abbe29692a3de8697ae082c60f2d21ab482","https://git.kernel.org/stable/c/786f089086b505372fb3f4f008d57e7845fff0d8","https://git.kernel.org/stable/c/97ba7c1f9c0a2401e644760d857b2386aa895997","https://git.kernel.org/stable/c/999a8bb70da2946336327b4480824d1691cae1fa","https://git.kernel.org/stable/c/9e200a06ae2abb321939693008290af32b33dd6e","https://git.kernel.org/stable/c/eec6cbbfa1e8d685cc245cfd5626d0715a127a48","https://git.kernel.org/stable/c/fdf87a0dc26d0550c60edc911cda42f9afec3557","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26675
|
Medium |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.78
- 6.6.17
- 6.7.5
|
In the Linux kernel, the following vulnerability has been resolved:
ppp_async: limit MRU to 64K
syzbot triggered a warning [1] in __alloc_pages():
WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)
Willem fixed a similar issue in commit c0a2a1b0d631 ("ppp: limit MRU to 64K")
Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU)
[1]:
WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543
Modules linked in:
CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
Workqueue: events_unbound flush_to_ldisc
pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543
lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537
sp : ffff800093967580
x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000
x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0
x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8
x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120
x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005
x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000
x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001
x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f
x5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020
x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0
Call trace:
__alloc_pages+0x308/0x698 mm/page_alloc.c:4543
__alloc_pages_node include/linux/gfp.h:238 [inline]
alloc_pages_node include/linux/gfp.h:261 [inline]
__kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926
__do_kmalloc_node mm/slub.c:3969 [inline]
__kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001
kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590
__alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651
__netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715
netdev_alloc_skb include/linux/skbuff.h:3235 [inline]
dev_alloc_skb include/linux/skbuff.h:3248 [inline]
ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline]
ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341
tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390
tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37
receive_buf drivers/tty/tty_buffer.c:444 [inline]
flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494
process_one_work+0x694/0x1204 kernel/workqueue.c:2633
process_scheduled_works kernel/workqueue.c:2706 [inline]
worker_thread+0x938/0xef4 kernel/workqueue.c:2787
kthread+0x288/0x310 kernel/kthread.c:388
ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860 |
["https://git.kernel.org/stable/c/210d938f963dddc543b07e66a79b7d8d4bd00bd8","https://git.kernel.org/stable/c/4e2c4846b2507f6dfc9bea72b7567c2693a82a16","https://git.kernel.org/stable/c/4fdb14ba89faff6e6969a4dffdc8e54235d6e5ed","https://git.kernel.org/stable/c/56fae81633ccee307cfcb032f706bf1863a56982","https://git.kernel.org/stable/c/58fbe665b097bf7b3144da7e7b91fb27aa8d0ae3","https://git.kernel.org/stable/c/7e5ef49670766c9742ffcd9cead7cdb018268719","https://git.kernel.org/stable/c/b06e067e93fa4b98acfd3a9f38a398ab91bbc58b","https://git.kernel.org/stable/c/cb88cb53badb8aeb3955ad6ce80b07b598e310b8","https://git.kernel.org/stable/c/210d938f963dddc543b07e66a79b7d8d4bd00bd8","https://git.kernel.org/stable/c/4e2c4846b2507f6dfc9bea72b7567c2693a82a16","https://git.kernel.org/stable/c/4fdb14ba89faff6e6969a4dffdc8e54235d6e5ed","https://git.kernel.org/stable/c/56fae81633ccee307cfcb032f706bf1863a56982","https://git.kernel.org/stable/c/58fbe665b097bf7b3144da7e7b91fb27aa8d0ae3","https://git.kernel.org/stable/c/7e5ef49670766c9742ffcd9cead7cdb018268719","https://git.kernel.org/stable/c/b06e067e93fa4b98acfd3a9f38a398ab91bbc58b","https://git.kernel.org/stable/c/cb88cb53badb8aeb3955ad6ce80b07b598e310b8","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52500
|
Medium |
fixed |
- 5.10.198
- 5.15.134
- 6.1.56
- 6.5.6
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: pm80xx: Avoid leaking tags when processing OPC_INB_SET_CONTROLLER_CONFIG command
Tags allocated for OPC_INB_SET_CONTROLLER_CONFIG command need to be freed
when we receive the response. |
["https://git.kernel.org/stable/c/2259e1901b2d8c0e8538fc99e77de443b939e749","https://git.kernel.org/stable/c/22e6d783a33015bcdf0979015e4eac603912bea7","https://git.kernel.org/stable/c/2afd8fcee0c4d65a482e30c3ad2a92c25e5e92d4","https://git.kernel.org/stable/c/c13e7331745852d0dd7c35eabbe181cbd5b01172","https://git.kernel.org/stable/c/d540a4370aba378fbedf349ba0bb68e96e24243d","https://git.kernel.org/stable/c/2259e1901b2d8c0e8538fc99e77de443b939e749","https://git.kernel.org/stable/c/22e6d783a33015bcdf0979015e4eac603912bea7","https://git.kernel.org/stable/c/2afd8fcee0c4d65a482e30c3ad2a92c25e5e92d4","https://git.kernel.org/stable/c/c13e7331745852d0dd7c35eabbe181cbd5b01172","https://git.kernel.org/stable/c/d540a4370aba378fbedf349ba0bb68e96e24243d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26758
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
md: Don't ignore suspended array in md_check_recovery()
mddev_suspend() never stop sync_thread, hence it doesn't make sense to
ignore suspended array in md_check_recovery(), which might cause
sync_thread can't be unregistered.
After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following
hang can be triggered by test shell/integrity-caching.sh:
1) suspend the array:
raid_postsuspend
mddev_suspend
2) stop the array:
raid_dtr
md_stop
__md_stop_writes
stop_sync_thread
set_bit(MD_RECOVERY_INTR, &mddev->recovery);
md_wakeup_thread_directly(mddev->sync_thread);
wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))
3) sync thread done:
md_do_sync
set_bit(MD_RECOVERY_DONE, &mddev->recovery);
md_wakeup_thread(mddev->thread);
4) daemon thread can't unregister sync thread:
md_check_recovery
if (mddev->suspended)
return; -> return directly
md_read_sync_thread
clear_bit(MD_RECOVERY_RUNNING, &mddev->recovery);
-> MD_RECOVERY_RUNNING can't be cleared, hence step 2 hang;
This problem is not just related to dm-raid, fix it by ignoring
suspended array in md_check_recovery(). And follow up patches will
improve dm-raid better to frozen sync thread during suspend. |
["https://git.kernel.org/stable/c/1baae052cccd08daf9a9d64c3f959d8cdb689757","https://git.kernel.org/stable/c/a55f0d6179a19c6b982e2dc344d58c98647a3be0","https://git.kernel.org/stable/c/1baae052cccd08daf9a9d64c3f959d8cdb689757","https://git.kernel.org/stable/c/a55f0d6179a19c6b982e2dc344d58c98647a3be0"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-25740
|
Medium |
|
N/A
|
A memory leak flaw was found in the UBI driver in drivers/mtd/ubi/attach.c in the Linux kernel through 6.7.4 for UBI_IOCATT, because kobj->name is not released. |
["https://lore.kernel.org/lkml/0171b6cc-95ee-3538-913b-65a391a446b3%40huawei.com/T/","https://lore.kernel.org/lkml/0171b6cc-95ee-3538-913b-65a391a446b3%40huawei.com/T/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3358
|
Medium |
fixed |
|
A null pointer dereference was found in the Linux kernel's Integrated Sensor Hub (ISH) driver. This issue could allow a local user to crash the system. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b3d40c3ec3dc4ad78017de6c3a38979f57aaaab8","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b3d40c3ec3dc4ad78017de6c3a38979f57aaaab8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26668
|
Medium |
fixed |
- 5.15.149
- 6.1.76
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_limit: reject configurations that cause integer overflow
Reject bogus configs where internal token counter wraps around.
This only occurs with very very large requests, such as 17gbyte/s.
Its better to reject this rather than having incorrect ratelimit. |
["https://git.kernel.org/stable/c/00c2c29aa36d1d1827c51a3720e9f893a22c7c6a","https://git.kernel.org/stable/c/79d4efd75e7dbecd855a3b8a63e65f7265f466e1","https://git.kernel.org/stable/c/9882495d02ecc490604f747437a40626dc9160d0","https://git.kernel.org/stable/c/bc6e242bb74e2ae616bfd2b250682b738e781c9b","https://git.kernel.org/stable/c/c9d9eb9c53d37cdebbad56b91e40baf42d5a97aa","https://git.kernel.org/stable/c/00c2c29aa36d1d1827c51a3720e9f893a22c7c6a","https://git.kernel.org/stable/c/79d4efd75e7dbecd855a3b8a63e65f7265f466e1","https://git.kernel.org/stable/c/9882495d02ecc490604f747437a40626dc9160d0","https://git.kernel.org/stable/c/bc6e242bb74e2ae616bfd2b250682b738e781c9b","https://git.kernel.org/stable/c/c9d9eb9c53d37cdebbad56b91e40baf42d5a97aa"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-23000
|
Medium |
fixed |
|
In the Linux kernel before 5.17, drivers/phy/tegra/xusb.c mishandles the tegra_xusb_find_port_node return value. Callers expect NULL in the error case, but an error pointer is used. |
["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17","https://github.com/torvalds/linux/commit/045a31b95509c8f25f5f04ec5e0dec5cd09f2c5f","https://security.netapp.com/advisory/ntap-20230331-0004/","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17","https://github.com/torvalds/linux/commit/045a31b95509c8f25f5f04ec5e0dec5cd09f2c5f","https://security.netapp.com/advisory/ntap-20230331-0004/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52638
|
Medium |
fixed |
- 5.15.149
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock
The following 3 locks would race against each other, causing the
deadlock situation in the Syzbot bug report:
- j1939_socks_lock
- active_session_list_lock
- sk_session_queue_lock
A reasonable fix is to change j1939_socks_lock to an rwlock, since in
the rare situations where a write lock is required for the linked list
that j1939_socks_lock is protecting, the code does not attempt to
acquire any more locks. This would break the circular lock dependency,
where, for example, the current thread already locks j1939_socks_lock
and attempts to acquire sk_session_queue_lock, and at the same time,
another thread attempts to acquire j1939_socks_lock while holding
sk_session_queue_lock.
NOTE: This patch along does not fix the unregister_netdevice bug
reported by Syzbot; instead, it solves a deadlock situation to prepare
for one or more further patches to actually fix the Syzbot bug, which
appears to be a reference counting problem within the j1939 codebase.
[mkl: remove unrelated newline change] |
["https://git.kernel.org/stable/c/03358aba991668d3bb2c65b3c82aa32c36851170","https://git.kernel.org/stable/c/26dfe112ec2e95fe0099681f6aec33da13c2dd8e","https://git.kernel.org/stable/c/559b6322f9480bff68cfa98d108991e945a4f284","https://git.kernel.org/stable/c/6cdedc18ba7b9dacc36466e27e3267d201948c8d","https://git.kernel.org/stable/c/aedda066d717a0b4335d7e0a00b2e3a61e40afcf","https://git.kernel.org/stable/c/03358aba991668d3bb2c65b3c82aa32c36851170","https://git.kernel.org/stable/c/26dfe112ec2e95fe0099681f6aec33da13c2dd8e","https://git.kernel.org/stable/c/559b6322f9480bff68cfa98d108991e945a4f284","https://git.kernel.org/stable/c/6cdedc18ba7b9dacc36466e27e3267d201948c8d","https://git.kernel.org/stable/c/aedda066d717a0b4335d7e0a00b2e3a61e40afcf"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26733
|
Medium |
fixed |
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
arp: Prevent overflow in arp_req_get().
syzkaller reported an overflown write in arp_req_get(). [0]
When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour
entry and copies neigh->ha to struct arpreq.arp_ha.sa_data.
The arp_ha here is struct sockaddr, not struct sockaddr_storage, so
the sa_data buffer is just 14 bytes.
In the splat below, 2 bytes are overflown to the next int field,
arp_flags. We initialise the field just after the memcpy(), so it's
not a problem.
However, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN),
arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL)
in arp_ioctl() before calling arp_req_get().
To avoid the overflow, let's limit the max length of memcpy().
Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible
array in struct sockaddr") just silenced syzkaller.
[0]:
memcpy: detected field-spanning write (size 16) of single field "r->arp_ha.sa_data" at net/ipv4/arp.c:1128 (size 14)
WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
Modules linked in:
CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014
RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6
RSP: 0018:ffffc900050b7998 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001
RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000
R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010
FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<TASK>
arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261
inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981
sock_do_ioctl+0xdf/0x260 net/socket.c:1204
sock_ioctl+0x3ef/0x650 net/socket.c:1321
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:870 [inline]
__se_sys_ioctl fs/ioctl.c:856 [inline]
__x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81
entry_SYSCALL_64_after_hwframe+0x64/0xce
RIP: 0033:0x7f172b262b8d
Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d
RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003
RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000
</TASK> |
["https://git.kernel.org/stable/c/3ab0d6f8289ba8402ca95a9fc61a34909d5e1f3a","https://git.kernel.org/stable/c/97eaa2955db4120ce6ec2ef123e860bc32232c50","https://git.kernel.org/stable/c/a3f2c083cb575d80a7627baf3339e78fedccbb91","https://git.kernel.org/stable/c/a7d6027790acea24446ddd6632d394096c0f4667","https://git.kernel.org/stable/c/dbc9b22d0ed319b4e29034ce0a3fe32a3ee2c587","https://git.kernel.org/stable/c/f119f2325ba70cbfdec701000dcad4d88805d5b0","https://git.kernel.org/stable/c/3ab0d6f8289ba8402ca95a9fc61a34909d5e1f3a","https://git.kernel.org/stable/c/97eaa2955db4120ce6ec2ef123e860bc32232c50","https://git.kernel.org/stable/c/a3f2c083cb575d80a7627baf3339e78fedccbb91","https://git.kernel.org/stable/c/a7d6027790acea24446ddd6632d394096c0f4667","https://git.kernel.org/stable/c/dbc9b22d0ed319b4e29034ce0a3fe32a3ee2c587","https://git.kernel.org/stable/c/f119f2325ba70cbfdec701000dcad4d88805d5b0","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://security.netapp.com/advisory/ntap-20241101-0013/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-1151
|
Medium |
|
N/A
|
A vulnerability was reported in the Open vSwitch sub-component in the Linux Kernel. The flaw occurs when a recursive operation of code push recursively calls into the code block. The OVS module does not validate the stack depth, pushing too many frames and causing a stack overflow. As a result, this can lead to a crash or other related issues. |
["https://access.redhat.com/errata/RHSA-2024:4823","https://access.redhat.com/errata/RHSA-2024:4831","https://access.redhat.com/errata/RHSA-2024:9315","https://access.redhat.com/security/cve/CVE-2024-1151","https://bugzilla.redhat.com/show_bug.cgi?id=2262241","https://lore.kernel.org/all/20240207132416.1488485-1-aconole@redhat.com/","https://access.redhat.com/errata/RHSA-2024:4823","https://access.redhat.com/errata/RHSA-2024:4831","https://access.redhat.com/security/cve/CVE-2024-1151","https://bugzilla.redhat.com/show_bug.cgi?id=2262241","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/3LZROQAX7Q7LEP4F7WQ3KUZKWCZGFFP2/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GS7S3XLTLOUKBXV67LLFZWB3YVFJZHRK/","https://lore.kernel.org/all/20240207132416.1488485-1-aconole@redhat.com/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52610
|
Medium |
fixed |
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_ct: fix skb leak and crash on ooo frags
act_ct adds skb->users before defragmentation. If frags arrive in order,
the last frag's reference is reset in:
inet_frag_reasm_prepare
skb_morph
which is not straightforward.
However when frags arrive out of order, nobody unref the last frag, and
all frags are leaked. The situation is even worse, as initiating packet
capture can lead to a crash[0] when skb has been cloned and shared at the
same time.
Fix the issue by removing skb_get() before defragmentation. act_ct
returns TC_ACT_CONSUMED when defrag failed or in progress.
[0]:
[ 843.804823] ------------[ cut here ]------------
[ 843.809659] kernel BUG at net/core/skbuff.c:2091!
[ 843.814516] invalid opcode: 0000 [#1] PREEMPT SMP
[ 843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2
[ 843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022
[ 843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300
[ 843.833805] Code: 8b 70 28 48 85 f6 74 82 48 83 c6 08 bf 01 00 00 00 e8 38 bd ff ff 8b 83 c0 00 00 00 48 03 83 c8 00 00 00 e9 62 ff ff ff 0f 0b <0f> 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89
[ 843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202
[ 843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820
[ 843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00
[ 843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000
[ 843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880
[ 843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900
[ 843.871680] FS: 0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000
[ 843.876242] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0
[ 843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 843.894229] PKRU: 55555554
[ 843.898539] Call Trace:
[ 843.902772] <IRQ>
[ 843.906922] ? __die_body+0x1e/0x60
[ 843.911032] ? die+0x3c/0x60
[ 843.915037] ? do_trap+0xe2/0x110
[ 843.918911] ? pskb_expand_head+0x2ac/0x300
[ 843.922687] ? do_error_trap+0x65/0x80
[ 843.926342] ? pskb_expand_head+0x2ac/0x300
[ 843.929905] ? exc_invalid_op+0x50/0x60
[ 843.933398] ? pskb_expand_head+0x2ac/0x300
[ 843.936835] ? asm_exc_invalid_op+0x1a/0x20
[ 843.940226] ? pskb_expand_head+0x2ac/0x300
[ 843.943580] inet_frag_reasm_prepare+0xd1/0x240
[ 843.946904] ip_defrag+0x5d4/0x870
[ 843.950132] nf_ct_handle_fragments+0xec/0x130 [nf_conntrack]
[ 843.953334] tcf_ct_act+0x252/0xd90 [act_ct]
[ 843.956473] ? tcf_mirred_act+0x516/0x5a0 [act_mirred]
[ 843.959657] tcf_action_exec+0xa1/0x160
[ 843.962823] fl_classify+0x1db/0x1f0 [cls_flower]
[ 843.966010] ? skb_clone+0x53/0xc0
[ 843.969173] tcf_classify+0x24d/0x420
[ 843.972333] tc_run+0x8f/0xf0
[ 843.975465] __netif_receive_skb_core+0x67a/0x1080
[ 843.978634] ? dev_gro_receive+0x249/0x730
[ 843.981759] __netif_receive_skb_list_core+0x12d/0x260
[ 843.984869] netif_receive_skb_list_internal+0x1cb/0x2f0
[ 843.987957] ? mlx5e_handle_rx_cqe_mpwrq_rep+0xfa/0x1a0 [mlx5_core]
[ 843.991170] napi_complete_done+0x72/0x1a0
[ 843.994305] mlx5e_napi_poll+0x28c/0x6d0 [mlx5_core]
[ 843.997501] __napi_poll+0x25/0x1b0
[ 844.000627] net_rx_action+0x256/0x330
[ 844.003705] __do_softirq+0xb3/0x29b
[ 844.006718] irq_exit_rcu+0x9e/0xc0
[ 844.009672] common_interrupt+0x86/0xa0
[ 844.012537] </IRQ>
[ 844.015285] <TASK>
[ 844.017937] asm_common_interrupt+0x26/0x40
[ 844.020591] RIP: 0010:acpi_safe_halt+0x1b/0x20
[ 844.023247] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 65 48 8b 04 25 00 18 03 00 48 8b 00 a8 08 75 0c 66 90 0f 00 2d 81 d0 44 00 fb
---truncated--- |
["https://git.kernel.org/stable/c/0b5b831122fc3789fff75be433ba3e4dd7b779d4","https://git.kernel.org/stable/c/172ba7d46c202e679f3ccb10264c67416aaeb1c4","https://git.kernel.org/stable/c/3f14b377d01d8357eba032b4cabc8c1149b458b6","https://git.kernel.org/stable/c/73f7da5fd124f2cda9161e2e46114915e6e82e97","https://git.kernel.org/stable/c/f5346df0591d10bc948761ca854b1fae6d2ef441","https://git.kernel.org/stable/c/0b5b831122fc3789fff75be433ba3e4dd7b779d4","https://git.kernel.org/stable/c/172ba7d46c202e679f3ccb10264c67416aaeb1c4","https://git.kernel.org/stable/c/3f14b377d01d8357eba032b4cabc8c1149b458b6","https://git.kernel.org/stable/c/73f7da5fd124f2cda9161e2e46114915e6e82e97","https://git.kernel.org/stable/c/f5346df0591d10bc948761ca854b1fae6d2ef441"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26602
|
Medium |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
sched/membarrier: reduce the ability to hammer on sys_membarrier
On some systems, sys_membarrier can be very expensive, causing overall
slowdowns for everything. So put a lock on the path in order to
serialize the accesses to prevent the ability for this to be called at
too high of a frequency and saturate the machine. |
["https://git.kernel.org/stable/c/2441a64070b85c14eecc3728cc87e883f953f265","https://git.kernel.org/stable/c/24ec7504a08a67247fbe798d1de995208a8c128a","https://git.kernel.org/stable/c/3cd139875e9a7688b3fc715264032620812a5fa3","https://git.kernel.org/stable/c/50fb4e17df319bb33be6f14e2a856950c1577dee","https://git.kernel.org/stable/c/944d5fe50f3f03daacfea16300e656a1691c4a23","https://git.kernel.org/stable/c/b6a2a9cbb67545c825ec95f06adb7ff300a2ad71","https://git.kernel.org/stable/c/c5b2063c65d05e79fad8029324581d86cfba7eea","https://git.kernel.org/stable/c/db896bbe4a9c67cee377e5f6a743350d3ae4acf6","https://git.kernel.org/stable/c/2441a64070b85c14eecc3728cc87e883f953f265","https://git.kernel.org/stable/c/24ec7504a08a67247fbe798d1de995208a8c128a","https://git.kernel.org/stable/c/3cd139875e9a7688b3fc715264032620812a5fa3","https://git.kernel.org/stable/c/50fb4e17df319bb33be6f14e2a856950c1577dee","https://git.kernel.org/stable/c/944d5fe50f3f03daacfea16300e656a1691c4a23","https://git.kernel.org/stable/c/b6a2a9cbb67545c825ec95f06adb7ff300a2ad71","https://git.kernel.org/stable/c/c5b2063c65d05e79fad8029324581d86cfba7eea","https://git.kernel.org/stable/c/db896bbe4a9c67cee377e5f6a743350d3ae4acf6","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52463
|
Medium |
fixed |
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
efivarfs: force RO when remounting if SetVariable is not supported
If SetVariable at runtime is not supported by the firmware we never assign
a callback for that function. At the same time mount the efivarfs as
RO so no one can call that. However, we never check the permission flags
when someone remounts the filesystem as RW. As a result this leads to a
crash looking like this:
$ mount -o remount,rw /sys/firmware/efi/efivars
$ efi-updatevar -f PK.auth PK
[ 303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[ 303.280482] Mem abort info:
[ 303.280854] ESR = 0x0000000086000004
[ 303.281338] EC = 0x21: IABT (current EL), IL = 32 bits
[ 303.282016] SET = 0, FnV = 0
[ 303.282414] EA = 0, S1PTW = 0
[ 303.282821] FSC = 0x04: level 0 translation fault
[ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000
[ 303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
[ 303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP
[ 303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6
[ 303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1
[ 303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023
[ 303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 303.292123] pc : 0x0
[ 303.292443] lr : efivar_set_variable_locked+0x74/0xec
[ 303.293156] sp : ffff800008673c10
[ 303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000
[ 303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027
[ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000
[ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000
[ 303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54
[ 303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4
[ 303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002
[ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201
[ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc
[ 303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000
[ 303.303341] Call trace:
[ 303.303679] 0x0
[ 303.303938] efivar_entry_set_get_size+0x98/0x16c
[ 303.304585] efivarfs_file_write+0xd0/0x1a4
[ 303.305148] vfs_write+0xc4/0x2e4
[ 303.305601] ksys_write+0x70/0x104
[ 303.306073] __arm64_sys_write+0x1c/0x28
[ 303.306622] invoke_syscall+0x48/0x114
[ 303.307156] el0_svc_common.constprop.0+0x44/0xec
[ 303.307803] do_el0_svc+0x38/0x98
[ 303.308268] el0_svc+0x2c/0x84
[ 303.308702] el0t_64_sync_handler+0xf4/0x120
[ 303.309293] el0t_64_sync+0x190/0x194
[ 303.309794] Code: ???????? ???????? ???????? ???????? (????????)
[ 303.310612] ---[ end trace 0000000000000000 ]---
Fix this by adding a .reconfigure() function to the fs operations which
we can use to check the requested flags and deny anything that's not RO
if the firmware doesn't implement SetVariable at runtime. |
["https://git.kernel.org/stable/c/0049fe7e4a85849bdd778cdb72e51a791ff3d737","https://git.kernel.org/stable/c/0e8d2444168dd519fea501599d150e62718ed2fe","https://git.kernel.org/stable/c/2aa141f8bc580f8f9811dfe4e0e6009812b73826","https://git.kernel.org/stable/c/94c742324ed7e42c5bd6a9ed22e4ec6d764db4d8","https://git.kernel.org/stable/c/d4a714873db0866cc471521114eeac4a5072d548","https://git.kernel.org/stable/c/d4a9aa7db574a0da64307729cc031fb68597aa8b","https://git.kernel.org/stable/c/0049fe7e4a85849bdd778cdb72e51a791ff3d737","https://git.kernel.org/stable/c/0e8d2444168dd519fea501599d150e62718ed2fe","https://git.kernel.org/stable/c/2aa141f8bc580f8f9811dfe4e0e6009812b73826","https://git.kernel.org/stable/c/94c742324ed7e42c5bd6a9ed22e4ec6d764db4d8","https://git.kernel.org/stable/c/d4a714873db0866cc471521114eeac4a5072d548","https://git.kernel.org/stable/c/d4a9aa7db574a0da64307729cc031fb68597aa8b","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26900
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
md: fix kmemleak of rdev->serial
If kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will be
alloc not be freed, and kmemleak occurs.
unreferenced object 0xffff88815a350000 (size 49152):
comm "mdadm", pid 789, jiffies 4294716910
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc f773277a):
[<0000000058b0a453>] kmemleak_alloc+0x61/0xe0
[<00000000366adf14>] __kmalloc_large_node+0x15e/0x270
[<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f
[<00000000f206d60a>] kvmalloc_node+0x74/0x150
[<0000000034bf3363>] rdev_init_serial+0x67/0x170
[<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220
[<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630
[<0000000073c28560>] md_add_new_disk+0x400/0x9f0
[<00000000770e30ff>] md_ioctl+0x15bf/0x1c10
[<000000006cfab718>] blkdev_ioctl+0x191/0x3f0
[<0000000085086a11>] vfs_ioctl+0x22/0x60
[<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0
[<00000000e54e675e>] do_syscall_64+0x71/0x150
[<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 |
["https://git.kernel.org/stable/c/4c1021ce46fc2fb6115f7e79d353941e6dcad366","https://git.kernel.org/stable/c/6cf350658736681b9d6b0b6e58c5c76b235bb4c4","https://git.kernel.org/stable/c/6d32c832a88513f65c2c2c9c75954ee8b387adea","https://git.kernel.org/stable/c/9fd0198f7ef06ae0d6636fb0578560857dead995","https://git.kernel.org/stable/c/beaf11969fd5cbe6f09cefaa34df1ce8578e8dd9","https://git.kernel.org/stable/c/f3a1787dc48213f6caea5ba7d47e0222e7fa34a9","https://git.kernel.org/stable/c/fb5b347efd1bda989846ffc74679d181222fb123","https://git.kernel.org/stable/c/4c1021ce46fc2fb6115f7e79d353941e6dcad366","https://git.kernel.org/stable/c/6cf350658736681b9d6b0b6e58c5c76b235bb4c4","https://git.kernel.org/stable/c/6d32c832a88513f65c2c2c9c75954ee8b387adea","https://git.kernel.org/stable/c/9fd0198f7ef06ae0d6636fb0578560857dead995","https://git.kernel.org/stable/c/beaf11969fd5cbe6f09cefaa34df1ce8578e8dd9","https://git.kernel.org/stable/c/f3a1787dc48213f6caea5ba7d47e0222e7fa34a9","https://git.kernel.org/stable/c/fb5b347efd1bda989846ffc74679d181222fb123","https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html","https://security.netapp.com/advisory/ntap-20240912-0011/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52595
|
Medium |
fixed |
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: rt2x00: restart beacon queue when hardware reset
When a hardware reset is triggered, all registers are reset, so all
queues are forced to stop in hardware interface. However, mac80211
will not automatically stop the queue. If we don't manually stop the
beacon queue, the queue will be deadlocked and unable to start again.
This patch fixes the issue where Apple devices cannot connect to the
AP after calling ieee80211_restart_hw(). |
["https://git.kernel.org/stable/c/04cfe4a5da57ab9358cdfadea22bcb37324aaf83","https://git.kernel.org/stable/c/4cc198580a7b93a36f5beb923f40f7ae27a3716c","https://git.kernel.org/stable/c/69e905beca193125820c201ab3db4fb0e245124e","https://git.kernel.org/stable/c/739b3ccd9486dff04af95f9a890846d088a84957","https://git.kernel.org/stable/c/a11d965a218f0cd95b13fe44d0bcd8a20ce134a8","https://git.kernel.org/stable/c/e1f113b57ddd18274d7c83618deca25cc880bc48","https://git.kernel.org/stable/c/fdb580ed05df8973aa5149cafa598c64bebcd0cb","https://git.kernel.org/stable/c/04cfe4a5da57ab9358cdfadea22bcb37324aaf83","https://git.kernel.org/stable/c/4cc198580a7b93a36f5beb923f40f7ae27a3716c","https://git.kernel.org/stable/c/69e905beca193125820c201ab3db4fb0e245124e","https://git.kernel.org/stable/c/739b3ccd9486dff04af95f9a890846d088a84957","https://git.kernel.org/stable/c/a11d965a218f0cd95b13fe44d0bcd8a20ce134a8","https://git.kernel.org/stable/c/e1f113b57ddd18274d7c83618deca25cc880bc48","https://git.kernel.org/stable/c/fdb580ed05df8973aa5149cafa598c64bebcd0cb","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3595
|
Medium |
fixed |
|
A vulnerability was found in Linux Kernel. It has been rated as problematic. Affected by this issue is the function sess_free_buffer of the file fs/cifs/sess.c of the component CIFS Handler. The manipulation leads to double free. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211364. |
["https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b854b4ee66437e6e1622fda90529c814978cb4ca","https://vuldb.com/?id.211364","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b854b4ee66437e6e1622fda90529c814978cb4ca","https://vuldb.com/?id.211364"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3544
|
Medium |
fixed |
|
A vulnerability, which was classified as problematic, was found in Linux Kernel. Affected is the function damon_sysfs_add_target of the file mm/damon/sysfs.c of the component Netfilter. The manipulation leads to memory leak. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211044. |
["https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next.git/commit/?id=1c8e2349f2d033f634d046063b704b2ca6c46972","https://vuldb.com/?id.211044","https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next.git/commit/?id=1c8e2349f2d033f634d046063b704b2ca6c46972","https://vuldb.com/?id.211044"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3212
|
Medium |
fixed |
|
A NULL pointer dereference issue was found in the gfs2 file system in the Linux kernel. It occurs on corrupt gfs2 file systems when the evict code tries to reference the journal descriptor structure after it has been freed and set to NULL. A privileged local user could use this flaw to cause a kernel panic. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2214348","https://github.com/torvalds/linux/commit/504a10d9e46bc37b23d0a1ae2f28973c8516e636","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230929-0005/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5480","https://bugzilla.redhat.com/show_bug.cgi?id=2214348","https://github.com/torvalds/linux/commit/504a10d9e46bc37b23d0a1ae2f28973c8516e636","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230929-0005/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5480"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52617
|
Medium |
fixed |
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
PCI: switchtec: Fix stdev_release() crash after surprise hot remove
A PCI device hot removal may occur while stdev->cdev is held open. The call
to stdev_release() then happens during close or exit, at a point way past
switchtec_pci_remove(). Otherwise the last ref would vanish with the
trailing put_device(), just before return.
At that later point in time, the devm cleanup has already removed the
stdev->mmio_mrpc mapping. Also, the stdev->pdev reference was not a counted
one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause
a fatal page fault, and the subsequent dma_free_coherent(), if reached,
would pass a stale &stdev->pdev->dev pointer.
Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after
stdev_kill(). Counting the stdev->pdev ref is now optional, but may prevent
future accidents.
Reproducible via the script at
https://lore.kernel.org/r/20231113212150.96410-1-dns@arista.com |
["https://git.kernel.org/stable/c/0233b836312e39a3c763fb53512b3fa455b473b3","https://git.kernel.org/stable/c/1d83c85922647758c1f1e4806a4c5c3cf591a20a","https://git.kernel.org/stable/c/4a5d0528cf19dbf060313dffbe047bc11c90c24c","https://git.kernel.org/stable/c/d8c293549946ee5078ed0ab77793cec365559355","https://git.kernel.org/stable/c/df25461119d987b8c81d232cfe4411e91dcabe66","https://git.kernel.org/stable/c/e129c7fa7070fbce57feb0bfc5eaa65eef44b693","https://git.kernel.org/stable/c/ff1c7e2fb9e9c3f53715fbe04d3ac47b80be7eb8","https://git.kernel.org/stable/c/0233b836312e39a3c763fb53512b3fa455b473b3","https://git.kernel.org/stable/c/1d83c85922647758c1f1e4806a4c5c3cf591a20a","https://git.kernel.org/stable/c/4a5d0528cf19dbf060313dffbe047bc11c90c24c","https://git.kernel.org/stable/c/d8c293549946ee5078ed0ab77793cec365559355","https://git.kernel.org/stable/c/df25461119d987b8c81d232cfe4411e91dcabe66","https://git.kernel.org/stable/c/e129c7fa7070fbce57feb0bfc5eaa65eef44b693","https://git.kernel.org/stable/c/ff1c7e2fb9e9c3f53715fbe04d3ac47b80be7eb8","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2021-3743
|
High |
fixed |
|
An out-of-bounds (OOB) memory read flaw was found in the Qualcomm IPC router protocol in the Linux kernel. A missing sanity check allows a local attacker to gain access to out-of-bounds memory, leading to a system crash or a leak of internal kernel information. The highest threat from this vulnerability is to system availability. |
["https://bugzilla.redhat.com/show_bug.cgi?id=1997961","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=7e78c597c3eb","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e78c597c3ebfd0cb329aa09a838734147e4f117","https://github.com/torvalds/linux/commit/7e78c597c3ebfd0cb329aa09a838734147e4f117","https://lists.openwall.net/netdev/2021/08/17/124","https://security.netapp.com/advisory/ntap-20220407-0007/","https://www.openwall.com/lists/oss-security/2021/08/27/2","https://www.oracle.com/security-alerts/cpujul2022.html","https://bugzilla.redhat.com/show_bug.cgi?id=1997961","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=7e78c597c3eb","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e78c597c3ebfd0cb329aa09a838734147e4f117","https://github.com/torvalds/linux/commit/7e78c597c3ebfd0cb329aa09a838734147e4f117","https://lists.openwall.net/netdev/2021/08/17/124","https://security.netapp.com/advisory/ntap-20220407-0007/","https://www.openwall.com/lists/oss-security/2021/08/27/2","https://www.oracle.com/security-alerts/cpujul2022.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-45863
|
Medium |
fixed |
|
An issue was discovered in lib/kobject.c in the Linux kernel before 6.2.3. With root access, an attacker can trigger a race condition that results in a fill_kobj_path out-of-bounds write. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.3","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3bb2a01caa813d3a1845d378bbe4169ef280d394","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.3","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3bb2a01caa813d3a1845d378bbe4169ef280d394","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52598
|
High |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
s390/ptrace: handle setting of fpc register correctly
If the content of the floating point control (fpc) register of a traced
process is modified with the ptrace interface the new value is tested for
validity by temporarily loading it into the fpc register.
This may lead to corruption of the fpc register of the tracing process:
if an interrupt happens while the value is temporarily loaded into the
fpc register, and within interrupt context floating point or vector
registers are used, the current fp/vx registers are saved with
save_fpu_regs() assuming they belong to user space and will be loaded into
fp/vx registers when returning to user space.
test_fp_ctl() restores the original user space fpc register value, however
it will be discarded, when returning to user space.
In result the tracer will incorrectly continue to run with the value that
was supposed to be used for the traced process.
Fix this by saving fpu register contents with save_fpu_regs() before using
test_fp_ctl(). |
["https://git.kernel.org/stable/c/02c6bbfb08bad78dd014e24c7b893723c15ec7a1","https://git.kernel.org/stable/c/28a1f492cb527f64593457a0a0f0d809b3f36c25","https://git.kernel.org/stable/c/6ccf904aac0292e1f6b1a1be6c407c414f7cf713","https://git.kernel.org/stable/c/6d0822f2cc9b153bf2df49a84599195a2e0d21a8","https://git.kernel.org/stable/c/7a4d6481fbdd661f9e40e95febb95e3dee82bad3","https://git.kernel.org/stable/c/856caf2730ea18cb39e95833719c02a02447dc0a","https://git.kernel.org/stable/c/8b13601d19c541158a6e18b278c00ba69ae37829","https://git.kernel.org/stable/c/bdce67df7f12fb0409fbc604ce7c4254703f56d4","https://git.kernel.org/stable/c/02c6bbfb08bad78dd014e24c7b893723c15ec7a1","https://git.kernel.org/stable/c/28a1f492cb527f64593457a0a0f0d809b3f36c25","https://git.kernel.org/stable/c/6ccf904aac0292e1f6b1a1be6c407c414f7cf713","https://git.kernel.org/stable/c/6d0822f2cc9b153bf2df49a84599195a2e0d21a8","https://git.kernel.org/stable/c/7a4d6481fbdd661f9e40e95febb95e3dee82bad3","https://git.kernel.org/stable/c/856caf2730ea18cb39e95833719c02a02447dc0a","https://git.kernel.org/stable/c/8b13601d19c541158a6e18b278c00ba69ae37829","https://git.kernel.org/stable/c/bdce67df7f12fb0409fbc604ce7c4254703f56d4","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3141
|
High |
fixed |
- 4.14.316
- 4.19.284
- 5.4.244
- 5.10.181
- 5.15.113
- 6.1.30
- 6.3.4
|
A use-after-free flaw was found in r592_remove in drivers/memstick/host/r592.c in media access in the Linux Kernel. This flaw allows a local attacker to crash the system at device disconnect, possibly leading to a kernel information leak. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=63264422785021704c39b38f65a78ab9e4a186d7","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/lkml/CAPDyKFoV9aZObZ5GBm0U_-UVeVkBN_rAG-kH3BKoP4EXdYM4bw%40mail.gmail.com/t/","https://security.netapp.com/advisory/ntap-20230706-0004/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=63264422785021704c39b38f65a78ab9e4a186d7","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/lkml/CAPDyKFoV9aZObZ5GBm0U_-UVeVkBN_rAG-kH3BKoP4EXdYM4bw%40mail.gmail.com/t/","https://security.netapp.com/advisory/ntap-20230706-0004/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52628
|
High |
fixed |
- 5.10.198
- 5.15.132
- 6.1.54
- 6.5.4
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: exthdr: fix 4-byte stack OOB write
If priv->len is a multiple of 4, then dst[len / 4] can write past
the destination array which leads to stack corruption.
This construct is necessary to clean the remainder of the register
in case ->len is NOT a multiple of the register size, so make it
conditional just like nft_payload.c does.
The bug was added in 4.1 cycle and then copied/inherited when
tcp/sctp and ip option support was added.
Bug reported by Zero Day Initiative project (ZDI-CAN-21950,
ZDI-CAN-21951, ZDI-CAN-21961). |
["https://git.kernel.org/stable/c/1ad7b189cc1411048434e8595ffcbe7873b71082","https://git.kernel.org/stable/c/28a97c43c9e32f437ebb8d6126f9bb7f3ca9521a","https://git.kernel.org/stable/c/a7d86a77c33ba1c357a7504341172cc1507f0698","https://git.kernel.org/stable/c/c8f292322ff16b9a2272a67de396c09a50e09dce","https://git.kernel.org/stable/c/cf39c4f77a773a547ac2bcf30ecdd303bb0c80cb","https://git.kernel.org/stable/c/d9ebfc0f21377690837ebbd119e679243e0099cc","https://git.kernel.org/stable/c/fd94d9dadee58e09b49075240fe83423eb1dcd36","https://git.kernel.org/stable/c/1ad7b189cc1411048434e8595ffcbe7873b71082","https://git.kernel.org/stable/c/28a97c43c9e32f437ebb8d6126f9bb7f3ca9521a","https://git.kernel.org/stable/c/a7d86a77c33ba1c357a7504341172cc1507f0698","https://git.kernel.org/stable/c/c8f292322ff16b9a2272a67de396c09a50e09dce","https://git.kernel.org/stable/c/cf39c4f77a773a547ac2bcf30ecdd303bb0c80cb","https://git.kernel.org/stable/c/d9ebfc0f21377690837ebbd119e679243e0099cc","https://git.kernel.org/stable/c/fd94d9dadee58e09b49075240fe83423eb1dcd36"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26665
|
High |
fixed |
- 5.10.210
- 5.15.149
- 6.1.78
- 6.6.17
- 6.7.5
|
In the Linux kernel, the following vulnerability has been resolved:
tunnels: fix out of bounds access when building IPv6 PMTU error
If the ICMPv6 error is built from a non-linear skb we get the following
splat,
BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240
Read of size 4 at addr ffff88811d402c80 by task netperf/820
CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543
...
kasan_report+0xd8/0x110
do_csum+0x220/0x240
csum_partial+0xc/0x20
skb_tunnel_check_pmtu+0xeb9/0x3280
vxlan_xmit_one+0x14c2/0x4080
vxlan_xmit+0xf61/0x5c00
dev_hard_start_xmit+0xfb/0x510
__dev_queue_xmit+0x7cd/0x32a0
br_dev_queue_push_xmit+0x39d/0x6a0
Use skb_checksum instead of csum_partial who cannot deal with non-linear
SKBs. |
["https://git.kernel.org/stable/c/510c869ffa4068c5f19ff4df51d1e2f3a30aaac1","https://git.kernel.org/stable/c/7dc9feb8b1705cf00de20563b6bc4831f4c99dab","https://git.kernel.org/stable/c/d75abeec401f8c86b470e7028a13fcdc87e5dd06","https://git.kernel.org/stable/c/d964dd1bc1452594b4207d9229c157d9386e5d8a","https://git.kernel.org/stable/c/e37cde7a5716466ff2a76f7f27f0a29b05b9a732","https://git.kernel.org/stable/c/e77bf828f1ca1c47fcff58bdc26b60a9d3dfbe1d","https://git.kernel.org/stable/c/510c869ffa4068c5f19ff4df51d1e2f3a30aaac1","https://git.kernel.org/stable/c/7dc9feb8b1705cf00de20563b6bc4831f4c99dab","https://git.kernel.org/stable/c/d75abeec401f8c86b470e7028a13fcdc87e5dd06","https://git.kernel.org/stable/c/d964dd1bc1452594b4207d9229c157d9386e5d8a","https://git.kernel.org/stable/c/e37cde7a5716466ff2a76f7f27f0a29b05b9a732","https://git.kernel.org/stable/c/e77bf828f1ca1c47fcff58bdc26b60a9d3dfbe1d","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52507
|
High |
fixed |
- 4.14.328
- 4.19.297
- 5.4.259
- 5.10.199
- 5.15.136
- 6.1.59
- 6.5.8
|
In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: assert requested protocol is valid
The protocol is used in a bit mask to determine if the protocol is
supported. Assert the provided protocol is less than the maximum
defined so it doesn't potentially perform a shift-out-of-bounds and
provide a clearer error for undefined protocols vs unsupported ones. |
["https://git.kernel.org/stable/c/25dd54b95abfdca423b65a4ee620a774777d8213","https://git.kernel.org/stable/c/2c231a247a1d1628e41fa1eefd1a5307c41c5f53","https://git.kernel.org/stable/c/354a6e707e29cb0c007176ee5b8db8be7bd2dee0","https://git.kernel.org/stable/c/6584eba7688dcf999542778b07f63828c21521da","https://git.kernel.org/stable/c/853dda54ba59ea70d5580a298b7ede4707826848","https://git.kernel.org/stable/c/95733ea130e35ef9ec5949a5908dde3feaba92cb","https://git.kernel.org/stable/c/a424807d860ba816aaafc3064b46b456361c0802","https://git.kernel.org/stable/c/a686f84101680b8442181a8846fbd3c934653729","https://git.kernel.org/stable/c/25dd54b95abfdca423b65a4ee620a774777d8213","https://git.kernel.org/stable/c/2c231a247a1d1628e41fa1eefd1a5307c41c5f53","https://git.kernel.org/stable/c/354a6e707e29cb0c007176ee5b8db8be7bd2dee0","https://git.kernel.org/stable/c/6584eba7688dcf999542778b07f63828c21521da","https://git.kernel.org/stable/c/853dda54ba59ea70d5580a298b7ede4707826848","https://git.kernel.org/stable/c/95733ea130e35ef9ec5949a5908dde3feaba92cb","https://git.kernel.org/stable/c/a424807d860ba816aaafc3064b46b456361c0802","https://git.kernel.org/stable/c/a686f84101680b8442181a8846fbd3c934653729"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26673
|
High |
fixed |
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations
- Disallow families other than NFPROTO_{IPV4,IPV6,INET}.
- Disallow layer 4 protocol with no ports, since destination port is a
mandatory attribute for this object. |
["https://git.kernel.org/stable/c/0f501dae16b7099e69ee9b0d5c70b8f40fd30e98","https://git.kernel.org/stable/c/38cc1605338d99205a263707f4dde76408d3e0e8","https://git.kernel.org/stable/c/65ee90efc928410c6f73b3d2e0afdd762652c09d","https://git.kernel.org/stable/c/8059918a1377f2f1fff06af4f5a4ed3d5acd6bc4","https://git.kernel.org/stable/c/b775ced05489f4b77a35fe203e9aeb22f428e38f","https://git.kernel.org/stable/c/cfe3550ea5df292c9e2d608e8c4560032391847e","https://git.kernel.org/stable/c/f549f340c91f08b938d60266e792ff7748dae483","https://git.kernel.org/stable/c/0f501dae16b7099e69ee9b0d5c70b8f40fd30e98","https://git.kernel.org/stable/c/38cc1605338d99205a263707f4dde76408d3e0e8","https://git.kernel.org/stable/c/65ee90efc928410c6f73b3d2e0afdd762652c09d","https://git.kernel.org/stable/c/8059918a1377f2f1fff06af4f5a4ed3d5acd6bc4","https://git.kernel.org/stable/c/b775ced05489f4b77a35fe203e9aeb22f428e38f","https://git.kernel.org/stable/c/cfe3550ea5df292c9e2d608e8c4560032391847e","https://git.kernel.org/stable/c/f549f340c91f08b938d60266e792ff7748dae483","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26791
|
High |
fixed |
- 4.19.309
- 5.4.271
- 5.10.212
- 5.15.151
- 6.1.81
- 6.6.21
- 6.7.9
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: dev-replace: properly validate device names
There's a syzbot report that device name buffers passed to device
replace are not properly checked for string termination which could lead
to a read out of bounds in getname_kernel().
Add a helper that validates both source and target device name buffers.
For devid as the source initialize the buffer to empty string in case
something tries to read it later.
This was originally analyzed and fixed in a different way by Edward Adam
Davis (see links). |
["https://git.kernel.org/stable/c/11d7a2e429c02d51e2dc90713823ea8b8d3d3a84","https://git.kernel.org/stable/c/2886fe308a83968dde252302884a1e63351cf16d","https://git.kernel.org/stable/c/343eecb4ff49a7b1cc1dfe86958a805cf2341cfb","https://git.kernel.org/stable/c/9845664b9ee47ce7ee7ea93caf47d39a9d4552c4","https://git.kernel.org/stable/c/ab2d68655d0f04650bef09fee948ff80597c5fb9","https://git.kernel.org/stable/c/b1690ced4d2d8b28868811fb81cd33eee5aefee1","https://git.kernel.org/stable/c/c6652e20d7d783d060fe5f987eac7b5cabe31311","https://git.kernel.org/stable/c/f590040ce2b712177306b03c2a63b16f7d48d3c8","https://git.kernel.org/stable/c/11d7a2e429c02d51e2dc90713823ea8b8d3d3a84","https://git.kernel.org/stable/c/2886fe308a83968dde252302884a1e63351cf16d","https://git.kernel.org/stable/c/343eecb4ff49a7b1cc1dfe86958a805cf2341cfb","https://git.kernel.org/stable/c/9845664b9ee47ce7ee7ea93caf47d39a9d4552c4","https://git.kernel.org/stable/c/ab2d68655d0f04650bef09fee948ff80597c5fb9","https://git.kernel.org/stable/c/b1690ced4d2d8b28868811fb81cd33eee5aefee1","https://git.kernel.org/stable/c/c6652e20d7d783d060fe5f987eac7b5cabe31311","https://git.kernel.org/stable/c/f590040ce2b712177306b03c2a63b16f7d48d3c8","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-39192
|
Medium |
fixed |
|
A flaw was found in the Netfilter subsystem in the Linux kernel. The xt_u32 module did not validate the fields in the xt_u32 structure. This flaw allows a local privileged attacker to trigger an out-of-bounds read by setting the size fields with a value beyond the array boundaries, leading to a crash or information disclosure. |
["https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-39192","https://bugzilla.redhat.com/show_bug.cgi?id=2226784","https://www.zerodayinitiative.com/advisories/ZDI-CAN-18408/","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-39192","https://bugzilla.redhat.com/show_bug.cgi?id=2226784","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.zerodayinitiative.com/advisories/ZDI-CAN-18408/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1855
|
Medium |
fixed |
- 4.14.311
- 4.19.279
- 5.4.238
- 5.10.176
- 5.15.104
- 6.1.21
- 6.2.8
- 6.3
|
A use-after-free flaw was found in xgene_hwmon_remove in drivers/hwmon/xgene-hwmon.c in the Hardware Monitoring Linux Kernel Driver (xgene-hwmon). This flaw could allow a local attacker to crash the system due to a race problem. This vulnerability could even lead to a kernel information leak problem. |
["https://github.com/torvalds/linux/commit/cb090e64cf25602b9adaf32d5dfc9c8bec493cd1","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20230318122758.2140868-1-linux%40roeck-us.net/","https://github.com/torvalds/linux/commit/cb090e64cf25602b9adaf32d5dfc9c8bec493cd1","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20230318122758.2140868-1-linux%40roeck-us.net/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-0160
|
Medium |
fixed |
|
A deadlock flaw was found in the Linux kernel’s BPF subsystem. This flaw allows a local user to potentially crash the system. |
["https://access.redhat.com/security/cve/CVE-2023-0160","https://bugzilla.redhat.com/show_bug.cgi?id=2159764","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ed17aa92dc56","https://lore.kernel.org/all/CABcoxUayum5oOqFMMqAeWuS8+EzojquSOSyDA3J_2omY=2EeAg@mail.gmail.com/","https://access.redhat.com/security/cve/CVE-2023-0160","https://bugzilla.redhat.com/show_bug.cgi?id=2159764","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ed17aa92dc56","https://lore.kernel.org/all/CABcoxUayum5oOqFMMqAeWuS8+EzojquSOSyDA3J_2omY=2EeAg@mail.gmail.com/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-0775
|
High |
fixed |
|
A use-after-free flaw was found in the __ext4_remount in fs/ext4/super.c in ext4 in the Linux kernel. This flaw allows a local user to cause an information leak problem while freeing the old quota file names before a potential failure, leading to a use-after-free. |
["https://access.redhat.com/security/cve/CVE-2024-0775","https://bugzilla.redhat.com/show_bug.cgi?id=2259414","https://scm.linefinity.com/common/linux-stable/commit/4c0b4818b1f636bc96359f7817a2d8bab6370162","https://access.redhat.com/security/cve/CVE-2024-0775","https://bugzilla.redhat.com/show_bug.cgi?id=2259414","https://scm.linefinity.com/common/linux-stable/commit/4c0b4818b1f636bc96359f7817a2d8bab6370162"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-33981
|
Low |
fixed |
|
drivers/block/floppy.c in the Linux kernel before 5.17.6 is vulnerable to a denial of service, because of a concurrency use-after-free flaw after deallocating raw_cmd in the raw_cmd_ioctl function. |
["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.6","https://exchange.xforce.ibmcloud.com/vulnerabilities/225362","https://github.com/torvalds/linux/commit/233087ca063686964a53c829d547c7571e3f67bf","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://seclists.org/oss-sec/2022/q2/66","https://www.debian.org/security/2022/dsa-5173","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.6","https://exchange.xforce.ibmcloud.com/vulnerabilities/225362","https://github.com/torvalds/linux/commit/233087ca063686964a53c829d547c7571e3f67bf","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://seclists.org/oss-sec/2022/q2/66","https://www.debian.org/security/2022/dsa-5173"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3772
|
Medium |
|
N/A
|
A flaw was found in the Linux kernel’s IP framework for transforming packets (XFRM subsystem). This issue may allow a malicious user with CAP_NET_ADMIN privileges to directly dereference a NULL pointer in xfrm_update_ae_params(), leading to a possible kernel crash and denial of service. |
["https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/errata/RHSA-2023:6901","https://access.redhat.com/errata/RHSA-2023:7077","https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:0575","https://access.redhat.com/security/cve/CVE-2023-3772","https://bugzilla.redhat.com/show_bug.cgi?id=2218943","http://www.openwall.com/lists/oss-security/2023/08/10/1","http://www.openwall.com/lists/oss-security/2023/08/10/3","https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/errata/RHSA-2023:6901","https://access.redhat.com/errata/RHSA-2023:7077","https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:0575","https://access.redhat.com/security/cve/CVE-2023-3772","https://bugzilla.redhat.com/show_bug.cgi?id=2218943","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.debian.org/security/2023/dsa-5492"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-0459
|
Medium |
fixed |
- 4.14.307
- 4.19.274
- 5.4.233
- 5.10.170
- 5.15.96
- 6.1.14
- 6.2.1
|
Copy_from_user on 64-bit versions of the Linux kernel does not implement the __uaccess_begin_nospec allowing a user to bypass the "access_ok" check and pass a kernel pointer to copy_from_user(). This would allow an attacker to leak information. We recommend upgrading beyond commit 74e19ef0ff8061ef55957c3abd71614ef0f42f47 |
["https://github.com/torvalds/linux/commit/4b842e4e25b12951fa10dedb4bc16bc47e3b850c","https://github.com/torvalds/linux/commit/74e19ef0ff8061ef55957c3abd71614ef0f42f47","https://github.com/torvalds/linux/commit/4b842e4e25b12951fa10dedb4bc16bc47e3b850c","https://github.com/torvalds/linux/commit/74e19ef0ff8061ef55957c3abd71614ef0f42f47"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-46862
|
Medium |
|
N/A
|
An issue was discovered in the Linux kernel through 6.5.9. During a race with SQ thread exit, an io_uring/fdinfo.c io_uring_show_fdinfo NULL pointer dereference can occur. |
["https://bugzilla.kernel.org/show_bug.cgi?id=218032#c4","https://github.com/torvalds/linux/commit/7644b1a1c9a7ae8ab99175989bfc8676055edb46","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://bugzilla.kernel.org/show_bug.cgi?id=218032#c4","https://github.com/torvalds/linux/commit/7644b1a1c9a7ae8ab99175989bfc8676055edb46","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-6176
|
Medium |
|
N/A
|
A null pointer dereference flaw was found in the Linux kernel API for the cryptographic algorithm scatterwalk functionality. This issue occurs when a user constructs a malicious packet with specific socket configuration, which could allow a local user to crash the system or escalate their privileges on the system. |
["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-6176","https://bugzilla.redhat.com/show_bug.cgi?id=2219359","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cfaa80c91f6f99b9342b6557f0f0e1143e434066","http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-6176","https://bugzilla.redhat.com/show_bug.cgi?id=2219359","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cfaa80c91f6f99b9342b6557f0f0e1143e434066"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52643
|
Medium |
fixed |
- 5.15.149
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
iio: core: fix memleak in iio_device_register_sysfs
When iio_device_register_sysfs_group() fails, we should
free iio_dev_opaque->chan_attr_group.attrs to prevent
potential memleak. |
["https://git.kernel.org/stable/c/1c6d19c8cbf6abcea2c8fca2db26abca2cbf0363","https://git.kernel.org/stable/c/359f220d0e753bba840eac19ffedcdc816b532f2","https://git.kernel.org/stable/c/3db312e06851996e7fb27cb5a8ccab4c0f9cdb93","https://git.kernel.org/stable/c/95a0d596bbd0552a78e13ced43f2be1038883c81","https://git.kernel.org/stable/c/b90126c86d83912688501826643ea698f0df1728","https://git.kernel.org/stable/c/1c6d19c8cbf6abcea2c8fca2db26abca2cbf0363","https://git.kernel.org/stable/c/359f220d0e753bba840eac19ffedcdc816b532f2","https://git.kernel.org/stable/c/3db312e06851996e7fb27cb5a8ccab4c0f9cdb93","https://git.kernel.org/stable/c/95a0d596bbd0552a78e13ced43f2be1038883c81","https://git.kernel.org/stable/c/b90126c86d83912688501826643ea698f0df1728"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26838
|
Medium |
fixed |
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/irdma: Fix KASAN issue with tasklet
KASAN testing revealed the following issue assocated with freeing an IRQ.
[50006.466686] Call Trace:
[50006.466691] <IRQ>
[50006.489538] dump_stack+0x5c/0x80
[50006.493475] print_address_description.constprop.6+0x1a/0x150
[50006.499872] ? irdma_sc_process_ceq+0x483/0x790 [irdma]
[50006.505742] ? irdma_sc_process_ceq+0x483/0x790 [irdma]
[50006.511644] kasan_report.cold.11+0x7f/0x118
[50006.516572] ? irdma_sc_process_ceq+0x483/0x790 [irdma]
[50006.522473] irdma_sc_process_ceq+0x483/0x790 [irdma]
[50006.528232] irdma_process_ceq+0xb2/0x400 [irdma]
[50006.533601] ? irdma_hw_flush_wqes_callback+0x370/0x370 [irdma]
[50006.540298] irdma_ceq_dpc+0x44/0x100 [irdma]
[50006.545306] tasklet_action_common.isra.14+0x148/0x2c0
[50006.551096] __do_softirq+0x1d0/0xaf8
[50006.555396] irq_exit_rcu+0x219/0x260
[50006.559670] irq_exit+0xa/0x20
[50006.563320] smp_apic_timer_interrupt+0x1bf/0x690
[50006.568645] apic_timer_interrupt+0xf/0x20
[50006.573341] </IRQ>
The issue is that a tasklet could be pending on another core racing
the delete of the irq.
Fix by insuring any scheduled tasklet is killed after deleting the
irq. |
["https://git.kernel.org/stable/c/0ae8ad0013978f7471f22bcf45b027393e87f5dc","https://git.kernel.org/stable/c/635d79aa477f9912e602feb5498bdd51fb9cb824","https://git.kernel.org/stable/c/b2e4a5266e3d133b4c7f0e43bf40d13ce14fd1aa","https://git.kernel.org/stable/c/bd97cea7b18a0a553773af806dfbfac27a7c4acb","https://git.kernel.org/stable/c/c6f1ca235f68b22b3e691b2ea87ac285e5946848","https://git.kernel.org/stable/c/0ae8ad0013978f7471f22bcf45b027393e87f5dc","https://git.kernel.org/stable/c/635d79aa477f9912e602feb5498bdd51fb9cb824","https://git.kernel.org/stable/c/b2e4a5266e3d133b4c7f0e43bf40d13ce14fd1aa","https://git.kernel.org/stable/c/bd97cea7b18a0a553773af806dfbfac27a7c4acb","https://git.kernel.org/stable/c/c6f1ca235f68b22b3e691b2ea87ac285e5946848"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26661
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()'
In "u32 otg_inst = pipe_ctx->stream_res.tg->inst;"
pipe_ctx->stream_res.tg could be NULL, it is relying on the caller to
ensure the tg is not NULL. |
["https://git.kernel.org/stable/c/39f24c08363af1cd945abad84e3c87fd3e3c845a","https://git.kernel.org/stable/c/3f3c237a706580326d3b7a1b97697e5031ca4667","https://git.kernel.org/stable/c/66951d98d9bf45ba25acf37fe0747253fafdf298","https://git.kernel.org/stable/c/39f24c08363af1cd945abad84e3c87fd3e3c845a","https://git.kernel.org/stable/c/3f3c237a706580326d3b7a1b97697e5031ca4667","https://git.kernel.org/stable/c/66951d98d9bf45ba25acf37fe0747253fafdf298"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26662
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix 'panel_cntl' could be null in 'dcn21_set_backlight_level()'
'panel_cntl' structure used to control the display panel could be null,
dereferencing it could lead to a null pointer access.
Fixes the below:
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn21/dcn21_hwseq.c:269 dcn21_set_backlight_level() error: we previously assumed 'panel_cntl' could be null (see line 250) |
["https://git.kernel.org/stable/c/0c863cab0e9173f8b6c7bc328bee3b8625f131b5","https://git.kernel.org/stable/c/2e150ccea13129eb048679114808eb9770443e4d","https://git.kernel.org/stable/c/e96fddb32931d007db12b1fce9b5e8e4c080401b","https://git.kernel.org/stable/c/0c863cab0e9173f8b6c7bc328bee3b8625f131b5","https://git.kernel.org/stable/c/2e150ccea13129eb048679114808eb9770443e4d","https://git.kernel.org/stable/c/e96fddb32931d007db12b1fce9b5e8e4c080401b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-42754
|
Medium |
fixed |
|
A NULL pointer dereference flaw was found in the Linux kernel ipv4 stack. The socket buffer (skb) was assumed to be associated with a device before calling __ip_options_compile, which is not always the case if the skb is re-routed by ipvs. This issue may allow a local user with CAP_NET_ADMIN privileges to crash the system. |
["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-42754","https://bugzilla.redhat.com/show_bug.cgi?id=2239845","https://seclists.org/oss-sec/2023/q4/14","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-42754","https://bugzilla.redhat.com/show_bug.cgi?id=2239845","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GISYSL3F6WIEVGHJGLC2MFNTUXHPTKQH/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GPMICQ2HVZO5UAM5KPXHAZKA2U3ZDOO6/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/V5PDNWPKAP3WL5RQZ4RIDS6MG32OHH5R/","https://seclists.org/oss-sec/2023/q4/14"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26717
|
Medium |
fixed |
- 5.15.149
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
HID: i2c-hid-of: fix NULL-deref on failed power up
A while back the I2C HID implementation was split in an ACPI and OF
part, but the new OF driver never initialises the client pointer which
is dereferenced on power-up failures. |
["https://git.kernel.org/stable/c/00aab7dcb2267f2aef59447602f34501efe1a07f","https://git.kernel.org/stable/c/4cad91344a62536a2949873bad6365fbb6232776","https://git.kernel.org/stable/c/62f5d219edbd174829aa18d4b3d97cd5fefbb783","https://git.kernel.org/stable/c/d7d7a0e3b6f5adc45f23667cbb919e99093a5b5c","https://git.kernel.org/stable/c/e28d6b63aeecbda450935fb58db0e682ea8212d3","https://git.kernel.org/stable/c/00aab7dcb2267f2aef59447602f34501efe1a07f","https://git.kernel.org/stable/c/4cad91344a62536a2949873bad6365fbb6232776","https://git.kernel.org/stable/c/62f5d219edbd174829aa18d4b3d97cd5fefbb783","https://git.kernel.org/stable/c/d7d7a0e3b6f5adc45f23667cbb919e99093a5b5c","https://git.kernel.org/stable/c/e28d6b63aeecbda450935fb58db0e682ea8212d3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26774
|
Medium |
fixed |
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid dividing by 0 in mb_update_avg_fragment_size() when block bitmap corrupt
Determine if bb_fragments is 0 instead of determining bb_free to eliminate
the risk of dividing by zero when the block bitmap is corrupted. |
["https://git.kernel.org/stable/c/687061cfaa2ac3095170e136dd9c29a4974f41d4","https://git.kernel.org/stable/c/8b40eb2e716b503f7a4e1090815a17b1341b2150","https://git.kernel.org/stable/c/8cf9cc602cfb40085967c0d140e32691c8b71cf3","https://git.kernel.org/stable/c/993bf0f4c393b3667830918f9247438a8f6fdb5b","https://git.kernel.org/stable/c/f32d2a745b02123258026e105a008f474f896d6a","https://git.kernel.org/stable/c/687061cfaa2ac3095170e136dd9c29a4974f41d4","https://git.kernel.org/stable/c/8b40eb2e716b503f7a4e1090815a17b1341b2150","https://git.kernel.org/stable/c/8cf9cc602cfb40085967c0d140e32691c8b71cf3","https://git.kernel.org/stable/c/993bf0f4c393b3667830918f9247438a8f6fdb5b","https://git.kernel.org/stable/c/f32d2a745b02123258026e105a008f474f896d6a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26803
|
Medium |
fixed |
- 5.15.151
- 6.1.81
- 6.6.21
- 6.7.9
|
In the Linux kernel, the following vulnerability has been resolved:
net: veth: clear GRO when clearing XDP even when down
veth sets NETIF_F_GRO automatically when XDP is enabled,
because both features use the same NAPI machinery.
The logic to clear NETIF_F_GRO sits in veth_disable_xdp() which
is called both on ndo_stop and when XDP is turned off.
To avoid the flag from being cleared when the device is brought
down, the clearing is skipped when IFF_UP is not set.
Bringing the device down should indeed not modify its features.
Unfortunately, this means that clearing is also skipped when
XDP is disabled _while_ the device is down. And there's nothing
on the open path to bring the device features back into sync.
IOW if user enables XDP, disables it and then brings the device
up we'll end up with a stray GRO flag set but no NAPI instances.
We don't depend on the GRO flag on the datapath, so the datapath
won't crash. We will crash (or hang), however, next time features
are sync'ed (either by user via ethtool or peer changing its config).
The GRO flag will go away, and veth will try to disable the NAPIs.
But the open path never created them since XDP was off, the GRO flag
was a stray. If NAPI was initialized before we'll hang in napi_disable().
If it never was we'll crash trying to stop uninitialized hrtimer.
Move the GRO flag updates to the XDP enable / disable paths,
instead of mixing them with the ndo_open / ndo_close paths. |
["https://git.kernel.org/stable/c/16edf51f33f52dff70ed455bc40a6cc443c04664","https://git.kernel.org/stable/c/7985d73961bbb4e726c1be7b9cd26becc7be8325","https://git.kernel.org/stable/c/8f7a3894e58e6f5d5815533cfde60e3838947941","https://git.kernel.org/stable/c/f011c103e654d83dc85f057a7d1bd0960d02831c","https://git.kernel.org/stable/c/fe9f801355f0b47668419f30f1fac1cf4539e736","https://git.kernel.org/stable/c/16edf51f33f52dff70ed455bc40a6cc443c04664","https://git.kernel.org/stable/c/7985d73961bbb4e726c1be7b9cd26becc7be8325","https://git.kernel.org/stable/c/8f7a3894e58e6f5d5815533cfde60e3838947941","https://git.kernel.org/stable/c/f011c103e654d83dc85f057a7d1bd0960d02831c","https://git.kernel.org/stable/c/fe9f801355f0b47668419f30f1fac1cf4539e736"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3114
|
Medium |
fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. imx_register_uart_clocks in drivers/clk/imx/clk.c lacks check of the return value of kcalloc() and will cause the null pointer dereference. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2153054","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=ed713e2bc093239ccd380c2ce8ae9e4162f5c037","https://bugzilla.redhat.com/show_bug.cgi?id=2153054","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=ed713e2bc093239ccd380c2ce8ae9e4162f5c037"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52532
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: mana: Fix TX CQE error handling
For an unknown TX CQE error type (probably from a newer hardware),
still free the SKB, update the queue tail, etc., otherwise the
accounting will be wrong.
Also, TX errors can be triggered by injecting corrupted packets, so
replace the WARN_ONCE to ratelimited error logging. |
["https://git.kernel.org/stable/c/a910e0f6304726da30a212feecec65cb97ff7a80","https://git.kernel.org/stable/c/b2b000069a4c307b09548dc2243f31f3ca0eac9c","https://git.kernel.org/stable/c/b67d7b1bfc46d05c1a58b172516454698e8d5004","https://git.kernel.org/stable/c/a910e0f6304726da30a212feecec65cb97ff7a80","https://git.kernel.org/stable/c/b2b000069a4c307b09548dc2243f31f3ca0eac9c","https://git.kernel.org/stable/c/b67d7b1bfc46d05c1a58b172516454698e8d5004"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-6679
|
Medium |
|
N/A
|
A null pointer dereference vulnerability was found in dpll_pin_parent_pin_set() in drivers/dpll/dpll_netlink.c in the Digital Phase Locked Loop (DPLL) subsystem in the Linux kernel. This issue could be exploited to trigger a denial of service. |
["https://access.redhat.com/errata/RHSA-2024:0439","https://access.redhat.com/errata/RHSA-2024:0448","https://access.redhat.com/errata/RHSA-2024:0461","https://access.redhat.com/security/cve/CVE-2023-6679","https://bugzilla.redhat.com/show_bug.cgi?id=2253986","https://lore.kernel.org/netdev/20231211083758.1082853-1-jiri@resnulli.us/","https://access.redhat.com/errata/RHSA-2024:0439","https://access.redhat.com/errata/RHSA-2024:0448","https://access.redhat.com/errata/RHSA-2024:0461","https://access.redhat.com/security/cve/CVE-2023-6679","https://bugzilla.redhat.com/show_bug.cgi?id=2253986","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7LSPIOMIJYTLZB6QKPQVVAYSUETUWKPF/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/LBVHM4LGMFIHBN4UBESYRFMYX3WUICV5/","https://lore.kernel.org/netdev/20231211083758.1082853-1-jiri@resnulli.us/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52448
|
Medium |
fixed |
- 5.4.268
- 5.10.209
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump
Syzkaller has reported a NULL pointer dereference when accessing
rgd->rd_rgl in gfs2_rgrp_dump(). This can happen when creating
rgd->rd_gl fails in read_rindex_entry(). Add a NULL pointer check in
gfs2_rgrp_dump() to prevent that. |
["https://git.kernel.org/stable/c/067a7c48c2c70f05f9460d6f0e8423e234729f05","https://git.kernel.org/stable/c/5c28478af371a1c3fdb570ca67f110e1ae60fc37","https://git.kernel.org/stable/c/8877243beafa7c6bfc42022cbfdf9e39b25bd4fa","https://git.kernel.org/stable/c/c323efd620c741168c8e0cc6fc0be04ab57e331a","https://git.kernel.org/stable/c/d69d7804cf9e2ba171a27e5f98bc266f13d0414a","https://git.kernel.org/stable/c/ee0586d73cbaf0e7058bc640d62a9daf2dfa9178","https://git.kernel.org/stable/c/efc8ef87ab9185a23d5676f2f7d986022d91bcde","https://git.kernel.org/stable/c/067a7c48c2c70f05f9460d6f0e8423e234729f05","https://git.kernel.org/stable/c/5c28478af371a1c3fdb570ca67f110e1ae60fc37","https://git.kernel.org/stable/c/8877243beafa7c6bfc42022cbfdf9e39b25bd4fa","https://git.kernel.org/stable/c/c323efd620c741168c8e0cc6fc0be04ab57e331a","https://git.kernel.org/stable/c/d69d7804cf9e2ba171a27e5f98bc266f13d0414a","https://git.kernel.org/stable/c/ee0586d73cbaf0e7058bc640d62a9daf2dfa9178","https://git.kernel.org/stable/c/efc8ef87ab9185a23d5676f2f7d986022d91bcde","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52476
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/lbr: Filter vsyscall addresses
We found that a panic can occur when a vsyscall is made while LBR sampling
is active. If the vsyscall is interrupted (NMI) for perf sampling, this
call sequence can occur (most recent at top):
__insn_get_emulate_prefix()
insn_get_emulate_prefix()
insn_get_prefixes()
insn_get_opcode()
decode_branch_type()
get_branch_type()
intel_pmu_lbr_filter()
intel_pmu_handle_irq()
perf_event_nmi_handler()
Within __insn_get_emulate_prefix() at frame 0, a macro is called:
peek_nbyte_next(insn_byte_t, insn, i)
Within this macro, this dereference occurs:
(insn)->next_byte
Inspecting registers at this point, the value of the next_byte field is the
address of the vsyscall made, for example the location of the vsyscall
version of gettimeofday() at 0xffffffffff600000. The access to an address
in the vsyscall region will trigger an oops due to an unhandled page fault.
To fix the bug, filtering for vsyscalls can be done when
determining the branch type. This patch will return
a "none" branch if a kernel address if found to lie in the
vsyscall region. |
["https://git.kernel.org/stable/c/3863989497652488a50f00e96de4331e5efabc6c","https://git.kernel.org/stable/c/403d201d1fd144cb249836dafb222f6375871c6c","https://git.kernel.org/stable/c/e53899771a02f798d436655efbd9d4b46c0f9265","https://git.kernel.org/stable/c/f71edacbd4f99c0e12fe4a4007ab4d687d0688db","https://git.kernel.org/stable/c/3863989497652488a50f00e96de4331e5efabc6c","https://git.kernel.org/stable/c/403d201d1fd144cb249836dafb222f6375871c6c","https://git.kernel.org/stable/c/e53899771a02f798d436655efbd9d4b46c0f9265","https://git.kernel.org/stable/c/f71edacbd4f99c0e12fe4a4007ab4d687d0688db"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52580
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net/core: Fix ETH_P_1588 flow dissector
When a PTP ethernet raw frame with a size of more than 256 bytes followed
by a 0xff pattern is sent to __skb_flow_dissect, nhoff value calculation
is wrong. For example: hdr->message_length takes the wrong value (0xffff)
and it does not replicate real header length. In this case, 'nhoff' value
was overridden and the PTP header was badly dissected. This leads to a
kernel crash.
net/core: flow_dissector
net/core flow dissector nhoff = 0x0000000e
net/core flow dissector hdr->message_length = 0x0000ffff
net/core flow dissector nhoff = 0x0001000d (u16 overflow)
...
skb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88
skb frag: 00000000: f7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Using the size of the ptp_header struct will allow the corrected
calculation of the nhoff value.
net/core flow dissector nhoff = 0x0000000e
net/core flow dissector nhoff = 0x00000030 (sizeof ptp_header)
...
skb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88 f7 ff ff
skb linear: 00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
skb linear: 00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
skb frag: 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Kernel trace:
[ 74.984279] ------------[ cut here ]------------
[ 74.989471] kernel BUG at include/linux/skbuff.h:2440!
[ 74.995237] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[ 75.001098] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U 5.15.85-intel-ese-standard-lts #1
[ 75.011629] Hardware name: Intel Corporation A-Island (CPU:AlderLake)/A-Island (ID:06), BIOS SB_ADLP.01.01.00.01.03.008.D-6A9D9E73-dirty Mar 30 2023
[ 75.026507] RIP: 0010:eth_type_trans+0xd0/0x130
[ 75.031594] Code: 03 88 47 78 eb c7 8b 47 68 2b 47 6c 48 8b 97 c0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb ab <0f> 0b b8 00 01 00 00 eb a2 48 85 ff 74 eb 48 8d 54 24 06 31 f6 b9
[ 75.052612] RSP: 0018:ffff9948c0228de0 EFLAGS: 00010297
[ 75.058473] RAX: 00000000000003f2 RBX: ffff8e47047dc300 RCX: 0000000000001003
[ 75.066462] RDX: ffff8e4e8c9ea040 RSI: ffff8e4704e0a000 RDI: ffff8e47047dc300
[ 75.074458] RBP: ffff8e4704e2acc0 R08: 00000000000003f3 R09: 0000000000000800
[ 75.082466] R10: 000000000000000d R11: ffff9948c0228dec R12: ffff8e4715e4e010
[ 75.090461] R13: ffff9948c0545018 R14: 0000000000000001 R15: 0000000000000800
[ 75.098464] FS: 0000000000000000(0000) GS:ffff8e4e8fb00000(0000) knlGS:0000000000000000
[ 75.107530] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 75.113982] CR2: 00007f5eb35934a0 CR3: 0000000150e0a002 CR4: 0000000000770ee0
[ 75.121980] PKRU: 55555554
[ 75.125035] Call Trace:
[ 75.127792] <IRQ>
[ 75.130063] ? eth_get_headlen+0xa4/0xc0
[ 75.134472] igc_process_skb_fields+0xcd/0x150
[ 75.139461] igc_poll+0xc80/0x17b0
[ 75.143272] __napi_poll+0x27/0x170
[ 75.147192] net_rx_action+0x234/0x280
[ 75.151409] __do_softirq+0xef/0x2f4
[ 75.155424] irq_exit_rcu+0xc7/0x110
[ 75.159432] common_interrupt+0xb8/0xd0
[ 75.163748] </IRQ>
[ 75.166112] <TASK>
[ 75.168473] asm_common_interrupt+0x22/0x40
[ 75.173175] RIP: 0010:cpuidle_enter_state+0xe2/0x350
[ 75.178749] Code: 85 c0 0f 8f 04 02 00 00 31 ff e8 39 6c 67 ff 45 84 ff 74 12 9c 58 f6 c4 02 0f 85 50 02 00 00 31 ff e8 52 b0 6d ff fb 45 85 f6 <0f> 88 b1 00 00 00 49 63 ce 4c 2b 2c 24 48 89 c8 48 6b d1 68 48 c1
[ 75.199757] RSP: 0018:ffff9948c013bea8 EFLAGS: 00000202
[ 75.205614] RAX: ffff8e4e8fb00000 RBX: ffffb948bfd23900 RCX: 000000000000001f
[ 75.213619] RDX: 0000000000000004 RSI: ffffffff94206161 RDI: ffffffff94212e20
[ 75.221620] RBP: 0000000000000004 R08: 000000117568973a R09: 0000000000000001
[ 75.229622] R10: 000000000000afc8 R11: ffff8e4e8fb29ce4 R12: ffffffff945ae980
[ 75.237628] R13: 000000117568973a R14: 0000000000000004 R15: 0000000000000000
[ 75.245635] ?
---truncated--- |
["https://git.kernel.org/stable/c/488ea2a3e2666022f79abfdd7d12e8305fc27a40","https://git.kernel.org/stable/c/48e105a2a1a10adc21c0ae717969f5e8e990ba48","https://git.kernel.org/stable/c/75ad80ed88a182ab2ad5513e448cf07b403af5c3","https://git.kernel.org/stable/c/f90a7b9586d72f907092078a9f394733ca502cc9","https://git.kernel.org/stable/c/488ea2a3e2666022f79abfdd7d12e8305fc27a40","https://git.kernel.org/stable/c/48e105a2a1a10adc21c0ae717969f5e8e990ba48","https://git.kernel.org/stable/c/75ad80ed88a182ab2ad5513e448cf07b403af5c3","https://git.kernel.org/stable/c/f90a7b9586d72f907092078a9f394733ca502cc9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52435
|
Medium |
fixed |
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.79
- 6.6.11
|
In the Linux kernel, the following vulnerability has been resolved:
net: prevent mss overflow in skb_segment()
Once again syzbot is able to crash the kernel in skb_segment() [1]
GSO_BY_FRAGS is a forbidden value, but unfortunately the following
computation in skb_segment() can reach it quite easily :
mss = mss * partial_segs;
65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead to
a bad final result.
Make sure to limit segmentation so that the new mss value is smaller
than GSO_BY_FRAGS.
[1]
general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
CPU: 1 PID: 5079 Comm: syz-executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551
Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00
RSP: 0018:ffffc900043473d0 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597
RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070
RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff
R10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0
R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046
FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109
ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120
skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53
__skb_gso_segment+0x339/0x710 net/core/gso.c:124
skb_gso_segment include/net/gso.h:83 [inline]
validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626
__dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
packet_xmit+0x257/0x380 net/packet/af_packet.c:276
packet_snd net/packet/af_packet.c:3087 [inline]
packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0xd5/0x180 net/socket.c:745
__sys_sendto+0x255/0x340 net/socket.c:2190
__do_sys_sendto net/socket.c:2202 [inline]
__se_sys_sendto net/socket.c:2198 [inline]
__x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
RIP: 0033:0x7f8692032aa9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 d1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fff8d685418 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9
RDX: 0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003
RBP: 00000000000f4240 R08: 0000000020000540 R09: 0000000000000014
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480
R13: 0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551
Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00
RSP: 0018:ffffc900043473d0 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597
RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070
RBP: ffffc90004347578 R0
---truncated--- |
["https://git.kernel.org/stable/c/0d3ffbbf8631d6db0552f46250015648991c856f","https://git.kernel.org/stable/c/23d05d563b7e7b0314e65c8e882bc27eac2da8e7","https://git.kernel.org/stable/c/6c53e8547687d9c767c139cd4b50af566f58c29a","https://git.kernel.org/stable/c/8f8f185643747fbb448de6aab0efa51c679909a3","https://git.kernel.org/stable/c/95b3904a261a9f810205da560e802cc326f50d77","https://git.kernel.org/stable/c/989b0ff35fe5fc9652ee5bafbe8483db6f27b137","https://git.kernel.org/stable/c/cd1022eaf87be8e6151435bd4df4c242c347e083","https://git.kernel.org/stable/c/23d05d563b7e7b0314e65c8e882bc27eac2da8e7","https://git.kernel.org/stable/c/6c53e8547687d9c767c139cd4b50af566f58c29a","https://git.kernel.org/stable/c/8f8f185643747fbb448de6aab0efa51c679909a3","https://git.kernel.org/stable/c/95b3904a261a9f810205da560e802cc326f50d77","https://git.kernel.org/stable/c/989b0ff35fe5fc9652ee5bafbe8483db6f27b137","https://git.kernel.org/stable/c/cd1022eaf87be8e6151435bd4df4c242c347e083","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52520
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: think-lmi: Fix reference leak
If a duplicate attribute is found using kset_find_obj(), a reference
to that attribute is returned which needs to be disposed accordingly
using kobject_put(). Move the setting name validation into a separate
function to allow for this change without having to duplicate the
cleanup code for this setting.
As a side note, a very similar bug was fixed in
commit 7295a996fdab ("platform/x86: dell-sysman: Fix reference leak"),
so it seems that the bug was copied from that driver.
Compile-tested only. |
["https://git.kernel.org/stable/c/124cf0ea4b82e1444ec8c7420af4e7db5558c293","https://git.kernel.org/stable/c/528ab3e605cabf2f9c9bd5944d3bfe15f6e94f81","https://git.kernel.org/stable/c/af21c9119a37cecb7ff27ce0c2f3cf721e9d0ec4","https://git.kernel.org/stable/c/c6e3023579de8d33256771ac0745239029e81106","https://git.kernel.org/stable/c/124cf0ea4b82e1444ec8c7420af4e7db5558c293","https://git.kernel.org/stable/c/528ab3e605cabf2f9c9bd5944d3bfe15f6e94f81","https://git.kernel.org/stable/c/af21c9119a37cecb7ff27ce0c2f3cf721e9d0ec4","https://git.kernel.org/stable/c/c6e3023579de8d33256771ac0745239029e81106"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52523
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Reject sk_msg egress redirects to non-TCP sockets
With a SOCKMAP/SOCKHASH map and an sk_msg program user can steer messages
sent from one TCP socket (s1) to actually egress from another TCP
socket (s2):
tcp_bpf_sendmsg(s1) // = sk_prot->sendmsg
tcp_bpf_send_verdict(s1) // __SK_REDIRECT case
tcp_bpf_sendmsg_redir(s2)
tcp_bpf_push_locked(s2)
tcp_bpf_push(s2)
tcp_rate_check_app_limited(s2) // expects tcp_sock
tcp_sendmsg_locked(s2) // ditto
There is a hard-coded assumption in the call-chain, that the egress
socket (s2) is a TCP socket.
However in commit 122e6c79efe1 ("sock_map: Update sock type checks for
UDP") we have enabled redirects to non-TCP sockets. This was done for the
sake of BPF sk_skb programs. There was no indention to support sk_msg
send-to-egress use case.
As a result, attempts to send-to-egress through a non-TCP socket lead to a
crash due to invalid downcast from sock to tcp_sock:
BUG: kernel NULL pointer dereference, address: 000000000000002f
...
Call Trace:
<TASK>
? show_regs+0x60/0x70
? __die+0x1f/0x70
? page_fault_oops+0x80/0x160
? do_user_addr_fault+0x2d7/0x800
? rcu_is_watching+0x11/0x50
? exc_page_fault+0x70/0x1c0
? asm_exc_page_fault+0x27/0x30
? tcp_tso_segs+0x14/0xa0
tcp_write_xmit+0x67/0xce0
__tcp_push_pending_frames+0x32/0xf0
tcp_push+0x107/0x140
tcp_sendmsg_locked+0x99f/0xbb0
tcp_bpf_push+0x19d/0x3a0
tcp_bpf_sendmsg_redir+0x55/0xd0
tcp_bpf_send_verdict+0x407/0x550
tcp_bpf_sendmsg+0x1a1/0x390
inet_sendmsg+0x6a/0x70
sock_sendmsg+0x9d/0xc0
? sockfd_lookup_light+0x12/0x80
__sys_sendto+0x10e/0x160
? syscall_enter_from_user_mode+0x20/0x60
? __this_cpu_preempt_check+0x13/0x20
? lockdep_hardirqs_on+0x82/0x110
__x64_sys_sendto+0x1f/0x30
do_syscall_64+0x38/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Reject selecting a non-TCP sockets as redirect target from a BPF sk_msg
program to prevent the crash. When attempted, user will receive an EACCES
error from send/sendto/sendmsg() syscall. |
["https://git.kernel.org/stable/c/b80e31baa43614e086a9d29dc1151932b1bd7fc5","https://git.kernel.org/stable/c/b8f97e47b6fb84fcf2f5a22e725eefb6cf5070c2","https://git.kernel.org/stable/c/bc8b89b6963803a123f64aa9494155a037b3d728","https://git.kernel.org/stable/c/ded6e448028f0f91b6af35985afca01fa02a9089","https://git.kernel.org/stable/c/b80e31baa43614e086a9d29dc1151932b1bd7fc5","https://git.kernel.org/stable/c/b8f97e47b6fb84fcf2f5a22e725eefb6cf5070c2","https://git.kernel.org/stable/c/bc8b89b6963803a123f64aa9494155a037b3d728","https://git.kernel.org/stable/c/ded6e448028f0f91b6af35985afca01fa02a9089"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52559
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Avoid memory allocation in iommu_suspend()
The iommu_suspend() syscore suspend callback is invoked with IRQ disabled.
Allocating memory with the GFP_KERNEL flag may re-enable IRQs during
the suspend callback, which can cause intermittent suspend/hibernation
problems with the following kernel traces:
Calling iommu_suspend+0x0/0x1d0
------------[ cut here ]------------
WARNING: CPU: 0 PID: 15 at kernel/time/timekeeping.c:868 ktime_get+0x9b/0xb0
...
CPU: 0 PID: 15 Comm: rcu_preempt Tainted: G U E 6.3-intel #r1
RIP: 0010:ktime_get+0x9b/0xb0
...
Call Trace:
<IRQ>
tick_sched_timer+0x22/0x90
? __pfx_tick_sched_timer+0x10/0x10
__hrtimer_run_queues+0x111/0x2b0
hrtimer_interrupt+0xfa/0x230
__sysvec_apic_timer_interrupt+0x63/0x140
sysvec_apic_timer_interrupt+0x7b/0xa0
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1f/0x30
...
------------[ cut here ]------------
Interrupts enabled after iommu_suspend+0x0/0x1d0
WARNING: CPU: 0 PID: 27420 at drivers/base/syscore.c:68 syscore_suspend+0x147/0x270
CPU: 0 PID: 27420 Comm: rtcwake Tainted: G U W E 6.3-intel #r1
RIP: 0010:syscore_suspend+0x147/0x270
...
Call Trace:
<TASK>
hibernation_snapshot+0x25b/0x670
hibernate+0xcd/0x390
state_store+0xcf/0xe0
kobj_attr_store+0x13/0x30
sysfs_kf_write+0x3f/0x50
kernfs_fop_write_iter+0x128/0x200
vfs_write+0x1fd/0x3c0
ksys_write+0x6f/0xf0
__x64_sys_write+0x1d/0x30
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x72/0xdc
Given that only 4 words memory is needed, avoid the memory allocation in
iommu_suspend(). |
["https://git.kernel.org/stable/c/29298c85a81abdc512e87537515ed4b1a9601d0e","https://git.kernel.org/stable/c/496c591f0b389eb782f36d9d4c2564b9a865eed0","https://git.kernel.org/stable/c/59df44bfb0ca4c3ee1f1c3c5d0ee8e314844799e","https://git.kernel.org/stable/c/c12ef025add77ca3a0902e8719d552b6d47b4282","https://git.kernel.org/stable/c/29298c85a81abdc512e87537515ed4b1a9601d0e","https://git.kernel.org/stable/c/496c591f0b389eb782f36d9d4c2564b9a865eed0","https://git.kernel.org/stable/c/59df44bfb0ca4c3ee1f1c3c5d0ee8e314844799e","https://git.kernel.org/stable/c/c12ef025add77ca3a0902e8719d552b6d47b4282"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52582
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
netfs: Only call folio_start_fscache() one time for each folio
If a network filesystem using netfs implements a clamp_length()
function, it can set subrequest lengths smaller than a page size.
When we loop through the folios in netfs_rreq_unlock_folios() to
set any folios to be written back, we need to make sure we only
call folio_start_fscache() once for each folio.
Otherwise, this simple testcase:
mount -o fsc,rsize=1024,wsize=1024 127.0.0.1:/export /mnt/nfs
dd if=/dev/zero of=/mnt/nfs/file.bin bs=4096 count=1
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.0126359 s, 324 kB/s
echo 3 > /proc/sys/vm/drop_caches
cat /mnt/nfs/file.bin > /dev/null
will trigger an oops similar to the following:
page dumped because: VM_BUG_ON_FOLIO(folio_test_private_2(folio))
------------[ cut here ]------------
kernel BUG at include/linux/netfs.h:44!
...
CPU: 5 PID: 134 Comm: kworker/u16:5 Kdump: loaded Not tainted 6.4.0-rc5
...
RIP: 0010:netfs_rreq_unlock_folios+0x68e/0x730 [netfs]
...
Call Trace:
netfs_rreq_assess+0x497/0x660 [netfs]
netfs_subreq_terminated+0x32b/0x610 [netfs]
nfs_netfs_read_completion+0x14e/0x1a0 [nfs]
nfs_read_completion+0x2f9/0x330 [nfs]
rpc_free_task+0x72/0xa0 [sunrpc]
rpc_async_release+0x46/0x70 [sunrpc]
process_one_work+0x3bd/0x710
worker_thread+0x89/0x610
kthread+0x181/0x1c0
ret_from_fork+0x29/0x50 |
["https://git.kernel.org/stable/c/d9f5537479d4ec97ea92ff24e81a517d5772581a","https://git.kernel.org/stable/c/df1c357f25d808e30b216188330e708e09e1a412","https://git.kernel.org/stable/c/df9950d37df113db59495fa09d060754366a2b7c","https://git.kernel.org/stable/c/d9f5537479d4ec97ea92ff24e81a517d5772581a","https://git.kernel.org/stable/c/df1c357f25d808e30b216188330e708e09e1a412","https://git.kernel.org/stable/c/df9950d37df113db59495fa09d060754366a2b7c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26595
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error path
When calling mlxsw_sp_acl_tcam_region_destroy() from an error path after
failing to attach the region to an ACL group, we hit a NULL pointer
dereference upon 'region->group->tcam' [1].
Fix by retrieving the 'tcam' pointer using mlxsw_sp_acl_to_tcam().
[1]
BUG: kernel NULL pointer dereference, address: 0000000000000000
[...]
RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0
[...]
Call Trace:
mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20
mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0
mlxsw_sp_acl_rule_add+0x47/0x240
mlxsw_sp_flower_replace+0x1a9/0x1d0
tc_setup_cb_add+0xdc/0x1c0
fl_hw_replace_filter+0x146/0x1f0
fl_change+0xc17/0x1360
tc_new_tfilter+0x472/0xb90
rtnetlink_rcv_msg+0x313/0x3b0
netlink_rcv_skb+0x58/0x100
netlink_unicast+0x244/0x390
netlink_sendmsg+0x1e4/0x440
____sys_sendmsg+0x164/0x260
___sys_sendmsg+0x9a/0xe0
__sys_sendmsg+0x7a/0xc0
do_syscall_64+0x40/0xe0
entry_SYSCALL_64_after_hwframe+0x63/0x6b |
["https://git.kernel.org/stable/c/75fa2d8b3c0175b519c99ace54ab8474cfd0077e","https://git.kernel.org/stable/c/817840d125a370626895df269c50c923b79b0a39","https://git.kernel.org/stable/c/d0a1efe417c97a1e9b914056ee6b86f1ef75fe1f","https://git.kernel.org/stable/c/efeb7dfea8ee10cdec11b6b6ba4e405edbe75809","https://git.kernel.org/stable/c/817840d125a370626895df269c50c923b79b0a39","https://git.kernel.org/stable/c/d0a1efe417c97a1e9b914056ee6b86f1ef75fe1f","https://git.kernel.org/stable/c/efeb7dfea8ee10cdec11b6b6ba4e405edbe75809"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26700
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix MST Null Ptr for RV
The change try to fix below error specific to RV platform:
BUG: kernel NULL pointer dereference, address: 0000000000000008
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2
Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022
RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper]
Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8>
RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224
RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280
RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850
R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000
R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224
FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0
Call Trace:
<TASK>
? __die+0x23/0x70
? page_fault_oops+0x171/0x4e0
? plist_add+0xbe/0x100
? exc_page_fault+0x7c/0x180
? asm_exc_page_fault+0x26/0x30
? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]
? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]
compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
drm_atomic_check_only+0x5c5/0xa40
drm_mode_atomic_ioctl+0x76e/0xbc0
? _copy_to_user+0x25/0x30
? drm_ioctl+0x296/0x4b0
? __pfx_drm_mode_atomic_ioctl+0x10/0x10
drm_ioctl_kernel+0xcd/0x170
drm_ioctl+0x26d/0x4b0
? __pfx_drm_mode_atomic_ioctl+0x10/0x10
amdgpu_drm_ioctl+0x4e/0x90 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
__x64_sys_ioctl+0x94/0xd0
do_syscall_64+0x60/0x90
? do_syscall_64+0x6c/0x90
entry_SYSCALL_64_after_hwframe+0x72/0xdc
RIP: 0033:0x7f4dad17f76f
Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c>
RSP: 002b:00007ffd9ae859f0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 000055e255a55900 RCX: 00007f4dad17f76f
RDX: 00007ffd9ae85a90 RSI: 00000000c03864bc RDI: 000000000000000b
RBP: 00007ffd9ae85a90 R08: 0000000000000003 R09: 0000000000000003
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c03864bc
R13: 000000000000000b R14: 000055e255a7fc60 R15: 000055e255a01eb0
</TASK>
Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device ccm cmac algif_hash algif_skcipher af_alg joydev mousedev bnep >
typec libphy k10temp ipmi_msghandler roles i2c_scmi acpi_cpufreq mac_hid nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_mas>
CR2: 0000000000000008
---[ end trace 0000000000000000 ]---
RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper]
Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8>
RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224
RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280
RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850
R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000
R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224
FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000
---truncated--- |
["https://git.kernel.org/stable/c/01d992088dce3945f70f49f34b0b911c5213c238","https://git.kernel.org/stable/c/5cd7185d2db76c42a9b7e69adad9591d9fca093f","https://git.kernel.org/stable/c/7407c61f43b66e90ad127d0cdd13cbc9d87141a5","https://git.kernel.org/stable/c/e6a7df96facdcf5b1f71eb3ec26f2f9f6ad61e57","https://git.kernel.org/stable/c/01d992088dce3945f70f49f34b0b911c5213c238","https://git.kernel.org/stable/c/5cd7185d2db76c42a9b7e69adad9591d9fca093f","https://git.kernel.org/stable/c/7407c61f43b66e90ad127d0cdd13cbc9d87141a5","https://git.kernel.org/stable/c/e6a7df96facdcf5b1f71eb3ec26f2f9f6ad61e57"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26844
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
block: Fix WARNING in _copy_from_iter
Syzkaller reports a warning in _copy_from_iter because an
iov_iter is supposedly used in the wrong direction. The reason
is that syzcaller managed to generate a request with
a transfer direction of SG_DXFER_TO_FROM_DEV. This instructs
the kernel to copy user buffers into the kernel, read into
the copied buffers and then copy the data back to user space.
Thus the iovec is used in both directions.
Detect this situation in the block layer and construct a new
iterator with the correct direction for the copy-in. |
["https://git.kernel.org/stable/c/0f1bae071de9967602807472921829a54b2e5956","https://git.kernel.org/stable/c/13f3956eb5681a4045a8dfdef48df5dc4d9f58a6","https://git.kernel.org/stable/c/8fc80874103a5c20aebdc2401361aa01c817f75b","https://git.kernel.org/stable/c/cbaf9be337f7da25742acfce325119e3395b1f1b","https://git.kernel.org/stable/c/0f1bae071de9967602807472921829a54b2e5956","https://git.kernel.org/stable/c/13f3956eb5681a4045a8dfdef48df5dc4d9f58a6","https://git.kernel.org/stable/c/8fc80874103a5c20aebdc2401361aa01c817f75b","https://git.kernel.org/stable/c/cbaf9be337f7da25742acfce325119e3395b1f1b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-1016
|
Medium |
|
N/A
|
A flaw was found in the Linux kernel in net/netfilter/nf_tables_core.c:nft_do_chain, which can cause a use-after-free. This issue needs to handle 'return' with proper preconditions, as it can lead to a kernel information leak problem caused by a local, unprivileged attacker. |
["http://blog.dbouman.nl/2022/04/02/How-The-Tables-Have-Turned-CVE-2022-1015-1016/","https://access.redhat.com/security/cve/CVE-2022-1016","https://bugzilla.redhat.com/show_bug.cgi?id=2066614","https://seclists.org/oss-sec/2022/q1/205","http://blog.dbouman.nl/2022/04/02/How-The-Tables-Have-Turned-CVE-2022-1015-1016/","https://access.redhat.com/security/cve/CVE-2022-1016","https://bugzilla.redhat.com/show_bug.cgi?id=2066614","https://seclists.org/oss-sec/2022/q1/205"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4133
|
Medium |
fixed |
|
A use-after-free vulnerability was found in the cxgb4 driver in the Linux kernel. The bug occurs when the cxgb4 device is detaching due to a possible rearming of the flower_stats_timer from the work queue. This flaw allows a local user to crash the system, causing a denial of service condition. |
["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-4133","https://bugzilla.redhat.com/show_bug.cgi?id=2221702","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-4133","https://bugzilla.redhat.com/show_bug.cgi?id=2221702"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52508
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
nvme-fc: Prevent null pointer dereference in nvme_fc_io_getuuid()
The nvme_fc_fcp_op structure describing an AEN operation is initialized with a
null request structure pointer. An FC LLDD may make a call to
nvme_fc_io_getuuid passing a pointer to an nvmefc_fcp_req for an AEN operation.
Add validation of the request structure pointer before dereference. |
["https://git.kernel.org/stable/c/8ae5b3a685dc59a8cf7ccfe0e850999ba9727a3c","https://git.kernel.org/stable/c/be90c9e29dd59b7d19a73297a1590ff3ec1d22ea","https://git.kernel.org/stable/c/dd46b3ac7322baf3772b33b29726e94f98289db7","https://git.kernel.org/stable/c/8ae5b3a685dc59a8cf7ccfe0e850999ba9727a3c","https://git.kernel.org/stable/c/be90c9e29dd59b7d19a73297a1590ff3ec1d22ea","https://git.kernel.org/stable/c/dd46b3ac7322baf3772b33b29726e94f98289db7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26603
|
Medium |
fixed |
- 5.15.150
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
x86/fpu: Stop relying on userspace for info to fault in xsave buffer
Before this change, the expected size of the user space buffer was
taken from fx_sw->xstate_size. fx_sw->xstate_size can be changed
from user-space, so it is possible construct a sigreturn frame where:
* fx_sw->xstate_size is smaller than the size required by valid bits in
fx_sw->xfeatures.
* user-space unmaps parts of the sigrame fpu buffer so that not all of
the buffer required by xrstor is accessible.
In this case, xrstor tries to restore and accesses the unmapped area
which results in a fault. But fault_in_readable succeeds because buf +
fx_sw->xstate_size is within the still mapped area, so it goes back and
tries xrstor again. It will spin in this loop forever.
Instead, fault in the maximum size which can be touched by XRSTOR (taken
from fpstate->user_size).
[ dhansen: tweak subject / changelog ] |
["https://git.kernel.org/stable/c/627339cccdc9166792ecf96bc3c9f711a60ce996","https://git.kernel.org/stable/c/627e28cbb65564e55008315d9e02fbb90478beda","https://git.kernel.org/stable/c/8bd3eee7720c14b59a206bd05b98d7586bccf99a","https://git.kernel.org/stable/c/b2479ab426cef7ab79a13005650eff956223ced2","https://git.kernel.org/stable/c/d877550eaf2dc9090d782864c96939397a3c6835","https://git.kernel.org/stable/c/627339cccdc9166792ecf96bc3c9f711a60ce996","https://git.kernel.org/stable/c/627e28cbb65564e55008315d9e02fbb90478beda","https://git.kernel.org/stable/c/8bd3eee7720c14b59a206bd05b98d7586bccf99a","https://git.kernel.org/stable/c/b2479ab426cef7ab79a13005650eff956223ced2","https://git.kernel.org/stable/c/d877550eaf2dc9090d782864c96939397a3c6835"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52576
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
x86/mm, kexec, ima: Use memblock_free_late() from ima_free_kexec_buffer()
The code calling ima_free_kexec_buffer() runs long after the memblock
allocator has already been torn down, potentially resulting in a use
after free in memblock_isolate_range().
With KASAN or KFENCE, this use after free will result in a BUG
from the idle task, and a subsequent kernel panic.
Switch ima_free_kexec_buffer() over to memblock_free_late() to avoid
that bug. |
["https://git.kernel.org/stable/c/34cf99c250d5cd2530b93a57b0de31d3aaf8685b","https://git.kernel.org/stable/c/d2dfbc0e3b7a04c2d941421a958dc31c897fb204","https://git.kernel.org/stable/c/eef16bfdb212da60f5144689f2967fb25b051a2b","https://git.kernel.org/stable/c/34cf99c250d5cd2530b93a57b0de31d3aaf8685b","https://git.kernel.org/stable/c/d2dfbc0e3b7a04c2d941421a958dc31c897fb204","https://git.kernel.org/stable/c/eef16bfdb212da60f5144689f2967fb25b051a2b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26881
|
Medium |
fixed |
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix kernel crash when 1588 is received on HIP08 devices
The HIP08 devices does not register the ptp devices, so the
hdev->ptp is NULL, but the hardware can receive 1588 messages,
and set the HNS3_RXD_TS_VLD_B bit, so, if match this case, the
access of hdev->ptp->flags will cause a kernel crash:
[ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018
[ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018
...
[ 5889.266118] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]
[ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 [hclge]
[ 5889.279101] sp : ffff800012c3bc50
[ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040
[ 5889.289927] x27: ffff800009116484 x26: 0000000080007500
[ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000
[ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000
[ 5889.309134] x21: 0000000000000000 x20: ffff204004220080
[ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000
[ 5889.321897] x17: 0000000000000000 x16: 0000000000000000
[ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000
[ 5889.334617] x13: 0000000000000000 x12: 00000000010011df
[ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000
[ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d
[ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480
[ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000
[ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000
[ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080
[ 5889.378857] Call trace:
[ 5889.382285] hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]
[ 5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3]
[ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3]
[ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3]
[ 5889.405270] hns3_nic_common_poll+0xa8/0x220 [hns3]
[ 5889.411084] napi_poll+0xcc/0x264
[ 5889.415329] net_rx_action+0xd4/0x21c
[ 5889.419911] __do_softirq+0x130/0x358
[ 5889.424484] irq_exit+0x134/0x154
[ 5889.428700] __handle_domain_irq+0x88/0xf0
[ 5889.433684] gic_handle_irq+0x78/0x2c0
[ 5889.438319] el1_irq+0xb8/0x140
[ 5889.442354] arch_cpu_idle+0x18/0x40
[ 5889.446816] default_idle_call+0x5c/0x1c0
[ 5889.451714] cpuidle_idle_call+0x174/0x1b0
[ 5889.456692] do_idle+0xc8/0x160
[ 5889.460717] cpu_startup_entry+0x30/0xfc
[ 5889.465523] secondary_start_kernel+0x158/0x1ec
[ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80)
[ 5889.477950] SMP: stopping secondary CPUs
[ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95
[ 5890.522951] Starting crashdump kernel... |
["https://git.kernel.org/stable/c/0fbcf2366ba9888cf02eda23e35fde7f7fcc07c3","https://git.kernel.org/stable/c/11b998360d96f6c76f04a95f54b49f24d3c858e4","https://git.kernel.org/stable/c/23ec1cec24293f9799c725941677d4e167997265","https://git.kernel.org/stable/c/b2bb19114c079dcfec1ea46e761f510e30505e70","https://git.kernel.org/stable/c/b3cf70472a600bcb2efe24906bc9bc6014d4c6f6","https://git.kernel.org/stable/c/f0b5225a7dfc1bf53c98215db8c2f0b4efd3f108","https://git.kernel.org/stable/c/0fbcf2366ba9888cf02eda23e35fde7f7fcc07c3","https://git.kernel.org/stable/c/11b998360d96f6c76f04a95f54b49f24d3c858e4","https://git.kernel.org/stable/c/23ec1cec24293f9799c725941677d4e167997265","https://git.kernel.org/stable/c/b2bb19114c079dcfec1ea46e761f510e30505e70","https://git.kernel.org/stable/c/b3cf70472a600bcb2efe24906bc9bc6014d4c6f6","https://git.kernel.org/stable/c/f0b5225a7dfc1bf53c98215db8c2f0b4efd3f108"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48629
|
Medium |
fixed |
- 4.19.236
- 5.4.187
- 5.10.108
- 5.15.31
- 5.16.17
|
In the Linux kernel, the following vulnerability has been resolved:
crypto: qcom-rng - ensure buffer for generate is completely filled
The generate function in struct rng_alg expects that the destination
buffer is completely filled if the function returns 0. qcom_rng_read()
can run into a situation where the buffer is partially filled with
randomness and the remaining part of the buffer is zeroed since
qcom_rng_generate() doesn't check the return value. This issue can
be reproduced by running the following from libkcapi:
kcapi-rng -b 9000000 > OUTFILE
The generated OUTFILE will have three huge sections that contain all
zeros, and this is caused by the code where the test
'val & PRNG_STATUS_DATA_AVAIL' fails.
Let's fix this issue by ensuring that qcom_rng_read() always returns
with a full buffer if the function returns success. Let's also have
qcom_rng_generate() return the correct value.
Here's some statistics from the ent project
(https://www.fourmilab.ch/random/) that shows information about the
quality of the generated numbers:
$ ent -c qcom-random-before
Value Char Occurrences Fraction
0 606748 0.067416
1 33104 0.003678
2 33001 0.003667
...
253 � 32883 0.003654
254 � 33035 0.003671
255 � 33239 0.003693
Total: 9000000 1.000000
Entropy = 7.811590 bits per byte.
Optimum compression would reduce the size
of this 9000000 byte file by 2 percent.
Chi square distribution for 9000000 samples is 9329962.81, and
randomly would exceed this value less than 0.01 percent of the
times.
Arithmetic mean value of data bytes is 119.3731 (127.5 = random).
Monte Carlo value for Pi is 3.197293333 (error 1.77 percent).
Serial correlation coefficient is 0.159130 (totally uncorrelated =
0.0).
Without this patch, the results of the chi-square test is 0.01%, and
the numbers are certainly not random according to ent's project page.
The results improve with this patch:
$ ent -c qcom-random-after
Value Char Occurrences Fraction
0 35432 0.003937
1 35127 0.003903
2 35424 0.003936
...
253 � 35201 0.003911
254 � 34835 0.003871
255 � 35368 0.003930
Total: 9000000 1.000000
Entropy = 7.999979 bits per byte.
Optimum compression would reduce the size
of this 9000000 byte file by 0 percent.
Chi square distribution for 9000000 samples is 258.77, and randomly
would exceed this value 42.24 percent of the times.
Arithmetic mean value of data bytes is 127.5006 (127.5 = random).
Monte Carlo value for Pi is 3.141277333 (error 0.01 percent).
Serial correlation coefficient is 0.000468 (totally uncorrelated =
0.0).
This change was tested on a Nexus 5 phone (msm8974 SoC). |
["https://git.kernel.org/stable/c/0f9b7b8df17525e464294c916acc8194ce38446b","https://git.kernel.org/stable/c/184f7bd08ce56f003530fc19f160d54e75bf5c9d","https://git.kernel.org/stable/c/485995cbc98a4f77cfd4f8ed4dd7ff8ab262964d","https://git.kernel.org/stable/c/a680b1832ced3b5fa7c93484248fd221ea0d614b","https://git.kernel.org/stable/c/a8e32bbb96c25b7ab29b1894dcd45e0b3b08fd9d","https://git.kernel.org/stable/c/ab9337c7cb6f875b6286440b1adfbeeef2b2b2bd","https://git.kernel.org/stable/c/0f9b7b8df17525e464294c916acc8194ce38446b","https://git.kernel.org/stable/c/184f7bd08ce56f003530fc19f160d54e75bf5c9d","https://git.kernel.org/stable/c/485995cbc98a4f77cfd4f8ed4dd7ff8ab262964d","https://git.kernel.org/stable/c/a680b1832ced3b5fa7c93484248fd221ea0d614b","https://git.kernel.org/stable/c/a8e32bbb96c25b7ab29b1894dcd45e0b3b08fd9d","https://git.kernel.org/stable/c/ab9337c7cb6f875b6286440b1adfbeeef2b2b2bd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26744
|
Medium |
fixed |
- 4.19.308
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srpt: Support specifying the srpt_service_guid parameter
Make loading ib_srpt with this parameter set work. The current behavior is
that setting that parameter while loading the ib_srpt kernel module
triggers the following kernel crash:
BUG: kernel NULL pointer dereference, address: 0000000000000000
Call Trace:
<TASK>
parse_one+0x18c/0x1d0
parse_args+0xe1/0x230
load_module+0x8de/0xa60
init_module_from_file+0x8b/0xd0
idempotent_init_module+0x181/0x240
__x64_sys_finit_module+0x5a/0xb0
do_syscall_64+0x5f/0xe0
entry_SYSCALL_64_after_hwframe+0x6e/0x76 |
["https://git.kernel.org/stable/c/5a5c039dac1b1b7ba3e91c791f4421052bf79b82","https://git.kernel.org/stable/c/84f1dac960cfa210a3b7a7522e6c2320ae91932b","https://git.kernel.org/stable/c/989af2f29342a9a7c7515523d879b698ac8465f4","https://git.kernel.org/stable/c/aee4dcfe17219fe60f2821923adea98549060af8","https://git.kernel.org/stable/c/c99a827d3cff9f84e1cb997b7cc6386d107aa74d","https://git.kernel.org/stable/c/e0055d6461b36bfc25a9d2ab974eef78d36a6738","https://git.kernel.org/stable/c/fdfa083549de5d50ebf7f6811f33757781e838c0","https://git.kernel.org/stable/c/fe2a73d57319feab4b3b175945671ce43492172f","https://git.kernel.org/stable/c/5a5c039dac1b1b7ba3e91c791f4421052bf79b82","https://git.kernel.org/stable/c/84f1dac960cfa210a3b7a7522e6c2320ae91932b","https://git.kernel.org/stable/c/989af2f29342a9a7c7515523d879b698ac8465f4","https://git.kernel.org/stable/c/aee4dcfe17219fe60f2821923adea98549060af8","https://git.kernel.org/stable/c/c99a827d3cff9f84e1cb997b7cc6386d107aa74d","https://git.kernel.org/stable/c/fdfa083549de5d50ebf7f6811f33757781e838c0","https://git.kernel.org/stable/c/fe2a73d57319feab4b3b175945671ce43492172f","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26772
|
Medium |
fixed |
- 4.19.308
- 5.4.270
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal()
Places the logic for checking if the group's block bitmap is corrupt under
the protection of the group lock to avoid allocating blocks from the group
with a corrupted block bitmap. |
["https://git.kernel.org/stable/c/21dbe20589c7f48e9c5d336ce6402bcebfa6d76a","https://git.kernel.org/stable/c/5a6dcc4ad0f7f7fa8e8d127b5526e7c5f2d38a43","https://git.kernel.org/stable/c/6b92b1bc16d691c95b152c6dbf027ad64315668d","https://git.kernel.org/stable/c/832698373a25950942c04a512daa652c18a9b513","https://git.kernel.org/stable/c/8de8305a25bfda607fc13475ebe84b978c96d7ff","https://git.kernel.org/stable/c/d3bbe77a76bc52e9d4d0a120f1509be36e25c916","https://git.kernel.org/stable/c/d639102f4cbd4cb65d1225dba3b9265596aab586","https://git.kernel.org/stable/c/ffeb72a80a82aba59a6774b0611f792e0ed3b0b7","https://git.kernel.org/stable/c/21dbe20589c7f48e9c5d336ce6402bcebfa6d76a","https://git.kernel.org/stable/c/5a6dcc4ad0f7f7fa8e8d127b5526e7c5f2d38a43","https://git.kernel.org/stable/c/6b92b1bc16d691c95b152c6dbf027ad64315668d","https://git.kernel.org/stable/c/832698373a25950942c04a512daa652c18a9b513","https://git.kernel.org/stable/c/8de8305a25bfda607fc13475ebe84b978c96d7ff","https://git.kernel.org/stable/c/d3bbe77a76bc52e9d4d0a120f1509be36e25c916","https://git.kernel.org/stable/c/d639102f4cbd4cb65d1225dba3b9265596aab586","https://git.kernel.org/stable/c/ffeb72a80a82aba59a6774b0611f792e0ed3b0b7","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26777
|
Medium |
fixed |
- 4.19.308
- 5.4.270
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
fbdev: sis: Error out if pixclock equals zero
The userspace program could pass any values to the driver through
ioctl() interface. If the driver doesn't check the value of pixclock,
it may cause divide-by-zero error.
In sisfb_check_var(), var->pixclock is used as a divisor to caculate
drate before it is checked against zero. Fix this by checking it
at the beginning.
This is similar to CVE-2022-3061 in i740fb which was fixed by
commit 15cf0b8. |
["https://git.kernel.org/stable/c/1d11dd3ea5d039c7da089f309f39c4cd363b924b","https://git.kernel.org/stable/c/6db07619d173765bd8622d63809cbfe361f04207","https://git.kernel.org/stable/c/84246c35ca34207114055a87552a1c4289c8fd7e","https://git.kernel.org/stable/c/99f1abc34a6dde248d2219d64aa493c76bbdd9eb","https://git.kernel.org/stable/c/cd36da760bd1f78c63c7078407baf01dd724f313","https://git.kernel.org/stable/c/df6e2088c6f4cad539cf67cba2d6764461e798d1","https://git.kernel.org/stable/c/e421946be7d9bf545147bea8419ef8239cb7ca52","https://git.kernel.org/stable/c/f329523f6a65c3bbce913ad35473d83a319d5d99","https://git.kernel.org/stable/c/1d11dd3ea5d039c7da089f309f39c4cd363b924b","https://git.kernel.org/stable/c/6db07619d173765bd8622d63809cbfe361f04207","https://git.kernel.org/stable/c/84246c35ca34207114055a87552a1c4289c8fd7e","https://git.kernel.org/stable/c/99f1abc34a6dde248d2219d64aa493c76bbdd9eb","https://git.kernel.org/stable/c/cd36da760bd1f78c63c7078407baf01dd724f313","https://git.kernel.org/stable/c/df6e2088c6f4cad539cf67cba2d6764461e798d1","https://git.kernel.org/stable/c/e421946be7d9bf545147bea8419ef8239cb7ca52","https://git.kernel.org/stable/c/f329523f6a65c3bbce913ad35473d83a319d5d99","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26778
|
Medium |
fixed |
- 4.19.308
- 5.4.270
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
fbdev: savage: Error out if pixclock equals zero
The userspace program could pass any values to the driver through
ioctl() interface. If the driver doesn't check the value of pixclock,
it may cause divide-by-zero error.
Although pixclock is checked in savagefb_decode_var(), but it is not
checked properly in savagefb_probe(). Fix this by checking whether
pixclock is zero in the function savagefb_check_var() before
info->var.pixclock is used as the divisor.
This is similar to CVE-2022-3061 in i740fb which was fixed by
commit 15cf0b8. |
["https://git.kernel.org/stable/c/04e5eac8f3ab2ff52fa191c187a46d4fdbc1e288","https://git.kernel.org/stable/c/070398d32c5f3ab0e890374904ad94551c76aec4","https://git.kernel.org/stable/c/224453de8505aede1890f007be973925a3edf6a1","https://git.kernel.org/stable/c/512ee6d6041e007ef5bf200c6e388e172a2c5b24","https://git.kernel.org/stable/c/84dce0f6a4cc5b7bfd7242ef9290db8ac1dd77ff","https://git.kernel.org/stable/c/8c54acf33e5adaad6374bf3ec1e3aff0591cc8e1","https://git.kernel.org/stable/c/a9ca4e80d23474f90841251f4ac0d941fa337a01","https://git.kernel.org/stable/c/bc3c2e58d73b28b9a8789fca84778ee165a72d13","https://git.kernel.org/stable/c/04e5eac8f3ab2ff52fa191c187a46d4fdbc1e288","https://git.kernel.org/stable/c/070398d32c5f3ab0e890374904ad94551c76aec4","https://git.kernel.org/stable/c/224453de8505aede1890f007be973925a3edf6a1","https://git.kernel.org/stable/c/512ee6d6041e007ef5bf200c6e388e172a2c5b24","https://git.kernel.org/stable/c/84dce0f6a4cc5b7bfd7242ef9290db8ac1dd77ff","https://git.kernel.org/stable/c/8c54acf33e5adaad6374bf3ec1e3aff0591cc8e1","https://git.kernel.org/stable/c/a9ca4e80d23474f90841251f4ac0d941fa337a01","https://git.kernel.org/stable/c/bc3c2e58d73b28b9a8789fca84778ee165a72d13","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-45869
|
Medium |
fixed |
|
A race condition in the x86 KVM subsystem in the Linux kernel through 6.1-rc6 allows guest OS users to cause a denial of service (host OS crash or host OS memory corruption) when nested virtualisation and the TDP MMU are enabled. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=47b0c2e4c220f2251fd8dcfbb44479819c715e15","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=47b0c2e4c220f2251fd8dcfbb44479819c715e15"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3521
|
Low |
fixed |
|
A vulnerability has been found in Linux Kernel and classified as problematic. This vulnerability affects the function kcm_tx_work of the file net/kcm/kcmsock.c of the component kcm. The manipulation leads to race condition. It is recommended to apply a patch to fix this issue. VDB-211018 is the identifier assigned to this vulnerability. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ec7eede369fe5b0d085ac51fdbb95184f87bfc6c","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://vuldb.com/?id.211018","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ec7eede369fe5b0d085ac51fdbb95184f87bfc6c","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://vuldb.com/?id.211018"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26769
|
Medium |
fixed |
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
nvmet-fc: avoid deadlock on delete association path
When deleting an association the shutdown path is deadlocking because we
try to flush the nvmet_wq nested. Avoid this by deadlock by deferring
the put work into its own work item. |
["https://git.kernel.org/stable/c/1d86f79287206deec36d63b89c741cf542b6cadd","https://git.kernel.org/stable/c/5e0bc09a52b6169ce90f7ac6e195791adb16cec4","https://git.kernel.org/stable/c/710c69dbaccdac312e32931abcb8499c1525d397","https://git.kernel.org/stable/c/9e6987f8937a7bd7516aa52f25cb7e12c0c92ee8","https://git.kernel.org/stable/c/eaf0971fdabf2a93c1429dc6bedf3bbe85dffa30","https://git.kernel.org/stable/c/1d86f79287206deec36d63b89c741cf542b6cadd","https://git.kernel.org/stable/c/5e0bc09a52b6169ce90f7ac6e195791adb16cec4","https://git.kernel.org/stable/c/710c69dbaccdac312e32931abcb8499c1525d397","https://git.kernel.org/stable/c/9e6987f8937a7bd7516aa52f25cb7e12c0c92ee8","https://git.kernel.org/stable/c/eaf0971fdabf2a93c1429dc6bedf3bbe85dffa30"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-28388
|
Medium |
|
N/A
|
usb_8dev_start_xmit in drivers/net/can/usb/usb_8dev.c in the Linux kernel through 5.17.1 has a double free. |
["https://github.com/torvalds/linux/commit/3d3925ff6433f98992685a9679613a2cc97f3ce2","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6IHHC455LMSJNG4CSZ5CEAHYWY2DE5YW/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LAWC35TO642FOP3UCA3C6IF7NAUFOVZ6/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XFMPUI3WI4U2F7ONHRW36WDY4ZE7LGGT/","https://security.netapp.com/advisory/ntap-20220513-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173","https://github.com/torvalds/linux/commit/3d3925ff6433f98992685a9679613a2cc97f3ce2","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6IHHC455LMSJNG4CSZ5CEAHYWY2DE5YW/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LAWC35TO642FOP3UCA3C6IF7NAUFOVZ6/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XFMPUI3WI4U2F7ONHRW36WDY4ZE7LGGT/","https://security.netapp.com/advisory/ntap-20220513-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-33952
|
Medium |
|
N/A
|
A double-free vulnerability was found in handling vmw_buffer_object objects in the vmwgfx driver in the Linux kernel. This issue occurs due to the lack of validating the existence of an object prior to performing further free operations on the object, which may allow a local privileged user to escalate privileges and execute code in the context of the kernel. |
["https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/errata/RHSA-2023:6901","https://access.redhat.com/errata/RHSA-2023:7077","https://access.redhat.com/errata/RHSA-2024:1404","https://access.redhat.com/errata/RHSA-2024:4823","https://access.redhat.com/errata/RHSA-2024:4831","https://access.redhat.com/security/cve/CVE-2023-33952","https://bugzilla.redhat.com/show_bug.cgi?id=2218212","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20292","https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/errata/RHSA-2023:6901","https://access.redhat.com/errata/RHSA-2023:7077","https://access.redhat.com/errata/RHSA-2024:1404","https://access.redhat.com/errata/RHSA-2024:4823","https://access.redhat.com/errata/RHSA-2024:4831","https://access.redhat.com/security/cve/CVE-2023-33952","https://bugzilla.redhat.com/show_bug.cgi?id=2218212","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20292"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3397
|
Medium |
|
N/A
|
A race condition occurred between the functions lmLogClose and txEnd in JFS, in the Linux Kernel, executed in different threads. This flaw allows a local attacker with normal user privileges to crash the system or leak internal kernel information. |
["https://access.redhat.com/security/cve/CVE-2023-3397","https://bugzilla.redhat.com/show_bug.cgi?id=2217271","https://www.spinics.net/lists/kernel/msg4788636.html","https://access.redhat.com/security/cve/CVE-2023-3397","https://bugzilla.redhat.com/show_bug.cgi?id=2217271","https://www.spinics.net/lists/kernel/msg4788636.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-30456
|
Medium |
fixed |
|
An issue was discovered in arch/x86/kvm/vmx/nested.c in the Linux kernel before 6.2.8. nVMX on x86_64 lacks consistency checks for CR0 and CR4. |
["http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.8","https://github.com/torvalds/linux/commit/112e66017bff7f2837030f34c2bc19501e9212d5","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230511-0007/","http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.8","https://github.com/torvalds/linux/commit/112e66017bff7f2837030f34c2bc19501e9212d5","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230511-0007/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26907
|
High |
fixed |
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix fortify source warning while accessing Eth segment
------------[ cut here ]------------
memcpy: detected field-spanning write (size 56) of single field "eseg->inline_hdr.start" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2)
WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy
[last unloaded: mlx_compat(OE)]
CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7
RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046
RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8
R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80
FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
? show_regs+0x72/0x90
? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
? __warn+0x8d/0x160
? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
? report_bug+0x1bb/0x1d0
? handle_bug+0x46/0x90
? exc_invalid_op+0x19/0x80
? asm_exc_invalid_op+0x1b/0x20
? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib]
ipoib_send+0x2ec/0x770 [ib_ipoib]
ipoib_start_xmit+0x5a0/0x770 [ib_ipoib]
dev_hard_start_xmit+0x8e/0x1e0
? validate_xmit_skb_list+0x4d/0x80
sch_direct_xmit+0x116/0x3a0
__dev_xmit_skb+0x1fd/0x580
__dev_queue_xmit+0x284/0x6b0
? _raw_spin_unlock_irq+0xe/0x50
? __flush_work.isra.0+0x20d/0x370
? push_pseudo_header+0x17/0x40 [ib_ipoib]
neigh_connected_output+0xcd/0x110
ip_finish_output2+0x179/0x480
? __smp_call_single_queue+0x61/0xa0
__ip_finish_output+0xc3/0x190
ip_finish_output+0x2e/0xf0
ip_output+0x78/0x110
? __pfx_ip_finish_output+0x10/0x10
ip_local_out+0x64/0x70
__ip_queue_xmit+0x18a/0x460
ip_queue_xmit+0x15/0x30
__tcp_transmit_skb+0x914/0x9c0
tcp_write_xmit+0x334/0x8d0
tcp_push_one+0x3c/0x60
tcp_sendmsg_locked+0x2e1/0xac0
tcp_sendmsg+0x2d/0x50
inet_sendmsg+0x43/0x90
sock_sendmsg+0x68/0x80
sock_write_iter+0x93/0x100
vfs_write+0x326/0x3c0
ksys_write+0xbd/0xf0
? do_syscall_64+0x69/0x90
__x64_sys_write+0x19/0x30
do_syscall_
---truncated--- |
["https://git.kernel.org/stable/c/185fa07000e0a81d54cf8c05414cebff14469a5c","https://git.kernel.org/stable/c/4d5e86a56615cc387d21c629f9af8fb0e958d350","https://git.kernel.org/stable/c/60ba938a8bc8c90e724c75f98e932f9fb7ae1b9d","https://git.kernel.org/stable/c/9a624a5f95733bac4648ecadb320ca83aa9c08fd","https://git.kernel.org/stable/c/cad82f1671e41094acd3b9a60cd27d67a3c64a21","https://git.kernel.org/stable/c/d27c48dc309da72c3b46351a1205d89687272baa","https://git.kernel.org/stable/c/185fa07000e0a81d54cf8c05414cebff14469a5c","https://git.kernel.org/stable/c/4d5e86a56615cc387d21c629f9af8fb0e958d350","https://git.kernel.org/stable/c/60ba938a8bc8c90e724c75f98e932f9fb7ae1b9d","https://git.kernel.org/stable/c/9a624a5f95733bac4648ecadb320ca83aa9c08fd","https://git.kernel.org/stable/c/cad82f1671e41094acd3b9a60cd27d67a3c64a21","https://git.kernel.org/stable/c/d27c48dc309da72c3b46351a1205d89687272baa","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3624
|
Low |
|
N/A
|
A vulnerability was found in Linux Kernel and classified as problematic. Affected by this issue is the function rlb_arp_xmit of the file drivers/net/bonding/bond_alb.c of the component IPsec. The manipulation leads to memory leak. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211928. |
["https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=4f5d33f4f798b1c6d92b613f0087f639d9836971","https://vuldb.com/?id.211928","https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=4f5d33f4f798b1c6d92b613f0087f639d9836971","https://vuldb.com/?id.211928"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52529
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
HID: sony: Fix a potential memory leak in sony_probe()
If an error occurs after a successful usb_alloc_urb() call, usb_free_urb()
should be called. |
["https://git.kernel.org/stable/c/bb0707fde7492121917fd9ddb43829e96ec0bb9e","https://git.kernel.org/stable/c/e1cd4004cde7c9b694bbdd8def0e02288ee58c74","https://git.kernel.org/stable/c/f237b17611fa3501f43f12d1cb64323e10fdcb4f","https://git.kernel.org/stable/c/f566efa7de1e35e6523f4acbaf85068a540be07d","https://git.kernel.org/stable/c/bb0707fde7492121917fd9ddb43829e96ec0bb9e","https://git.kernel.org/stable/c/e1cd4004cde7c9b694bbdd8def0e02288ee58c74","https://git.kernel.org/stable/c/f237b17611fa3501f43f12d1cb64323e10fdcb4f","https://git.kernel.org/stable/c/f566efa7de1e35e6523f4acbaf85068a540be07d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3268
|
High |
fixed |
|
An out of bounds (OOB) memory access flaw was found in the Linux kernel in relay_file_read_start_pos in kernel/relay.c in the relayfs. This flaw could allow a local attacker to crash the system or leak kernel internal information. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43ec16f1450f4936025a9bdf1a273affdb9732c1","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/lkml/1682238502-1892-1-git-send-email-yangpc%40wangsu.com/T/","https://security.netapp.com/advisory/ntap-20230824-0006/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5480","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43ec16f1450f4936025a9bdf1a273affdb9732c1","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/lkml/1682238502-1892-1-git-send-email-yangpc%40wangsu.com/T/","https://security.netapp.com/advisory/ntap-20230824-0006/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5480"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1382
|
Medium |
fixed |
|
A data race flaw was found in the Linux kernel, between where con is allocated and con->sock is set. This issue leads to a NULL pointer dereference when accessing con->sock->sk in net/tipc/topsrv.c in the tipc protocol in the Linux kernel. |
["https://lore.kernel.org/netdev/bc7bd3183f1c275c820690fc65b708238fe9e38e.1668807842.git.lucien.xin%40gmail.com/T/#u","https://lore.kernel.org/netdev/bc7bd3183f1c275c820690fc65b708238fe9e38e.1668807842.git.lucien.xin%40gmail.com/T/#u"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26607
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
drm/bridge: sii902x: Fix probing race issue
A null pointer dereference crash has been observed rarely on TI
platforms using sii9022 bridge:
[ 53.271356] sii902x_get_edid+0x34/0x70 [sii902x]
[ 53.276066] sii902x_bridge_get_edid+0x14/0x20 [sii902x]
[ 53.281381] drm_bridge_get_edid+0x20/0x34 [drm]
[ 53.286305] drm_bridge_connector_get_modes+0x8c/0xcc [drm_kms_helper]
[ 53.292955] drm_helper_probe_single_connector_modes+0x190/0x538 [drm_kms_helper]
[ 53.300510] drm_client_modeset_probe+0x1f0/0xbd4 [drm]
[ 53.305958] __drm_fb_helper_initial_config_and_unlock+0x50/0x510 [drm_kms_helper]
[ 53.313611] drm_fb_helper_initial_config+0x48/0x58 [drm_kms_helper]
[ 53.320039] drm_fbdev_dma_client_hotplug+0x84/0xd4 [drm_dma_helper]
[ 53.326401] drm_client_register+0x5c/0xa0 [drm]
[ 53.331216] drm_fbdev_dma_setup+0xc8/0x13c [drm_dma_helper]
[ 53.336881] tidss_probe+0x128/0x264 [tidss]
[ 53.341174] platform_probe+0x68/0xc4
[ 53.344841] really_probe+0x188/0x3c4
[ 53.348501] __driver_probe_device+0x7c/0x16c
[ 53.352854] driver_probe_device+0x3c/0x10c
[ 53.357033] __device_attach_driver+0xbc/0x158
[ 53.361472] bus_for_each_drv+0x88/0xe8
[ 53.365303] __device_attach+0xa0/0x1b4
[ 53.369135] device_initial_probe+0x14/0x20
[ 53.373314] bus_probe_device+0xb0/0xb4
[ 53.377145] deferred_probe_work_func+0xcc/0x124
[ 53.381757] process_one_work+0x1f0/0x518
[ 53.385770] worker_thread+0x1e8/0x3dc
[ 53.389519] kthread+0x11c/0x120
[ 53.392750] ret_from_fork+0x10/0x20
The issue here is as follows:
- tidss probes, but is deferred as sii902x is still missing.
- sii902x starts probing and enters sii902x_init().
- sii902x calls drm_bridge_add(). Now the sii902x bridge is ready from
DRM's perspective.
- sii902x calls sii902x_audio_codec_init() and
platform_device_register_data()
- The registration of the audio platform device causes probing of the
deferred devices.
- tidss probes, which eventually causes sii902x_bridge_get_edid() to be
called.
- sii902x_bridge_get_edid() tries to use the i2c to read the edid.
However, the sii902x driver has not set up the i2c part yet, leading
to the crash.
Fix this by moving the drm_bridge_add() to the end of the
sii902x_init(), which is also at the very end of sii902x_probe(). |
["https://git.kernel.org/stable/c/08ac6f132dd77e40f786d8af51140c96c6d739c9","https://git.kernel.org/stable/c/2a4c6af7934a7b4c304542c38fee35e09cc1770c","https://git.kernel.org/stable/c/56f96cf6eb11a1c2d594367c3becbfb06a855ec1","https://git.kernel.org/stable/c/e0f83c234ea7a3dec1f84e5d02caa1c51664a076","https://git.kernel.org/stable/c/08ac6f132dd77e40f786d8af51140c96c6d739c9","https://git.kernel.org/stable/c/2a4c6af7934a7b4c304542c38fee35e09cc1770c","https://git.kernel.org/stable/c/56f96cf6eb11a1c2d594367c3becbfb06a855ec1","https://git.kernel.org/stable/c/e0f83c234ea7a3dec1f84e5d02caa1c51664a076"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-0468
|
Medium |
fixed |
|
A use-after-free flaw was found in io_uring/poll.c in io_poll_check_events in the io_uring subcomponent in the Linux Kernel due to a race condition of poll_refs. This flaw may cause a NULL pointer dereference. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2164024","https://bugzilla.redhat.com/show_bug.cgi?id=2164024"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4010
|
Medium |
|
N/A
|
A flaw was found in the USB Host Controller Driver framework in the Linux kernel. The usb_giveback_urb function has a logic loophole in its implementation. Due to the inappropriate judgment condition of the goto statement, the function cannot return under the input of a specific malformed descriptor file, so it falls into an endless loop, resulting in a denial of service. |
["https://access.redhat.com/security/cve/CVE-2023-4010","https://bugzilla.redhat.com/show_bug.cgi?id=2227726","https://github.com/wanrenmi/a-usb-kernel-bug","https://access.redhat.com/security/cve/CVE-2023-4010","https://bugzilla.redhat.com/show_bug.cgi?id=2227726","https://github.com/wanrenmi/a-usb-kernel-bug"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-3606
|
Medium |
fixed |
|
A vulnerability was found in Linux Kernel. It has been classified as problematic. This affects the function find_prog_by_sec_insn of the file tools/lib/bpf/libbpf.c of the component BPF. The manipulation leads to null pointer dereference. It is recommended to apply a patch to fix this issue. The identifier VDB-211749 was assigned to this vulnerability. |
["https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d0d382f95a9270dcf803539d6781d6bd67e3f5b2","https://vuldb.com/?id.211749","https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d0d382f95a9270dcf803539d6781d6bd67e3f5b2","https://vuldb.com/?id.211749"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-39189
|
Medium |
fixed |
|
A flaw was found in the Netfilter subsystem in the Linux kernel. The nfnl_osf_add_callback function did not validate the user mode controlled opt_num field. This flaw allows a local privileged (CAP_NET_ADMIN) attacker to trigger an out-of-bounds read, leading to a crash or information disclosure. |
["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-39189","https://bugzilla.redhat.com/show_bug.cgi?id=2226777","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-39189","https://bugzilla.redhat.com/show_bug.cgi?id=2226777","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52573
|
Medium |
fixed |
- 5.4.258
- 5.10.198
- 5.15.134
- 6.1.56
- 6.5.6
|
In the Linux kernel, the following vulnerability has been resolved:
net: rds: Fix possible NULL-pointer dereference
In rds_rdma_cm_event_handler_cmn() check, if conn pointer exists
before dereferencing it as rdma_set_service_type() argument
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
["https://git.kernel.org/stable/c/069ac51c37a6f07a51f7134d8c34289075786a35","https://git.kernel.org/stable/c/51fa66024a5eabf270164f2dc82a48ffb35a12e9","https://git.kernel.org/stable/c/812da2a08dc5cc75fb71e29083ea20904510ac7a","https://git.kernel.org/stable/c/ea82139e6e3561100d38d14401d57c0ea93fc07e","https://git.kernel.org/stable/c/f1d95df0f31048f1c59092648997686e3f7d9478","https://git.kernel.org/stable/c/f515112e833791001aaa8ab886af3ca78503617f","https://git.kernel.org/stable/c/069ac51c37a6f07a51f7134d8c34289075786a35","https://git.kernel.org/stable/c/51fa66024a5eabf270164f2dc82a48ffb35a12e9","https://git.kernel.org/stable/c/812da2a08dc5cc75fb71e29083ea20904510ac7a","https://git.kernel.org/stable/c/ea82139e6e3561100d38d14401d57c0ea93fc07e","https://git.kernel.org/stable/c/f1d95df0f31048f1c59092648997686e3f7d9478","https://git.kernel.org/stable/c/f515112e833791001aaa8ab886af3ca78503617f"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26776
|
Medium |
fixed |
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected
Return IRQ_NONE from the interrupt handler when no interrupt was
detected. Because an empty interrupt will cause a null pointer error:
Unable to handle kernel NULL pointer dereference at virtual
address 0000000000000008
Call trace:
complete+0x54/0x100
hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx]
__handle_irq_event_percpu+0x64/0x1e0
handle_irq_event+0x7c/0x1cc |
["https://git.kernel.org/stable/c/0399d7eba41d9b28f5bdd7757ec21a5b7046858d","https://git.kernel.org/stable/c/d637b5118274701e8448f35953877daf04df18b4","https://git.kernel.org/stable/c/de8b6e1c231a95abf95ad097b993d34b31458ec9","https://git.kernel.org/stable/c/e4168ac25b4bd378bd7dda322d589482a136c1fd","https://git.kernel.org/stable/c/e94da8aca2e78ef9ecca02eb211869eacd5504e5","https://git.kernel.org/stable/c/f19361d570c67e7e014896fa2dacd7d721bf0aa8","https://git.kernel.org/stable/c/0399d7eba41d9b28f5bdd7757ec21a5b7046858d","https://git.kernel.org/stable/c/d637b5118274701e8448f35953877daf04df18b4","https://git.kernel.org/stable/c/de8b6e1c231a95abf95ad097b993d34b31458ec9","https://git.kernel.org/stable/c/e4168ac25b4bd378bd7dda322d589482a136c1fd","https://git.kernel.org/stable/c/e94da8aca2e78ef9ecca02eb211869eacd5504e5","https://git.kernel.org/stable/c/f19361d570c67e7e014896fa2dacd7d721bf0aa8","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48628
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ceph: drop messages from MDS when unmounting
When unmounting all the dirty buffers will be flushed and after
the last osd request is finished the last reference of the i_count
will be released. Then it will flush the dirty cap/snap to MDSs,
and the unmounting won't wait the possible acks, which will ihold
the inodes when updating the metadata locally but makes no sense
any more, of this. This will make the evict_inodes() to skip these
inodes.
If encrypt is enabled the kernel generate a warning when removing
the encrypt keys when the skipped inodes still hold the keyring:
WARNING: CPU: 4 PID: 168846 at fs/crypto/keyring.c:242 fscrypt_destroy_keyring+0x7e/0xd0
CPU: 4 PID: 168846 Comm: umount Tainted: G S 6.1.0-rc5-ceph-g72ead199864c #1
Hardware name: Supermicro SYS-5018R-WR/X10SRW-F, BIOS 2.0 12/17/2015
RIP: 0010:fscrypt_destroy_keyring+0x7e/0xd0
RSP: 0018:ffffc9000b277e28 EFLAGS: 00010202
RAX: 0000000000000002 RBX: ffff88810d52ac00 RCX: ffff88810b56aa00
RDX: 0000000080000000 RSI: ffffffff822f3a09 RDI: ffff888108f59000
RBP: ffff8881d394fb88 R08: 0000000000000028 R09: 0000000000000000
R10: 0000000000000001 R11: 11ff4fe6834fcd91 R12: ffff8881d394fc40
R13: ffff888108f59000 R14: ffff8881d394f800 R15: 0000000000000000
FS: 00007fd83f6f1080(0000) GS:ffff88885fd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f918d417000 CR3: 000000017f89a005 CR4: 00000000003706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
generic_shutdown_super+0x47/0x120
kill_anon_super+0x14/0x30
ceph_kill_sb+0x36/0x90 [ceph]
deactivate_locked_super+0x29/0x60
cleanup_mnt+0xb8/0x140
task_work_run+0x67/0xb0
exit_to_user_mode_prepare+0x23d/0x240
syscall_exit_to_user_mode+0x25/0x60
do_syscall_64+0x40/0x80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fd83dc39e9b
Later the kernel will crash when iput() the inodes and dereferencing
the "sb->s_master_keys", which has been released by the
generic_shutdown_super(). |
["https://git.kernel.org/stable/c/47f82395f04a976d4fa97de7f2acffa1c1096571","https://git.kernel.org/stable/c/89744b64914426cbabceb3d8a149176b5dafdfb5","https://git.kernel.org/stable/c/e3dfcab2080dc1f9a4b09cc1327361bc2845bfcd","https://git.kernel.org/stable/c/47f82395f04a976d4fa97de7f2acffa1c1096571","https://git.kernel.org/stable/c/89744b64914426cbabceb3d8a149176b5dafdfb5","https://git.kernel.org/stable/c/e3dfcab2080dc1f9a4b09cc1327361bc2845bfcd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-0615
|
Medium |
fixed |
|
A memory leak flaw and potential divide by zero and Integer overflow was found in the Linux kernel V4L2 and vivid test code functionality. This issue occurs when a user triggers ioctls, such as VIDIOC_S_DV_TIMINGS ioctl. This could allow a local user to crash the system if vivid test code enabled. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2166287","https://bugzilla.redhat.com/show_bug.cgi?id=2166287"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-46343
|
Medium |
fixed |
|
In the Linux kernel before 6.5.9, there is a NULL pointer dereference in send_acknowledge in net/nfc/nci/spi.c. |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.5.9","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7937609cd387246aed994e81aa4fa951358fba41","https://github.com/torvalds/linux/commit/7937609cd387246aed994e81aa4fa951358fba41","https://lore.kernel.org/netdev/20231013184129.18738-1-krzysztof.kozlowski%40linaro.org/T/#r38bdbaf8ae15305b77f6c5bc8e15d38f405623c7","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.5.9","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7937609cd387246aed994e81aa4fa951358fba41","https://github.com/torvalds/linux/commit/7937609cd387246aed994e81aa4fa951358fba41","https://lore.kernel.org/netdev/20231013184129.18738-1-krzysztof.kozlowski%40linaro.org/T/#r38bdbaf8ae15305b77f6c5bc8e15d38f405623c7"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26587
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: netdevsim: don't try to destroy PHC on VFs
PHC gets initialized in nsim_init_netdevsim(), which
is only called if (nsim_dev_port_is_pf()).
Create a counterpart of nsim_init_netdevsim() and
move the mock_phc_destroy() there.
This fixes a crash trying to destroy netdevsim with
VFs instantiated, as caught by running the devlink.sh test:
BUG: kernel NULL pointer dereference, address: 00000000000000b8
RIP: 0010:mock_phc_destroy+0xd/0x30
Call Trace:
<TASK>
nsim_destroy+0x4a/0x70 [netdevsim]
__nsim_dev_port_del+0x47/0x70 [netdevsim]
nsim_dev_reload_destroy+0x105/0x120 [netdevsim]
nsim_drv_remove+0x2f/0xb0 [netdevsim]
device_release_driver_internal+0x1a1/0x210
bus_remove_device+0xd5/0x120
device_del+0x159/0x490
device_unregister+0x12/0x30
del_device_store+0x11a/0x1a0 [netdevsim]
kernfs_fop_write_iter+0x130/0x1d0
vfs_write+0x30b/0x4b0
ksys_write+0x69/0xf0
do_syscall_64+0xcc/0x1e0
entry_SYSCALL_64_after_hwframe+0x6f/0x77 |
["https://git.kernel.org/stable/c/08aca65997fb6f233066883b1f1e653bcb1f26ca","https://git.kernel.org/stable/c/c5068e442eed063d2f1658e6b6d3c1c6fcf1e588","https://git.kernel.org/stable/c/ea937f77208323d35ffe2f8d8fc81b00118bfcda","https://git.kernel.org/stable/c/08aca65997fb6f233066883b1f1e653bcb1f26ca","https://git.kernel.org/stable/c/c5068e442eed063d2f1658e6b6d3c1c6fcf1e588","https://git.kernel.org/stable/c/ea937f77208323d35ffe2f8d8fc81b00118bfcda"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-49441
|
Medium |
fixed |
- 3.19
- 4.5
- 4.9.318
- 4.14.283
- 4.19.247
- 5.4.198
- 5.10.121
- 5.15.46
- 5.17.14
- 5.18.3
|
In the Linux kernel, the following vulnerability has been resolved:
tty: fix deadlock caused by calling printk() under tty_port->lock
pty_write() invokes kmalloc() which may invoke a normal printk() to print
failure message. This can cause a deadlock in the scenario reported by
syz-bot below:
CPU0 CPU1 CPU2
---- ---- ----
lock(console_owner);
lock(&port_lock_key);
lock(&port->lock);
lock(&port_lock_key);
lock(&port->lock);
lock(console_owner);
As commit dbdda842fe96 ("printk: Add console owner and waiter logic to
load balance console writes") said, such deadlock can be prevented by
using printk_deferred() in kmalloc() (which is invoked in the section
guarded by the port->lock). But there are too many printk() on the
kmalloc() path, and kmalloc() can be called from anywhere, so changing
printk() to printk_deferred() is too complicated and inelegant.
Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so
that printk() will not be called, and this deadlock problem can be
avoided.
Syzbot reported the following lockdep error:
======================================================
WARNING: possible circular locking dependency detected
5.4.143-00237-g08ccc19a-dirty #10 Not tainted
------------------------------------------------------
syz-executor.4/29420 is trying to acquire lock:
ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline]
ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023
but task is already holding lock:
ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&port->lock){-.-.}-{2:2}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159
tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock);
tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47
serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767
serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854
serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key);
serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870
serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126
__handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156
[...]
-> #1 (&port_lock_key){-.-.}-{2:2}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159
serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198
<-- lock(&port_lock_key);
call_console_drivers kernel/printk/printk.c:1819 [inline]
console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504
vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner);
vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394
printk+0xba/0xed kernel/printk/printk.c:2084
register_console+0x8b3/0xc10 kernel/printk/printk.c:2829
univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681
console_init+0x49d/0x6d3 kernel/printk/printk.c:2915
start_kernel+0x5e9/0x879 init/main.c:713
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241
-> #0 (console_owner){....}-{0:0}:
[...]
lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734
console_trylock_spinning kernel/printk/printk.c:1773
---truncated--- |
["https://git.kernel.org/stable/c/04ee31678c128a6cc7bb057ea189a8624ba5a314","https://git.kernel.org/stable/c/0bcf44903ef4df742dcada86ccaedd25374ffb50","https://git.kernel.org/stable/c/18ca0d55e8639b911df8aae1b47598b13f9acded","https://git.kernel.org/stable/c/3219ac364ac3d8d30771612a6010f1e0b7fa0a28","https://git.kernel.org/stable/c/4af21b12a60ed2d3642284f4f85b42d7dc6ac246","https://git.kernel.org/stable/c/4c253caf9264d2aa47ee806a87986dd8eb91a5d9","https://git.kernel.org/stable/c/6b9dbedbe3499fef862c4dff5217cf91f34e43b3","https://git.kernel.org/stable/c/9834b13e8b962caa28fbcf1f422dd82413da4ede","https://git.kernel.org/stable/c/b3c974501d0c32258ae0e04e5cc3fb92383b40f6"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26691
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Fix circular locking dependency
The rule inside kvm enforces that the vcpu->mutex is taken *inside*
kvm->lock. The rule is violated by the pkvm_create_hyp_vm() which acquires
the kvm->lock while already holding the vcpu->mutex lock from
kvm_vcpu_ioctl(). Avoid the circular locking dependency altogether by
protecting the hyp vm handle with the config_lock, much like we already
do for other forms of VM-scoped data. |
["https://git.kernel.org/stable/c/10c02aad111df02088d1a81792a709f6a7eca6cc","https://git.kernel.org/stable/c/3ab1c40a1e915e350d9181a4603af393141970cc","https://git.kernel.org/stable/c/3d16cebf01127f459dcfeb79ed77bd68b124c228","https://git.kernel.org/stable/c/10c02aad111df02088d1a81792a709f6a7eca6cc","https://git.kernel.org/stable/c/3ab1c40a1e915e350d9181a4603af393141970cc","https://git.kernel.org/stable/c/3d16cebf01127f459dcfeb79ed77bd68b124c228"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26775
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
aoe: avoid potential deadlock at set_capacity
Move set_capacity() outside of the section procected by (&d->lock).
To avoid possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
[1] lock(&bdev->bd_size_lock);
local_irq_disable();
[2] lock(&d->lock);
[3] lock(&bdev->bd_size_lock);
<Interrupt>
[4] lock(&d->lock);
*** DEADLOCK ***
Where [1](&bdev->bd_size_lock) hold by zram_add()->set_capacity().
[2]lock(&d->lock) hold by aoeblk_gdalloc(). And aoeblk_gdalloc()
is trying to acquire [3](&bdev->bd_size_lock) at set_capacity() call.
In this situation an attempt to acquire [4]lock(&d->lock) from
aoecmd_cfg_rsp() will lead to deadlock.
So the simplest solution is breaking lock dependency
[2](&d->lock) -> [3](&bdev->bd_size_lock) by moving set_capacity()
outside. |
["https://git.kernel.org/stable/c/19a77b27163820f793b4d022979ffdca8f659b77","https://git.kernel.org/stable/c/2d623c94fbba3554f4446ba6f3c764994e8b0d26","https://git.kernel.org/stable/c/673629018ba04906899dcb631beec34d871f709c","https://git.kernel.org/stable/c/e169bd4fb2b36c4b2bee63c35c740c85daeb2e86","https://git.kernel.org/stable/c/19a77b27163820f793b4d022979ffdca8f659b77","https://git.kernel.org/stable/c/2d623c94fbba3554f4446ba6f3c764994e8b0d26","https://git.kernel.org/stable/c/673629018ba04906899dcb631beec34d871f709c","https://git.kernel.org/stable/c/e169bd4fb2b36c4b2bee63c35c740c85daeb2e86"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26891
|
Medium |
fixed |
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected
For those endpoint devices connect to system via hotplug capable ports,
users could request a hot reset to the device by flapping device's link
through setting the slot's link control register, as pciehp_ist() DLLSC
interrupt sequence response, pciehp will unload the device driver and
then power it off. thus cause an IOMMU device-TLB invalidation (Intel
VT-d spec, or ATS Invalidation in PCIe spec r6.1) request for non-existence
target device to be sent and deadly loop to retry that request after ITE
fault triggered in interrupt context.
That would cause following continuous hard lockup warning and system hang
[ 4211.433662] pcieport 0000:17:01.0: pciehp: Slot(108): Link Down
[ 4211.433664] pcieport 0000:17:01.0: pciehp: Slot(108): Card not present
[ 4223.822591] NMI watchdog: Watchdog detected hard LOCKUP on cpu 144
[ 4223.822622] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S
OE kernel version xxxx
[ 4223.822623] Hardware name: vendorname xxxx 666-106,
BIOS 01.01.02.03.01 05/15/2023
[ 4223.822623] RIP: 0010:qi_submit_sync+0x2c0/0x490
[ 4223.822624] Code: 48 be 00 00 00 00 00 08 00 00 49 85 74 24 20 0f 95 c1 48 8b
57 10 83 c1 04 83 3c 1a 03 0f 84 a2 01 00 00 49 8b 04 24 8b 70 34 <40> f6 c6 1
0 74 17 49 8b 04 24 8b 80 80 00 00 00 89 c2 d3 fa 41 39
[ 4223.822624] RSP: 0018:ffffc4f074f0bbb8 EFLAGS: 00000093
[ 4223.822625] RAX: ffffc4f040059000 RBX: 0000000000000014 RCX: 0000000000000005
[ 4223.822625] RDX: ffff9f3841315800 RSI: 0000000000000000 RDI: ffff9f38401a8340
[ 4223.822625] RBP: ffff9f38401a8340 R08: ffffc4f074f0bc00 R09: 0000000000000000
[ 4223.822626] R10: 0000000000000010 R11: 0000000000000018 R12: ffff9f384005e200
[ 4223.822626] R13: 0000000000000004 R14: 0000000000000046 R15: 0000000000000004
[ 4223.822626] FS: 0000000000000000(0000) GS:ffffa237ae400000(0000)
knlGS:0000000000000000
[ 4223.822627] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4223.822627] CR2: 00007ffe86515d80 CR3: 000002fd3000a001 CR4: 0000000000770ee0
[ 4223.822627] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 4223.822628] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
[ 4223.822628] PKRU: 55555554
[ 4223.822628] Call Trace:
[ 4223.822628] qi_flush_dev_iotlb+0xb1/0xd0
[ 4223.822628] __dmar_remove_one_dev_info+0x224/0x250
[ 4223.822629] dmar_remove_one_dev_info+0x3e/0x50
[ 4223.822629] intel_iommu_release_device+0x1f/0x30
[ 4223.822629] iommu_release_device+0x33/0x60
[ 4223.822629] iommu_bus_notifier+0x7f/0x90
[ 4223.822630] blocking_notifier_call_chain+0x60/0x90
[ 4223.822630] device_del+0x2e5/0x420
[ 4223.822630] pci_remove_bus_device+0x70/0x110
[ 4223.822630] pciehp_unconfigure_device+0x7c/0x130
[ 4223.822631] pciehp_disable_slot+0x6b/0x100
[ 4223.822631] pciehp_handle_presence_or_link_change+0xd8/0x320
[ 4223.822631] pciehp_ist+0x176/0x180
[ 4223.822631] ? irq_finalize_oneshot.part.50+0x110/0x110
[ 4223.822632] irq_thread_fn+0x19/0x50
[ 4223.822632] irq_thread+0x104/0x190
[ 4223.822632] ? irq_forced_thread_fn+0x90/0x90
[ 4223.822632] ? irq_thread_check_affinity+0xe0/0xe0
[ 4223.822633] kthread+0x114/0x130
[ 4223.822633] ? __kthread_cancel_work+0x40/0x40
[ 4223.822633] ret_from_fork+0x1f/0x30
[ 4223.822633] Kernel panic - not syncing: Hard LOCKUP
[ 4223.822634] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S
OE kernel version xxxx
[ 4223.822634] Hardware name: vendorname xxxx 666-106,
BIOS 01.01.02.03.01 05/15/2023
[ 4223.822634] Call Trace:
[ 4223.822634] <NMI>
[ 4223.822635] dump_stack+0x6d/0x88
[ 4223.822635] panic+0x101/0x2d0
[ 4223.822635] ? ret_from_fork+0x11/0x30
[ 4223.822635] nmi_panic.cold.14+0xc/0xc
[ 4223.822636] watchdog_overflow_callback.cold.8+0x6d/0x81
[ 4223.822636] __perf_event_overflow+0x4f/0xf0
[ 4223.822636] handle_pmi_common
---truncated--- |
["https://git.kernel.org/stable/c/025bc6b41e020aeb1e71f84ae3ffce945026de05","https://git.kernel.org/stable/c/2b74b2a92e524d7c8dec8e02e95ecf18b667c062","https://git.kernel.org/stable/c/34a7b30f56d30114bf4d436e4dc793afe326fbcf","https://git.kernel.org/stable/c/4fc82cd907ac075648789cc3a00877778aa1838b","https://git.kernel.org/stable/c/c04f2780919f20e2cc4846764221f5e802555868","https://git.kernel.org/stable/c/d70f1c85113cd8c2aa8373f491ca5d1b22ec0554","https://git.kernel.org/stable/c/f873b85ec762c5a6abe94a7ddb31df5d3ba07d85","https://git.kernel.org/stable/c/025bc6b41e020aeb1e71f84ae3ffce945026de05","https://git.kernel.org/stable/c/2b74b2a92e524d7c8dec8e02e95ecf18b667c062","https://git.kernel.org/stable/c/34a7b30f56d30114bf4d436e4dc793afe326fbcf","https://git.kernel.org/stable/c/4fc82cd907ac075648789cc3a00877778aa1838b","https://git.kernel.org/stable/c/c04f2780919f20e2cc4846764221f5e802555868","https://git.kernel.org/stable/c/d70f1c85113cd8c2aa8373f491ca5d1b22ec0554","https://git.kernel.org/stable/c/f873b85ec762c5a6abe94a7ddb31df5d3ba07d85","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1076
|
Medium |
|
N/A
|
A flaw was found in the Linux Kernel. The tun/tap sockets have their socket UID hardcoded to 0 due to a type confusion in their initialization function. While it will be often correct, as tuntap devices require CAP_NET_ADMIN, it may not always be the case, e.g., a non-root user only having that capability. This would make tun/tap sockets being incorrectly treated in filtering/routing decisions, possibly bypassing network filters. |
["https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=66b2c338adce580dfce2199591e65e2bab889cff","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a096ccca6e503a5c575717ff8a36ace27510ab0a","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=66b2c338adce580dfce2199591e65e2bab889cff","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a096ccca6e503a5c575717ff8a36ace27510ab0a","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52635
|
Medium |
fixed |
- 5.10.210
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
PM / devfreq: Synchronize devfreq_monitor_[start/stop]
There is a chance if a frequent switch of the governor
done in a loop result in timer list corruption where
timer cancel being done from two place one from
cancel_delayed_work_sync() and followed by expire_timers()
can be seen from the traces[1].
while true
do
echo "simple_ondemand" > /sys/class/devfreq/1d84000.ufshc/governor
echo "performance" > /sys/class/devfreq/1d84000.ufshc/governor
done
It looks to be issue with devfreq driver where
device_monitor_[start/stop] need to synchronized so that
delayed work should get corrupted while it is either
being queued or running or being cancelled.
Let's use polling flag and devfreq lock to synchronize the
queueing the timer instance twice and work data being
corrupted.
[1]
...
..
<idle>-0 [003] 9436.209662: timer_cancel timer=0xffffff80444f0428
<idle>-0 [003] 9436.209664: timer_expire_entry timer=0xffffff80444f0428 now=0x10022da1c function=__typeid__ZTSFvP10timer_listE_global_addr baseclk=0x10022da1c
<idle>-0 [003] 9436.209718: timer_expire_exit timer=0xffffff80444f0428
kworker/u16:6-14217 [003] 9436.209863: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2b now=0x10022da1c flags=182452227
vendor.xxxyyy.ha-1593 [004] 9436.209888: timer_cancel timer=0xffffff80444f0428
vendor.xxxyyy.ha-1593 [004] 9436.216390: timer_init timer=0xffffff80444f0428
vendor.xxxyyy.ha-1593 [004] 9436.216392: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2c now=0x10022da1d flags=186646532
vendor.xxxyyy.ha-1593 [005] 9436.220992: timer_cancel timer=0xffffff80444f0428
xxxyyyTraceManag-7795 [004] 9436.261641: timer_cancel timer=0xffffff80444f0428
[2]
9436.261653][ C4] Unable to handle kernel paging request at virtual address dead00000000012a
[ 9436.261664][ C4] Mem abort info:
[ 9436.261666][ C4] ESR = 0x96000044
[ 9436.261669][ C4] EC = 0x25: DABT (current EL), IL = 32 bits
[ 9436.261671][ C4] SET = 0, FnV = 0
[ 9436.261673][ C4] EA = 0, S1PTW = 0
[ 9436.261675][ C4] Data abort info:
[ 9436.261677][ C4] ISV = 0, ISS = 0x00000044
[ 9436.261680][ C4] CM = 0, WnR = 1
[ 9436.261682][ C4] [dead00000000012a] address between user and kernel address ranges
[ 9436.261685][ C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP
[ 9436.261701][ C4] Skip md ftrace buffer dump for: 0x3a982d0
...
[ 9436.262138][ C4] CPU: 4 PID: 7795 Comm: TraceManag Tainted: G S W O 5.10.149-android12-9-o-g17f915d29d0c #1
[ 9436.262141][ C4] Hardware name: Qualcomm Technologies, Inc. (DT)
[ 9436.262144][ C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--)
[ 9436.262161][ C4] pc : expire_timers+0x9c/0x438
[ 9436.262164][ C4] lr : expire_timers+0x2a4/0x438
[ 9436.262168][ C4] sp : ffffffc010023dd0
[ 9436.262171][ C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18
[ 9436.262178][ C4] x27: ffffffd063569dd0 x26: ffffffd063536008
[ 9436.262182][ C4] x25: 0000000000000001 x24: ffffff88f7c69280
[ 9436.262185][ C4] x23: 00000000000000e0 x22: dead000000000122
[ 9436.262188][ C4] x21: 000000010022da29 x20: ffffff8af72b4e80
[ 9436.262191][ C4] x19: ffffffc010023e50 x18: ffffffc010025038
[ 9436.262195][ C4] x17: 0000000000000240 x16: 0000000000000201
[ 9436.262199][ C4] x15: ffffffffffffffff x14: ffffff889f3c3100
[ 9436.262203][ C4] x13: ffffff889f3c3100 x12: 00000000049f56b8
[ 9436.262207][ C4] x11: 00000000049f56b8 x10: 00000000ffffffff
[ 9436.262212][ C4] x9 : ffffffc010023e50 x8 : dead000000000122
[ 9436.262216][ C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8
[ 9436.262220][ C4] x5 : 0000000000000000 x4 : 0000000000000101
[ 9436.262223][ C4] x3 : 0000000000000080 x2 : ffffff8
---truncated--- |
["https://git.kernel.org/stable/c/099f6a9edbe30b142c1d97fe9a4748601d995675","https://git.kernel.org/stable/c/0aedb319ef3ed39e9e5a7b7726c8264ca627bbd9","https://git.kernel.org/stable/c/31569995fc65007b73a3fff605ec2b3401b435e9","https://git.kernel.org/stable/c/3399cc7013e761fee9d6eec795e9b31ab0cbe475","https://git.kernel.org/stable/c/ae815e2fdc284ab31651d52460698bd89c0fce22","https://git.kernel.org/stable/c/aed5ed595960c6d301dcd4ed31aeaa7a8054c0c6","https://git.kernel.org/stable/c/099f6a9edbe30b142c1d97fe9a4748601d995675","https://git.kernel.org/stable/c/0aedb319ef3ed39e9e5a7b7726c8264ca627bbd9","https://git.kernel.org/stable/c/31569995fc65007b73a3fff605ec2b3401b435e9","https://git.kernel.org/stable/c/3399cc7013e761fee9d6eec795e9b31ab0cbe475","https://git.kernel.org/stable/c/ae815e2fdc284ab31651d52460698bd89c0fce22","https://git.kernel.org/stable/c/aed5ed595960c6d301dcd4ed31aeaa7a8054c0c6","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48619
|
Medium |
fixed |
|
An issue was discovered in drivers/input/input.c in the Linux kernel before 5.17.10. An attacker can cause a denial of service (panic) because input_set_capability mishandles the situation in which an event code falls outside of a bitmap. |
["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.10","https://github.com/torvalds/linux/commit/409353cbe9fe48f6bc196114c442b1cff05a39bc","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.10","https://github.com/torvalds/linux/commit/409353cbe9fe48f6bc196114c442b1cff05a39bc"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52590
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: Avoid touching renamed directory if parent does not change
The VFS will not be locking moved directory if its parent does not
change. Change ocfs2 rename code to avoid touching renamed directory if
its parent does not change as without locking that can corrupt the
filesystem. |
["https://git.kernel.org/stable/c/9d618d19b29c2943527e3a43da0a35aea91062fc","https://git.kernel.org/stable/c/de940cede3c41624e2de27f805b490999f419df9","https://git.kernel.org/stable/c/9d618d19b29c2943527e3a43da0a35aea91062fc","https://git.kernel.org/stable/c/de940cede3c41624e2de27f805b490999f419df9"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26808
|
Medium |
fixed |
- 5.10.210
- 5.15.149
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechain
Remove netdevice from inet/ingress basechain in case NETDEV_UNREGISTER
event is reported, otherwise a stale reference to netdevice remains in
the hook list. |
["https://git.kernel.org/stable/c/01acb2e8666a6529697141a6017edbf206921913","https://git.kernel.org/stable/c/36a0a80f32209238469deb481967d777a3d539ee","https://git.kernel.org/stable/c/70f17b48c86622217a58d5099d29242fc9adac58","https://git.kernel.org/stable/c/9489e214ea8f2a90345516016aa51f2db3a8cc2f","https://git.kernel.org/stable/c/af149a46890e8285d1618bd68b8d159bdb87fdb3","https://git.kernel.org/stable/c/e5888acbf1a3d8d021990ce6c6061fd5b2bb21b4","https://git.kernel.org/stable/c/01acb2e8666a6529697141a6017edbf206921913","https://git.kernel.org/stable/c/36a0a80f32209238469deb481967d777a3d539ee","https://git.kernel.org/stable/c/70f17b48c86622217a58d5099d29242fc9adac58","https://git.kernel.org/stable/c/9489e214ea8f2a90345516016aa51f2db3a8cc2f","https://git.kernel.org/stable/c/af149a46890e8285d1618bd68b8d159bdb87fdb3","https://git.kernel.org/stable/c/e5888acbf1a3d8d021990ce6c6061fd5b2bb21b4","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4569
|
Medium |
fixed |
|
A memory leak flaw was found in nft_set_catchall_flush in net/netfilter/nf_tables_api.c in the Linux Kernel. This issue may allow a local attacker to cause double-deactivations of catchall elements, which can result in a memory leak. |
["https://access.redhat.com/security/cve/CVE-2023-4569","https://bugzilla.redhat.com/show_bug.cgi?id=2235470","https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230812110526.49808-1-fw@strlen.de/","https://www.debian.org/security/2023/dsa-5492","https://access.redhat.com/security/cve/CVE-2023-4569","https://bugzilla.redhat.com/show_bug.cgi?id=2235470","https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230812110526.49808-1-fw@strlen.de/","https://www.debian.org/security/2023/dsa-5492"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52627
|
Medium |
fixed |
- 5.10.210
- 5.15.149
- 6.1.76
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: ad7091r: Allow users to configure device events
AD7091R-5 devices are supported by the ad7091r-5 driver together with
the ad7091r-base driver. Those drivers declared iio events for notifying
user space when ADC readings fall bellow the thresholds of low limit
registers or above the values set in high limit registers.
However, to configure iio events and their thresholds, a set of callback
functions must be implemented and those were not present until now.
The consequence of trying to configure ad7091r-5 events without the
proper callback functions was a null pointer dereference in the kernel
because the pointers to the callback functions were not set.
Implement event configuration callbacks allowing users to read/write
event thresholds and enable/disable event generation.
Since the event spec structs are generic to AD7091R devices, also move
those from the ad7091r-5 driver the base driver so they can be reused
when support for ad7091r-2/-4/-8 be added. |
["https://git.kernel.org/stable/c/020e71c7ffc25dfe29ed9be6c2d39af7bd7f661f","https://git.kernel.org/stable/c/137568aa540a9f587c48ff7d4c51cdba08cfe9a4","https://git.kernel.org/stable/c/1eba6f7ffa295a0eec098c107043074be7cc4ec5","https://git.kernel.org/stable/c/49f322ce1f265935f15e5512da69a399f27a5091","https://git.kernel.org/stable/c/55aca2ce91a63740278502066beaddbd841af9c6","https://git.kernel.org/stable/c/89c4e63324e208a23098f7fb15c00487cecbfed2","https://git.kernel.org/stable/c/020e71c7ffc25dfe29ed9be6c2d39af7bd7f661f","https://git.kernel.org/stable/c/137568aa540a9f587c48ff7d4c51cdba08cfe9a4","https://git.kernel.org/stable/c/1eba6f7ffa295a0eec098c107043074be7cc4ec5","https://git.kernel.org/stable/c/49f322ce1f265935f15e5512da69a399f27a5091","https://git.kernel.org/stable/c/55aca2ce91a63740278502066beaddbd841af9c6","https://git.kernel.org/stable/c/89c4e63324e208a23098f7fb15c00487cecbfed2","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-23850
|
Medium |
|
N/A
|
In btrfs_get_root_ref in fs/btrfs/disk-io.c in the Linux kernel through 6.7.1, there can be an assertion failure and crash because a subvolume can be read out too soon after its root item is inserted upon subvolume creation. |
["https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/EZOU3745CWCDZ7EMKMXB2OEEIB5Q3IWM/","https://lore.kernel.org/all/6a80cb4b32af89787dadee728310e5e2ca85343f.1705741883.git.wqu%40suse.com/","https://lore.kernel.org/lkml/CALGdzuo6awWdau3X=8XK547x2vX_-VoFmH1aPsqosRTQ5WzJVA%40mail.gmail.com/","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/EZOU3745CWCDZ7EMKMXB2OEEIB5Q3IWM/","https://lore.kernel.org/all/6a80cb4b32af89787dadee728310e5e2ca85343f.1705741883.git.wqu%40suse.com/","https://lore.kernel.org/lkml/CALGdzuo6awWdau3X=8XK547x2vX_-VoFmH1aPsqosRTQ5WzJVA%40mail.gmail.com/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26615
|
Medium |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.76
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix illegal rmb_desc access in SMC-D connection dump
A crash was found when dumping SMC-D connections. It can be reproduced
by following steps:
- run nginx/wrk test:
smc_run nginx
smc_run wrk -t 16 -c 1000 -d <duration> -H 'Connection: Close' <URL>
- continuously dump SMC-D connections in parallel:
watch -n 1 'smcss -D'
BUG: kernel NULL pointer dereference, address: 0000000000000030
CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55
RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]
Call Trace:
<TASK>
? __die+0x24/0x70
? page_fault_oops+0x66/0x150
? exc_page_fault+0x69/0x140
? asm_exc_page_fault+0x26/0x30
? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]
? __kmalloc_node_track_caller+0x35d/0x430
? __alloc_skb+0x77/0x170
smc_diag_dump_proto+0xd0/0xf0 [smc_diag]
smc_diag_dump+0x26/0x60 [smc_diag]
netlink_dump+0x19f/0x320
__netlink_dump_start+0x1dc/0x300
smc_diag_handler_dump+0x6a/0x80 [smc_diag]
? __pfx_smc_diag_dump+0x10/0x10 [smc_diag]
sock_diag_rcv_msg+0x121/0x140
? __pfx_sock_diag_rcv_msg+0x10/0x10
netlink_rcv_skb+0x5a/0x110
sock_diag_rcv+0x28/0x40
netlink_unicast+0x22a/0x330
netlink_sendmsg+0x1f8/0x420
__sock_sendmsg+0xb0/0xc0
____sys_sendmsg+0x24e/0x300
? copy_msghdr_from_user+0x62/0x80
___sys_sendmsg+0x7c/0xd0
? __do_fault+0x34/0x160
? do_read_fault+0x5f/0x100
? do_fault+0xb0/0x110
? __handle_mm_fault+0x2b0/0x6c0
__sys_sendmsg+0x4d/0x80
do_syscall_64+0x69/0x180
entry_SYSCALL_64_after_hwframe+0x6e/0x76
It is possible that the connection is in process of being established
when we dump it. Assumed that the connection has been registered in a
link group by smc_conn_create() but the rmb_desc has not yet been
initialized by smc_buf_create(), thus causing the illegal access to
conn->rmb_desc. So fix it by checking before dump. |
["https://git.kernel.org/stable/c/1fea9969b81c67d0cb1611d1b8b7d19049d937be","https://git.kernel.org/stable/c/27aea64838914c6122db5b8bd4bed865c9736f22","https://git.kernel.org/stable/c/5fed92ca32eafbfae8b6bee8ca34cca71c6a8b6d","https://git.kernel.org/stable/c/68b888d51ac82f2b96bf5e077a31d76afcdef25a","https://git.kernel.org/stable/c/6994dba06321e3c48fdad0ba796a063d9d82183a","https://git.kernel.org/stable/c/8f3f9186e5bb96a9c9654c41653210e3ea7e48a6","https://git.kernel.org/stable/c/a164c2922675d7051805cdaf2b07daffe44f20d9","https://git.kernel.org/stable/c/dbc153fd3c142909e564bb256da087e13fbf239c","https://git.kernel.org/stable/c/1fea9969b81c67d0cb1611d1b8b7d19049d937be","https://git.kernel.org/stable/c/27aea64838914c6122db5b8bd4bed865c9736f22","https://git.kernel.org/stable/c/5fed92ca32eafbfae8b6bee8ca34cca71c6a8b6d","https://git.kernel.org/stable/c/68b888d51ac82f2b96bf5e077a31d76afcdef25a","https://git.kernel.org/stable/c/6994dba06321e3c48fdad0ba796a063d9d82183a","https://git.kernel.org/stable/c/8f3f9186e5bb96a9c9654c41653210e3ea7e48a6","https://git.kernel.org/stable/c/a164c2922675d7051805cdaf2b07daffe44f20d9","https://git.kernel.org/stable/c/dbc153fd3c142909e564bb256da087e13fbf239c","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26879
|
Medium |
fixed |
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
clk: meson: Add missing clocks to axg_clk_regmaps
Some clocks were missing from axg_clk_regmaps, which caused kernel panic
during cat /sys/kernel/debug/clk/clk_summary
[ 57.349402] Unable to handle kernel NULL pointer dereference at virtual address 00000000000001fc
...
[ 57.430002] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 57.436900] pc : regmap_read+0x1c/0x88
[ 57.440608] lr : clk_regmap_gate_is_enabled+0x3c/0xb0
[ 57.445611] sp : ffff800082f1b690
[ 57.448888] x29: ffff800082f1b690 x28: 0000000000000000 x27: ffff800080eb9a70
[ 57.455961] x26: 0000000000000007 x25: 0000000000000016 x24: 0000000000000000
[ 57.463033] x23: ffff800080e8b488 x22: 0000000000000015 x21: ffff00000e7e7000
[ 57.470106] x20: ffff00000400ec00 x19: 0000000000000000 x18: ffffffffffffffff
[ 57.477178] x17: 0000000000000000 x16: 0000000000000000 x15: ffff0000042a3000
[ 57.484251] x14: 0000000000000000 x13: ffff0000042a2fec x12: 0000000005f5e100
[ 57.491323] x11: abcc77118461cefd x10: 0000000000000020 x9 : ffff8000805e4b24
[ 57.498396] x8 : ffff0000028063c0 x7 : ffff800082f1b710 x6 : ffff800082f1b710
[ 57.505468] x5 : 00000000ffffffd0 x4 : ffff800082f1b6e0 x3 : 0000000000001000
[ 57.512541] x2 : ffff800082f1b6e4 x1 : 000000000000012c x0 : 0000000000000000
[ 57.519615] Call trace:
[ 57.522030] regmap_read+0x1c/0x88
[ 57.525393] clk_regmap_gate_is_enabled+0x3c/0xb0
[ 57.530050] clk_core_is_enabled+0x44/0x120
[ 57.534190] clk_summary_show_subtree+0x154/0x2f0
[ 57.538847] clk_summary_show_subtree+0x220/0x2f0
[ 57.543505] clk_summary_show_subtree+0x220/0x2f0
[ 57.548162] clk_summary_show_subtree+0x220/0x2f0
[ 57.552820] clk_summary_show_subtree+0x220/0x2f0
[ 57.557477] clk_summary_show_subtree+0x220/0x2f0
[ 57.562135] clk_summary_show_subtree+0x220/0x2f0
[ 57.566792] clk_summary_show_subtree+0x220/0x2f0
[ 57.571450] clk_summary_show+0x84/0xb8
[ 57.575245] seq_read_iter+0x1bc/0x4b8
[ 57.578954] seq_read+0x8c/0xd0
[ 57.582059] full_proxy_read+0x68/0xc8
[ 57.585767] vfs_read+0xb0/0x268
[ 57.588959] ksys_read+0x70/0x108
[ 57.592236] __arm64_sys_read+0x24/0x38
[ 57.596031] invoke_syscall+0x50/0x128
[ 57.599740] el0_svc_common.constprop.0+0x48/0xf8
[ 57.604397] do_el0_svc+0x28/0x40
[ 57.607675] el0_svc+0x34/0xb8
[ 57.610694] el0t_64_sync_handler+0x13c/0x158
[ 57.615006] el0t_64_sync+0x190/0x198
[ 57.618635] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (b941fc00)
[ 57.624668] ---[ end trace 0000000000000000 ]---
[jbrunet: add missing Fixes tag] |
["https://git.kernel.org/stable/c/0cbefc7b5bdad86b18a263d837450cdc9a56f8d7","https://git.kernel.org/stable/c/7ae1b0dc12ec407f12f80b49d22c6ad2308e2202","https://git.kernel.org/stable/c/9f3e5df38b4528213449e55b80f0316864f2a1c8","https://git.kernel.org/stable/c/a03ed00787b0ce7a83eebabd0fa95ecc4a5cac84","https://git.kernel.org/stable/c/a860aaebacbc908fa06e2642402058f40bfffe10","https://git.kernel.org/stable/c/ba535bce57e71463a86f8b33a0ea88c26e3a6418","https://git.kernel.org/stable/c/0cbefc7b5bdad86b18a263d837450cdc9a56f8d7","https://git.kernel.org/stable/c/7ae1b0dc12ec407f12f80b49d22c6ad2308e2202","https://git.kernel.org/stable/c/9f3e5df38b4528213449e55b80f0316864f2a1c8","https://git.kernel.org/stable/c/a03ed00787b0ce7a83eebabd0fa95ecc4a5cac84","https://git.kernel.org/stable/c/a860aaebacbc908fa06e2642402058f40bfffe10","https://git.kernel.org/stable/c/ba535bce57e71463a86f8b33a0ea88c26e3a6418"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-39198
|
Medium |
fixed |
|
A race condition was found in the QXL driver in the Linux kernel. The qxl_mode_dumb_create() function dereferences the qobj returned by the qxl_gem_object_create_with_handle(), but the handle is the only one holding a reference to it. This flaw allows an attacker to guess the returned handle value and trigger a use-after-free issue, potentially leading to a denial of service or privilege escalation. |
["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-39198","https://bugzilla.redhat.com/show_bug.cgi?id=2218332","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-39198","https://bugzilla.redhat.com/show_bug.cgi?id=2218332","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4155
|
Medium |
|
N/A
|
A flaw was found in KVM AMD Secure Encrypted Virtualization (SEV) in the Linux kernel. A KVM guest using SEV-ES or SEV-SNP with multiple vCPUs can trigger a double fetch race condition vulnerability and invoke the `VMGEXIT` handler recursively. If an attacker manages to call the handler multiple times, they can trigger a stack overflow and cause a denial of service or potentially guest-to-host escape in kernel configurations without stack guard pages (`CONFIG_VMAP_STACK`). |
["https://access.redhat.com/security/cve/CVE-2023-4155","https://bugzilla.redhat.com/show_bug.cgi?id=2213802","https://access.redhat.com/security/cve/CVE-2023-4155","https://bugzilla.redhat.com/show_bug.cgi?id=2213802"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-0854
|
Medium |
|
N/A
|
A memory leak flaw was found in the Linux kernel’s DMA subsystem, in the way a user calls DMA_FROM_DEVICE. This flaw allows a local user to read random memory from the kernel space. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel/dma/swiotlb.c?h=v5.17-rc8\u0026id=aa6f8dcbab473f3a3c7454b74caa46d36cdc5d13","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://www.debian.org/security/2022/dsa-5161","https://www.debian.org/security/2022/dsa-5173","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel/dma/swiotlb.c?h=v5.17-rc8\u0026id=aa6f8dcbab473f3a3c7454b74caa46d36cdc5d13","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://www.debian.org/security/2022/dsa-5161","https://www.debian.org/security/2022/dsa-5173"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1611
|
Medium |
fixed |
- 5.10.177
- 5.15.106
- 6.1.23
- 6.2.10
|
A use-after-free flaw was found in btrfs_search_slot in fs/btrfs/ctree.c in btrfs in the Linux Kernel.This flaw allows an attacker to crash the system and possibly cause a kernel information lea |
["https://bugzilla.redhat.com/show_bug.cgi?id=2181342","https://github.com/torvalds/linux/commit/2f1a6be12ab6c8470d5776e68644726c94257c54","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/5QCM6XO4HSPLGR3DFYWFRIA3GCBIHZR4/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ZWECAZ7V7EPSXMINO6Q6KWNKDY2CO6ZW/","https://lore.kernel.org/linux-btrfs/35b9a70650ea947387cf352914a8774b4f7e8a6f.1679481128.git.fdmanana%40suse.com/","https://bugzilla.redhat.com/show_bug.cgi?id=2181342","https://github.com/torvalds/linux/commit/2f1a6be12ab6c8470d5776e68644726c94257c54","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/5QCM6XO4HSPLGR3DFYWFRIA3GCBIHZR4/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ZWECAZ7V7EPSXMINO6Q6KWNKDY2CO6ZW/","https://lore.kernel.org/linux-btrfs/35b9a70650ea947387cf352914a8774b4f7e8a6f.1679481128.git.fdmanana%40suse.com/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26869
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to truncate meta inode pages forcely
Below race case can cause data corruption:
Thread A GC thread
- gc_data_segment
- ra_data_block
- locked meta_inode page
- f2fs_inplace_write_data
- invalidate_mapping_pages
: fail to invalidate meta_inode page
due to lock failure or dirty|writeback
status
- f2fs_submit_page_bio
: write last dirty data to old blkaddr
- move_data_block
- load old data from meta_inode page
- f2fs_submit_page_write
: write old data to new blkaddr
Because invalidate_mapping_pages() will skip invalidating page which
has unclear status including locked, dirty, writeback and so on, so
we need to use truncate_inode_pages_range() instead of
invalidate_mapping_pages() to make sure meta_inode page will be dropped. |
["https://git.kernel.org/stable/c/04226d8e3c4028dc451e9d8777356ec0f7919253","https://git.kernel.org/stable/c/77bfdb89cc222fc7bfe198eda77bdc427d5ac189","https://git.kernel.org/stable/c/9f0c4a46be1fe9b97dbe66d49204c1371e3ece65","https://git.kernel.org/stable/c/c92f2927df860a60ba815d3ee610a944b92a8694","https://git.kernel.org/stable/c/04226d8e3c4028dc451e9d8777356ec0f7919253","https://git.kernel.org/stable/c/77bfdb89cc222fc7bfe198eda77bdc427d5ac189","https://git.kernel.org/stable/c/9f0c4a46be1fe9b97dbe66d49204c1371e3ece65","https://git.kernel.org/stable/c/c92f2927df860a60ba815d3ee610a944b92a8694"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26631
|
Medium |
fixed |
- 5.15.148
- 6.1.75
- 6.6.14
- 6.7.2
|
In the Linux kernel, the following vulnerability has been resolved:
ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work
idev->mc_ifc_count can be written over without proper locking.
Originally found by syzbot [1], fix this issue by encapsulating calls
to mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) with
mutex_lock() and mutex_unlock() accordingly as these functions
should only be called with mc_lock per their declarations.
[1]
BUG: KCSAN: data-race in ipv6_mc_down / mld_ifc_work
write to 0xffff88813a80c832 of 1 bytes by task 3771 on cpu 0:
mld_ifc_stop_work net/ipv6/mcast.c:1080 [inline]
ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725
addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949
addrconf_notify+0x310/0x980
notifier_call_chain kernel/notifier.c:93 [inline]
raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461
__dev_notify_flags+0x205/0x3d0
dev_change_flags+0xab/0xd0 net/core/dev.c:8685
do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916
rtnl_group_changelink net/core/rtnetlink.c:3458 [inline]
__rtnl_newlink net/core/rtnetlink.c:3717 [inline]
rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754
rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558
netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545
rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576
netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]
netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368
netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910
...
write to 0xffff88813a80c832 of 1 bytes by task 22 on cpu 1:
mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653
process_one_work kernel/workqueue.c:2627 [inline]
process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700
worker_thread+0x525/0x730 kernel/workqueue.c:2781
... |
["https://git.kernel.org/stable/c/2e7ef287f07c74985f1bf2858bedc62bd9ebf155","https://git.kernel.org/stable/c/380540bb06bb1d1b12bdc947d1b8f56cda6b5663","https://git.kernel.org/stable/c/3bb5849675ae1d592929798a2b37ea450879c855","https://git.kernel.org/stable/c/3cc283fd16fba72e2cefe3a6f48d7a36b0438900","https://git.kernel.org/stable/c/62b3387beef11738eb6ce667601a28fa089fa02c","https://git.kernel.org/stable/c/2e7ef287f07c74985f1bf2858bedc62bd9ebf155","https://git.kernel.org/stable/c/380540bb06bb1d1b12bdc947d1b8f56cda6b5663","https://git.kernel.org/stable/c/3bb5849675ae1d592929798a2b37ea450879c855","https://git.kernel.org/stable/c/3cc283fd16fba72e2cefe3a6f48d7a36b0438900","https://git.kernel.org/stable/c/62b3387beef11738eb6ce667601a28fa089fa02c"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-45887
|
Medium |
|
N/A
|
An issue was discovered in the Linux kernel through 6.0.9. drivers/media/usb/ttusb-dec/ttusb_dec.c has a memory leak because of the lack of a dvb_frontend_detach call. |
["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=517a281338322ff8293f988771c98aaa7205e457","https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/","https://lore.kernel.org/linux-media/20221115131822.6640-5-imv4bel%40gmail.com/","https://security.netapp.com/advisory/ntap-20230113-0006/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=517a281338322ff8293f988771c98aaa7205e457","https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/","https://lore.kernel.org/linux-media/20221115131822.6640-5-imv4bel%40gmail.com/","https://security.netapp.com/advisory/ntap-20230113-0006/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-39193
|
Medium |
fixed |
|
A flaw was found in the Netfilter subsystem in the Linux kernel. The sctp_mt_check did not validate the flag_count field. This flaw allows a local privileged (CAP_NET_ADMIN) attacker to trigger an out-of-bounds read, leading to a crash or information disclosure. |
["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-39193","https://bugzilla.redhat.com/show_bug.cgi?id=2226787","https://www.zerodayinitiative.com/advisories/ZDI-CAN-18866/","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-39193","https://bugzilla.redhat.com/show_bug.cgi?id=2226787","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.zerodayinitiative.com/advisories/ZDI-CAN-18866/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26894
|
Medium |
fixed |
- 4.19.311
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit()
After unregistering the CPU idle device, the memory associated with
it is not freed, leading to a memory leak:
unreferenced object 0xffff896282f6c000 (size 1024):
comm "swapper/0", pid 1, jiffies 4294893170
hex dump (first 32 bytes):
00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 8836a742):
[<ffffffff993495ed>] kmalloc_trace+0x29d/0x340
[<ffffffff9972f3b3>] acpi_processor_power_init+0xf3/0x1c0
[<ffffffff9972d263>] __acpi_processor_start+0xd3/0xf0
[<ffffffff9972d2bc>] acpi_processor_start+0x2c/0x50
[<ffffffff99805872>] really_probe+0xe2/0x480
[<ffffffff99805c98>] __driver_probe_device+0x78/0x160
[<ffffffff99805daf>] driver_probe_device+0x1f/0x90
[<ffffffff9980601e>] __driver_attach+0xce/0x1c0
[<ffffffff99803170>] bus_for_each_dev+0x70/0xc0
[<ffffffff99804822>] bus_add_driver+0x112/0x210
[<ffffffff99807245>] driver_register+0x55/0x100
[<ffffffff9aee4acb>] acpi_processor_driver_init+0x3b/0xc0
[<ffffffff990012d1>] do_one_initcall+0x41/0x300
[<ffffffff9ae7c4b0>] kernel_init_freeable+0x320/0x470
[<ffffffff99b231f6>] kernel_init+0x16/0x1b0
[<ffffffff99042e6d>] ret_from_fork+0x2d/0x50
Fix this by freeing the CPU idle device after unregistering it. |
["https://git.kernel.org/stable/c/1cbaf4c793b0808532f4e7b40bc4be7cec2c78f2","https://git.kernel.org/stable/c/3d48e5be107429ff5d824e7f2a00d1b610d36fbc","https://git.kernel.org/stable/c/8d14a4d0afb49a5b8535d414c782bb334860e73e","https://git.kernel.org/stable/c/c2a30c81bf3cb9033fa9f5305baf7c377075e2e5","https://git.kernel.org/stable/c/cd5c2d0b09d5b6d3f0a7bbabe6761a4997e9dee9","https://git.kernel.org/stable/c/d351bcadab6caa6d8ce7159ff4b77e2da35c09fa","https://git.kernel.org/stable/c/e18afcb7b2a12b635ac10081f943fcf84ddacc51","https://git.kernel.org/stable/c/ea96bf3f80625cddba1391a87613356b1b45716d","https://git.kernel.org/stable/c/fad9bcd4d754cc689c19dc04d2c44b82c1a5d6c8","https://git.kernel.org/stable/c/1cbaf4c793b0808532f4e7b40bc4be7cec2c78f2","https://git.kernel.org/stable/c/3d48e5be107429ff5d824e7f2a00d1b610d36fbc","https://git.kernel.org/stable/c/8d14a4d0afb49a5b8535d414c782bb334860e73e","https://git.kernel.org/stable/c/c2a30c81bf3cb9033fa9f5305baf7c377075e2e5","https://git.kernel.org/stable/c/cd5c2d0b09d5b6d3f0a7bbabe6761a4997e9dee9","https://git.kernel.org/stable/c/d351bcadab6caa6d8ce7159ff4b77e2da35c09fa","https://git.kernel.org/stable/c/e18afcb7b2a12b635ac10081f943fcf84ddacc51","https://git.kernel.org/stable/c/ea96bf3f80625cddba1391a87613356b1b45716d","https://git.kernel.org/stable/c/fad9bcd4d754cc689c19dc04d2c44b82c1a5d6c8","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-42755
|
Medium |
fixed |
|
A flaw was found in the IPv4 Resource Reservation Protocol (RSVP) classifier in the Linux kernel. The xprt pointer may go beyond the linear part of the skb, leading to an out-of-bounds read in the `rsvp_classify` function. This issue may allow a local user to crash the system and cause a denial of service. |
["https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-42755","https://bugzilla.redhat.com/show_bug.cgi?id=2239847","https://seclists.org/oss-sec/2023/q3/229","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-42755","https://bugzilla.redhat.com/show_bug.cgi?id=2239847","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://seclists.org/oss-sec/2023/q3/229"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1513
|
Low |
fixed |
|
A flaw was found in KVM. When calling the KVM_GET_DEBUGREGS ioctl, on 32-bit systems, there might be some uninitialized portions of the kvm_debugregs structure that could be copied to userspace, causing an information leak. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2179892","https://github.com/torvalds/linux/commit/2c10b61421a28e95a46ab489fd56c0f442ff6952","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/kvm/20230214103304.3689213-1-gregkh%40linuxfoundation.org/","https://bugzilla.redhat.com/show_bug.cgi?id=2179892","https://github.com/torvalds/linux/commit/2c10b61421a28e95a46ab489fd56c0f442ff6952","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/kvm/20230214103304.3689213-1-gregkh%40linuxfoundation.org/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26810
|
Medium |
fixed |
- 5.4.274
- 5.10.215
- 5.15.154
- 6.1.84
- 6.6.24
- 6.7.12
- 6.8.3
|
In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: Lock external INTx masking ops
Mask operations through config space changes to DisINTx may race INTx
configuration changes via ioctl. Create wrappers that add locking for
paths outside of the core interrupt code.
In particular, irq_type is updated holding igate, therefore testing
is_intx() requires holding igate. For example clearing DisINTx from
config space can otherwise race changes of the interrupt configuration.
This aligns interfaces which may trigger the INTx eventfd into two
camps, one side serialized by igate and the other only enabled while
INTx is configured. A subsequent patch introduces synchronization for
the latter flows. |
["https://git.kernel.org/stable/c/03505e3344b0576fd619416793a31eae9c5b73bf","https://git.kernel.org/stable/c/04a4a017b9ffd7b0f427b8c376688d14cb614651","https://git.kernel.org/stable/c/1e71b6449d55179170efc8dee8664510bb813b42","https://git.kernel.org/stable/c/3dd9be6cb55e0f47544e7cdda486413f7134e3b3","https://git.kernel.org/stable/c/3fe0ac10bd117df847c93408a9d428a453cd60e5","https://git.kernel.org/stable/c/6fe478d855b20ac1eb5da724afe16af5a2aaaa40","https://git.kernel.org/stable/c/810cd4bb53456d0503cc4e7934e063835152c1b7","https://git.kernel.org/stable/c/ec73e079729258a05452356cf6d098bf1504d5a6","https://git.kernel.org/stable/c/03505e3344b0576fd619416793a31eae9c5b73bf","https://git.kernel.org/stable/c/04a4a017b9ffd7b0f427b8c376688d14cb614651","https://git.kernel.org/stable/c/1e71b6449d55179170efc8dee8664510bb813b42","https://git.kernel.org/stable/c/3dd9be6cb55e0f47544e7cdda486413f7134e3b3","https://git.kernel.org/stable/c/3fe0ac10bd117df847c93408a9d428a453cd60e5","https://git.kernel.org/stable/c/6fe478d855b20ac1eb5da724afe16af5a2aaaa40","https://git.kernel.org/stable/c/810cd4bb53456d0503cc4e7934e063835152c1b7","https://git.kernel.org/stable/c/ec73e079729258a05452356cf6d098bf1504d5a6","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26855
|
Medium |
fixed |
- 5.4.272
- 5.10.213
- 5.15.152
- 6.1.82
- 6.6.22
- 6.7.10
|
In the Linux kernel, the following vulnerability has been resolved:
net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink()
The function ice_bridge_setlink() may encounter a NULL pointer dereference
if nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently
in nla_for_each_nested(). To address this issue, add a check to ensure that
br_spec is not NULL before proceeding with the nested attribute iteration. |
["https://git.kernel.org/stable/c/06e456a05d669ca30b224b8ed962421770c1496c","https://git.kernel.org/stable/c/0e296067ae0d74a10b4933601f9aa9f0ec8f157f","https://git.kernel.org/stable/c/1a770927dc1d642b22417c3e668c871689fc58b3","https://git.kernel.org/stable/c/37fe99016b12d32100ce670216816dba6c48b309","https://git.kernel.org/stable/c/8d95465d9a424200485792858c5b3be54658ce19","https://git.kernel.org/stable/c/afdd29726a6de4ba27cd15590661424c888dc596","https://git.kernel.org/stable/c/d9fefc51133107e59d192d773be86c1150cfeebb","https://git.kernel.org/stable/c/06e456a05d669ca30b224b8ed962421770c1496c","https://git.kernel.org/stable/c/0e296067ae0d74a10b4933601f9aa9f0ec8f157f","https://git.kernel.org/stable/c/1a770927dc1d642b22417c3e668c871689fc58b3","https://git.kernel.org/stable/c/37fe99016b12d32100ce670216816dba6c48b309","https://git.kernel.org/stable/c/8d95465d9a424200485792858c5b3be54658ce19","https://git.kernel.org/stable/c/afdd29726a6de4ba27cd15590661424c888dc596","https://git.kernel.org/stable/c/d9fefc51133107e59d192d773be86c1150cfeebb","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26719
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
nouveau: offload fence uevents work to workqueue
This should break the deadlock between the fctx lock and the irq lock.
This offloads the processing off the work from the irq into a workqueue. |
["https://git.kernel.org/stable/c/39126abc5e20611579602f03b66627d7cd1422f0","https://git.kernel.org/stable/c/985d053f7633d8b539ab1531738d538efac678a9","https://git.kernel.org/stable/c/cc0037fa592d56e4abb9c7d1c52c4d2dc25cd906","https://git.kernel.org/stable/c/39126abc5e20611579602f03b66627d7cd1422f0","https://git.kernel.org/stable/c/985d053f7633d8b539ab1531738d538efac678a9","https://git.kernel.org/stable/c/cc0037fa592d56e4abb9c7d1c52c4d2dc25cd906"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-2162
|
Medium |
fixed |
|
A use-after-free vulnerability was found in iscsi_sw_tcp_session_create in drivers/scsi/iscsi_tcp.c in SCSI sub-component in the Linux Kernel. In this flaw an attacker could leak kernel internal information. |
["https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://www.spinics.net/lists/linux-scsi/msg181542.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://www.spinics.net/lists/linux-scsi/msg181542.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26635
|
Medium |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.76
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
llc: Drop support for ETH_P_TR_802_2.
syzbot reported an uninit-value bug below. [0]
llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2
(0x0011), and syzbot abused the latter to trigger the bug.
write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16)
llc_conn_handler() initialises local variables {saddr,daddr}.mac
based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes
them to __llc_lookup().
However, the initialisation is done only when skb->protocol is
htons(ETH_P_802_2), otherwise, __llc_lookup_established() and
__llc_lookup_listener() will read garbage.
The missing initialisation existed prior to commit 211ed865108e
("net: delete all instances of special processing for token ring").
It removed the part to kick out the token ring stuff but forgot to
close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().
Let's remove llc_tr_packet_type and complete the deprecation.
[0]:
BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90
__llc_lookup_established+0xe9d/0xf90
__llc_lookup net/llc/llc_conn.c:611 [inline]
llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791
llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
__netif_receive_skb_one_core net/core/dev.c:5527 [inline]
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641
netif_receive_skb_internal net/core/dev.c:5727 [inline]
netif_receive_skb+0x58/0x660 net/core/dev.c:5786
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
call_write_iter include/linux/fs.h:2020 [inline]
new_sync_write fs/read_write.c:491 [inline]
vfs_write+0x8ef/0x1490 fs/read_write.c:584
ksys_write+0x20f/0x4c0 fs/read_write.c:637
__do_sys_write fs/read_write.c:649 [inline]
__se_sys_write fs/read_write.c:646 [inline]
__x64_sys_write+0x93/0xd0 fs/read_write.c:646
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Local variable daddr created at:
llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783
llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023 |
["https://git.kernel.org/stable/c/165ad1e22779685c3ed3dd349c6c4c632309cc62","https://git.kernel.org/stable/c/660c3053d992b68fee893a0e9ec9159228cffdc6","https://git.kernel.org/stable/c/9ccdef19cf9497c2803b005369668feb91cacdfd","https://git.kernel.org/stable/c/b8e8838f82f332ae80c643dbb1ca4418d0628097","https://git.kernel.org/stable/c/c0fe2fe7a5a291dfcf6dc64301732c8d3dc6a828","https://git.kernel.org/stable/c/df57fc2f2abf548aa889a36ab0bdcc94a75399dc","https://git.kernel.org/stable/c/e3f9bed9bee261e3347131764e42aeedf1ffea61","https://git.kernel.org/stable/c/f1f34a515fb1e25e85dee94f781e7869ae351fb8","https://git.kernel.org/stable/c/165ad1e22779685c3ed3dd349c6c4c632309cc62","https://git.kernel.org/stable/c/660c3053d992b68fee893a0e9ec9159228cffdc6","https://git.kernel.org/stable/c/9ccdef19cf9497c2803b005369668feb91cacdfd","https://git.kernel.org/stable/c/b8e8838f82f332ae80c643dbb1ca4418d0628097","https://git.kernel.org/stable/c/c0fe2fe7a5a291dfcf6dc64301732c8d3dc6a828","https://git.kernel.org/stable/c/df57fc2f2abf548aa889a36ab0bdcc94a75399dc","https://git.kernel.org/stable/c/e3f9bed9bee261e3347131764e42aeedf1ffea61","https://git.kernel.org/stable/c/f1f34a515fb1e25e85dee94f781e7869ae351fb8","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26636
|
Medium |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.76
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
llc: make llc_ui_sendmsg() more robust against bonding changes
syzbot was able to trick llc_ui_sendmsg(), allocating an skb with no
headroom, but subsequently trying to push 14 bytes of Ethernet header [1]
Like some others, llc_ui_sendmsg() releases the socket lock before
calling sock_alloc_send_skb().
Then it acquires it again, but does not redo all the sanity checks
that were performed.
This fix:
- Uses LL_RESERVED_SPACE() to reserve space.
- Check all conditions again after socket lock is held again.
- Do not account Ethernet header for mtu limitation.
[1]
skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0
kernel BUG at net/core/skbuff.c:193 !
Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : skb_panic net/core/skbuff.c:189 [inline]
pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
lr : skb_panic net/core/skbuff.c:189 [inline]
lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
sp : ffff800096f97000
x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000
x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2
x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0
x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce
x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001
x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400
x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000
x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714
x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089
Call trace:
skb_panic net/core/skbuff.c:189 [inline]
skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
skb_push+0xf0/0x108 net/core/skbuff.c:2451
eth_header+0x44/0x1f8 net/ethernet/eth.c:83
dev_hard_header include/linux/netdevice.h:3188 [inline]
llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33
llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85
llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]
llc_sap_next_state net/llc/llc_sap.c:182 [inline]
llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209
llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270
llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
sock_sendmsg+0x194/0x274 net/socket.c:767
splice_to_socket+0x7cc/0xd58 fs/splice.c:881
do_splice_from fs/splice.c:933 [inline]
direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142
splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088
do_splice_direct+0x20c/0x348 fs/splice.c:1194
do_sendfile+0x4bc/0xc70 fs/read_write.c:1254
__do_sys_sendfile64 fs/read_write.c:1322 [inline]
__se_sys_sendfile64 fs/read_write.c:1308 [inline]
__arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308
__invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155
el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678
el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595
Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000) |
["https://git.kernel.org/stable/c/04f2a74b562f3a7498be0399309669f342793d8c","https://git.kernel.org/stable/c/6d53b813ff8b177f86f149c2f744442681f720e4","https://git.kernel.org/stable/c/84e9d10419f6f4f3f3cd8f9aaf44a48719aa4b1b","https://git.kernel.org/stable/c/b643d0defcbacd7fe548bc65c3e4e6f17dc5eb2d","https://git.kernel.org/stable/c/c22044270da68881074fda81a7d34812726cb249","https://git.kernel.org/stable/c/c451c008f563d56d5e676c9dcafae565fcad84bb","https://git.kernel.org/stable/c/cafd3ad3fe03ef4d6632747be9ee15dc0029db4b","https://git.kernel.org/stable/c/dad555c816a50c6a6a8a86be1f9177673918c647","https://git.kernel.org/stable/c/04f2a74b562f3a7498be0399309669f342793d8c","https://git.kernel.org/stable/c/6d53b813ff8b177f86f149c2f744442681f720e4","https://git.kernel.org/stable/c/84e9d10419f6f4f3f3cd8f9aaf44a48719aa4b1b","https://git.kernel.org/stable/c/b643d0defcbacd7fe548bc65c3e4e6f17dc5eb2d","https://git.kernel.org/stable/c/c22044270da68881074fda81a7d34812726cb249","https://git.kernel.org/stable/c/c451c008f563d56d5e676c9dcafae565fcad84bb","https://git.kernel.org/stable/c/cafd3ad3fe03ef4d6632747be9ee15dc0029db4b","https://git.kernel.org/stable/c/dad555c816a50c6a6a8a86be1f9177673918c647","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26645
|
Medium |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.76
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
tracing: Ensure visibility when inserting an element into tracing_map
Running the following two commands in parallel on a multi-processor
AArch64 machine can sporadically produce an unexpected warning about
duplicate histogram entries:
$ while true; do
echo hist:key=id.syscall:val=hitcount > \
/sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger
cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist
sleep 0.001
done
$ stress-ng --sysbadaddr $(nproc)
The warning looks as follows:
[ 2911.172474] ------------[ cut here ]------------
[ 2911.173111] Duplicates detected: 1
[ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408
[ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E)
[ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1
[ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01
[ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018
[ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408
[ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408
[ 2911.185310] sp : ffff8000a1513900
[ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001
[ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008
[ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180
[ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff
[ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8
[ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731
[ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c
[ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8
[ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000
[ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480
[ 2911.194259] Call trace:
[ 2911.194626] tracing_map_sort_entries+0x3e0/0x408
[ 2911.195220] hist_show+0x124/0x800
[ 2911.195692] seq_read_iter+0x1d4/0x4e8
[ 2911.196193] seq_read+0xe8/0x138
[ 2911.196638] vfs_read+0xc8/0x300
[ 2911.197078] ksys_read+0x70/0x108
[ 2911.197534] __arm64_sys_read+0x24/0x38
[ 2911.198046] invoke_syscall+0x78/0x108
[ 2911.198553] el0_svc_common.constprop.0+0xd0/0xf8
[ 2911.199157] do_el0_svc+0x28/0x40
[ 2911.199613] el0_svc+0x40/0x178
[ 2911.200048] el0t_64_sync_handler+0x13c/0x158
[ 2911.200621] el0t_64_sync+0x1a8/0x1b0
[ 2911.201115] ---[ end trace 0000000000000000 ]---
The problem appears to be caused by CPU reordering of writes issued from
__tracing_map_insert().
The check for the presence of an element with a given key in this
function is:
val = READ_ONCE(entry->val);
if (val && keys_match(key, val->key, map->key_size)) ...
The write of a new entry is:
elt = get_free_elt(map);
memcpy(elt->key, key, map->key_size);
entry->val = elt;
The "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;"
stores may become visible in the reversed order on another CPU. This
second CPU might then incorrectly determine that a new key doesn't match
an already present val->key and subse
---truncated--- |
["https://git.kernel.org/stable/c/2b44760609e9eaafc9d234a6883d042fc21132a7","https://git.kernel.org/stable/c/5022b331c041e8c54b9a6a3251579bd1e8c0fc0b","https://git.kernel.org/stable/c/a1eebe76e187dbe11ca299f8dbb6e45d5b1889e7","https://git.kernel.org/stable/c/aef1cb00856ccfd614467cfb50b791278992e177","https://git.kernel.org/stable/c/bf4aeff7da85c3becd39fb73bac94122331c30fb","https://git.kernel.org/stable/c/dad9b28f675ed99b4dec261db2a397efeb80b74c","https://git.kernel.org/stable/c/ef70dfa0b1e5084f32635156c9a5c795352ad860","https://git.kernel.org/stable/c/f4f7e696db0274ff560482cc52eddbf0551d4b7a","https://git.kernel.org/stable/c/2b44760609e9eaafc9d234a6883d042fc21132a7","https://git.kernel.org/stable/c/5022b331c041e8c54b9a6a3251579bd1e8c0fc0b","https://git.kernel.org/stable/c/a1eebe76e187dbe11ca299f8dbb6e45d5b1889e7","https://git.kernel.org/stable/c/aef1cb00856ccfd614467cfb50b791278992e177","https://git.kernel.org/stable/c/bf4aeff7da85c3becd39fb73bac94122331c30fb","https://git.kernel.org/stable/c/dad9b28f675ed99b4dec261db2a397efeb80b74c","https://git.kernel.org/stable/c/ef70dfa0b1e5084f32635156c9a5c795352ad860","https://git.kernel.org/stable/c/f4f7e696db0274ff560482cc52eddbf0551d4b7a","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26805
|
Medium |
fixed |
- 3.13
- 3.15
- 3.19
- 4.2
- 4.19.309
- 5.4.271
- 5.10.212
- 5.15.151
- 6.1.81
- 6.6.21
- 6.7.9
|
In the Linux kernel, the following vulnerability has been resolved:
netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter
syzbot reported the following uninit-value access issue [1]:
netlink_to_full_skb() creates a new `skb` and puts the `skb->data`
passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The data
size is specified as `len` and passed to skb_put_data(). This `len`
is based on `skb->end` that is not data offset but buffer offset. The
`skb->end` contains data and tailroom. Since the tailroom is not
initialized when the new `skb` created, KMSAN detects uninitialized
memory area when copying the data.
This patch resolved this issue by correct the len from `skb->end` to
`skb->len`, which is the actual data offset.
BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline]
BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline]
BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline]
BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
copy_to_user_iter lib/iov_iter.c:24 [inline]
iterate_ubuf include/linux/iov_iter.h:29 [inline]
iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
iterate_and_advance include/linux/iov_iter.h:271 [inline]
_copy_to_iter+0x364/0x2520 lib/iov_iter.c:186
copy_to_iter include/linux/uio.h:197 [inline]
simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532
__skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420
skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546
skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline]
packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482
sock_recvmsg_nosec net/socket.c:1044 [inline]
sock_recvmsg net/socket.c:1066 [inline]
sock_read_iter+0x467/0x580 net/socket.c:1136
call_read_iter include/linux/fs.h:2014 [inline]
new_sync_read fs/read_write.c:389 [inline]
vfs_read+0x8f6/0xe00 fs/read_write.c:470
ksys_read+0x20f/0x4c0 fs/read_write.c:613
__do_sys_read fs/read_write.c:623 [inline]
__se_sys_read fs/read_write.c:621 [inline]
__x64_sys_read+0x93/0xd0 fs/read_write.c:621
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was stored to memory at:
skb_put_data include/linux/skbuff.h:2622 [inline]
netlink_to_full_skb net/netlink/af_netlink.c:181 [inline]
__netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline]
__netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325
netlink_deliver_tap net/netlink/af_netlink.c:338 [inline]
netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline]
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368
netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
__sys_sendmsg net/socket.c:2667 [inline]
__do_sys_sendmsg net/socket.c:2676 [inline]
__se_sys_sendmsg net/socket.c:2674 [inline]
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2674
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at:
free_pages_prepare mm/page_alloc.c:1087 [inline]
free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347
free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533
release_pages+0x23d3/0x2410 mm/swap.c:1042
free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316
tlb_batch_pages
---truncated--- |
["https://git.kernel.org/stable/c/0b27bf4c494d61e5663baa34c3edd7ccebf0ea44","https://git.kernel.org/stable/c/59fc3e3d049e39e7d0d271f20dd5fb47c57faf1d","https://git.kernel.org/stable/c/661779e1fcafe1b74b3f3fe8e980c1e207fea1fd","https://git.kernel.org/stable/c/9ae51361da43270f4ba0eb924427a07e87e48777","https://git.kernel.org/stable/c/c71ed29d15b1a1ed6c464f8c3536996963046285","https://git.kernel.org/stable/c/d3ada42e534a83b618bbc1e490d23bf0fdae4736","https://git.kernel.org/stable/c/ec343a55b687a452f5e87f3b52bf9f155864df65","https://git.kernel.org/stable/c/f19d1f98e60e68b11fc60839105dd02a30ec0d77","https://git.kernel.org/stable/c/0b27bf4c494d61e5663baa34c3edd7ccebf0ea44","https://git.kernel.org/stable/c/59fc3e3d049e39e7d0d271f20dd5fb47c57faf1d","https://git.kernel.org/stable/c/661779e1fcafe1b74b3f3fe8e980c1e207fea1fd","https://git.kernel.org/stable/c/9ae51361da43270f4ba0eb924427a07e87e48777","https://git.kernel.org/stable/c/c71ed29d15b1a1ed6c464f8c3536996963046285","https://git.kernel.org/stable/c/d3ada42e534a83b618bbc1e490d23bf0fdae4736","https://git.kernel.org/stable/c/ec343a55b687a452f5e87f3b52bf9f155864df65","https://git.kernel.org/stable/c/f19d1f98e60e68b11fc60839105dd02a30ec0d77","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26825
|
Medium |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: free rx_data_reassembly skb on NCI device cleanup
rx_data_reassembly skb is stored during NCI data exchange for processing
fragmented packets. It is dropped only when the last fragment is processed
or when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received.
However, the NCI device may be deallocated before that which leads to skb
leak.
As by design the rx_data_reassembly skb is bound to the NCI device and
nothing prevents the device to be freed before the skb is processed in
some way and cleaned, free it on the NCI device cleanup.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller. |
["https://git.kernel.org/stable/c/16d3f507b0fa70453dc54550df093d6e9ac630c1","https://git.kernel.org/stable/c/2f6d16f0520d6505241629ee2f5c131b547d5f9d","https://git.kernel.org/stable/c/471c9ede8061357b43a116fa692e70d91941ac23","https://git.kernel.org/stable/c/5c0c5ffaed73cbae6c317374dc32ba6cacc60895","https://git.kernel.org/stable/c/71349abe3aba7fedcab5b3fcd7aa82371fb5ccbf","https://git.kernel.org/stable/c/7e9a8498658b398bf11b8e388005fa54e40aed81","https://git.kernel.org/stable/c/a3d90fb5c23f29ba59c04005ae76c5228cef2be9","https://git.kernel.org/stable/c/bfb007aebe6bff451f7f3a4be19f4f286d0d5d9c","https://git.kernel.org/stable/c/16d3f507b0fa70453dc54550df093d6e9ac630c1","https://git.kernel.org/stable/c/2f6d16f0520d6505241629ee2f5c131b547d5f9d","https://git.kernel.org/stable/c/471c9ede8061357b43a116fa692e70d91941ac23","https://git.kernel.org/stable/c/5c0c5ffaed73cbae6c317374dc32ba6cacc60895","https://git.kernel.org/stable/c/71349abe3aba7fedcab5b3fcd7aa82371fb5ccbf","https://git.kernel.org/stable/c/7e9a8498658b398bf11b8e388005fa54e40aed81","https://git.kernel.org/stable/c/a3d90fb5c23f29ba59c04005ae76c5228cef2be9","https://git.kernel.org/stable/c/bfb007aebe6bff451f7f3a4be19f4f286d0d5d9c","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26845
|
Medium |
fixed |
- 4.19.308
- 5.4.270
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: core: Add TMF to tmr_list handling
An abort that is responded to by iSCSI itself is added to tmr_list but does
not go to target core. A LUN_RESET that goes through tmr_list takes a
refcounter on the abort and waits for completion. However, the abort will
be never complete because it was not started in target core.
Unable to locate ITT: 0x05000000 on CID: 0
Unable to locate RefTaskTag: 0x05000000 on CID: 0.
wait_for_tasks: Stopping tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop
wait for tasks: tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop
...
INFO: task kworker/0:2:49 blocked for more than 491 seconds.
task:kworker/0:2 state:D stack: 0 pid: 49 ppid: 2 flags:0x00000800
Workqueue: events target_tmr_work [target_core_mod]
Call Trace:
__switch_to+0x2c4/0x470
_schedule+0x314/0x1730
schedule+0x64/0x130
schedule_timeout+0x168/0x430
wait_for_completion+0x140/0x270
target_put_cmd_and_wait+0x64/0xb0 [target_core_mod]
core_tmr_lun_reset+0x30/0xa0 [target_core_mod]
target_tmr_work+0xc8/0x1b0 [target_core_mod]
process_one_work+0x2d4/0x5d0
worker_thread+0x78/0x6c0
To fix this, only add abort to tmr_list if it will be handled by target
core. |
["https://git.kernel.org/stable/c/11f3fe5001ed05721e641f0ecaa7a73b7deb245d","https://git.kernel.org/stable/c/168ed59170de1fd7274080fe102216162d6826cf","https://git.kernel.org/stable/c/36bc5040c863b44af06094b22f1e50059227b9cb","https://git.kernel.org/stable/c/425a571a7e6fc389954cf2564e1edbba3740e171","https://git.kernel.org/stable/c/83ab68168a3d990d5ff39ab030ad5754cbbccb25","https://git.kernel.org/stable/c/a9849b67b4402a12eb35eadc9306c1ef9847d53d","https://git.kernel.org/stable/c/bd508f96b5fef96d8a0ce9cbb211d82bcfc2341f","https://git.kernel.org/stable/c/e717bd412001495f17400bfc09f606f1b594ef5a","https://git.kernel.org/stable/c/11f3fe5001ed05721e641f0ecaa7a73b7deb245d","https://git.kernel.org/stable/c/168ed59170de1fd7274080fe102216162d6826cf","https://git.kernel.org/stable/c/36bc5040c863b44af06094b22f1e50059227b9cb","https://git.kernel.org/stable/c/425a571a7e6fc389954cf2564e1edbba3740e171","https://git.kernel.org/stable/c/83ab68168a3d990d5ff39ab030ad5754cbbccb25","https://git.kernel.org/stable/c/a9849b67b4402a12eb35eadc9306c1ef9847d53d","https://git.kernel.org/stable/c/bd508f96b5fef96d8a0ce9cbb211d82bcfc2341f","https://git.kernel.org/stable/c/e717bd412001495f17400bfc09f606f1b594ef5a","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26857
|
Medium |
fixed |
- 4.19.310
- 5.4.272
- 5.10.213
- 5.15.152
- 6.1.82
- 6.6.22
- 6.7.10
|
In the Linux kernel, the following vulnerability has been resolved:
geneve: make sure to pull inner header in geneve_rx()
syzbot triggered a bug in geneve_rx() [1]
Issue is similar to the one I fixed in commit 8d975c15c0cd
("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")
We have to save skb->network_header in a temporary variable
in order to be able to recompute the network_header pointer
after a pskb_inet_may_pull() call.
pskb_inet_may_pull() makes sure the needed headers are in skb->head.
[1]
BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline]
BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391
IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
geneve_rx drivers/net/geneve.c:279 [inline]
geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391
udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108
udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186
udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346
__udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422
udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604
ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205
ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233
NF_HOOK include/linux/netfilter.h:314 [inline]
ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254
dst_input include/net/dst.h:461 [inline]
ip_rcv_finish net/ipv4/ip_input.c:449 [inline]
NF_HOOK include/linux/netfilter.h:314 [inline]
ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569
__netif_receive_skb_one_core net/core/dev.c:5534 [inline]
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648
process_backlog+0x480/0x8b0 net/core/dev.c:5976
__napi_poll+0xe3/0x980 net/core/dev.c:6576
napi_poll net/core/dev.c:6645 [inline]
net_rx_action+0x8b8/0x1870 net/core/dev.c:6778
__do_softirq+0x1b7/0x7c5 kernel/softirq.c:553
do_softirq+0x9a/0xf0 kernel/softirq.c:454
__local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381
local_bh_enable include/linux/bottom_half.h:33 [inline]
rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline]
__dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378
dev_queue_xmit include/linux/netdevice.h:3171 [inline]
packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276
packet_snd net/packet/af_packet.c:3081 [inline]
packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
__sys_sendto+0x735/0xa10 net/socket.c:2191
__do_sys_sendto net/socket.c:2203 [inline]
__se_sys_sendto net/socket.c:2199 [inline]
__x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at:
slab_post_alloc_hook mm/slub.c:3819 [inline]
slab_alloc_node mm/slub.c:3860 [inline]
kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
__alloc_skb+0x352/0x790 net/core/skbuff.c:651
alloc_skb include/linux/skbuff.h:1296 [inline]
alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394
sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783
packet_alloc_skb net/packet/af_packet.c:2930 [inline]
packet_snd net/packet/af_packet.c:3024 [inline]
packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
__sys_sendto+0x735/0xa10 net/socket.c:2191
__do_sys_sendto net/socket.c:2203 [inline]
__se_sys_sendto net/socket.c:2199 [inline]
__x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b |
["https://git.kernel.org/stable/c/048e16dee1fc609c1c85072ccd70bfd4b5fef6ca","https://git.kernel.org/stable/c/0ece581d2a66e8e488c0d3b3e7b5760dbbfdbdd5","https://git.kernel.org/stable/c/1ca1ba465e55b9460e4e75dec9fff31e708fec74","https://git.kernel.org/stable/c/59d2a4076983303f324557a114cfd5c32e1f6b29","https://git.kernel.org/stable/c/c0b22568a9d8384fd000cc49acb8f74bde40d1b5","https://git.kernel.org/stable/c/c7137900691f5692fe3de54566ea7b30bb35d66c","https://git.kernel.org/stable/c/e431c3227864b5646601c97f5f898d99472f2914","https://git.kernel.org/stable/c/e77e0b0f2a11735c64b105edaee54d6344faca8a","https://git.kernel.org/stable/c/048e16dee1fc609c1c85072ccd70bfd4b5fef6ca","https://git.kernel.org/stable/c/0ece581d2a66e8e488c0d3b3e7b5760dbbfdbdd5","https://git.kernel.org/stable/c/1ca1ba465e55b9460e4e75dec9fff31e708fec74","https://git.kernel.org/stable/c/59d2a4076983303f324557a114cfd5c32e1f6b29","https://git.kernel.org/stable/c/c0b22568a9d8384fd000cc49acb8f74bde40d1b5","https://git.kernel.org/stable/c/c7137900691f5692fe3de54566ea7b30bb35d66c","https://git.kernel.org/stable/c/e431c3227864b5646601c97f5f898d99472f2914","https://git.kernel.org/stable/c/e77e0b0f2a11735c64b105edaee54d6344faca8a","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-37454
|
Medium |
|
N/A
|
An issue was discovered in the Linux kernel through 6.4.2. A crafted UDF filesystem image causes a use-after-free write operation in the udf_put_super and udf_close_lvid functions in fs/udf/super.c. NOTE: the suse.com reference has a different perspective about this. |
["https://bugzilla.suse.com/show_bug.cgi?id=CVE-2023-37454","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6f861765464f43a71462d52026fbddfc858239a5","https://lore.kernel.org/all/00000000000056e02f05dfb6e11a%40google.com/T/","https://syzkaller.appspot.com/bug?extid=26873a72980f8fa8bc55","https://syzkaller.appspot.com/bug?extid=60864ed35b1073540d57","https://syzkaller.appspot.com/bug?extid=61564e5023b7229ec85d","https://bugzilla.suse.com/show_bug.cgi?id=CVE-2023-37454","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6f861765464f43a71462d52026fbddfc858239a5","https://lore.kernel.org/all/00000000000056e02f05dfb6e11a%40google.com/T/","https://syzkaller.appspot.com/bug?extid=26873a72980f8fa8bc55","https://syzkaller.appspot.com/bug?extid=60864ed35b1073540d57","https://syzkaller.appspot.com/bug?extid=61564e5023b7229ec85d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26697
|
Medium |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix data corruption in dsync block recovery for small block sizes
The helper function nilfs_recovery_copy_block() of
nilfs_recovery_dsync_blocks(), which recovers data from logs created by
data sync writes during a mount after an unclean shutdown, incorrectly
calculates the on-page offset when copying repair data to the file's page
cache. In environments where the block size is smaller than the page
size, this flaw can cause data corruption and leak uninitialized memory
bytes during the recovery process.
Fix these issues by correcting this byte offset calculation on the page. |
["https://git.kernel.org/stable/c/120f7fa2008e3bd8b7680b4ab5df942decf60fd5","https://git.kernel.org/stable/c/2000016bab499074e6248ea85aeea7dd762355d9","https://git.kernel.org/stable/c/2e1480538ef60bfee5473dfe02b1ecbaf1a4aa0d","https://git.kernel.org/stable/c/364a66be2abdcd4fd426ffa44d9b8f40aafb3caa","https://git.kernel.org/stable/c/5278c3eb6bf5896417572b52adb6be9d26e92f65","https://git.kernel.org/stable/c/67b8bcbaed4777871bb0dcc888fb02a614a98ab1","https://git.kernel.org/stable/c/9c9c68d64fd3284f7097ed6ae057c8441f39fcd3","https://git.kernel.org/stable/c/a6efe6dbaaf504f5b3f8a5c3f711fe54e7dda0ba","https://git.kernel.org/stable/c/120f7fa2008e3bd8b7680b4ab5df942decf60fd5","https://git.kernel.org/stable/c/2000016bab499074e6248ea85aeea7dd762355d9","https://git.kernel.org/stable/c/2e1480538ef60bfee5473dfe02b1ecbaf1a4aa0d","https://git.kernel.org/stable/c/364a66be2abdcd4fd426ffa44d9b8f40aafb3caa","https://git.kernel.org/stable/c/5278c3eb6bf5896417572b52adb6be9d26e92f65","https://git.kernel.org/stable/c/67b8bcbaed4777871bb0dcc888fb02a614a98ab1","https://git.kernel.org/stable/c/9c9c68d64fd3284f7097ed6ae057c8441f39fcd3","https://git.kernel.org/stable/c/a6efe6dbaaf504f5b3f8a5c3f711fe54e7dda0ba","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26839
|
Medium |
fixed |
- 4.19.308
- 5.4.270
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
IB/hfi1: Fix a memleak in init_credit_return
When dma_alloc_coherent fails to allocate dd->cr_base[i].va,
init_credit_return should deallocate dd->cr_base and
dd->cr_base[i] that allocated before. Or those resources
would be never freed and a memleak is triggered. |
["https://git.kernel.org/stable/c/2e4f9f20b32658ef3724aa46f7aef4908d2609e3","https://git.kernel.org/stable/c/3fa240bb6b2dbb3e7a3ee1440a4889cbb6207eb7","https://git.kernel.org/stable/c/52de5805c147137205662af89ed7e083d656ae25","https://git.kernel.org/stable/c/809aa64ebff51eb170ee31a95f83b2d21efa32e2","https://git.kernel.org/stable/c/8412c86e89cc78d8b513cb25cf2157a2adf3670a","https://git.kernel.org/stable/c/b41d0ade0398007fb746213f09903d52a920e896","https://git.kernel.org/stable/c/cecfb90cf71d91e9efebd68b9e9b84661b277cc8","https://git.kernel.org/stable/c/f0d857ce31a6bc7a82afcdbadb8f7417d482604b","https://git.kernel.org/stable/c/2e4f9f20b32658ef3724aa46f7aef4908d2609e3","https://git.kernel.org/stable/c/3fa240bb6b2dbb3e7a3ee1440a4889cbb6207eb7","https://git.kernel.org/stable/c/52de5805c147137205662af89ed7e083d656ae25","https://git.kernel.org/stable/c/809aa64ebff51eb170ee31a95f83b2d21efa32e2","https://git.kernel.org/stable/c/8412c86e89cc78d8b513cb25cf2157a2adf3670a","https://git.kernel.org/stable/c/b41d0ade0398007fb746213f09903d52a920e896","https://git.kernel.org/stable/c/cecfb90cf71d91e9efebd68b9e9b84661b277cc8","https://git.kernel.org/stable/c/f0d857ce31a6bc7a82afcdbadb8f7417d482604b","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26851
|
Medium |
fixed |
- 4.19.310
- 5.4.272
- 5.10.213
- 5.15.152
- 6.1.82
- 6.6.22
- 6.7.10
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_h323: Add protection for bmp length out of range
UBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shifts
that are out of bounds for their data type.
vmlinux get_bitmap(b=75) + 712
<net/netfilter/nf_conntrack_h323_asn1.c:0>
vmlinux decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956
<net/netfilter/nf_conntrack_h323_asn1.c:592>
vmlinux decode_choice(base=0xFFFFFFD0080370F0, level=23843636) + 1216
<net/netfilter/nf_conntrack_h323_asn1.c:814>
vmlinux decode_seq(f=0xFFFFFFD0080371A8, level=134443500) + 812
<net/netfilter/nf_conntrack_h323_asn1.c:576>
vmlinux decode_choice(base=0xFFFFFFD008037280, level=0) + 1216
<net/netfilter/nf_conntrack_h323_asn1.c:814>
vmlinux DecodeRasMessage() + 304
<net/netfilter/nf_conntrack_h323_asn1.c:833>
vmlinux ras_help() + 684
<net/netfilter/nf_conntrack_h323_main.c:1728>
vmlinux nf_confirm() + 188
<net/netfilter/nf_conntrack_proto.c:137>
Due to abnormal data in skb->data, the extension bitmap length
exceeds 32 when decoding ras message then uses the length to make
a shift operation. It will change into negative after several loop.
UBSAN load could detect a negative shift as an undefined behaviour
and reports exception.
So we add the protection to avoid the length exceeding 32. Or else
it will return out of range error and stop decoding. |
["https://git.kernel.org/stable/c/014a807f1cc9c9d5173c1cd935835553b00d211c","https://git.kernel.org/stable/c/39001e3c42000e7c2038717af0d33c32319ad591","https://git.kernel.org/stable/c/4bafcc43baf7bcf93566394dbd15726b5b456b7a","https://git.kernel.org/stable/c/767146637efc528b5e3d31297df115e85a2fd362","https://git.kernel.org/stable/c/80ee5054435a11c87c9a4f30f1ff750080c96416","https://git.kernel.org/stable/c/98db42191329c679f4ca52bec0b319689e1ad8cb","https://git.kernel.org/stable/c/b3c0f553820516ad4b62a9390ecd28d6f73a7b13","https://git.kernel.org/stable/c/ccd1108b16ab572d9bf635586b0925635dbd6bbc","https://git.kernel.org/stable/c/014a807f1cc9c9d5173c1cd935835553b00d211c","https://git.kernel.org/stable/c/39001e3c42000e7c2038717af0d33c32319ad591","https://git.kernel.org/stable/c/4bafcc43baf7bcf93566394dbd15726b5b456b7a","https://git.kernel.org/stable/c/767146637efc528b5e3d31297df115e85a2fd362","https://git.kernel.org/stable/c/80ee5054435a11c87c9a4f30f1ff750080c96416","https://git.kernel.org/stable/c/98db42191329c679f4ca52bec0b319689e1ad8cb","https://git.kernel.org/stable/c/b3c0f553820516ad4b62a9390ecd28d6f73a7b13","https://git.kernel.org/stable/c/ccd1108b16ab572d9bf635586b0925635dbd6bbc","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3161
|
Medium |
fixed |
|
A flaw was found in the Framebuffer Console (fbcon) in the Linux Kernel. When providing font->width and font->height greater than 32 to fbcon_set_font, since there are no checks in place, a shift-out-of-bounds occurs leading to undefined behavior and possible denial of service. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2213485","https://github.com/torvalds/linux/commit/2b09d5d364986f724f17001ccfe4126b9b43a0be","https://bugzilla.redhat.com/show_bug.cgi?id=2213485","https://github.com/torvalds/linux/commit/2b09d5d364986f724f17001ccfe4126b9b43a0be"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26863
|
Medium |
fixed |
- 4.19.311
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
hsr: Fix uninit-value access in hsr_get_node()
KMSAN reported the following uninit-value access issue [1]:
=====================================================
BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246
hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246
fill_frame_info net/hsr/hsr_forward.c:577 [inline]
hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615
hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
xmit_one net/core/dev.c:3548 [inline]
dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276
packet_snd net/packet/af_packet.c:3087 [inline]
packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
__sys_sendto+0x735/0xa10 net/socket.c:2191
__do_sys_sendto net/socket.c:2203 [inline]
__se_sys_sendto net/socket.c:2199 [inline]
__x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at:
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
slab_alloc_node mm/slub.c:3478 [inline]
kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
__alloc_skb+0x318/0x740 net/core/skbuff.c:651
alloc_skb include/linux/skbuff.h:1286 [inline]
alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334
sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787
packet_alloc_skb net/packet/af_packet.c:2936 [inline]
packet_snd net/packet/af_packet.c:3030 [inline]
packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
__sys_sendto+0x735/0xa10 net/socket.c:2191
__do_sys_sendto net/socket.c:2203 [inline]
__se_sys_sendto net/socket.c:2199 [inline]
__x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
=====================================================
If the packet type ID field in the Ethernet header is either ETH_P_PRP or
ETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr()
reads an invalid value as a sequence number. This causes the above issue.
This patch fixes the issue by returning NULL if the Ethernet header is not
followed by an HSR tag. |
["https://git.kernel.org/stable/c/09e5cdbe2cc88c3c758927644a3eb02fac317209","https://git.kernel.org/stable/c/1ed222ca7396938eb1ab2d034f1ba0d8b00a7122","https://git.kernel.org/stable/c/39cc316fb3bc5e7c9dc5eed314fe510d119c6862","https://git.kernel.org/stable/c/7fb2d4d6bb1c85f7a23aace0ed6c86a95dea792a","https://git.kernel.org/stable/c/889ed056eae7fda85b769a9ab33c093379c45428","https://git.kernel.org/stable/c/97d2148ea435dff4b4e71817c9032eb321bcd37e","https://git.kernel.org/stable/c/a809bbfd0e503351d3051317288a70a4569a4949","https://git.kernel.org/stable/c/ddbec99f58571301679addbc022256970ca3eac6","https://git.kernel.org/stable/c/e3b2bfb8ff1810a537b2aa55ba906a6743ed120c","https://git.kernel.org/stable/c/09e5cdbe2cc88c3c758927644a3eb02fac317209","https://git.kernel.org/stable/c/1ed222ca7396938eb1ab2d034f1ba0d8b00a7122","https://git.kernel.org/stable/c/39cc316fb3bc5e7c9dc5eed314fe510d119c6862","https://git.kernel.org/stable/c/7fb2d4d6bb1c85f7a23aace0ed6c86a95dea792a","https://git.kernel.org/stable/c/889ed056eae7fda85b769a9ab33c093379c45428","https://git.kernel.org/stable/c/97d2148ea435dff4b4e71817c9032eb321bcd37e","https://git.kernel.org/stable/c/a809bbfd0e503351d3051317288a70a4569a4949","https://git.kernel.org/stable/c/ddbec99f58571301679addbc022256970ca3eac6","https://git.kernel.org/stable/c/e3b2bfb8ff1810a537b2aa55ba906a6743ed120c","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52513
|
Medium |
fixed |
- 5.4.258
- 5.10.198
- 5.15.135
- 6.1.57
- 6.5.7
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/siw: Fix connection failure handling
In case immediate MPA request processing fails, the newly
created endpoint unlinks the listening endpoint and is
ready to be dropped. This special case was not handled
correctly by the code handling the later TCP socket close,
causing a NULL dereference crash in siw_cm_work_handler()
when dereferencing a NULL listener. We now also cancel
the useless MPA timeout, if immediate MPA request
processing fails.
This patch furthermore simplifies MPA processing in general:
Scheduling a useless TCP socket read in sk_data_ready() upcall
is now surpressed, if the socket is already moved out of
TCP_ESTABLISHED state. |
["https://git.kernel.org/stable/c/0d520cdb0cd095eac5d00078dfd318408c9b5eed","https://git.kernel.org/stable/c/53a3f777049771496f791504e7dc8ef017cba590","https://git.kernel.org/stable/c/5cf38e638e5d01b68f9133968a85e8b3fd1ecf2f","https://git.kernel.org/stable/c/6e26812e289b374c17677d238164a5a8f5770594","https://git.kernel.org/stable/c/81b7bf367eea795d259d0261710c6a89f548844d","https://git.kernel.org/stable/c/eeafc50a77f6a783c2c44e7ec3674a7b693e06f8","https://git.kernel.org/stable/c/0d520cdb0cd095eac5d00078dfd318408c9b5eed","https://git.kernel.org/stable/c/53a3f777049771496f791504e7dc8ef017cba590","https://git.kernel.org/stable/c/5cf38e638e5d01b68f9133968a85e8b3fd1ecf2f","https://git.kernel.org/stable/c/6e26812e289b374c17677d238164a5a8f5770594","https://git.kernel.org/stable/c/81b7bf367eea795d259d0261710c6a89f548844d","https://git.kernel.org/stable/c/eeafc50a77f6a783c2c44e7ec3674a7b693e06f8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26644
|
Medium |
fixed |
- 5.10.210
- 5.15.149
- 6.1.76
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't abort filesystem when attempting to snapshot deleted subvolume
If the source file descriptor to the snapshot ioctl refers to a deleted
subvolume, we get the following abort:
BTRFS: Transaction aborted (error -2)
WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs]
Modules linked in: pata_acpi btrfs ata_piix libata scsi_mod virtio_net blake2b_generic xor net_failover virtio_rng failover scsi_common rng_core raid6_pq libcrc32c
CPU: 0 PID: 833 Comm: t_snapshot_dele Not tainted 6.7.0-rc6 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
RIP: 0010:create_pending_snapshot+0x1040/0x1190 [btrfs]
RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027
RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840
RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998
R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe
R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80
FS: 00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0
Call Trace:
<TASK>
? create_pending_snapshot+0x1040/0x1190 [btrfs]
? __warn+0x81/0x130
? create_pending_snapshot+0x1040/0x1190 [btrfs]
? report_bug+0x171/0x1a0
? handle_bug+0x3a/0x70
? exc_invalid_op+0x17/0x70
? asm_exc_invalid_op+0x1a/0x20
? create_pending_snapshot+0x1040/0x1190 [btrfs]
? create_pending_snapshot+0x1040/0x1190 [btrfs]
create_pending_snapshots+0x92/0xc0 [btrfs]
btrfs_commit_transaction+0x66b/0xf40 [btrfs]
btrfs_mksubvol+0x301/0x4d0 [btrfs]
btrfs_mksnapshot+0x80/0xb0 [btrfs]
__btrfs_ioctl_snap_create+0x1c2/0x1d0 [btrfs]
btrfs_ioctl_snap_create_v2+0xc4/0x150 [btrfs]
btrfs_ioctl+0x8a6/0x2650 [btrfs]
? kmem_cache_free+0x22/0x340
? do_sys_openat2+0x97/0xe0
__x64_sys_ioctl+0x97/0xd0
do_syscall_64+0x46/0xf0
entry_SYSCALL_64_after_hwframe+0x6e/0x76
RIP: 0033:0x7fe20abe83af
RSP: 002b:00007ffe6eff1360 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fe20abe83af
RDX: 00007ffe6eff23c0 RSI: 0000000050009417 RDI: 0000000000000003
RBP: 0000000000000003 R08: 0000000000000000 R09: 00007fe20ad16cd0
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffe6eff13c0 R14: 00007fe20ad45000 R15: 0000559a120b6d58
</TASK>
---[ end trace 0000000000000000 ]---
BTRFS: error (device vdc: state A) in create_pending_snapshot:1875: errno=-2 No such entry
BTRFS info (device vdc: state EA): forced readonly
BTRFS warning (device vdc: state EA): Skipping commit of aborted transaction.
BTRFS: error (device vdc: state EA) in cleanup_transaction:2055: errno=-2 No such entry
This happens because create_pending_snapshot() initializes the new root
item as a copy of the source root item. This includes the refs field,
which is 0 for a deleted subvolume. The call to btrfs_insert_root()
therefore inserts a root with refs == 0. btrfs_get_new_fs_root() then
finds the root and returns -ENOENT if refs == 0, which causes
create_pending_snapshot() to abort.
Fix it by checking the source root's refs before attempting the
snapshot, but after locking subvol_sem to avoid racing with deletion. |
["https://git.kernel.org/stable/c/0877497dc97834728e1b528ddf1e1c484292c29c","https://git.kernel.org/stable/c/2bdf872bcfe629a6202ffd6641615a8ed00e8464","https://git.kernel.org/stable/c/6e6bca99e8d88d989a7cde4c064abea552d5219b","https://git.kernel.org/stable/c/7081929ab2572920e94d70be3d332e5c9f97095a","https://git.kernel.org/stable/c/d8680b722f0ff6d7a01ddacc1844e0d52354d6ff","https://git.kernel.org/stable/c/ec794a7528199e1be6d47bec03f4755aa75df256","https://git.kernel.org/stable/c/0877497dc97834728e1b528ddf1e1c484292c29c","https://git.kernel.org/stable/c/2bdf872bcfe629a6202ffd6641615a8ed00e8464","https://git.kernel.org/stable/c/6e6bca99e8d88d989a7cde4c064abea552d5219b","https://git.kernel.org/stable/c/7081929ab2572920e94d70be3d332e5c9f97095a","https://git.kernel.org/stable/c/d8680b722f0ff6d7a01ddacc1844e0d52354d6ff","https://git.kernel.org/stable/c/ec794a7528199e1be6d47bec03f4755aa75df256","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26707
|
Medium |
fixed |
- 5.10.210
- 5.15.149
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()
Syzkaller reported [1] hitting a warning after failing to allocate
resources for skb in hsr_init_skb(). Since a WARN_ONCE() call will
not help much in this case, it might be prudent to switch to
netdev_warn_once(). At the very least it will suppress syzkaller
reports such as [1].
Just in case, use netdev_warn_once() in send_prp_supervision_frame()
for similar reasons.
[1]
HSR: Could not send supervision frame
WARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
...
Call Trace:
<IRQ>
hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382
call_timer_fn+0x193/0x590 kernel/time/timer.c:1700
expire_timers kernel/time/timer.c:1751 [inline]
__run_timers+0x764/0xb20 kernel/time/timer.c:2022
run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035
__do_softirq+0x21a/0x8de kernel/softirq.c:553
invoke_softirq kernel/softirq.c:427 [inline]
__irq_exit_rcu kernel/softirq.c:632 [inline]
irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644
sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649
...
This issue is also found in older kernels (at least up to 5.10). |
["https://git.kernel.org/stable/c/0d8011a878fdf96123bc0d6a12e2fe7ced5fddfb","https://git.kernel.org/stable/c/37e8c97e539015637cb920d3e6f1e404f707a06e","https://git.kernel.org/stable/c/547545e50c913861219947ce490c68a1776b9b51","https://git.kernel.org/stable/c/56440799fc4621c279df16176f83a995d056023a","https://git.kernel.org/stable/c/923dea2a7ea9e1ef5ac4031fba461c1cc92e32b8","https://git.kernel.org/stable/c/de769423b2f053182a41317c4db5a927e90622a0","https://git.kernel.org/stable/c/0d8011a878fdf96123bc0d6a12e2fe7ced5fddfb","https://git.kernel.org/stable/c/37e8c97e539015637cb920d3e6f1e404f707a06e","https://git.kernel.org/stable/c/547545e50c913861219947ce490c68a1776b9b51","https://git.kernel.org/stable/c/56440799fc4621c279df16176f83a995d056023a","https://git.kernel.org/stable/c/923dea2a7ea9e1ef5ac4031fba461c1cc92e32b8","https://git.kernel.org/stable/c/de769423b2f053182a41317c4db5a927e90622a0","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26787
|
Medium |
fixed |
- 5.10.213
- 5.15.152
- 6.1.81
- 6.6.21
- 6.7.9
|
In the Linux kernel, the following vulnerability has been resolved:
mmc: mmci: stm32: fix DMA API overlapping mappings warning
Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning:
DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST,
overlapping mappings aren't supported
WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568
add_dma_entry+0x234/0x2f4
Modules linked in:
CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1
Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT)
Workqueue: events_freezable mmc_rescan
Call trace:
add_dma_entry+0x234/0x2f4
debug_dma_map_sg+0x198/0x350
__dma_map_sg_attrs+0xa0/0x110
dma_map_sg_attrs+0x10/0x2c
sdmmc_idma_prep_data+0x80/0xc0
mmci_prep_data+0x38/0x84
mmci_start_data+0x108/0x2dc
mmci_request+0xe4/0x190
__mmc_start_request+0x68/0x140
mmc_start_request+0x94/0xc0
mmc_wait_for_req+0x70/0x100
mmc_send_tuning+0x108/0x1ac
sdmmc_execute_tuning+0x14c/0x210
mmc_execute_tuning+0x48/0xec
mmc_sd_init_uhs_card.part.0+0x208/0x464
mmc_sd_init_card+0x318/0x89c
mmc_attach_sd+0xe4/0x180
mmc_rescan+0x244/0x320
DMA API debug brings to light leaking dma-mappings as dma_map_sg and
dma_unmap_sg are not correctly balanced.
If an error occurs in mmci_cmd_irq function, only mmci_dma_error
function is called and as this API is not managed on stm32 variant,
dma_unmap_sg is never called in this error path. |
["https://git.kernel.org/stable/c/0224cbc53ba82b84affa7619b6d1b1a254bc2c53","https://git.kernel.org/stable/c/176e66269f0de327375fc0ea51c12c2f5a97e4c4","https://git.kernel.org/stable/c/5ae5060e17a3fc38e54c3e5bd8abd6b1d5bfae7c","https://git.kernel.org/stable/c/6b1ba3f9040be5efc4396d86c9752cdc564730be","https://git.kernel.org/stable/c/70af82bb9c897faa25a44e4181f36c60312b71ef","https://git.kernel.org/stable/c/d610a307225951929b9dff807788439454476f85","https://git.kernel.org/stable/c/0224cbc53ba82b84affa7619b6d1b1a254bc2c53","https://git.kernel.org/stable/c/176e66269f0de327375fc0ea51c12c2f5a97e4c4","https://git.kernel.org/stable/c/5ae5060e17a3fc38e54c3e5bd8abd6b1d5bfae7c","https://git.kernel.org/stable/c/6b1ba3f9040be5efc4396d86c9752cdc564730be","https://git.kernel.org/stable/c/70af82bb9c897faa25a44e4181f36c60312b71ef","https://git.kernel.org/stable/c/d610a307225951929b9dff807788439454476f85","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26795
|
Medium |
fixed |
- 5.10.212
- 5.15.151
- 6.1.81
- 6.6.21
- 6.7.9
|
In the Linux kernel, the following vulnerability has been resolved:
riscv: Sparse-Memory/vmemmap out-of-bounds fix
Offset vmemmap so that the first page of vmemmap will be mapped
to the first page of physical memory in order to ensure that
vmemmap’s bounds will be respected during
pfn_to_page()/page_to_pfn() operations.
The conversion macros will produce correct SV39/48/57 addresses
for every possible/valid DRAM_BASE inside the physical memory limits.
v2:Address Alex's comments |
["https://git.kernel.org/stable/c/2a1728c15ec4f45ed9248ae22f626541c179bfbe","https://git.kernel.org/stable/c/5941a90c55d3bfba732b32208d58d997600b44ef","https://git.kernel.org/stable/c/8310080799b40fd9f2a8b808c657269678c149af","https://git.kernel.org/stable/c/8af1c121b0102041809bc137ec600d1865eaeedd","https://git.kernel.org/stable/c/a11dd49dcb9376776193e15641f84fcc1e5980c9","https://git.kernel.org/stable/c/a278d5c60f21aa15d540abb2f2da6e6d795c3e6e","https://git.kernel.org/stable/c/2a1728c15ec4f45ed9248ae22f626541c179bfbe","https://git.kernel.org/stable/c/5941a90c55d3bfba732b32208d58d997600b44ef","https://git.kernel.org/stable/c/8310080799b40fd9f2a8b808c657269678c149af","https://git.kernel.org/stable/c/8af1c121b0102041809bc137ec600d1865eaeedd","https://git.kernel.org/stable/c/a11dd49dcb9376776193e15641f84fcc1e5980c9","https://git.kernel.org/stable/c/a278d5c60f21aa15d540abb2f2da6e6d795c3e6e","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4459
|
Medium |
fixed |
|
A NULL pointer dereference flaw was found in vmxnet3_rq_cleanup in drivers/net/vmxnet3/vmxnet3_drv.c in the networking sub-component in vmxnet3 in the Linux Kernel. This issue may allow a local attacker with normal user privilege to cause a denial of service due to a missing sanity check during cleanup. |
["https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:1250","https://access.redhat.com/errata/RHSA-2024:1306","https://access.redhat.com/errata/RHSA-2024:1367","https://access.redhat.com/errata/RHSA-2024:1382","https://access.redhat.com/errata/RHSA-2024:2006","https://access.redhat.com/errata/RHSA-2024:2008","https://access.redhat.com/security/cve/CVE-2023-4459","https://bugzilla.redhat.com/show_bug.cgi?id=2219268","https://github.com/torvalds/linux/commit/edf410cb74dc612fd47ef5be319c5a0bcd6e6ccd","https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:1250","https://access.redhat.com/errata/RHSA-2024:1306","https://access.redhat.com/errata/RHSA-2024:1367","https://access.redhat.com/errata/RHSA-2024:1382","https://access.redhat.com/errata/RHSA-2024:2006","https://access.redhat.com/errata/RHSA-2024:2008","https://access.redhat.com/security/cve/CVE-2023-4459","https://bugzilla.redhat.com/show_bug.cgi?id=2219268","https://github.com/torvalds/linux/commit/edf410cb74dc612fd47ef5be319c5a0bcd6e6ccd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26833
|
Medium |
fixed |
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix memory leak in dm_sw_fini()
After destroying dmub_srv, the memory associated with it is
not freed, causing a memory leak:
unreferenced object 0xffff896302b45800 (size 1024):
comm "(udev-worker)", pid 222, jiffies 4294894636
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 6265fd77):
[<ffffffff993495ed>] kmalloc_trace+0x29d/0x340
[<ffffffffc0ea4a94>] dm_dmub_sw_init+0xb4/0x450 [amdgpu]
[<ffffffffc0ea4e55>] dm_sw_init+0x15/0x2b0 [amdgpu]
[<ffffffffc0ba8557>] amdgpu_device_init+0x1417/0x24e0 [amdgpu]
[<ffffffffc0bab285>] amdgpu_driver_load_kms+0x15/0x190 [amdgpu]
[<ffffffffc0ba09c7>] amdgpu_pci_probe+0x187/0x4e0 [amdgpu]
[<ffffffff9968fd1e>] local_pci_probe+0x3e/0x90
[<ffffffff996918a3>] pci_device_probe+0xc3/0x230
[<ffffffff99805872>] really_probe+0xe2/0x480
[<ffffffff99805c98>] __driver_probe_device+0x78/0x160
[<ffffffff99805daf>] driver_probe_device+0x1f/0x90
[<ffffffff9980601e>] __driver_attach+0xce/0x1c0
[<ffffffff99803170>] bus_for_each_dev+0x70/0xc0
[<ffffffff99804822>] bus_add_driver+0x112/0x210
[<ffffffff99807245>] driver_register+0x55/0x100
[<ffffffff990012d1>] do_one_initcall+0x41/0x300
Fix this by freeing dmub_srv after destroying it. |
["https://git.kernel.org/stable/c/10c6b90e975358c17856a578419dc449887899c2","https://git.kernel.org/stable/c/33f649f1b1cea39ed360e6c12bba4fac83118e6e","https://git.kernel.org/stable/c/541e79265ea7e339a7c4a462feafe9f8f996e04b","https://git.kernel.org/stable/c/58168005337eabef345a872be3f87d0215ff3b30","https://git.kernel.org/stable/c/b49b022f7dfce85eb77d0d987008fde5c01d7857","https://git.kernel.org/stable/c/bae67893578d608e35691dcdfa90c4957debf1d3","https://git.kernel.org/stable/c/10c6b90e975358c17856a578419dc449887899c2","https://git.kernel.org/stable/c/33f649f1b1cea39ed360e6c12bba4fac83118e6e","https://git.kernel.org/stable/c/541e79265ea7e339a7c4a462feafe9f8f996e04b","https://git.kernel.org/stable/c/58168005337eabef345a872be3f87d0215ff3b30","https://git.kernel.org/stable/c/b49b022f7dfce85eb77d0d987008fde5c01d7857","https://git.kernel.org/stable/c/bae67893578d608e35691dcdfa90c4957debf1d3","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-48627
|
Medium |
fixed |
- 5.4.274
- 5.10.132
- 5.15.56
- 5.18.13
|
In the Linux kernel, the following vulnerability has been resolved:
vt: fix memory overlapping when deleting chars in the buffer
A memory overlapping copy occurs when deleting a long line. This memory
overlapping copy can cause data corruption when scr_memcpyw is optimized
to memcpy because memcpy does not ensure its behavior if the destination
buffer overlaps with the source buffer. The line buffer is not always
broken, because the memcpy utilizes the hardware acceleration, whose
result is not deterministic.
Fix this problem by using replacing the scr_memcpyw with scr_memmovew. |
["https://git.kernel.org/stable/c/14d2cc21ca622310babf373e3a8f0b40acfe8265","https://git.kernel.org/stable/c/39cdb68c64d84e71a4a717000b6e5de208ee60cc","https://git.kernel.org/stable/c/57964a5710252bc82fe22d9fa98c180c58c20244","https://git.kernel.org/stable/c/815be99d934e3292906536275f2b8d5131cdf52c","https://git.kernel.org/stable/c/bfee93c9a6c395f9aa62268f1cedf64999844926","https://git.kernel.org/stable/c/c8686c014b5e872ba7e334f33ca553f14446fc29","https://git.kernel.org/stable/c/14d2cc21ca622310babf373e3a8f0b40acfe8265","https://git.kernel.org/stable/c/39cdb68c64d84e71a4a717000b6e5de208ee60cc","https://git.kernel.org/stable/c/57964a5710252bc82fe22d9fa98c180c58c20244","https://git.kernel.org/stable/c/815be99d934e3292906536275f2b8d5131cdf52c","https://git.kernel.org/stable/c/bfee93c9a6c395f9aa62268f1cedf64999844926","https://git.kernel.org/stable/c/c8686c014b5e872ba7e334f33ca553f14446fc29","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52498
|
Medium |
fixed |
- 5.10.210
- 5.15.149
- 6.1.76
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
PM: sleep: Fix possible deadlocks in core system-wide PM code
It is reported that in low-memory situations the system-wide resume core
code deadlocks, because async_schedule_dev() executes its argument
function synchronously if it cannot allocate memory (and not only in
that case) and that function attempts to acquire a mutex that is already
held. Executing the argument function synchronously from within
dpm_async_fn() may also be problematic for ordering reasons (it may
cause a consumer device's resume callback to be invoked before a
requisite supplier device's one, for example).
Address this by changing the code in question to use
async_schedule_dev_nocall() for scheduling the asynchronous
execution of device suspend and resume functions and to directly
run them synchronously if async_schedule_dev_nocall() returns false. |
["https://git.kernel.org/stable/c/7839d0078e0d5e6cc2fa0b0dfbee71de74f1e557","https://git.kernel.org/stable/c/9bd3dce27b01c51295b60e1433e1dadfb16649f7","https://git.kernel.org/stable/c/a1d62c775b07213c73f81ae842424c74dd14b5f0","https://git.kernel.org/stable/c/e1c9d32c98309ae764893a481552d3f99d46cb34","https://git.kernel.org/stable/c/e681e29d1f59a04ef773296e4bebb17b1b79f8fe","https://git.kernel.org/stable/c/f46eb832389f162ad13cb780d0b8cde93641990d","https://git.kernel.org/stable/c/7839d0078e0d5e6cc2fa0b0dfbee71de74f1e557","https://git.kernel.org/stable/c/9bd3dce27b01c51295b60e1433e1dadfb16649f7","https://git.kernel.org/stable/c/a1d62c775b07213c73f81ae842424c74dd14b5f0","https://git.kernel.org/stable/c/e1c9d32c98309ae764893a481552d3f99d46cb34","https://git.kernel.org/stable/c/e681e29d1f59a04ef773296e4bebb17b1b79f8fe","https://git.kernel.org/stable/c/f46eb832389f162ad13cb780d0b8cde93641990d","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2025-21684
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
gpio: xilinx: Convert gpio_lock to raw spinlock
irq_chip functions may be called in raw spinlock context. Therefore, we
must also use a raw spinlock for our own internal locking.
This fixes the following lockdep splat:
[ 5.349336] =============================
[ 5.353349] [ BUG: Invalid wait context ]
[ 5.357361] 6.13.0-rc5+ #69 Tainted: G W
[ 5.363031] -----------------------------
[ 5.367045] kworker/u17:1/44 is trying to lock:
[ 5.371587] ffffff88018b02c0 (&chip->gpio_lock){....}-{3:3}, at: xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))
[ 5.380079] other info that might help us debug this:
[ 5.385138] context-{5:5}
[ 5.387762] 5 locks held by kworker/u17:1/44:
[ 5.392123] #0: ffffff8800014958 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3204)
[ 5.402260] #1: ffffffc082fcbdd8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3205)
[ 5.411528] #2: ffffff880172c900 (&dev->mutex){....}-{4:4}, at: __device_attach (drivers/base/dd.c:1006)
[ 5.419929] #3: ffffff88039c8268 (request_class#2){+.+.}-{4:4}, at: __setup_irq (kernel/irq/internals.h:156 kernel/irq/manage.c:1596)
[ 5.428331] #4: ffffff88039c80c8 (lock_class#2){....}-{2:2}, at: __setup_irq (kernel/irq/manage.c:1614)
[ 5.436472] stack backtrace:
[ 5.439359] CPU: 2 UID: 0 PID: 44 Comm: kworker/u17:1 Tainted: G W 6.13.0-rc5+ #69
[ 5.448690] Tainted: [W]=WARN
[ 5.451656] Hardware name: xlnx,zynqmp (DT)
[ 5.455845] Workqueue: events_unbound deferred_probe_work_func
[ 5.461699] Call trace:
[ 5.464147] show_stack+0x18/0x24 C
[ 5.467821] dump_stack_lvl (lib/dump_stack.c:123)
[ 5.471501] dump_stack (lib/dump_stack.c:130)
[ 5.474824] __lock_acquire (kernel/locking/lockdep.c:4828 kernel/locking/lockdep.c:4898 kernel/locking/lockdep.c:5176)
[ 5.478758] lock_acquire (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814)
[ 5.482429] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)
[ 5.486797] xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))
[ 5.490737] irq_enable (kernel/irq/internals.h:236 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345)
[ 5.494060] __irq_startup (kernel/irq/internals.h:241 kernel/irq/chip.c:180 kernel/irq/chip.c:250)
[ 5.497645] irq_startup (kernel/irq/chip.c:270)
[ 5.501143] __setup_irq (kernel/irq/manage.c:1807)
[ 5.504728] request_threaded_irq (kernel/irq/manage.c:2208) |
["https://git.kernel.org/stable/c/9860370c2172704b6b4f0075a0c2a29fd84af96a","https://git.kernel.org/stable/c/9c035105c5537d2ecad6b9415e9417a1ffbd0a62","https://git.kernel.org/stable/c/b0111650ee596219bb5defa0ce1a1308e6e77ccf","https://git.kernel.org/stable/c/d25041d4a3b2af64c888cf762362b2528ba59294","https://git.kernel.org/stable/c/f0ed2d0abc021f56fa27dc6d0770535c1851a43b"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52527
|
Medium |
fixed |
- 4.14.327
- 4.19.296
- 5.4.258
- 5.10.198
- 5.15.135
- 6.1.57
- 6.5.7
|
In the Linux kernel, the following vulnerability has been resolved:
ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()
Including the transhdrlen in length is a problem when the packet is
partially filled (e.g. something like send(MSG_MORE) happened previously)
when appending to an IPv4 or IPv6 packet as we don't want to repeat the
transport header or account for it twice. This can happen under some
circumstances, such as splicing into an L2TP socket.
The symptom observed is a warning in __ip6_append_data():
WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800
that occurs when MSG_SPLICE_PAGES is used to append more data to an already
partially occupied skbuff. The warning occurs when 'copy' is larger than
the amount of data in the message iterator. This is because the requested
length includes the transport header length when it shouldn't. This can be
triggered by, for example:
sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP);
bind(sfd, ...); // ::1
connect(sfd, ...); // ::1 port 7
send(sfd, buffer, 4100, MSG_MORE);
sendfile(sfd, dfd, NULL, 1024);
Fix this by only adding transhdrlen into the length if the write queue is
empty in l2tp_ip6_sendmsg(), analogously to how UDP does things.
l2tp_ip_sendmsg() looks like it won't suffer from this problem as it builds
the UDP packet itself. |
["https://git.kernel.org/stable/c/1fc793d68d50dee4782ef2e808913d5dd880bcc6","https://git.kernel.org/stable/c/559d697c5d072593d22b3e0bd8b8081108aeaf59","https://git.kernel.org/stable/c/7626b9fed53092aa2147978070e610ecb61af844","https://git.kernel.org/stable/c/96b2e1090397217839fcd6c9b6d8f5d439e705ed","https://git.kernel.org/stable/c/9d4c75800f61e5d75c1659ba201b6c0c7ead3070","https://git.kernel.org/stable/c/cd1189956393bf850b2e275e37411855d3bd86bb","https://git.kernel.org/stable/c/f6a7182179c0ed788e3755ee2ed18c888ddcc33f","https://git.kernel.org/stable/c/fe80658c08e3001c80c5533cd41abfbb0e0e28fd","https://git.kernel.org/stable/c/1fc793d68d50dee4782ef2e808913d5dd880bcc6","https://git.kernel.org/stable/c/559d697c5d072593d22b3e0bd8b8081108aeaf59","https://git.kernel.org/stable/c/7626b9fed53092aa2147978070e610ecb61af844","https://git.kernel.org/stable/c/96b2e1090397217839fcd6c9b6d8f5d439e705ed","https://git.kernel.org/stable/c/9d4c75800f61e5d75c1659ba201b6c0c7ead3070","https://git.kernel.org/stable/c/cd1189956393bf850b2e275e37411855d3bd86bb","https://git.kernel.org/stable/c/f6a7182179c0ed788e3755ee2ed18c888ddcc33f","https://git.kernel.org/stable/c/fe80658c08e3001c80c5533cd41abfbb0e0e28fd"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52528
|
Medium |
fixed |
- 4.14.327
- 4.19.296
- 5.4.258
- 5.10.198
- 5.15.135
- 6.1.57
- 6.5.7
|
In the Linux kernel, the following vulnerability has been resolved:
net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg
syzbot reported the following uninit-value access issue:
=====================================================
BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482
CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x21c/0x280 lib/dump_stack.c:118
kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121
__msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482
usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737
usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374
really_probe+0xf20/0x20b0 drivers/base/dd.c:529
driver_probe_device+0x293/0x390 drivers/base/dd.c:701
__device_attach_driver+0x63f/0x830 drivers/base/dd.c:807
bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431
__device_attach+0x4e2/0x7f0 drivers/base/dd.c:873
device_initial_probe+0x4a/0x60 drivers/base/dd.c:920
bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491
device_add+0x3b0e/0x40d0 drivers/base/core.c:2680
usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032
usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241
usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272
really_probe+0xf20/0x20b0 drivers/base/dd.c:529
driver_probe_device+0x293/0x390 drivers/base/dd.c:701
__device_attach_driver+0x63f/0x830 drivers/base/dd.c:807
bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431
__device_attach+0x4e2/0x7f0 drivers/base/dd.c:873
device_initial_probe+0x4a/0x60 drivers/base/dd.c:920
bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491
device_add+0x3b0e/0x40d0 drivers/base/core.c:2680
usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554
hub_port_connect drivers/usb/core/hub.c:5208 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]
port_event drivers/usb/core/hub.c:5494 [inline]
hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576
process_one_work+0x1688/0x2140 kernel/workqueue.c:2269
worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415
kthread+0x551/0x590 kernel/kthread.c:292
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
Local variable ----buf.i87@smsc75xx_bind created at:
__smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]
smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482
__smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]
smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482
This issue is caused because usbnet_read_cmd() reads less bytes than requested
(zero byte in the reproducer). In this case, 'buf' is not properly filled.
This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads
less bytes than requested. |
["https://git.kernel.org/stable/c/2a36d9e2995c8c3c3f179aab1215a69cff06cbed","https://git.kernel.org/stable/c/30bc4d7aebe33904b0f2d3aad4b4a9c6029ad0c5","https://git.kernel.org/stable/c/310f1c92f65ad905b7e81fe14de82d979ebbd825","https://git.kernel.org/stable/c/3e0af6eec1789fd11934164a7f4dbcad979855a4","https://git.kernel.org/stable/c/4931e80da9463b03bfe42be54a9a19f213b0f76d","https://git.kernel.org/stable/c/9ffc5018020fe646795a8dc1203224b8f776dc09","https://git.kernel.org/stable/c/cda10784a176d7192f08ecb518f777a4e9575812","https://git.kernel.org/stable/c/e9c65989920f7c28775ec4e0c11b483910fb67b8","https://git.kernel.org/stable/c/2a36d9e2995c8c3c3f179aab1215a69cff06cbed","https://git.kernel.org/stable/c/30bc4d7aebe33904b0f2d3aad4b4a9c6029ad0c5","https://git.kernel.org/stable/c/310f1c92f65ad905b7e81fe14de82d979ebbd825","https://git.kernel.org/stable/c/3e0af6eec1789fd11934164a7f4dbcad979855a4","https://git.kernel.org/stable/c/4931e80da9463b03bfe42be54a9a19f213b0f76d","https://git.kernel.org/stable/c/9ffc5018020fe646795a8dc1203224b8f776dc09","https://git.kernel.org/stable/c/cda10784a176d7192f08ecb518f777a4e9575812","https://git.kernel.org/stable/c/e9c65989920f7c28775ec4e0c11b483910fb67b8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26788
|
Medium |
fixed |
- 5.4.271
- 5.10.212
- 5.15.151
- 6.1.81
- 6.6.21
- 6.7.9
|
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: fsl-qdma: init irq after reg initialization
Initialize the qDMA irqs after the registers are configured so that
interrupts that may have been pending from a primary kernel don't get
processed by the irq handler before it is ready to and cause panic with
the following trace:
Call trace:
fsl_qdma_queue_handler+0xf8/0x3e8
__handle_irq_event_percpu+0x78/0x2b0
handle_irq_event_percpu+0x1c/0x68
handle_irq_event+0x44/0x78
handle_fasteoi_irq+0xc8/0x178
generic_handle_irq+0x24/0x38
__handle_domain_irq+0x90/0x100
gic_handle_irq+0x5c/0xb8
el1_irq+0xb8/0x180
_raw_spin_unlock_irqrestore+0x14/0x40
__setup_irq+0x4bc/0x798
request_threaded_irq+0xd8/0x190
devm_request_threaded_irq+0x74/0xe8
fsl_qdma_probe+0x4d4/0xca8
platform_drv_probe+0x50/0xa0
really_probe+0xe0/0x3f8
driver_probe_device+0x64/0x130
device_driver_attach+0x6c/0x78
__driver_attach+0xbc/0x158
bus_for_each_dev+0x5c/0x98
driver_attach+0x20/0x28
bus_add_driver+0x158/0x220
driver_register+0x60/0x110
__platform_driver_register+0x44/0x50
fsl_qdma_driver_init+0x18/0x20
do_one_initcall+0x48/0x258
kernel_init_freeable+0x1a4/0x23c
kernel_init+0x10/0xf8
ret_from_fork+0x10/0x18 |
["https://git.kernel.org/stable/c/3cc5fb824c2125aa3740d905b3e5b378c8a09478","https://git.kernel.org/stable/c/4529c084a320be78ff2c5e64297ae998c6fdf66b","https://git.kernel.org/stable/c/474d521da890b3e3585335fb80a6044cb2553d99","https://git.kernel.org/stable/c/677102a930643c31f1b4c512b041407058bdfef8","https://git.kernel.org/stable/c/87a39071e0b639f45e05d296cc0538eef44ec0bd","https://git.kernel.org/stable/c/9579a21e99fe8dab22a253050ddff28d340d74e1","https://git.kernel.org/stable/c/a69c8bbb946936ac4eb6a6ae1e849435aa8d947d","https://git.kernel.org/stable/c/3cc5fb824c2125aa3740d905b3e5b378c8a09478","https://git.kernel.org/stable/c/4529c084a320be78ff2c5e64297ae998c6fdf66b","https://git.kernel.org/stable/c/474d521da890b3e3585335fb80a6044cb2553d99","https://git.kernel.org/stable/c/677102a930643c31f1b4c512b041407058bdfef8","https://git.kernel.org/stable/c/87a39071e0b639f45e05d296cc0538eef44ec0bd","https://git.kernel.org/stable/c/9579a21e99fe8dab22a253050ddff28d340d74e1","https://git.kernel.org/stable/c/a69c8bbb946936ac4eb6a6ae1e849435aa8d947d","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52566
|
Medium |
fixed |
- 4.14.327
- 4.19.296
- 5.4.258
- 5.10.198
- 5.15.134
- 6.1.56
- 6.5.6
|
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential use after free in nilfs_gccache_submit_read_data()
In nilfs_gccache_submit_read_data(), brelse(bh) is called to drop the
reference count of bh when the call to nilfs_dat_translate() fails. If
the reference count hits 0 and its owner page gets unlocked, bh may be
freed. However, bh->b_page is dereferenced to put the page after that,
which may result in a use-after-free bug. This patch moves the release
operation after unlocking and putting the page.
NOTE: The function in question is only called in GC, and in combination
with current userland tools, address translation using DAT does not occur
in that function, so the code path that causes this issue will not be
executed. However, it is possible to run that code path by intentionally
modifying the userland GC library or by calling the GC ioctl directly.
[konishi.ryusuke@gmail.com: NOTE added to the commit log] |
["https://git.kernel.org/stable/c/193b5a1c6c67c36b430989dc063fe7ea4e200a33","https://git.kernel.org/stable/c/28df4646ad8b433340772edc90ca709cdefc53e2","https://git.kernel.org/stable/c/3936e8714907cd55e37c7cc50e50229e4a9042e8","https://git.kernel.org/stable/c/7130a87ca32396eb9bf48b71a2d42259ae44c6c7","https://git.kernel.org/stable/c/7ee29facd8a9c5a26079148e36bcf07141b3a6bc","https://git.kernel.org/stable/c/980663f1d189eedafd18d80053d9cf3e2ceb5c8c","https://git.kernel.org/stable/c/bb61224f6abc8e71bfdf06d7c984e23460875f5b","https://git.kernel.org/stable/c/fb1084e63ee56958b0a56e17a50a4fd86445b9c1","https://git.kernel.org/stable/c/193b5a1c6c67c36b430989dc063fe7ea4e200a33","https://git.kernel.org/stable/c/28df4646ad8b433340772edc90ca709cdefc53e2","https://git.kernel.org/stable/c/3936e8714907cd55e37c7cc50e50229e4a9042e8","https://git.kernel.org/stable/c/7130a87ca32396eb9bf48b71a2d42259ae44c6c7","https://git.kernel.org/stable/c/7ee29facd8a9c5a26079148e36bcf07141b3a6bc","https://git.kernel.org/stable/c/980663f1d189eedafd18d80053d9cf3e2ceb5c8c","https://git.kernel.org/stable/c/bb61224f6abc8e71bfdf06d7c984e23460875f5b","https://git.kernel.org/stable/c/fb1084e63ee56958b0a56e17a50a4fd86445b9c1"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26702
|
Medium |
fixed |
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRC
Recently, we encounter kernel crash in function rm3100_common_probe
caused by out of bound access of array rm3100_samp_rates (because of
underlying hardware failures). Add boundary check to prevent out of
bound access. |
["https://git.kernel.org/stable/c/176256ff8abff29335ecff905a09fb49e8dcf513","https://git.kernel.org/stable/c/1d8c67e94e9e977603473a543d4f322cf2c4aa01","https://git.kernel.org/stable/c/36a49290d7e6d554020057a409747a092b1d3b56","https://git.kernel.org/stable/c/57d05dbbcd0b3dc0c252103b43012eef5d6430d1","https://git.kernel.org/stable/c/7200170e88e3ec54d9e9c63f07514c3cead11481","https://git.kernel.org/stable/c/792595bab4925aa06532a14dd256db523eb4fa5e","https://git.kernel.org/stable/c/8d5838a473e8e6d812257c69745f5920e4924a60","https://git.kernel.org/stable/c/176256ff8abff29335ecff905a09fb49e8dcf513","https://git.kernel.org/stable/c/1d8c67e94e9e977603473a543d4f322cf2c4aa01","https://git.kernel.org/stable/c/36a49290d7e6d554020057a409747a092b1d3b56","https://git.kernel.org/stable/c/57d05dbbcd0b3dc0c252103b43012eef5d6430d1","https://git.kernel.org/stable/c/7200170e88e3ec54d9e9c63f07514c3cead11481","https://git.kernel.org/stable/c/792595bab4925aa06532a14dd256db523eb4fa5e","https://git.kernel.org/stable/c/8d5838a473e8e6d812257c69745f5920e4924a60","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26903
|
Medium |
fixed |
- 4.19.311
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
|
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security
During our fuzz testing of the connection and disconnection process at the
RFCOMM layer, we discovered this bug. By comparing the packets from a
normal connection and disconnection process with the testcase that
triggered a KASAN report. We analyzed the cause of this bug as follows:
1. In the packets captured during a normal connection, the host sends a
`Read Encryption Key Size` type of `HCI_CMD` packet
(Command Opcode: 0x1408) to the controller to inquire the length of
encryption key.After receiving this packet, the controller immediately
replies with a Command Completepacket (Event Code: 0x0e) to return the
Encryption Key Size.
2. In our fuzz test case, the timing of the controller's response to this
packet was delayed to an unexpected point: after the RFCOMM and L2CAP
layers had disconnected but before the HCI layer had disconnected.
3. After receiving the Encryption Key Size Response at the time described
in point 2, the host still called the rfcomm_check_security function.
However, by this time `struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;`
had already been released, and when the function executed
`return hci_conn_security(conn->hcon, d->sec_level, auth_type, d->out);`,
specifically when accessing `conn->hcon`, a null-ptr-deref error occurred.
To fix this bug, check if `sk->sk_state` is BT_CLOSED before calling
rfcomm_recv_frame in rfcomm_process_rx. |
["https://git.kernel.org/stable/c/2535b848fa0f42ddff3e5255cf5e742c9b77bb26","https://git.kernel.org/stable/c/369f419c097e82407dd429a202cde9a73d3ae29b","https://git.kernel.org/stable/c/3ead59bafad05f2967ae2438c0528d53244cfde5","https://git.kernel.org/stable/c/567c0411dc3b424fc7bd1e6109726d7ba32d4f73","https://git.kernel.org/stable/c/5f369efd9d963c1f711a06c9b8baf9f5ce616d85","https://git.kernel.org/stable/c/5f9fe302dd3a9bbc50f4888464c1773f45166bfd","https://git.kernel.org/stable/c/81d7d920a22fd58ef9aedb1bd0a68ee32bd23e96","https://git.kernel.org/stable/c/8d1753973f598531baaa2c1033cf7f7b5bb004b0","https://git.kernel.org/stable/c/2535b848fa0f42ddff3e5255cf5e742c9b77bb26","https://git.kernel.org/stable/c/369f419c097e82407dd429a202cde9a73d3ae29b","https://git.kernel.org/stable/c/3ead59bafad05f2967ae2438c0528d53244cfde5","https://git.kernel.org/stable/c/567c0411dc3b424fc7bd1e6109726d7ba32d4f73","https://git.kernel.org/stable/c/5f369efd9d963c1f711a06c9b8baf9f5ce616d85","https://git.kernel.org/stable/c/5f9fe302dd3a9bbc50f4888464c1773f45166bfd","https://git.kernel.org/stable/c/81d7d920a22fd58ef9aedb1bd0a68ee32bd23e96","https://git.kernel.org/stable/c/8d1753973f598531baaa2c1033cf7f7b5bb004b0","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-2166
|
Medium |
fixed |
|
A null pointer dereference issue was found in can protocol in net/can/af_can.c in the Linux before Linux. ml_priv may not be initialized in the receive path of CAN frames. A local user could use this flaw to crash the system or potentially cause a denial of service. |
["https://lore.kernel.org/lkml/CAO4mrfcV_07hbj8NUuZrA8FH-kaRsrFy-2metecpTuE5kKHn5w%40mail.gmail.com/","https://lore.kernel.org/lkml/CAO4mrfcV_07hbj8NUuZrA8FH-kaRsrFy-2metecpTuE5kKHn5w%40mail.gmail.com/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-28327
|
Medium |
fixed |
|
A NULL pointer dereference flaw was found in the UNIX protocol in net/unix/diag.c In unix_diag_get_exact in the Linux Kernel. The newly allocated skb does not have sk, leading to a NULL pointer. This flaw allows a local user to crash or potentially cause a denial of service. |
["https://bugzilla.redhat.com/show_bug.cgi?id=2177382","https://bugzilla.redhat.com/show_bug.cgi?id=2177382"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26779
|
Medium |
fixed |
- 4.19.308
- 5.4.270
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix race condition on enabling fast-xmit
fast-xmit must only be enabled after the sta has been uploaded to the driver,
otherwise it could end up passing the not-yet-uploaded sta via drv_tx calls
to the driver, leading to potential crashes because of uninitialized drv_priv
data.
Add a missing sta->uploaded check and re-check fast xmit after inserting a sta. |
["https://git.kernel.org/stable/c/281280276b70c822f55ce15b661f6d1d3228aaa9","https://git.kernel.org/stable/c/54b79d8786964e2f840e8a2ec4a9f9a50f3d4954","https://git.kernel.org/stable/c/5ffab99e070b9f8ae0cf60c3c3602b84eee818dd","https://git.kernel.org/stable/c/76fad1174a0cae6fc857b9f88b261a2e4f07d587","https://git.kernel.org/stable/c/85720b69aef177318f4a18efbcc4302228a340e5","https://git.kernel.org/stable/c/88c18fd06608b3adee547102505d715f21075c9d","https://git.kernel.org/stable/c/bcbc84af1183c8cf3d1ca9b78540c2185cd85e7f","https://git.kernel.org/stable/c/eb39bb548bf974acad7bd6780fe11f9e6652d696","https://git.kernel.org/stable/c/281280276b70c822f55ce15b661f6d1d3228aaa9","https://git.kernel.org/stable/c/54b79d8786964e2f840e8a2ec4a9f9a50f3d4954","https://git.kernel.org/stable/c/5ffab99e070b9f8ae0cf60c3c3602b84eee818dd","https://git.kernel.org/stable/c/76fad1174a0cae6fc857b9f88b261a2e4f07d587","https://git.kernel.org/stable/c/85720b69aef177318f4a18efbcc4302228a340e5","https://git.kernel.org/stable/c/88c18fd06608b3adee547102505d715f21075c9d","https://git.kernel.org/stable/c/bcbc84af1183c8cf3d1ca9b78540c2185cd85e7f","https://git.kernel.org/stable/c/eb39bb548bf974acad7bd6780fe11f9e6652d696","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-25739
|
Medium |
|
N/A
|
create_empty_lvol in drivers/mtd/ubi/vtbl.c in the Linux kernel through 6.7.4 can attempt to allocate zero bytes, and crash, because of a missing check for ubi->leb_size. |
["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=68a24aba7c593eafa8fd00f2f76407b9b32b47a9","https://groups.google.com/g/syzkaller/c/Xl97YcQA4hg","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/mtd/ubi/vtbl.c?h=v6.6.24\u0026id=d1b505c988b7","https://www.spinics.net/lists/kernel/msg5074816.html","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=68a24aba7c593eafa8fd00f2f76407b9b32b47a9","https://groups.google.com/g/syzkaller/c/Xl97YcQA4hg","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://www.spinics.net/lists/kernel/msg5074816.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-25741
|
Medium |
|
N/A
|
printer_write in drivers/usb/gadget/function/f_printer.c in the Linux kernel through 6.7.4 does not properly call usb_ep_queue, which might allow attackers to cause a denial of service or have unspecified other impact. |
["https://www.spinics.net/lists/linux-usb/msg252167.html","https://www.spinics.net/lists/linux-usb/msg252167.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52477
|
Medium |
fixed |
- 4.14.328
- 4.19.297
- 5.4.259
- 5.10.199
- 5.15.136
- 6.1.59
- 6.5.8
|
In the Linux kernel, the following vulnerability has been resolved:
usb: hub: Guard against accesses to uninitialized BOS descriptors
Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h
access fields inside udev->bos without checking if it was allocated and
initialized. If usb_get_bos_descriptor() fails for whatever
reason, udev->bos will be NULL and those accesses will result in a
crash:
BUG: kernel NULL pointer dereference, address: 0000000000000018
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1>
Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021
Workqueue: usb_hub_wq hub_event
RIP: 0010:hub_port_reset+0x193/0x788
Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9
RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310
RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840
RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0
Call Trace:
hub_event+0x73f/0x156e
? hub_activate+0x5b7/0x68f
process_one_work+0x1a2/0x487
worker_thread+0x11a/0x288
kthread+0x13a/0x152
? process_one_work+0x487/0x487
? kthread_associate_blkcg+0x70/0x70
ret_from_fork+0x1f/0x30
Fall back to a default behavior if the BOS descriptor isn't accessible
and skip all the functionalities that depend on it: LPM support checks,
Super Speed capabilitiy checks, U1/U2 states setup. |
["https://git.kernel.org/stable/c/136f69a04e71ba3458d137aec3bb2ce1232c0289","https://git.kernel.org/stable/c/241f230324337ed5eae3846a554fb6d15169872c","https://git.kernel.org/stable/c/528f0ba9f7a4bc1b61c9b6eb591ff97ca37cac6b","https://git.kernel.org/stable/c/6ad3e9fd3632106696692232bf7ff88b9f7e1bc3","https://git.kernel.org/stable/c/8e7346bfea56453e31b7421c1c17ca2fb9ed613d","https://git.kernel.org/stable/c/c64e4dca9aefd232b17ac4c779b608b286654e81","https://git.kernel.org/stable/c/f74a7afc224acd5e922c7a2e52244d891bbe44ee","https://git.kernel.org/stable/c/fb9895ab9533534335fa83d70344b397ac862c81","https://git.kernel.org/stable/c/136f69a04e71ba3458d137aec3bb2ce1232c0289","https://git.kernel.org/stable/c/241f230324337ed5eae3846a554fb6d15169872c","https://git.kernel.org/stable/c/528f0ba9f7a4bc1b61c9b6eb591ff97ca37cac6b","https://git.kernel.org/stable/c/6ad3e9fd3632106696692232bf7ff88b9f7e1bc3","https://git.kernel.org/stable/c/8e7346bfea56453e31b7421c1c17ca2fb9ed613d","https://git.kernel.org/stable/c/c64e4dca9aefd232b17ac4c779b608b286654e81","https://git.kernel.org/stable/c/f74a7afc224acd5e922c7a2e52244d891bbe44ee","https://git.kernel.org/stable/c/fb9895ab9533534335fa83d70344b397ac862c81"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52484
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range
When running an SVA case, the following soft lockup is triggered:
--------------------------------------------------------------------
watchdog: BUG: soft lockup - CPU#244 stuck for 26s!
pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50
lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50
sp : ffff8000d83ef290
x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000
x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000
x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0
x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0
x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa
x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a
x2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001
Call trace:
arm_smmu_cmdq_issue_cmdlist+0x178/0xa50
__arm_smmu_tlb_inv_range+0x118/0x254
arm_smmu_tlb_inv_range_asid+0x6c/0x130
arm_smmu_mm_invalidate_range+0xa0/0xa4
__mmu_notifier_invalidate_range_end+0x88/0x120
unmap_vmas+0x194/0x1e0
unmap_region+0xb4/0x144
do_mas_align_munmap+0x290/0x490
do_mas_munmap+0xbc/0x124
__vm_munmap+0xa8/0x19c
__arm64_sys_munmap+0x28/0x50
invoke_syscall+0x78/0x11c
el0_svc_common.constprop.0+0x58/0x1c0
do_el0_svc+0x34/0x60
el0_svc+0x2c/0xd4
el0t_64_sync_handler+0x114/0x140
el0t_64_sync+0x1a4/0x1a8
--------------------------------------------------------------------
Note that since 6.6-rc1 the arm_smmu_mm_invalidate_range above is renamed
to "arm_smmu_mm_arch_invalidate_secondary_tlbs", yet the problem remains.
The commit 06ff87bae8d3 ("arm64: mm: remove unused functions and variable
protoypes") fixed a similar lockup on the CPU MMU side. Yet, it can occur
to SMMU too, since arm_smmu_mm_arch_invalidate_secondary_tlbs() is called
typically next to MMU tlb flush function, e.g.
tlb_flush_mmu_tlbonly {
tlb_flush {
__flush_tlb_range {
// check MAX_TLBI_OPS
}
}
mmu_notifier_arch_invalidate_secondary_tlbs {
arm_smmu_mm_arch_invalidate_secondary_tlbs {
// does not check MAX_TLBI_OPS
}
}
}
Clone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an
SVA case SMMU uses the CPU page table, so it makes sense to align with the
tlbflush code. Then, replace per-page TLBI commands with a single per-asid
TLBI command, if the request size hits this threshold. |
["https://git.kernel.org/stable/c/3283a1bce9bbc978059f790b84f3c10c32492429","https://git.kernel.org/stable/c/d5afb4b47e13161b3f33904d45110f9e6463bad6","https://git.kernel.org/stable/c/f5a604757aa8e37ea9c7011dc9da54fa1b30f29b","https://git.kernel.org/stable/c/f90f4c562003ac3d3b135c5a40a5383313f27264","https://git.kernel.org/stable/c/3283a1bce9bbc978059f790b84f3c10c32492429","https://git.kernel.org/stable/c/d5afb4b47e13161b3f33904d45110f9e6463bad6","https://git.kernel.org/stable/c/f5a604757aa8e37ea9c7011dc9da54fa1b30f29b","https://git.kernel.org/stable/c/f90f4c562003ac3d3b135c5a40a5383313f27264"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-0639
|
Medium |
|
N/A
|
A denial of service vulnerability due to a deadlock was found in sctp_auto_asconf_init in net/sctp/socket.c in the Linux kernel’s SCTP subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system. |
["https://access.redhat.com/security/cve/CVE-2024-0639","https://bugzilla.redhat.com/show_bug.cgi?id=2258754","https://github.com/torvalds/linux/commit/6feb37b3b06e9049e20dcf7e23998f92c9c5be9a","https://access.redhat.com/security/cve/CVE-2024-0639","https://bugzilla.redhat.com/show_bug.cgi?id=2258754","https://github.com/torvalds/linux/commit/6feb37b3b06e9049e20dcf7e23998f92c9c5be9a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-0641
|
Medium |
fixed |
|
A denial of service vulnerability was found in tipc_crypto_key_revoke in net/tipc/crypto.c in the Linux kernel’s TIPC subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system. |
["https://access.redhat.com/security/cve/CVE-2024-0641","https://bugzilla.redhat.com/show_bug.cgi?id=2258757","https://github.com/torvalds/linux/commit/08e50cf071847323414df0835109b6f3560d44f5","https://access.redhat.com/security/cve/CVE-2024-0641","https://bugzilla.redhat.com/show_bug.cgi?id=2258757","https://github.com/torvalds/linux/commit/08e50cf071847323414df0835109b6f3560d44f5"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3863
|
Medium |
fixed |
|
A use-after-free flaw was found in nfc_llcp_find_local in net/nfc/llcp_core.c in NFC in the Linux kernel. This flaw allows a local user with special privileges to impact a kernel information leak issue. |
["https://access.redhat.com/security/cve/CVE-2023-3863","https://bugzilla.redhat.com/show_bug.cgi?id=2225126","https://github.com/torvalds/linux/commit/6709d4b7bc2e079241fdef15d1160581c5261c10","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20240202-0002/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492","https://access.redhat.com/security/cve/CVE-2023-3863","https://bugzilla.redhat.com/show_bug.cgi?id=2225126","https://github.com/torvalds/linux/commit/6709d4b7bc2e079241fdef15d1160581c5261c10","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20240202-0002/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-39194
|
Medium |
fixed |
|
A flaw was found in the XFRM subsystem in the Linux kernel. The specific flaw exists within the processing of state filters, which can result in a read past the end of an allocated buffer. This flaw allows a local privileged (CAP_NET_ADMIN) attacker to trigger an out-of-bounds read, potentially leading to an information disclosure. |
["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-39194","https://bugzilla.redhat.com/show_bug.cgi?id=2226788","https://www.zerodayinitiative.com/advisories/ZDI-CAN-18111/","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-39194","https://bugzilla.redhat.com/show_bug.cgi?id=2226788","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.zerodayinitiative.com/advisories/ZDI-CAN-18111/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26861
|
Medium |
fixed |
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
wireguard: receive: annotate data-race around receiving_counter.counter
Syzkaller with KCSAN identified a data-race issue when accessing
keypair->receiving_counter.counter. Use READ_ONCE() and WRITE_ONCE()
annotations to mark the data race as intentional.
BUG: KCSAN: data-race in wg_packet_decrypt_worker / wg_packet_rx_poll
write to 0xffff888107765888 of 8 bytes by interrupt on cpu 0:
counter_validate drivers/net/wireguard/receive.c:321 [inline]
wg_packet_rx_poll+0x3ac/0xf00 drivers/net/wireguard/receive.c:461
__napi_poll+0x60/0x3b0 net/core/dev.c:6536
napi_poll net/core/dev.c:6605 [inline]
net_rx_action+0x32b/0x750 net/core/dev.c:6738
__do_softirq+0xc4/0x279 kernel/softirq.c:553
do_softirq+0x5e/0x90 kernel/softirq.c:454
__local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381
__raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]
_raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210
spin_unlock_bh include/linux/spinlock.h:396 [inline]
ptr_ring_consume_bh include/linux/ptr_ring.h:367 [inline]
wg_packet_decrypt_worker+0x6c5/0x700 drivers/net/wireguard/receive.c:499
process_one_work kernel/workqueue.c:2633 [inline]
...
read to 0xffff888107765888 of 8 bytes by task 3196 on cpu 1:
decrypt_packet drivers/net/wireguard/receive.c:252 [inline]
wg_packet_decrypt_worker+0x220/0x700 drivers/net/wireguard/receive.c:501
process_one_work kernel/workqueue.c:2633 [inline]
process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2706
worker_thread+0x525/0x730 kernel/workqueue.c:2787
... |
["https://git.kernel.org/stable/c/3f94da807fe1668b9830f0eefbbf7e887b0a7bc6","https://git.kernel.org/stable/c/45a83b220c83e3c326513269afbf69ae6fc65cce","https://git.kernel.org/stable/c/78739d72f16b2d7d549f713f1dfebd678d32484b","https://git.kernel.org/stable/c/bba045dc4d996d03dce6fe45726e78a1a1f6d4c3","https://git.kernel.org/stable/c/d691be84ab898cf136a35176eaf2f8fc116563f0","https://git.kernel.org/stable/c/f87884e0dffd61b47e58bc6e1e2f6843c212b0cc","https://git.kernel.org/stable/c/fdf16de078a97bf14bb8ee2b8d47cc3d3ead09ed","https://git.kernel.org/stable/c/3f94da807fe1668b9830f0eefbbf7e887b0a7bc6","https://git.kernel.org/stable/c/45a83b220c83e3c326513269afbf69ae6fc65cce","https://git.kernel.org/stable/c/78739d72f16b2d7d549f713f1dfebd678d32484b","https://git.kernel.org/stable/c/bba045dc4d996d03dce6fe45726e78a1a1f6d4c3","https://git.kernel.org/stable/c/d691be84ab898cf136a35176eaf2f8fc116563f0","https://git.kernel.org/stable/c/f87884e0dffd61b47e58bc6e1e2f6843c212b0cc","https://git.kernel.org/stable/c/fdf16de078a97bf14bb8ee2b8d47cc3d3ead09ed","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52608
|
Medium |
fixed |
- 5.15.149
- 6.1.76
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Check mailbox/SMT channel for consistency
On reception of a completion interrupt the shared memory area is accessed
to retrieve the message header at first and then, if the message sequence
number identifies a transaction which is still pending, the related
payload is fetched too.
When an SCMI command times out the channel ownership remains with the
platform until eventually a late reply is received and, as a consequence,
any further transmission attempt remains pending, waiting for the channel
to be relinquished by the platform.
Once that late reply is received the channel ownership is given back
to the agent and any pending request is then allowed to proceed and
overwrite the SMT area of the just delivered late reply; then the wait
for the reply to the new request starts.
It has been observed that the spurious IRQ related to the late reply can
be wrongly associated with the freshly enqueued request: when that happens
the SCMI stack in-flight lookup procedure is fooled by the fact that the
message header now present in the SMT area is related to the new pending
transaction, even though the real reply has still to arrive.
This race-condition on the A2P channel can be detected by looking at the
channel status bits: a genuine reply from the platform will have set the
channel free bit before triggering the completion IRQ.
Add a consistency check to validate such condition in the A2P ISR. |
["https://git.kernel.org/stable/c/12dc4217f16551d6dee9cbefc23fdb5659558cda","https://git.kernel.org/stable/c/437a310b22244d4e0b78665c3042e5d1c0f45306","https://git.kernel.org/stable/c/614cc65032dcb0b64d23f5c5e338a8a04b12be5d","https://git.kernel.org/stable/c/7f95f6997f4fdd17abec3200cae45420a5489350","https://git.kernel.org/stable/c/9b5e1b93c83ee5fc9f5d7bd2d45b421bd87774a2","https://git.kernel.org/stable/c/12dc4217f16551d6dee9cbefc23fdb5659558cda","https://git.kernel.org/stable/c/437a310b22244d4e0b78665c3042e5d1c0f45306","https://git.kernel.org/stable/c/614cc65032dcb0b64d23f5c5e338a8a04b12be5d","https://git.kernel.org/stable/c/7f95f6997f4fdd17abec3200cae45420a5489350","https://git.kernel.org/stable/c/9b5e1b93c83ee5fc9f5d7bd2d45b421bd87774a2"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52645
|
Medium |
fixed |
- 5.15.150
- 6.1.80
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
pmdomain: mediatek: fix race conditions with genpd
If the power domains are registered first with genpd and *after that*
the driver attempts to power them on in the probe sequence, then it is
possible that a race condition occurs if genpd tries to power them on
in the same time.
The same is valid for powering them off before unregistering them
from genpd.
Attempt to fix race conditions by first removing the domains from genpd
and *after that* powering down domains.
Also first power up the domains and *after that* register them
to genpd. |
["https://git.kernel.org/stable/c/339ddc983bc1622341d95f244c361cda3da3a4ff","https://git.kernel.org/stable/c/3cd1d92ee1dbf3e8f988767eb75f26207397792b","https://git.kernel.org/stable/c/475426ad1ae0bfdfd8f160ed9750903799392438","https://git.kernel.org/stable/c/c41336f4d69057cbf88fed47951379b384540df5","https://git.kernel.org/stable/c/f83b9abee9faa4868a6fac4669b86f4c215dae25","https://git.kernel.org/stable/c/339ddc983bc1622341d95f244c361cda3da3a4ff","https://git.kernel.org/stable/c/3cd1d92ee1dbf3e8f988767eb75f26207397792b","https://git.kernel.org/stable/c/475426ad1ae0bfdfd8f160ed9750903799392438","https://git.kernel.org/stable/c/c41336f4d69057cbf88fed47951379b384540df5","https://git.kernel.org/stable/c/f83b9abee9faa4868a6fac4669b86f4c215dae25"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26837
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: switchdev: Skip MDB replays of deferred events on offload
Before this change, generation of the list of MDB events to replay
would race against the creation of new group memberships, either from
the IGMP/MLD snooping logic or from user configuration.
While new memberships are immediately visible to walkers of
br->mdb_list, the notification of their existence to switchdev event
subscribers is deferred until a later point in time. So if a replay
list was generated during a time that overlapped with such a window,
it would also contain a replay of the not-yet-delivered event.
The driver would thus receive two copies of what the bridge internally
considered to be one single event. On destruction of the bridge, only
a single membership deletion event was therefore sent. As a
consequence of this, drivers which reference count memberships (at
least DSA), would be left with orphan groups in their hardware
database when the bridge was destroyed.
This is only an issue when replaying additions. While deletion events
may still be pending on the deferred queue, they will already have
been removed from br->mdb_list, so no duplicates can be generated in
that scenario.
To a user this meant that old group memberships, from a bridge in
which a port was previously attached, could be reanimated (in
hardware) when the port joined a new bridge, without the new bridge's
knowledge.
For example, on an mv88e6xxx system, create a snooping bridge and
immediately add a port to it:
root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \
> ip link set dev x3 up master br0
And then destroy the bridge:
root@infix-06-0b-00:~$ ip link del dev br0
root@infix-06-0b-00:~$ mvls atu
ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a
DEV:0 Marvell 88E6393X
33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . .
33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . .
ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a
root@infix-06-0b-00:~$
The two IPv6 groups remain in the hardware database because the
port (x3) is notified of the host's membership twice: once via the
original event and once via a replay. Since only a single delete
notification is sent, the count remains at 1 when the bridge is
destroyed.
Then add the same port (or another port belonging to the same hardware
domain) to a new bridge, this time with snooping disabled:
root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \
> ip link set dev x3 up master br1
All multicast, including the two IPv6 groups from br0, should now be
flooded, according to the policy of br1. But instead the old
memberships are still active in the hardware database, causing the
switch to only forward traffic to those groups towards the CPU (port
0).
Eliminate the race in two steps:
1. Grab the write-side lock of the MDB while generating the replay
list.
This prevents new memberships from showing up while we are generating
the replay list. But it leaves the scenario in which a deferred event
was already generated, but not delivered, before we grabbed the
lock. Therefore:
2. Make sure that no deferred version of a replay event is already
enqueued to the switchdev deferred queue, before adding it to the
replay list, when replaying additions. |
["https://git.kernel.org/stable/c/2d5b4b3376fa146a23917b8577064906d643925f","https://git.kernel.org/stable/c/603be95437e7fd85ba694e75918067fb9e7754db","https://git.kernel.org/stable/c/dc489f86257cab5056e747344f17a164f63bff4b","https://git.kernel.org/stable/c/e0b4c5b1d760008f1dd18c07c35af0442e54f9c8","https://git.kernel.org/stable/c/2d5b4b3376fa146a23917b8577064906d643925f","https://git.kernel.org/stable/c/603be95437e7fd85ba694e75918067fb9e7754db","https://git.kernel.org/stable/c/dc489f86257cab5056e747344f17a164f63bff4b","https://git.kernel.org/stable/c/e0b4c5b1d760008f1dd18c07c35af0442e54f9c8"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52489
|
Medium |
fixed |
- 5.10.210
- 5.15.149
- 6.1.76
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
mm/sparsemem: fix race in accessing memory_section->usage
The below race is observed on a PFN which falls into the device memory
region with the system memory configuration where PFN's are such that
[ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL]. Since normal zone start and end
pfn contains the device memory PFN's as well, the compaction triggered
will try on the device memory PFN's too though they end up in NOP(because
pfn_to_online_page() returns NULL for ZONE_DEVICE memory sections). When
from other core, the section mappings are being removed for the
ZONE_DEVICE region, that the PFN in question belongs to, on which
compaction is currently being operated is resulting into the kernel crash
with CONFIG_SPASEMEM_VMEMAP enabled. The crash logs can be seen at [1].
compact_zone() memunmap_pages
------------- ---------------
__pageblock_pfn_to_page
......
(a)pfn_valid():
valid_section()//return true
(b)__remove_pages()->
sparse_remove_section()->
section_deactivate():
[Free the array ms->usage and set
ms->usage = NULL]
pfn_section_valid()
[Access ms->usage which
is NULL]
NOTE: From the above it can be said that the race is reduced to between
the pfn_valid()/pfn_section_valid() and the section deactivate with
SPASEMEM_VMEMAP enabled.
The commit b943f045a9af("mm/sparse: fix kernel crash with
pfn_section_valid check") tried to address the same problem by clearing
the SECTION_HAS_MEM_MAP with the expectation of valid_section() returns
false thus ms->usage is not accessed.
Fix this issue by the below steps:
a) Clear SECTION_HAS_MEM_MAP before freeing the ->usage.
b) RCU protected read side critical section will either return NULL
when SECTION_HAS_MEM_MAP is cleared or can successfully access ->usage.
c) Free the ->usage with kfree_rcu() and set ms->usage = NULL. No
attempt will be made to access ->usage after this as the
SECTION_HAS_MEM_MAP is cleared thus valid_section() return false.
Thanks to David/Pavan for their inputs on this patch.
[1] https://lore.kernel.org/linux-mm/994410bb-89aa-d987-1f50-f514903c55aa@quicinc.com/
On Snapdragon SoC, with the mentioned memory configuration of PFN's as
[ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL], we are able to see bunch of
issues daily while testing on a device farm.
For this particular issue below is the log. Though the below log is
not directly pointing to the pfn_section_valid(){ ms->usage;}, when we
loaded this dump on T32 lauterbach tool, it is pointing.
[ 540.578056] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000000
[ 540.578068] Mem abort info:
[ 540.578070] ESR = 0x0000000096000005
[ 540.578073] EC = 0x25: DABT (current EL), IL = 32 bits
[ 540.578077] SET = 0, FnV = 0
[ 540.578080] EA = 0, S1PTW = 0
[ 540.578082] FSC = 0x05: level 1 translation fault
[ 540.578085] Data abort info:
[ 540.578086] ISV = 0, ISS = 0x00000005
[ 540.578088] CM = 0, WnR = 0
[ 540.579431] pstate: 82400005 (Nzcv daif +PAN -UAO +TCO -DIT -SSBSBTYPE=--)
[ 540.579436] pc : __pageblock_pfn_to_page+0x6c/0x14c
[ 540.579454] lr : compact_zone+0x994/0x1058
[ 540.579460] sp : ffffffc03579b510
[ 540.579463] x29: ffffffc03579b510 x28: 0000000000235800 x27:000000000000000c
[ 540.579470] x26: 0000000000235c00 x25: 0000000000000068 x24:ffffffc03579b640
[ 540.579477] x23: 0000000000000001 x22: ffffffc03579b660 x21:0000000000000000
[ 540.579483] x20: 0000000000235bff x19: ffffffdebf7e3940 x18:ffffffdebf66d140
[ 540.579489] x17: 00000000739ba063 x16: 00000000739ba063 x15:00000000009f4bff
[ 540.579495] x14: 0000008000000000 x13: 0000000000000000 x12:0000000000000001
[ 540.579501] x11: 0000000000000000 x10: 0000000000000000 x9 :ffffff897d2cd440
[ 540.579507] x8 : 0000000000000000 x7 : 0000000000000000 x6 :ffffffc03579b5b4
[ 540.579512] x5 : 0000000000027f25 x4 : ffffffc03579b5b8 x3 :0000000000000
---truncated--- |
["https://git.kernel.org/stable/c/3a01daace71b521563c38bbbf874e14c3e58adb7","https://git.kernel.org/stable/c/5ec8e8ea8b7783fab150cf86404fc38cb4db8800","https://git.kernel.org/stable/c/68ed9e33324021e9d6b798e9db00ca3093d2012a","https://git.kernel.org/stable/c/70064241f2229f7ba7b9599a98f68d9142e81a97","https://git.kernel.org/stable/c/90ad17575d26874287271127d43ef3c2af876cea","https://git.kernel.org/stable/c/b448de2459b6d62a53892487ab18b7d823ff0529","https://git.kernel.org/stable/c/3a01daace71b521563c38bbbf874e14c3e58adb7","https://git.kernel.org/stable/c/5ec8e8ea8b7783fab150cf86404fc38cb4db8800","https://git.kernel.org/stable/c/68ed9e33324021e9d6b798e9db00ca3093d2012a","https://git.kernel.org/stable/c/70064241f2229f7ba7b9599a98f68d9142e81a97","https://git.kernel.org/stable/c/90ad17575d26874287271127d43ef3c2af876cea","https://git.kernel.org/stable/c/b448de2459b6d62a53892487ab18b7d823ff0529","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52502
|
Medium |
fixed |
- 4.19.297
- 5.4.259
- 5.10.199
- 5.15.136
- 6.1.59
- 6.5.8
|
In the Linux kernel, the following vulnerability has been resolved:
net: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn()
Sili Luo reported a race in nfc_llcp_sock_get(), leading to UAF.
Getting a reference on the socket found in a lookup while
holding a lock should happen before releasing the lock.
nfc_llcp_sock_get_sn() has a similar problem.
Finally nfc_llcp_recv_snl() needs to make sure the socket
found by nfc_llcp_sock_from_sn() does not disappear. |
["https://git.kernel.org/stable/c/31c07dffafce914c1d1543c135382a11ff058d93","https://git.kernel.org/stable/c/6ac22ecdaad2ecc662048f8c6b0ceb1ca0699ef9","https://git.kernel.org/stable/c/7adcf014bda16cdbf804af5c164d94d5d025db2d","https://git.kernel.org/stable/c/d1af8a39cf839d93c8967fdd858f6bbdc3e4a15c","https://git.kernel.org/stable/c/d888d3f70b0de32b4f51534175f039ddab15eef8","https://git.kernel.org/stable/c/e4f2611f07c87b3ddb57c4b9e8efcd1e330fc3dc","https://git.kernel.org/stable/c/e863f5720a5680e50c4cecf12424d7cc31b3eb0a","https://git.kernel.org/stable/c/31c07dffafce914c1d1543c135382a11ff058d93","https://git.kernel.org/stable/c/6ac22ecdaad2ecc662048f8c6b0ceb1ca0699ef9","https://git.kernel.org/stable/c/7adcf014bda16cdbf804af5c164d94d5d025db2d","https://git.kernel.org/stable/c/d1af8a39cf839d93c8967fdd858f6bbdc3e4a15c","https://git.kernel.org/stable/c/d888d3f70b0de32b4f51534175f039ddab15eef8","https://git.kernel.org/stable/c/e4f2611f07c87b3ddb57c4b9e8efcd1e330fc3dc","https://git.kernel.org/stable/c/e863f5720a5680e50c4cecf12424d7cc31b3eb0a"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-39842
|
Medium |
fixed |
|
An issue was discovered in the Linux kernel before 5.19. In pxa3xx_gcu_write in drivers/video/fbdev/pxa3xx-gcu.c, the count parameter has a type conflict of size_t versus int, causing an integer overflow and bypassing the size check. After that, because it is used as the third argument to copy_from_user(), a heap overflow may occur. NOTE: the original discoverer disputes that the overflow can actually happen. |
["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19","https://github.com/torvalds/linux/commit/a09d2d00af53b43c6f11e6ab3cb58443c2cac8a7","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/all/YylaC1wHHyLw22D3%40kadam/T/","https://www.debian.org/security/2022/dsa-5257","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19","https://github.com/torvalds/linux/commit/a09d2d00af53b43c6f11e6ab3cb58443c2cac8a7","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/all/YylaC1wHHyLw22D3%40kadam/T/","https://www.debian.org/security/2022/dsa-5257"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26843
|
Medium |
fixed |
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
efi: runtime: Fix potential overflow of soft-reserved region size
md_size will have been narrowed if we have >= 4GB worth of pages in a
soft-reserved region. |
["https://git.kernel.org/stable/c/156cb12ffdcf33883304f0db645e1eadae712fe0","https://git.kernel.org/stable/c/4aa36b62c3eaa869860bf78b1146e9f2b5f782a9","https://git.kernel.org/stable/c/4fff3d735baea104017f2e3c245e27cdc79f2426","https://git.kernel.org/stable/c/700c3f642c32721f246e09d3a9511acf40ae42be","https://git.kernel.org/stable/c/cf3d6813601fe496de7f023435e31bfffa74ae70","https://git.kernel.org/stable/c/de1034b38a346ef6be25fe8792f5d1e0684d5ff4","https://git.kernel.org/stable/c/156cb12ffdcf33883304f0db645e1eadae712fe0","https://git.kernel.org/stable/c/4aa36b62c3eaa869860bf78b1146e9f2b5f782a9","https://git.kernel.org/stable/c/4fff3d735baea104017f2e3c245e27cdc79f2426","https://git.kernel.org/stable/c/700c3f642c32721f246e09d3a9511acf40ae42be","https://git.kernel.org/stable/c/cf3d6813601fe496de7f023435e31bfffa74ae70","https://git.kernel.org/stable/c/de1034b38a346ef6be25fe8792f5d1e0684d5ff4","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-2860
|
Medium |
|
N/A
|
An out-of-bounds read vulnerability was found in the SR-IPv6 implementation in the Linux kernel. The flaw exists within the processing of seg6 attributes. The issue results from the improper validation of user-supplied data, which can result in a read past the end of an allocated buffer. This flaw allows a privileged local user to disclose sensitive information on affected installations of the Linux kernel. |
["https://access.redhat.com/security/cve/CVE-2023-2860","https://bugzilla.redhat.com/show_bug.cgi?id=2218122","https://www.zerodayinitiative.com/advisories/ZDI-CAN-18511","https://access.redhat.com/security/cve/CVE-2023-2860","https://bugzilla.redhat.com/show_bug.cgi?id=2218122","https://www.zerodayinitiative.com/advisories/ZDI-CAN-18511"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52492
|
Medium |
fixed |
- 5.10.210
- 5.15.149
- 6.1.76
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: fix NULL pointer in channel unregistration function
__dma_async_device_channel_register() can fail. In case of failure,
chan->local is freed (with free_percpu()), and chan->local is nullified.
When dma_async_device_unregister() is called (because of managed API or
intentionally by DMA controller driver), channels are unconditionally
unregistered, leading to this NULL pointer:
[ 1.318693] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0
[...]
[ 1.484499] Call trace:
[ 1.486930] device_del+0x40/0x394
[ 1.490314] device_unregister+0x20/0x7c
[ 1.494220] __dma_async_device_channel_unregister+0x68/0xc0
Look at dma_async_device_register() function error path, channel device
unregistration is done only if chan->local is not NULL.
Then add the same condition at the beginning of
__dma_async_device_channel_unregister() function, to avoid NULL pointer
issue whatever the API used to reach this function. |
["https://git.kernel.org/stable/c/047fce470412ab64cb7345f9ff5d06919078ad79","https://git.kernel.org/stable/c/2ab32986a0b9e329eb7f8f04dd57cc127f797c08","https://git.kernel.org/stable/c/7f0ccfad2031eddcc510caf4e57f2d4aa2d8a50b","https://git.kernel.org/stable/c/9263fd2a63487c6d04cbb7b74a48fb12e1e352d0","https://git.kernel.org/stable/c/9de69732dde4e443c1c7f89acbbed2c45a6a8e17","https://git.kernel.org/stable/c/f5c24d94512f1b288262beda4d3dcb9629222fc7","https://git.kernel.org/stable/c/047fce470412ab64cb7345f9ff5d06919078ad79","https://git.kernel.org/stable/c/2ab32986a0b9e329eb7f8f04dd57cc127f797c08","https://git.kernel.org/stable/c/7f0ccfad2031eddcc510caf4e57f2d4aa2d8a50b","https://git.kernel.org/stable/c/9263fd2a63487c6d04cbb7b74a48fb12e1e352d0","https://git.kernel.org/stable/c/9de69732dde4e443c1c7f89acbbed2c45a6a8e17","https://git.kernel.org/stable/c/f5c24d94512f1b288262beda4d3dcb9629222fc7","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52574
|
Medium |
fixed |
- 4.14.327
- 4.19.296
- 5.4.258
- 5.10.198
- 5.15.134
- 6.1.56
- 6.5.6
|
In the Linux kernel, the following vulnerability has been resolved:
team: fix null-ptr-deref when team device type is changed
Get a null-ptr-deref bug as follows with reproducer [1].
BUG: kernel NULL pointer dereference, address: 0000000000000228
...
RIP: 0010:vlan_dev_hard_header+0x35/0x140 [8021q]
...
Call Trace:
<TASK>
? __die+0x24/0x70
? page_fault_oops+0x82/0x150
? exc_page_fault+0x69/0x150
? asm_exc_page_fault+0x26/0x30
? vlan_dev_hard_header+0x35/0x140 [8021q]
? vlan_dev_hard_header+0x8e/0x140 [8021q]
neigh_connected_output+0xb2/0x100
ip6_finish_output2+0x1cb/0x520
? nf_hook_slow+0x43/0xc0
? ip6_mtu+0x46/0x80
ip6_finish_output+0x2a/0xb0
mld_sendpack+0x18f/0x250
mld_ifc_work+0x39/0x160
process_one_work+0x1e6/0x3f0
worker_thread+0x4d/0x2f0
? __pfx_worker_thread+0x10/0x10
kthread+0xe5/0x120
? __pfx_kthread+0x10/0x10
ret_from_fork+0x34/0x50
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1b/0x30
[1]
$ teamd -t team0 -d -c '{"runner": {"name": "loadbalance"}}'
$ ip link add name t-dummy type dummy
$ ip link add link t-dummy name t-dummy.100 type vlan id 100
$ ip link add name t-nlmon type nlmon
$ ip link set t-nlmon master team0
$ ip link set t-nlmon nomaster
$ ip link set t-dummy up
$ ip link set team0 up
$ ip link set t-dummy.100 down
$ ip link set t-dummy.100 master team0
When enslave a vlan device to team device and team device type is changed
from non-ether to ether, header_ops of team device is changed to
vlan_header_ops. That is incorrect and will trigger null-ptr-deref
for vlan->real_dev in vlan_dev_hard_header() because team device is not
a vlan device.
Cache eth_header_ops in team_setup(), then assign cached header_ops to
header_ops of team net device when its type is changed from non-ether
to ether to fix the bug. |
["https://git.kernel.org/stable/c/1779eb51b9cc628cee551f252701a85a2a50a457","https://git.kernel.org/stable/c/2f0acb0736ecc3eb85dc80ad2790d634dcb10b58","https://git.kernel.org/stable/c/492032760127251e5540a5716a70996bacf2a3fd","https://git.kernel.org/stable/c/a7fb47b9711101d2405b0eb1276fb1f9b9b270c7","https://git.kernel.org/stable/c/b44dd92e2afd89eb6e9d27616858e72a67bdc1a7","https://git.kernel.org/stable/c/c5f6478686bb45f453031594ae19b6c9723a780d","https://git.kernel.org/stable/c/cac50d9f5d876be32cb9aa21c74018468900284d","https://git.kernel.org/stable/c/cd05eec2ee0cc396813a32ef675634e403748255","https://git.kernel.org/stable/c/1779eb51b9cc628cee551f252701a85a2a50a457","https://git.kernel.org/stable/c/2f0acb0736ecc3eb85dc80ad2790d634dcb10b58","https://git.kernel.org/stable/c/492032760127251e5540a5716a70996bacf2a3fd","https://git.kernel.org/stable/c/a7fb47b9711101d2405b0eb1276fb1f9b9b270c7","https://git.kernel.org/stable/c/b44dd92e2afd89eb6e9d27616858e72a67bdc1a7","https://git.kernel.org/stable/c/c5f6478686bb45f453031594ae19b6c9723a780d","https://git.kernel.org/stable/c/cac50d9f5d876be32cb9aa21c74018468900284d","https://git.kernel.org/stable/c/cd05eec2ee0cc396813a32ef675634e403748255"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52587
|
Medium |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.77
- 6.6.16
- 6.7.4
|
In the Linux kernel, the following vulnerability has been resolved:
IB/ipoib: Fix mcast list locking
Releasing the `priv->lock` while iterating the `priv->multicast_list` in
`ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` to
remove the items while in the middle of iteration. If the mcast is removed
while the lock was dropped, the for loop spins forever resulting in a hard
lockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel):
Task A (kworker/u72:2 below) | Task B (kworker/u72:0 below)
-----------------------------------+-----------------------------------
ipoib_mcast_join_task(work) | ipoib_ib_dev_flush_light(work)
spin_lock_irq(&priv->lock) | __ipoib_ib_dev_flush(priv, ...)
list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv->dev)
&priv->multicast_list, list) |
ipoib_mcast_join(dev, mcast) |
spin_unlock_irq(&priv->lock) |
| spin_lock_irqsave(&priv->lock, flags)
| list_for_each_entry_safe(mcast, tmcast,
| &priv->multicast_list, list)
| list_del(&mcast->list);
| list_add_tail(&mcast->list, &remove_list)
| spin_unlock_irqrestore(&priv->lock, flags)
spin_lock_irq(&priv->lock) |
| ipoib_mcast_remove_list(&remove_list)
(Here, `mcast` is no longer on the | list_for_each_entry_safe(mcast, tmcast,
`priv->multicast_list` and we keep | remove_list, list)
spinning on the `remove_list` of | >>> wait_for_completion(&mcast->done)
the other thread which is blocked |
and the list is still valid on |
it's stack.)
Fix this by keeping the lock held and changing to GFP_ATOMIC to prevent
eventual sleeps.
Unfortunately we could not reproduce the lockup and confirm this fix but
based on the code review I think this fix should address such lockups.
crash> bc 31
PID: 747 TASK: ff1c6a1a007e8000 CPU: 31 COMMAND: "kworker/u72:2"
--
[exception RIP: ipoib_mcast_join_task+0x1b1]
RIP: ffffffffc0944ac1 RSP: ff646f199a8c7e00 RFLAGS: 00000002
RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 0000000000000000
work (&priv->mcast_task{,.work})
RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000
&mcast->list
RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff1c6a1920c9a000
R10: ff646f199a8c7e00 R11: ff1c6a191a7d9800 R12: ff1c6a192d60ac00
mcast
R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15: ff1c6a1a04dc82d8
dev priv (&priv->lock) &priv->multicast_list (aka head)
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
--- <NMI exception stack> ---
#5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 at ffffffffc0944ac1 [ib_ipoib]
#6 [ff646f199a8c7e98] process_one_work+0x1a7 at ffffffff9bf10967
crash> rx ff646f199a8c7e68
ff646f199a8c7e68: ff1c6a1a04dc82f8 <<< work = &priv->mcast_task.work
crash> list -hO ipoib_dev_priv.multicast_list ff1c6a1a04dc8000
(empty)
crash> ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000
mcast_task.work.func = 0xffffffffc0944910 <ipoib_mcast_join_task>,
mcast_mutex.owner.counter = 0xff1c69998efec000
crash> b 8
PID: 8 TASK: ff1c69998efec000 CPU: 33 COMMAND: "kworker/u72:0"
--
#3 [ff646f1980153d50] wait_for_completion+0x96 at ffffffff9c7d7646
#4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 at ffffffffc0944dc6 [ib_ipoib]
#5 [ff646f1980153de8] ipoib_mcast_dev_flush+0x1a7 at ffffffffc09455a7 [ib_ipoib]
#6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 at ffffffffc09431a4 [ib_ipoib]
#7 [ff
---truncated--- |
["https://git.kernel.org/stable/c/342258fb46d66c1b4c7e2c3717ac01e10c03cf18","https://git.kernel.org/stable/c/4c8922ae8eb8dcc1e4b7d1059d97a8334288d825","https://git.kernel.org/stable/c/4f973e211b3b1c6d36f7c6a19239d258856749f9","https://git.kernel.org/stable/c/5108a2dc2db5630fb6cd58b8be80a0c134bc310a","https://git.kernel.org/stable/c/615e3adc2042b7be4ad122a043fc9135e6342c90","https://git.kernel.org/stable/c/7c7bd4d561e9dc6f5b7df9e184974915f6701a89","https://git.kernel.org/stable/c/ac2630fd3c90ffec34a0bfc4d413668538b0e8f2","https://git.kernel.org/stable/c/ed790bd0903ed3352ebf7f650d910f49b7319b34","https://git.kernel.org/stable/c/342258fb46d66c1b4c7e2c3717ac01e10c03cf18","https://git.kernel.org/stable/c/4c8922ae8eb8dcc1e4b7d1059d97a8334288d825","https://git.kernel.org/stable/c/4f973e211b3b1c6d36f7c6a19239d258856749f9","https://git.kernel.org/stable/c/5108a2dc2db5630fb6cd58b8be80a0c134bc310a","https://git.kernel.org/stable/c/615e3adc2042b7be4ad122a043fc9135e6342c90","https://git.kernel.org/stable/c/7c7bd4d561e9dc6f5b7df9e184974915f6701a89","https://git.kernel.org/stable/c/ac2630fd3c90ffec34a0bfc4d413668538b0e8f2","https://git.kernel.org/stable/c/ed790bd0903ed3352ebf7f650d910f49b7319b34","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-2985
|
Medium |
fixed |
|
A use after free flaw was found in hfsplus_put_super in fs/hfsplus/super.c in the Linux Kernel. This flaw could allow a local user to cause a denial of service problem. |
["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=07db5e247ab5858439b14dd7cc1fe538b9efcf32","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=07db5e247ab5858439b14dd7cc1fe538b9efcf32"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52615
|
Medium |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.76
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
hwrng: core - Fix page fault dead lock on mmap-ed hwrng
There is a dead-lock in the hwrng device read path. This triggers
when the user reads from /dev/hwrng into memory also mmap-ed from
/dev/hwrng. The resulting page fault triggers a recursive read
which then dead-locks.
Fix this by using a stack buffer when calling copy_to_user. |
["https://git.kernel.org/stable/c/26cc6d7006f922df6cc4389248032d955750b2a0","https://git.kernel.org/stable/c/5030d4c798863ccb266563201b341a099e8cdd48","https://git.kernel.org/stable/c/6822a14271786150e178869f1495cc03e74c5029","https://git.kernel.org/stable/c/78aafb3884f6bc6636efcc1760c891c8500b9922","https://git.kernel.org/stable/c/aa8aa16ed9adf1df05bb339d588cf485a011839e","https://git.kernel.org/stable/c/c6a8111aacbfe7a8a70f46cc0de8eed00561693c","https://git.kernel.org/stable/c/eafd83b92f6c044007a3591cbd476bcf90455990","https://git.kernel.org/stable/c/ecabe8cd456d3bf81e92c53b074732f3140f170d","https://git.kernel.org/stable/c/26cc6d7006f922df6cc4389248032d955750b2a0","https://git.kernel.org/stable/c/5030d4c798863ccb266563201b341a099e8cdd48","https://git.kernel.org/stable/c/6822a14271786150e178869f1495cc03e74c5029","https://git.kernel.org/stable/c/78aafb3884f6bc6636efcc1760c891c8500b9922","https://git.kernel.org/stable/c/aa8aa16ed9adf1df05bb339d588cf485a011839e","https://git.kernel.org/stable/c/c6a8111aacbfe7a8a70f46cc0de8eed00561693c","https://git.kernel.org/stable/c/eafd83b92f6c044007a3591cbd476bcf90455990","https://git.kernel.org/stable/c/ecabe8cd456d3bf81e92c53b074732f3140f170d","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52486
|
Medium |
fixed |
- 4.19.307
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.76
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
drm: Don't unref the same fb many times by mistake due to deadlock handling
If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()
we proceed to unref the fb and then retry the whole thing from the top.
But we forget to reset the fb pointer back to NULL, and so if we then
get another error during the retry, before the fb lookup, we proceed
the unref the same fb again without having gotten another reference.
The end result is that the fb will (eventually) end up being freed
while it's still in use.
Reset fb to NULL once we've unreffed it to avoid doing it again
until we've done another fb lookup.
This turned out to be pretty easy to hit on a DG2 when doing async
flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I
saw that drm_closefb() simply got stuck in a busy loop while walking
the framebuffer list. Fortunately I was able to convince it to oops
instead, and from there it was easier to track down the culprit. |
["https://git.kernel.org/stable/c/376e21a9e4c2c63ee5d8d3aa74be5082c3882229","https://git.kernel.org/stable/c/62f2e79cf9f4f47cc9dea9cebdf58d9f7b5695e0","https://git.kernel.org/stable/c/9dd334a8245011ace45e53298175c7b659edb3e7","https://git.kernel.org/stable/c/b4af63da9d94986c529d74499fdfe44289acd551","https://git.kernel.org/stable/c/bfd0feb1b109cb63b87fdcd00122603787c75a1a","https://git.kernel.org/stable/c/cb4daf271302d71a6b9a7c01bd0b6d76febd8f0c","https://git.kernel.org/stable/c/d7afdf360f4ac142832b098b4de974e867cc063c","https://git.kernel.org/stable/c/f55261469be87c55df13db76dc945f6bcd825105","https://git.kernel.org/stable/c/376e21a9e4c2c63ee5d8d3aa74be5082c3882229","https://git.kernel.org/stable/c/62f2e79cf9f4f47cc9dea9cebdf58d9f7b5695e0","https://git.kernel.org/stable/c/9dd334a8245011ace45e53298175c7b659edb3e7","https://git.kernel.org/stable/c/b4af63da9d94986c529d74499fdfe44289acd551","https://git.kernel.org/stable/c/bfd0feb1b109cb63b87fdcd00122603787c75a1a","https://git.kernel.org/stable/c/cb4daf271302d71a6b9a7c01bd0b6d76febd8f0c","https://git.kernel.org/stable/c/d7afdf360f4ac142832b098b4de974e867cc063c","https://git.kernel.org/stable/c/f55261469be87c55df13db76dc945f6bcd825105","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-4194
|
Medium |
|
N/A
|
A flaw was found in the Linux kernel's TUN/TAP functionality. This issue could allow a local user to bypass network filters and gain unauthorized access to some resources. The original patches fixing CVE-2023-1076 are incorrect or incomplete. The problem is that the following upstream commits - a096ccca6e50 ("tun: tun_chr_open(): correctly initialize socket uid"), - 66b2c338adce ("tap: tap_open(): correctly initialize socket uid"), pass "inode->i_uid" to sock_init_data_uid() as the last parameter and that turns out to not be accurate. |
["https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/security/cve/CVE-2023-4194","https://bugzilla.redhat.com/show_bug.cgi?id=2229498","https://lore.kernel.org/all/20230731164237.48365-1-lersek@redhat.com/","https://lore.kernel.org/all/20230731164237.48365-2-lersek@redhat.com/","https://lore.kernel.org/all/20230731164237.48365-3-lersek@redhat.com/","https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/security/cve/CVE-2023-4194","https://bugzilla.redhat.com/show_bug.cgi?id=2229498","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/344H6HO6SSC4KT7PDFXSDIXKMKHISSGF/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/3TYLSJ2SAI7RF56ZLQ5CQWCJLVJSD73Q/","https://lore.kernel.org/all/20230731164237.48365-1-lersek@redhat.com/","https://lore.kernel.org/all/20230731164237.48365-2-lersek@redhat.com/","https://lore.kernel.org/all/20230731164237.48365-3-lersek@redhat.com/","https://security.netapp.com/advisory/ntap-20231027-0002/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26790
|
Medium |
fixed |
- 5.4.271
- 5.10.212
- 5.15.151
- 6.1.81
- 6.6.21
- 6.7.9
|
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read
There is chip (ls1028a) errata:
The SoC may hang on 16 byte unaligned read transactions by QDMA.
Unaligned read transactions initiated by QDMA may stall in the NOC
(Network On-Chip), causing a deadlock condition. Stalled transactions will
trigger completion timeouts in PCIe controller.
Workaround:
Enable prefetch by setting the source descriptor prefetchable bit
( SD[PF] = 1 ).
Implement this workaround. |
["https://git.kernel.org/stable/c/106c1ac953a66556ec77456c46e818208d3a9bce","https://git.kernel.org/stable/c/237ecf1afe6c22534fa43abdf2bf0b0f52de0aaa","https://git.kernel.org/stable/c/518d78b4fac68cac29a263554d7f3b19da99d0da","https://git.kernel.org/stable/c/5b696e9c388251f1c7373be92293769a489fd367","https://git.kernel.org/stable/c/9d739bccf261dd93ec1babf82f5c5d71dd4caa3e","https://git.kernel.org/stable/c/ad2f8920c314e0a2d9e984fc94b729eca3cda471","https://git.kernel.org/stable/c/bb3a06e9b9a30e33d96aadc0e077be095a4f8580","https://git.kernel.org/stable/c/106c1ac953a66556ec77456c46e818208d3a9bce","https://git.kernel.org/stable/c/237ecf1afe6c22534fa43abdf2bf0b0f52de0aaa","https://git.kernel.org/stable/c/518d78b4fac68cac29a263554d7f3b19da99d0da","https://git.kernel.org/stable/c/5b696e9c388251f1c7373be92293769a489fd367","https://git.kernel.org/stable/c/9d739bccf261dd93ec1babf82f5c5d71dd4caa3e","https://git.kernel.org/stable/c/ad2f8920c314e0a2d9e984fc94b729eca3cda471","https://git.kernel.org/stable/c/bb3a06e9b9a30e33d96aadc0e077be095a4f8580","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52493
|
Medium |
fixed |
- 5.10.210
- 5.15.149
- 6.1.76
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
bus: mhi: host: Drop chan lock before queuing buffers
Ensure read and write locks for the channel are not taken in succession by
dropping the read lock from parse_xfer_event() such that a callback given
to client can potentially queue buffers and acquire the write lock in that
process. Any queueing of buffers should be done without channel read lock
acquired as it can result in multiple locks and a soft lockup.
[mani: added fixes tag and cc'ed stable] |
["https://git.kernel.org/stable/c/01bd694ac2f682fb8017e16148b928482bc8fa4b","https://git.kernel.org/stable/c/20a6dea2d1c68d4e03c6bb50bc12e72e226b5c0e","https://git.kernel.org/stable/c/3c5ec66b4b3f6816f3a6161538672e389e537690","https://git.kernel.org/stable/c/6e4c84316e2b70709f0d00c33ba3358d9fc8eece","https://git.kernel.org/stable/c/b8eff20d87092e14cac976d057cb0aea2f1d0830","https://git.kernel.org/stable/c/eaefb9464031215d63c0a8a7e2bfaa00736aa17e","https://git.kernel.org/stable/c/01bd694ac2f682fb8017e16148b928482bc8fa4b","https://git.kernel.org/stable/c/20a6dea2d1c68d4e03c6bb50bc12e72e226b5c0e","https://git.kernel.org/stable/c/3c5ec66b4b3f6816f3a6161538672e389e537690","https://git.kernel.org/stable/c/6e4c84316e2b70709f0d00c33ba3358d9fc8eece","https://git.kernel.org/stable/c/b8eff20d87092e14cac976d057cb0aea2f1d0830","https://git.kernel.org/stable/c/eaefb9464031215d63c0a8a7e2bfaa00736aa17e","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26614
|
Medium |
fixed |
- 5.10.210
- 5.15.149
- 6.1.76
- 6.6.15
- 6.7.3
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: make sure init the accept_queue's spinlocks once
When I run syz's reproduction C program locally, it causes the following
issue:
pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0!
WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7
30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908
RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900
RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff
R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000
R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000
FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0
Call Trace:
<IRQ>
_raw_spin_unlock (kernel/locking/spinlock.c:186)
inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321)
inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358)
tcp_check_req (net/ipv4/tcp_minisocks.c:868)
tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260)
ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205)
ip_local_deliver_finish (net/ipv4/ip_input.c:234)
__netif_receive_skb_one_core (net/core/dev.c:5529)
process_backlog (./include/linux/rcupdate.h:779)
__napi_poll (net/core/dev.c:6533)
net_rx_action (net/core/dev.c:6604)
__do_softirq (./arch/x86/include/asm/jump_label.h:27)
do_softirq (kernel/softirq.c:454 kernel/softirq.c:441)
</IRQ>
<TASK>
__local_bh_enable_ip (kernel/softirq.c:381)
__dev_queue_xmit (net/core/dev.c:4374)
ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235)
__ip_queue_xmit (net/ipv4/ip_output.c:535)
__tcp_transmit_skb (net/ipv4/tcp_output.c:1462)
tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469)
tcp_rcv_state_process (net/ipv4/tcp_input.c:6657)
tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929)
__release_sock (./include/net/sock.h:1121 net/core/sock.c:2968)
release_sock (net/core/sock.c:3536)
inet_wait_for_connect (net/ipv4/af_inet.c:609)
__inet_stream_connect (net/ipv4/af_inet.c:702)
inet_stream_connect (net/ipv4/af_inet.c:748)
__sys_connect (./include/linux/file.h:45 net/socket.c:2064)
__x64_sys_connect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070)
do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
RIP: 0033:0x7fa10ff05a3d
Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89
c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89 01 48
RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d
RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003
RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640
R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20
</TASK>
The issue triggering process is analyzed as follows:
Thread A Thread B
tcp_v4_rcv //receive ack TCP packet inet_shutdown
tcp_check_req tcp_disconnect //disconnect sock
... tcp_set_state(sk, TCP_CLOSE)
inet_csk_complete_hashdance ...
inet_csk_reqsk_queue_add
---truncated--- |
["https://git.kernel.org/stable/c/168e7e599860654876c2a1102a82610285c02f02","https://git.kernel.org/stable/c/198bc90e0e734e5f98c3d2833e8390cac3df61b2","https://git.kernel.org/stable/c/3982fe726a63fb3de6005e534e2ac8ca7e0aca2a","https://git.kernel.org/stable/c/b1e0a68a0cd2a83259c444f638b417a8fffc6855","https://git.kernel.org/stable/c/bc99dcedd2f422d602516762b96c8ef1ae6b2882","https://git.kernel.org/stable/c/d86cc6ab33b085eaef27ea88b78fc8e2375c0ef3","https://git.kernel.org/stable/c/168e7e599860654876c2a1102a82610285c02f02","https://git.kernel.org/stable/c/198bc90e0e734e5f98c3d2833e8390cac3df61b2","https://git.kernel.org/stable/c/3982fe726a63fb3de6005e534e2ac8ca7e0aca2a","https://git.kernel.org/stable/c/b1e0a68a0cd2a83259c444f638b417a8fffc6855","https://git.kernel.org/stable/c/bc99dcedd2f422d602516762b96c8ef1ae6b2882","https://git.kernel.org/stable/c/d86cc6ab33b085eaef27ea88b78fc8e2375c0ef3","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-38409
|
Medium |
fixed |
|
An issue was discovered in set_con2fb_map in drivers/video/fbdev/core/fbcon.c in the Linux kernel before 6.2.12. Because an assignment occurs only for the first vc, the fbcon_registered_fb and fbcon_display arrays can be desynchronized in fbcon_mode_deleted (the con2fb_map points at the old fb_info). |
["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.12","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=fffb0b52d5258554c645c966c6cbef7de50b851d","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.12","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=fffb0b52d5258554c645c966c6cbef7de50b851d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26726
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't drop extent_map for free space inode on write error
While running the CI for an unrelated change I hit the following panic
with generic/648 on btrfs_holes_spacecache.
assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385
------------[ cut here ]------------
kernel BUG at fs/btrfs/extent_io.c:1385!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1
RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0
Call Trace:
<TASK>
extent_write_cache_pages+0x2ac/0x8f0
extent_writepages+0x87/0x110
do_writepages+0xd5/0x1f0
filemap_fdatawrite_wbc+0x63/0x90
__filemap_fdatawrite_range+0x5c/0x80
btrfs_fdatawrite_range+0x1f/0x50
btrfs_write_out_cache+0x507/0x560
btrfs_write_dirty_block_groups+0x32a/0x420
commit_cowonly_roots+0x21b/0x290
btrfs_commit_transaction+0x813/0x1360
btrfs_sync_file+0x51a/0x640
__x64_sys_fdatasync+0x52/0x90
do_syscall_64+0x9c/0x190
entry_SYSCALL_64_after_hwframe+0x6e/0x76
This happens because we fail to write out the free space cache in one
instance, come back around and attempt to write it again. However on
the second pass through we go to call btrfs_get_extent() on the inode to
get the extent mapping. Because this is a new block group, and with the
free space inode we always search the commit root to avoid deadlocking
with the tree, we find nothing and return a EXTENT_MAP_HOLE for the
requested range.
This happens because the first time we try to write the space cache out
we hit an error, and on an error we drop the extent mapping. This is
normal for normal files, but the free space cache inode is special. We
always expect the extent map to be correct. Thus the second time
through we end up with a bogus extent map.
Since we're deprecating this feature, the most straightforward way to
fix this is to simply skip dropping the extent map range for this failed
range.
I shortened the test by using error injection to stress the area to make
it easier to reproduce. With this patch in place we no longer panic
with my error injection test. |
["https://git.kernel.org/stable/c/02f2b95b00bf57d20320ee168b30fb7f3db8e555","https://git.kernel.org/stable/c/5571e41ec6e56e35f34ae9f5b3a335ef510e0ade","https://git.kernel.org/stable/c/7bddf18f474f166c19f91b2baf67bf7c5eda03f7","https://git.kernel.org/stable/c/a4b7741c8302e28073bfc6dd1c2e73598e5e535e","https://git.kernel.org/stable/c/02f2b95b00bf57d20320ee168b30fb7f3db8e555","https://git.kernel.org/stable/c/5571e41ec6e56e35f34ae9f5b3a335ef510e0ade","https://git.kernel.org/stable/c/7bddf18f474f166c19f91b2baf67bf7c5eda03f7","https://git.kernel.org/stable/c/a4b7741c8302e28073bfc6dd1c2e73598e5e535e"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-6560
|
Medium |
|
N/A
|
An out-of-bounds memory access flaw was found in the io_uring SQ/CQ rings functionality in the Linux kernel. This issue could allow a local user to crash the system. |
["http://packetstormsecurity.com/files/176405/io_uring-__io_uaddr_map-Dangerous-Multi-Page-Handling.html","https://access.redhat.com/security/cve/CVE-2023-6560","https://bugzilla.redhat.com/show_bug.cgi?id=2253249","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/AU4NHBDEDLRW33O76Y6LFECEYNQET5GZ/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UCQIPFUQXKXRCH5Y4RP3C5NK4IHNBNVK/","https://patchwork.kernel.org/project/io-uring/patch/20231130194633.649319-2-axboe@kernel.dk/","http://packetstormsecurity.com/files/176405/io_uring-__io_uaddr_map-Dangerous-Multi-Page-Handling.html","https://access.redhat.com/security/cve/CVE-2023-6560","https://bugzilla.redhat.com/show_bug.cgi?id=2253249","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/AU4NHBDEDLRW33O76Y6LFECEYNQET5GZ/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UCQIPFUQXKXRCH5Y4RP3C5NK4IHNBNVK/","https://patchwork.kernel.org/project/io-uring/patch/20231130194633.649319-2-axboe@kernel.dk/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26764
|
Low |
fixed |
- 4.19.308
- 5.4.270
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio
If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the
following kernel warning appears:
WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8
Call trace:
kiocb_set_cancel_fn+0x9c/0xa8
ffs_epfile_read_iter+0x144/0x1d0
io_read+0x19c/0x498
io_issue_sqe+0x118/0x27c
io_submit_sqes+0x25c/0x5fc
__arm64_sys_io_uring_enter+0x104/0xab0
invoke_syscall+0x58/0x11c
el0_svc_common+0xb4/0xf4
do_el0_svc+0x2c/0xb0
el0_svc+0x2c/0xa4
el0t_64_sync_handler+0x68/0xb4
el0t_64_sync+0x1a4/0x1a8
Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is
submitted by libaio. |
["https://git.kernel.org/stable/c/18f614369def2a11a52f569fe0f910b199d13487","https://git.kernel.org/stable/c/1dc7d74fe456944a9b1c57bd776280249f441ac6","https://git.kernel.org/stable/c/337b543e274fe7a8f47df3c8293cc6686ffa620f","https://git.kernel.org/stable/c/b4eea7a05ee0ab5ab0514421e6ba8c5d249cf942","https://git.kernel.org/stable/c/b820de741ae48ccf50dd95e297889c286ff4f760","https://git.kernel.org/stable/c/d7b6fa97ec894edd02f64b83e5e72e1aa352f353","https://git.kernel.org/stable/c/e7e23fc5d5fe422827c9a43ecb579448f73876c7","https://git.kernel.org/stable/c/ea1cd64d59f22d6d13f367d62ec6e27b9344695f","https://git.kernel.org/stable/c/18f614369def2a11a52f569fe0f910b199d13487","https://git.kernel.org/stable/c/1dc7d74fe456944a9b1c57bd776280249f441ac6","https://git.kernel.org/stable/c/337b543e274fe7a8f47df3c8293cc6686ffa620f","https://git.kernel.org/stable/c/b4eea7a05ee0ab5ab0514421e6ba8c5d249cf942","https://git.kernel.org/stable/c/b820de741ae48ccf50dd95e297889c286ff4f760","https://git.kernel.org/stable/c/d7b6fa97ec894edd02f64b83e5e72e1aa352f353","https://git.kernel.org/stable/c/e7e23fc5d5fe422827c9a43ecb579448f73876c7","https://git.kernel.org/stable/c/ea1cd64d59f22d6d13f367d62ec6e27b9344695f","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52621
|
High |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
bpf: Check rcu_read_lock_trace_held() before calling bpf map helpers
These three bpf_map_{lookup,update,delete}_elem() helpers are also
available for sleepable bpf program, so add the corresponding lock
assertion for sleepable bpf program, otherwise the following warning
will be reported when a sleepable bpf program manipulates bpf map under
interpreter mode (aka bpf_jit_enable=0):
WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ......
CPU: 3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......
RIP: 0010:bpf_map_lookup_elem+0x54/0x60
......
Call Trace:
<TASK>
? __warn+0xa5/0x240
? bpf_map_lookup_elem+0x54/0x60
? report_bug+0x1ba/0x1f0
? handle_bug+0x40/0x80
? exc_invalid_op+0x18/0x50
? asm_exc_invalid_op+0x1b/0x20
? __pfx_bpf_map_lookup_elem+0x10/0x10
? rcu_lockdep_current_cpu_online+0x65/0xb0
? rcu_is_watching+0x23/0x50
? bpf_map_lookup_elem+0x54/0x60
? __pfx_bpf_map_lookup_elem+0x10/0x10
___bpf_prog_run+0x513/0x3b70
__bpf_prog_run32+0x9d/0xd0
? __bpf_prog_enter_sleepable_recur+0xad/0x120
? __bpf_prog_enter_sleepable_recur+0x3e/0x120
bpf_trampoline_6442580665+0x4d/0x1000
__x64_sys_getpgid+0x5/0x30
? do_syscall_64+0x36/0xb0
entry_SYSCALL_64_after_hwframe+0x6e/0x76
</TASK> |
["https://git.kernel.org/stable/c/169410eba271afc9f0fb476d996795aa26770c6d","https://git.kernel.org/stable/c/3516f93cc63d956e1b290ae4b7bf2586074535a0","https://git.kernel.org/stable/c/483cb92334cd7f1d5387dccc0ab5d595d27a669d","https://git.kernel.org/stable/c/82f2df94dac1aa9b879e74d1f82ba1b631bdc612","https://git.kernel.org/stable/c/c7f1b6146f4a46d727c0d046284c28b6882c6304","https://git.kernel.org/stable/c/d6d6fe4bb105595118f12abeed4a7bdd450853f3","https://git.kernel.org/stable/c/169410eba271afc9f0fb476d996795aa26770c6d","https://git.kernel.org/stable/c/483cb92334cd7f1d5387dccc0ab5d595d27a669d","https://git.kernel.org/stable/c/c7f1b6146f4a46d727c0d046284c28b6882c6304","https://git.kernel.org/stable/c/d6d6fe4bb105595118f12abeed4a7bdd450853f3"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-3439
|
Medium |
fixed |
|
A flaw was found in the MCTP protocol in the Linux kernel. The function mctp_unregister() reclaims the device's relevant resource when a netcard detaches. However, a running routine may be unaware of this and cause the use-after-free of the mdev->addrs object, potentially leading to a denial of service. |
["http://www.openwall.com/lists/oss-security/2023/07/02/1","https://bugzilla.redhat.com/show_bug.cgi?id=2217915","https://github.com/torvalds/linux/commit/b561275d633bcd8e0e8055ab86f1a13df75a0269","http://www.openwall.com/lists/oss-security/2023/07/02/1","https://bugzilla.redhat.com/show_bug.cgi?id=2217915","https://github.com/torvalds/linux/commit/b561275d633bcd8e0e8055ab86f1a13df75a0269"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26878
|
Medium |
fixed |
- 4.19.311
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
quota: Fix potential NULL pointer dereference
Below race may cause NULL pointer dereference
P1 P2
dquot_free_inode quota_off
drop_dquot_ref
remove_dquot_ref
dquots = i_dquot(inode)
dquots = i_dquot(inode)
srcu_read_lock
dquots[cnt]) != NULL (1)
dquots[type] = NULL (2)
spin_lock(&dquots[cnt]->dq_dqb_lock) (3)
....
If dquot_free_inode(or other routines) checks inode's quota pointers (1)
before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer
dereference will be triggered.
So let's fix it by using a temporary pointer to avoid this issue. |
["https://git.kernel.org/stable/c/1ca72a3de915f87232c9a4cb9bebbd3af8ed3e25","https://git.kernel.org/stable/c/40a673b4b07efd6f74ff3ab60f38b26aa91ee5d5","https://git.kernel.org/stable/c/49669f8e7eb053f91d239df7b1bfb4500255a9d0","https://git.kernel.org/stable/c/61380537aa6dd32d8a723d98b8f1bd1b11d8fee0","https://git.kernel.org/stable/c/6afc9f4434fa8063aa768c2bf5bf98583aee0877","https://git.kernel.org/stable/c/7f9e833fc0f9b47be503af012eb5903086939754","https://git.kernel.org/stable/c/8514899c1a4edf802f03c408db901063aa3f05a1","https://git.kernel.org/stable/c/d0aa72604fbd80c8aabb46eda00535ed35570f1f","https://git.kernel.org/stable/c/f2649d98aa9ca8623149b3cb8df00c944f5655c7","https://git.kernel.org/stable/c/1ca72a3de915f87232c9a4cb9bebbd3af8ed3e25","https://git.kernel.org/stable/c/40a673b4b07efd6f74ff3ab60f38b26aa91ee5d5","https://git.kernel.org/stable/c/49669f8e7eb053f91d239df7b1bfb4500255a9d0","https://git.kernel.org/stable/c/61380537aa6dd32d8a723d98b8f1bd1b11d8fee0","https://git.kernel.org/stable/c/6afc9f4434fa8063aa768c2bf5bf98583aee0877","https://git.kernel.org/stable/c/7f9e833fc0f9b47be503af012eb5903086939754","https://git.kernel.org/stable/c/8514899c1a4edf802f03c408db901063aa3f05a1","https://git.kernel.org/stable/c/d0aa72604fbd80c8aabb46eda00535ed35570f1f","https://git.kernel.org/stable/c/f2649d98aa9ca8623149b3cb8df00c944f5655c7","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26698
|
Medium |
fixed |
- 5.10.210
- 5.15.149
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove
In commit ac5047671758 ("hv_netvsc: Disable NAPI before closing the
VMBus channel"), napi_disable was getting called for all channels,
including all subchannels without confirming if they are enabled or not.
This caused hv_netvsc getting hung at napi_disable, when netvsc_probe()
has finished running but nvdev->subchan_work has not started yet.
netvsc_subchan_work() -> rndis_set_subchannel() has not created the
sub-channels and because of that netvsc_sc_open() is not running.
netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for which
netvsc_subchan_work did not run.
netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI
cannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear the
NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the
opposite.
Now during netvsc_device_remove(), when napi_disable is called for those
subchannels, napi_disable gets stuck on infinite msleep.
This fix addresses this problem by ensuring that napi_disable() is not
getting called for non-enabled NAPI struct.
But netif_napi_del() is still necessary for these non-enabled NAPI struct
for cleanup purpose.
Call trace:
[ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002
[ 654.568030] Call Trace:
[ 654.571221] <TASK>
[ 654.573790] __schedule+0x2d6/0x960
[ 654.577733] schedule+0x69/0xf0
[ 654.581214] schedule_timeout+0x87/0x140
[ 654.585463] ? __bpf_trace_tick_stop+0x20/0x20
[ 654.590291] msleep+0x2d/0x40
[ 654.593625] napi_disable+0x2b/0x80
[ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc]
[ 654.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc]
[ 654.611101] ? do_wait_intr+0xb0/0xb0
[ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc]
[ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus] |
["https://git.kernel.org/stable/c/0e8875de9dad12805ff66e92cd5edea6a421f1cd","https://git.kernel.org/stable/c/22a77c0f5b8233237731df3288d067af51a2fd7b","https://git.kernel.org/stable/c/48a8ccccffbae10c91d31fc872db5c31aba07518","https://git.kernel.org/stable/c/7656372ae190e54e8c8cf1039725a5ea59fdf84a","https://git.kernel.org/stable/c/9ec807e7b6f5fcf9499f3baa69f254bb239a847f","https://git.kernel.org/stable/c/e0526ec5360a48ad3ab2e26e802b0532302a7e11","https://git.kernel.org/stable/c/0e8875de9dad12805ff66e92cd5edea6a421f1cd","https://git.kernel.org/stable/c/22a77c0f5b8233237731df3288d067af51a2fd7b","https://git.kernel.org/stable/c/48a8ccccffbae10c91d31fc872db5c31aba07518","https://git.kernel.org/stable/c/7656372ae190e54e8c8cf1039725a5ea59fdf84a","https://git.kernel.org/stable/c/9ec807e7b6f5fcf9499f3baa69f254bb239a847f","https://git.kernel.org/stable/c/e0526ec5360a48ad3ab2e26e802b0532302a7e11","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52644
|
Medium |
fixed |
- 4.19.311
- 5.4.273
- 5.10.214
- 5.15.153
- 6.1.83
- 6.6.23
- 6.7.11
- 6.8.2
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled
When QoS is disabled, the queue priority value will not map to the correct
ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS
is disabled to prevent trying to stop/wake a non-existent queue and failing
to stop/wake the actual queue instantiated.
Log of issue before change (with kernel parameter qos=0):
[ +5.112651] ------------[ cut here ]------------
[ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211]
[ +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3
[ +0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common
[ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)]
[ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS
[ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019
[ +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211]
[ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00
[ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097
[ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000
[ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900
[ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0
[ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000
[ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40
[ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000
[ +0.000001] CS: 0010 DS: 0
---truncated--- |
["https://git.kernel.org/stable/c/04a2b6eff2ae1c19cb7f41e803bcbfaf94c06455","https://git.kernel.org/stable/c/1824f942527f784a19e01eac2d9679a21623d010","https://git.kernel.org/stable/c/31aaf17200c336fe258b70d39c40645ae19d0240","https://git.kernel.org/stable/c/4049a9f80513a6739c5677736a4c88f96df1b436","https://git.kernel.org/stable/c/49f067726ab01c87cf57566797a8a719badbbf08","https://git.kernel.org/stable/c/9636951e4468f02c72cc75a82dc65d003077edbc","https://git.kernel.org/stable/c/bc845e2e42cae95172c04bf29807c480f51a2a83","https://git.kernel.org/stable/c/c67698325c68f8768db858f5c87c34823421746d","https://git.kernel.org/stable/c/f1cf77bb870046a6111a604f7f7fe83d1c8c9610","https://git.kernel.org/stable/c/04a2b6eff2ae1c19cb7f41e803bcbfaf94c06455","https://git.kernel.org/stable/c/1824f942527f784a19e01eac2d9679a21623d010","https://git.kernel.org/stable/c/31aaf17200c336fe258b70d39c40645ae19d0240","https://git.kernel.org/stable/c/4049a9f80513a6739c5677736a4c88f96df1b436","https://git.kernel.org/stable/c/49f067726ab01c87cf57566797a8a719badbbf08","https://git.kernel.org/stable/c/9636951e4468f02c72cc75a82dc65d003077edbc","https://git.kernel.org/stable/c/bc845e2e42cae95172c04bf29807c480f51a2a83","https://git.kernel.org/stable/c/c67698325c68f8768db858f5c87c34823421746d","https://git.kernel.org/stable/c/f1cf77bb870046a6111a604f7f7fe83d1c8c9610","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26712
|
Medium |
fixed |
- 5.10.210
- 5.15.149
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
powerpc/kasan: Fix addr error caused by page alignment
In kasan_init_region, when k_start is not page aligned, at the begin of
for loop, k_cur = k_start & PAGE_MASK is less than k_start, and then
`va = block + k_cur - k_start` is less than block, the addr va is invalid,
because the memory address space from va to block is not alloced by
memblock_alloc, which will not be reserved by memblock_reserve later, it
will be used by other places.
As a result, memory overwriting occurs.
for example:
int __init __weak kasan_init_region(void *start, size_t size)
{
[...]
/* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */
block = memblock_alloc(k_end - k_start, PAGE_SIZE);
[...]
for (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) {
/* at the begin of for loop
* block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400)
* va(dcd96c00) is less than block(dcd97000), va is invalid
*/
void *va = block + k_cur - k_start;
[...]
}
[...]
}
Therefore, page alignment is performed on k_start before
memblock_alloc() to ensure the validity of the VA address. |
["https://git.kernel.org/stable/c/0516c06b19dc64807c10e01bb99b552bdf2d7dbe","https://git.kernel.org/stable/c/0c09912dd8387e228afcc5e34ac5d79b1e3a1058","https://git.kernel.org/stable/c/230e89b5ad0a33f530a2a976b3e5e4385cb27882","https://git.kernel.org/stable/c/2738e0aa2fb24a7ab9c878d912dc2b239738c6c6","https://git.kernel.org/stable/c/4a7aee96200ad281a5cc4cf5c7a2e2a49d2b97b0","https://git.kernel.org/stable/c/70ef2ba1f4286b2b73675aeb424b590c92d57b25","https://git.kernel.org/stable/c/0516c06b19dc64807c10e01bb99b552bdf2d7dbe","https://git.kernel.org/stable/c/0c09912dd8387e228afcc5e34ac5d79b1e3a1058","https://git.kernel.org/stable/c/230e89b5ad0a33f530a2a976b3e5e4385cb27882","https://git.kernel.org/stable/c/2738e0aa2fb24a7ab9c878d912dc2b239738c6c6","https://git.kernel.org/stable/c/4a7aee96200ad281a5cc4cf5c7a2e2a49d2b97b0","https://git.kernel.org/stable/c/70ef2ba1f4286b2b73675aeb424b590c92d57b25","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26846
|
Medium |
fixed |
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
nvme-fc: do not wait in vain when unloading module
The module exit path has race between deleting all controllers and
freeing 'left over IDs'. To prevent double free a synchronization
between nvme_delete_ctrl and ida_destroy has been added by the initial
commit.
There is some logic around trying to prevent from hanging forever in
wait_for_completion, though it does not handling all cases. E.g.
blktests is able to reproduce the situation where the module unload
hangs forever.
If we completely rely on the cleanup code executed from the
nvme_delete_ctrl path, all IDs will be freed eventually. This makes
calling ida_destroy unnecessary. We only have to ensure that all
nvme_delete_ctrl code has been executed before we leave
nvme_fc_exit_module. This is done by flushing the nvme_delete_wq
workqueue.
While at it, remove the unused nvme_fc_wq workqueue too. |
["https://git.kernel.org/stable/c/085195aa90a924c79e35569bcdad860d764a8e17","https://git.kernel.org/stable/c/0bf567d6d9ffe09e059bbdfb4d07143cef42c75c","https://git.kernel.org/stable/c/4f2c95015ec2a1899161be6c0bdaecedd5a7bfb2","https://git.kernel.org/stable/c/70fbfc47a392b98e5f8dba70c6efc6839205c982","https://git.kernel.org/stable/c/baa6b7eb8c66486bd64608adc63fe03b30d3c0b9","https://git.kernel.org/stable/c/c0882c366418bf9c19e1ba7f270fe377a9bf5d67","https://git.kernel.org/stable/c/085195aa90a924c79e35569bcdad860d764a8e17","https://git.kernel.org/stable/c/0bf567d6d9ffe09e059bbdfb4d07143cef42c75c","https://git.kernel.org/stable/c/4f2c95015ec2a1899161be6c0bdaecedd5a7bfb2","https://git.kernel.org/stable/c/70fbfc47a392b98e5f8dba70c6efc6839205c982","https://git.kernel.org/stable/c/baa6b7eb8c66486bd64608adc63fe03b30d3c0b9","https://git.kernel.org/stable/c/c0882c366418bf9c19e1ba7f270fe377a9bf5d67","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-33951
|
Medium |
|
N/A
|
A race condition vulnerability was found in the vmwgfx driver in the Linux kernel. The flaw exists within the handling of GEM objects. The issue results from improper locking when performing operations on an object. This flaw allows a local privileged user to disclose information in the context of the kernel. |
["https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/errata/RHSA-2023:6901","https://access.redhat.com/errata/RHSA-2023:7077","https://access.redhat.com/errata/RHSA-2024:1404","https://access.redhat.com/errata/RHSA-2024:4823","https://access.redhat.com/errata/RHSA-2024:4831","https://access.redhat.com/security/cve/CVE-2023-33951","https://bugzilla.redhat.com/show_bug.cgi?id=2218195","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20110/","https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/errata/RHSA-2023:6901","https://access.redhat.com/errata/RHSA-2023:7077","https://access.redhat.com/errata/RHSA-2024:1404","https://access.redhat.com/errata/RHSA-2024:4823","https://access.redhat.com/errata/RHSA-2024:4831","https://access.redhat.com/security/cve/CVE-2023-33951","https://bugzilla.redhat.com/show_bug.cgi?id=2218195","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20110/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26727
|
Medium |
fixed |
- 5.10.210
- 5.15.149
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not ASSERT() if the newly created subvolume already got read
[BUG]
There is a syzbot crash, triggered by the ASSERT() during subvolume
creation:
assertion failed: !anon_dev, in fs/btrfs/disk-io.c:1319
------------[ cut here ]------------
kernel BUG at fs/btrfs/disk-io.c:1319!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
RIP: 0010:btrfs_get_root_ref.part.0+0x9aa/0xa60
<TASK>
btrfs_get_new_fs_root+0xd3/0xf0
create_subvol+0xd02/0x1650
btrfs_mksubvol+0xe95/0x12b0
__btrfs_ioctl_snap_create+0x2f9/0x4f0
btrfs_ioctl_snap_create+0x16b/0x200
btrfs_ioctl+0x35f0/0x5cf0
__x64_sys_ioctl+0x19d/0x210
do_syscall_64+0x3f/0xe0
entry_SYSCALL_64_after_hwframe+0x63/0x6b
---[ end trace 0000000000000000 ]---
[CAUSE]
During create_subvol(), after inserting root item for the newly created
subvolume, we would trigger btrfs_get_new_fs_root() to get the
btrfs_root of that subvolume.
The idea here is, we have preallocated an anonymous device number for
the subvolume, thus we can assign it to the new subvolume.
But there is really nothing preventing things like backref walk to read
the new subvolume.
If that happens before we call btrfs_get_new_fs_root(), the subvolume
would be read out, with a new anonymous device number assigned already.
In that case, we would trigger ASSERT(), as we really expect no one to
read out that subvolume (which is not yet accessible from the fs).
But things like backref walk is still possible to trigger the read on
the subvolume.
Thus our assumption on the ASSERT() is not correct in the first place.
[FIX]
Fix it by removing the ASSERT(), and just free the @anon_dev, reset it
to 0, and continue.
If the subvolume tree is read out by something else, it should have
already get a new anon_dev assigned thus we only need to free the
preallocated one. |
["https://git.kernel.org/stable/c/3f5d47eb163bceb1b9e613c9003bae5fefc0046f","https://git.kernel.org/stable/c/5a172344bfdabb46458e03708735d7b1a918c468","https://git.kernel.org/stable/c/66b317a2fc45b2ef66527ee3f8fa08fb5beab88d","https://git.kernel.org/stable/c/833775656d447c545133a744a0ed1e189ce61430","https://git.kernel.org/stable/c/e03ee2fe873eb68c1f9ba5112fee70303ebf9dfb","https://git.kernel.org/stable/c/e31546b0f34af21738c4ceac47d662c00ee6382f","https://git.kernel.org/stable/c/3f5d47eb163bceb1b9e613c9003bae5fefc0046f","https://git.kernel.org/stable/c/5a172344bfdabb46458e03708735d7b1a918c468","https://git.kernel.org/stable/c/66b317a2fc45b2ef66527ee3f8fa08fb5beab88d","https://git.kernel.org/stable/c/833775656d447c545133a744a0ed1e189ce61430","https://git.kernel.org/stable/c/e03ee2fe873eb68c1f9ba5112fee70303ebf9dfb","https://git.kernel.org/stable/c/e31546b0f34af21738c4ceac47d662c00ee6382f","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52569
|
Medium |
fixed |
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: remove BUG() after failure to insert delayed dir index item
Instead of calling BUG() when we fail to insert a delayed dir index item
into the delayed node's tree, we can just release all the resources we
have allocated/acquired before and return the error to the caller. This is
fine because all existing call chains undo anything they have done before
calling btrfs_insert_delayed_dir_index() or BUG_ON (when creating pending
snapshots in the transaction commit path).
So remove the BUG() call and do proper error handling.
This relates to a syzbot report linked below, but does not fix it because
it only prevents hitting a BUG(), it does not fix the issue where somehow
we attempt to use twice the same index number for different index items. |
["https://git.kernel.org/stable/c/2c58c3931ede7cd08cbecf1f1a4acaf0a04a41a9","https://git.kernel.org/stable/c/39c4a9522db0072570d602e9b365119e17fb9f4f","https://git.kernel.org/stable/c/d10fd53393cc5de4b9cf1a4b8f9984f0a037aa51","https://git.kernel.org/stable/c/2c58c3931ede7cd08cbecf1f1a4acaf0a04a41a9","https://git.kernel.org/stable/c/39c4a9522db0072570d602e9b365119e17fb9f4f","https://git.kernel.org/stable/c/d10fd53393cc5de4b9cf1a4b8f9984f0a037aa51"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-1075
|
Low |
|
N/A
|
A flaw was found in the Linux Kernel. The tls_is_tx_ready() incorrectly checks for list emptiness, potentially accessing a type confused entry to the list_head, leaking the last byte of the confused field that overlaps with rec->tx_ready. |
["https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ffe2a22562444720b05bdfeb999c03e810d84cbb","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ffe2a22562444720b05bdfeb999c03e810d84cbb"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-0340
|
Medium |
fixed |
|
A vulnerability was found in vhost_new_msg in drivers/vhost/vhost.c in the Linux kernel, which does not properly initialize memory in messages passed between virtual guests and the host operating system in the vhost/vhost.c:vhost_new_msg() function. This issue can allow local privileged users to read some kernel memory contents when reading from the /dev/vhost-net device file. |
["https://access.redhat.com/errata/RHSA-2024:3618","https://access.redhat.com/errata/RHSA-2024:3627","https://access.redhat.com/errata/RHSA-2024:9315","https://access.redhat.com/errata/RHSA-2025:7526","https://access.redhat.com/security/cve/CVE-2024-0340","https://bugzilla.redhat.com/show_bug.cgi?id=2257406","https://lore.kernel.org/lkml/5kn47peabxjrptkqa6dwtyus35ahf4pcj4qm4pumse33kxqpjw@mec4se5relrc/T/","https://access.redhat.com/errata/RHSA-2024:3618","https://access.redhat.com/errata/RHSA-2024:3627","https://access.redhat.com/security/cve/CVE-2024-0340","https://bugzilla.redhat.com/show_bug.cgi?id=2257406","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lore.kernel.org/lkml/5kn47peabxjrptkqa6dwtyus35ahf4pcj4qm4pumse33kxqpjw@mec4se5relrc/T/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-52478
|
Medium |
fixed |
- 4.14.328
- 4.19.297
- 5.4.259
- 5.10.199
- 5.15.136
- 6.1.59
- 6.5.8
|
In the Linux kernel, the following vulnerability has been resolved:
HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect
hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU)
races when it races with itself.
hidpp_connect_event() primarily runs from a workqueue but it also runs
on probe() and if a "device-connected" packet is received by the hw
when the thread running hidpp_connect_event() from probe() is waiting on
the hw, then a second thread running hidpp_connect_event() will be
started from the workqueue.
This opens the following races (note the below code is simplified):
1. Retrieving + printing the protocol (harmless race):
if (!hidpp->protocol_major) {
hidpp_root_get_protocol_version()
hidpp->protocol_major = response.rap.params[0];
}
We can actually see this race hit in the dmesg in the abrt output
attached to rhbz#2227968:
[ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.
[ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.
Testing with extra logging added has shown that after this the 2 threads
take turn grabbing the hw access mutex (send_mutex) so they ping-pong
through all the other TOCTOU cases managing to hit all of them:
2. Updating the name to the HIDPP name (harmless race):
if (hidpp->name == hdev->name) {
...
hidpp->name = new_name;
}
3. Initializing the power_supply class for the battery (problematic!):
hidpp_initialize_battery()
{
if (hidpp->battery.ps)
return 0;
probe_battery(); /* Blocks, threads take turns executing this */
hidpp->battery.desc.properties =
devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);
hidpp->battery.ps =
devm_power_supply_register(&hidpp->hid_dev->dev,
&hidpp->battery.desc, cfg);
}
4. Creating delayed input_device (potentially problematic):
if (hidpp->delayed_input)
return;
hidpp->delayed_input = hidpp_allocate_input(hdev);
The really big problem here is 3. Hitting the race leads to the following
sequence:
hidpp->battery.desc.properties =
devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);
hidpp->battery.ps =
devm_power_supply_register(&hidpp->hid_dev->dev,
&hidpp->battery.desc, cfg);
...
hidpp->battery.desc.properties =
devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);
hidpp->battery.ps =
devm_power_supply_register(&hidpp->hid_dev->dev,
&hidpp->battery.desc, cfg);
So now we have registered 2 power supplies for the same battery,
which looks a bit weird from userspace's pov but this is not even
the really big problem.
Notice how:
1. This is all devm-maganaged
2. The hidpp->battery.desc struct is shared between the 2 power supplies
3. hidpp->battery.desc.properties points to the result from the second
devm_kmemdup()
This causes a use after free scenario on USB disconnect of the receiver:
1. The last registered power supply class device gets unregistered
2. The memory from the last devm_kmemdup() call gets freed,
hidpp->battery.desc.properties now points to freed memory
3. The first registered power supply class device gets unregistered,
this involves sending a remove uevent to userspace which invokes
power_supply_uevent() to fill the uevent data
4. power_supply_uevent() uses hidpp->battery.desc.properties which
now points to freed memory leading to backtraces like this one:
Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08
...
Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event
Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0
...
Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30
Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0
Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0x10d/0x1d0
Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0
Sep 22 20:01:35 eric kernel: kobject_uevent_env+0x291/0x680
Sep 22 20:01:35 eric kernel:
---truncated--- |
["https://git.kernel.org/stable/c/093af62c023537f097d2ebdfaa0bc7c1a6e874e1","https://git.kernel.org/stable/c/28ddc1e0b898291323b62d770b1b931de131a528","https://git.kernel.org/stable/c/44481b244fcaa2b895a53081d6204c574720c38c","https://git.kernel.org/stable/c/ca0c4cc1d215dc22ab0e738c9f017c650f3183f5","https://git.kernel.org/stable/c/cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b","https://git.kernel.org/stable/c/dac501397b9d81e4782232c39f94f4307b137452","https://git.kernel.org/stable/c/f7b2c7d9831af99369fe8ad9b2a68d78942f414e","https://git.kernel.org/stable/c/fd72ac9556a473fc7daf54efb6ca8a97180d621d","https://git.kernel.org/stable/c/093af62c023537f097d2ebdfaa0bc7c1a6e874e1","https://git.kernel.org/stable/c/28ddc1e0b898291323b62d770b1b931de131a528","https://git.kernel.org/stable/c/44481b244fcaa2b895a53081d6204c574720c38c","https://git.kernel.org/stable/c/ca0c4cc1d215dc22ab0e738c9f017c650f3183f5","https://git.kernel.org/stable/c/cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b","https://git.kernel.org/stable/c/dac501397b9d81e4782232c39f94f4307b137452","https://git.kernel.org/stable/c/f7b2c7d9831af99369fe8ad9b2a68d78942f414e","https://git.kernel.org/stable/c/fd72ac9556a473fc7daf54efb6ca8a97180d621d"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26910
|
Medium |
fixed |
- 5.4.269
- 5.10.210
- 5.15.149
- 6.1.79
- 6.6.18
- 6.7.6
|
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: fix performance regression in swap operation
The patch "netfilter: ipset: fix race condition between swap/destroy
and kernel side add/del/test", commit 28628fa9 fixes a race condition.
But the synchronize_rcu() added to the swap function unnecessarily slows
it down: it can safely be moved to destroy and use call_rcu() instead.
Eric Dumazet pointed out that simply calling the destroy functions as
rcu callback does not work: sets with timeout use garbage collectors
which need cancelling at destroy which can wait. Therefore the destroy
functions are split into two: cancelling garbage collectors safely at
executing the command received by netlink and moving the remaining
part only into the rcu callback. |
["https://git.kernel.org/stable/c/653bc5e6d9995d7d5f497c665b321875a626161c","https://git.kernel.org/stable/c/970709a67696b100a57b33af1a3d75fc34b747eb","https://git.kernel.org/stable/c/97f7cf1cd80eeed3b7c808b7c12463295c751001","https://git.kernel.org/stable/c/a24d5f2ac8ef702a58e55ec276aad29b4bd97e05","https://git.kernel.org/stable/c/b93a6756a01f4fd2f329a39216f9824c56a66397","https://git.kernel.org/stable/c/c2dc077d8f722a1c73a24e674f925602ee5ece49","https://git.kernel.org/stable/c/c7f2733e5011bfd136f1ca93497394d43aa76225","https://git.kernel.org/stable/c/653bc5e6d9995d7d5f497c665b321875a626161c","https://git.kernel.org/stable/c/970709a67696b100a57b33af1a3d75fc34b747eb","https://git.kernel.org/stable/c/97f7cf1cd80eeed3b7c808b7c12463295c751001","https://git.kernel.org/stable/c/a24d5f2ac8ef702a58e55ec276aad29b4bd97e05","https://git.kernel.org/stable/c/b93a6756a01f4fd2f329a39216f9824c56a66397","https://git.kernel.org/stable/c/c2dc077d8f722a1c73a24e674f925602ee5ece49","https://git.kernel.org/stable/c/c7f2733e5011bfd136f1ca93497394d43aa76225","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-24448
|
Low |
fixed |
|
An issue was discovered in fs/nfs/dir.c in the Linux kernel before 5.16.5. If an application sets the O_DIRECTORY flag, and tries to open a regular file, nfs_atomic_open() performs a regular lookup. If a regular file is found, ENOTDIR should occur, but the server instead returns uninitialized data in the file descriptor. |
["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.5","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ac795161c93699d600db16c1a8cc23a65a1eceaf","https://github.com/torvalds/linux/commit/ab0fc21bc7105b54bafd85bd8b82742f9e68898a","https://github.com/torvalds/linux/commit/ac795161c93699d600db16c1a8cc23a65a1eceaf","https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://lore.kernel.org/all/67d6a536-9027-1928-99b6-af512a36cd1a%40huawei.com/T/","https://www.debian.org/security/2022/dsa-5092","https://www.debian.org/security/2022/dsa-5096","https://www.spinics.net/lists/stable/msg531976.html","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.5","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ac795161c93699d600db16c1a8cc23a65a1eceaf","https://github.com/torvalds/linux/commit/ab0fc21bc7105b54bafd85bd8b82742f9e68898a","https://github.com/torvalds/linux/commit/ac795161c93699d600db16c1a8cc23a65a1eceaf","https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://lore.kernel.org/all/67d6a536-9027-1928-99b6-af512a36cd1a%40huawei.com/T/","https://www.debian.org/security/2022/dsa-5092","https://www.debian.org/security/2022/dsa-5096","https://www.spinics.net/lists/stable/msg531976.html"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-4662
|
Medium |
fixed |
|
A flaw incorrect access control in the Linux kernel USB core subsystem was found in the way user attaches usb device. A local user could use this flaw to crash the system. |
["https://lore.kernel.org/all/20220913140355.910732567%40linuxfoundation.org/","https://lore.kernel.org/all/CAB7eexLLApHJwZfMQ=X-PtRhw0BgO+5KcSMS05FNUYejJXqtSA%40mail.gmail.com/","https://lore.kernel.org/all/20220913140355.910732567%40linuxfoundation.org/","https://lore.kernel.org/all/CAB7eexLLApHJwZfMQ=X-PtRhw0BgO+5KcSMS05FNUYejJXqtSA%40mail.gmail.com/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2023-42756
|
Medium |
fixed |
|
A flaw was found in the Netfilter subsystem of the Linux kernel. A race condition between IPSET_CMD_ADD and IPSET_CMD_SWAP can lead to a kernel panic due to the invocation of `__ip_set_put` on a wrong `set`. This issue may allow a local user to crash the system. |
["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/security/cve/CVE-2023-42756","https://bugzilla.redhat.com/show_bug.cgi?id=2239848","https://seclists.org/oss-sec/2023/q3/242","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/security/cve/CVE-2023-42756","https://bugzilla.redhat.com/show_bug.cgi?id=2239848","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GISYSL3F6WIEVGHJGLC2MFNTUXHPTKQH/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GPMICQ2HVZO5UAM5KPXHAZKA2U3ZDOO6/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/V5PDNWPKAP3WL5RQZ4RIDS6MG32OHH5R/","https://seclists.org/oss-sec/2023/q3/242"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2022-2503
|
Medium |
fixed |
|
Dm-verity is used for extending root-of-trust to root filesystems. LoadPin builds on this property to restrict module/firmware loads to just the trusted root filesystem. Device-mapper table reloads currently allow users with root privileges to switch out the target with an equivalent dm-linear target and bypass verification till reboot. This allows root to bypass LoadPin and can be used to load untrusted and unverified kernel modules and firmware, which implies arbitrary kernel execution and persistence for peripherals that do not verify firmware updates. We recommend upgrading past commit 4caae58406f8ceb741603eee460d79bacca9b1b5 |
["https://github.com/google/security-research/security/advisories/GHSA-6vq3-w69p-w63m","https://security.netapp.com/advisory/ntap-20230214-0005/","https://github.com/google/security-research/security/advisories/GHSA-6vq3-w69p-w63m","https://security.netapp.com/advisory/ntap-20230214-0005/"] |
pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel |
5.15.26.container |
linux-kernel |
CVE-2024-26743
|
Medium |
fixed |
- 5.10.211
- 5.15.150
- 6.1.80
- 6.6.19
- 6.7.7
|
In the Linux kernel, the following vulnerability has been resolved:
RDMA/qedr: Fix qedr_create_user_qp error flow
Avoid the following warning by making sure to free the allocated
resources in case that qedr_init_user_queue() fail.
-----------[ cut here ]-----------
WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
Modules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3
ghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt]
CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1
Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022
RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff
RSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286
RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016
RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600
RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80
R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0
Call Trace:
<TASK>
? show_trace_log_lvl+0x1c4/0x2df
? show_trace_log_lvl+0x1c4/0x2df
? ib_uverbs_close+0x1f/0xb0 [ib_uverbs]
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
? __warn+0x81/0x110
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
? report_bug+0x10a/0x140
? handle_bug+0x3c/0x70
? exc_invalid_op+0x14/0x70
? asm_exc_invalid_op+0x16/0x20
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
ib_uverbs_close+0x1f/0xb0 [ib_uverbs]
__fput+0x94/0x250
task_work_run+0x5c/0x90
do_exit+0x270/0x4a0
do_group_exit+0x2d/0x90
get_signal+0x87c/0x8c0
arch_do_signal_or_restart+0x25/0x100
? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs]
exit_to_user_mode_loop+0x9c/0x130
exit_to_user_mode_prepare+0xb6/0x100
syscall_exit_to_user_mode+0x12/0x40
do_syscall_64+0x69/0x90
? syscall_exit_work+0x103/0x130
? syscall_exit_to_user_mode+0x22/0x40
? do_syscall_64+0x69/0x90
? syscall_exit_work+0x103/0x130
? syscall_exit_to_user_mode+0x22/0x40
? do_syscall_64+0x69/0x90
? do_syscall_64+0x69/0x90
? common_interrupt+0x43/0xa0
entry_SYSCALL_64_after_hwframe+0x72/0xdc
RIP: 0033:0x1470abe3ec6b
Code: Unable to access opcode bytes at RIP 0x1470abe3ec41.
RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b
RDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004
RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00
R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358
R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470
</TASK>
--[ end trace 888a9b92e04c5c97 ]-- |
["https://git.kernel.org/stable/c/135e5465fefa463c5ec93c4eede48b9fedac894a","https://git.kernel.org/stable/c/5639414a52a29336ffa1ede80a67c6d927acbc5a","https://git.kernel.org/stable/c/5ba4e6d5863c53e937f49932dee0ecb004c65928","https://git.kernel.org/stable/c/7f31a244c753aacf40b71d01f03ca6742f81bbbc","https://git.kernel.org/stable/c/95175dda017cd4982cd47960536fa1de003d3298","https://git.kernel.org/stable/c/bab8875c06ebda5e01c5c4cab30022aed85c14e6","https://git.kernel.org/stable/c/135e5465fefa463c5ec93c4eede48b9fedac894a","https://git.kernel.org/stable/c/5639414a52a29336ffa1ede80a67c6d927acbc5a","https://git.kernel.org/stable/c/5ba4e6d5863c53e937f49932dee0ecb004c65928","https://git.kernel.org/stable/c/7f31a244c753aacf40b71d01f03ca6742f81bbbc","https://git.kernel.org/stable/c/95175dda017cd4982cd47960536fa1de003d3298","https://git.kernel.org/stable/c/bab8875c06ebda5e01c5c4cab30022aed85c14e6","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] |
pkg:generic/linux-kernel@5.15.26.container |